Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve the toplevel API #7589
Original bug ID: 7589
I think that there is agreement among the persons trying to improve the toplevel experience of OCaml that the toplevel API as it exists is largely unhelpful.
The purpose of this issue is to highlight a few salient point that I hope can be gradually fixed at a certain point in time. I decided not to open one issue for each of these things as I think it's better to have a global view on these problems.
The expunge process (PR #6704) remains hugely problematic with anything that tries to improve the toplevel experience using compiler libs. I'm not sure whether it should exist or not but it's quite clear that at least the Toploop API should be able to export enough things so that it can be used in the toplevel without having to resort to this terrible kind of thing .
In the toploop API a mecanism is lacking to track which objects were already loaded or which paths included. It seems that each one of ocamlfind/utop/odig is maintaining its own incomplete datastructures for this. I think it should be provided by the Toploop API itself.
4.04 introduced a nice mecanism in the typechecker's Env module to load cmis on demand that combined with odig's module dependency resolution , allows to completely eschew the need to #require libraries (or need for ocamlfind in the toplevel for most of the cases). Just type a phrase with the module you want and it gets loaded on the fly. This was experimentally made to work in utop-full, but is impossible to provide either in ocaml and utop because of the expunge process which hides Env; of course loading ocamlcommon.cma doesn't help as it provides us with a new Env that is unrelated to the one the toplevel is using. It can be provided in
Basically we have something very nice from a UX perspective almost reachable but it's not because of the dire state of the toploop business. One option here would be to make the needed Env hook available via the Toploop API itself (provided dependencies allow this). See here  if you are interested fore more details about this.
The native Toploop API is basically identical to the bytecode one but lives in a different module name. This means that the burden of separating code paths for the two APIs is put on each of the clients of the Toploop API which is absurd and leads to code duplication. The two distinguished APIs should be unified under the same name with a boolean or variant in the API indicating which one you are dealing with (to e.g. adapt the suffixes of loaded compilation objects) and be provided as library variants (similar to thread and vm-thread) against one should link.
It would be nice to implement Jérémie Dimino's idea about installing toplevel printers via annotations . This should eschew the need for toplevel support libraries (ocamlfind) or pkg_top_init.ml files (odig convention) in 98% of the cases.