[it’s possible that what I’m writing below is incorrect and has been superseded by new developments in the Ocaml tooling. But I kinda doubt it.]
I’m not sure what you’re asking, but … depending on what you mean by “reload”, it’s possible that what you’re asking for is impossible.
(1) Ocaml is a lexically-scoped language, and adheres pretty carefully to the “don’t modify things that are not marked as mutable”.
(2) module-level bindings (name-bindings in general) are not mutable
(3) So perhaps what you mean is that you want to load some code (e.g. a “.cmo”), modify/recompile, and load that “.cmo” again? This is possible (or at least, I’ve done it with “.ml” files, e.g.
# #use "foo.ml" ;;
several times in a single toplevel
ocaml instance. It’s been so long since I did it with a “.cmo” that I forget whether that works, but I’d be surprised if it didn’t. And of course, I’d expect that you could load a bunch of code that way in series.
(4) BUT this is just loading new code, that shadows/obscures previously-loaded code with the same names, right? It’s not/NOT “reloading”. If what you want is (e.g.) to load modules A,B,C, then modify module A and somehow cause it to be reloaded so that B,C “automatically” see the new version of A, I think you’re out-of-luck.
This is a basic principle of ML-like languages, at play here. The idea is, instead of making it possible to “persistently update” some complex dependency-graph of code and objects, ML-like languages try to make it efficient to bootstrap that graph from scratch.
(5) I should add that of course all the tooling I know of, supports this model. If you were to load an ocamlfind module, then modify/reinstall it, and try to load it again, I can’t imagine any results other than chaos … complete chaos.
(6) BTW, there are other languages that support such recompile/reloading. There are always significant limitations (e.g. in Java, Erlang) and you can always get yourself wedged, sometimes with great ease and hilarity ensuing (e.g. Java). This stuff has existed since the days of LISP, and always with interesting caveats. Which is why, I suspect, the ML languages just don’t bother.