Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the toplevel API #7589

vicuna opened this Issue Jul 19, 2017 · 0 comments


None yet
1 participant
Copy link

vicuna commented Jul 19, 2017

Original bug ID: 7589
Reporter: @dbuenzli
Status: acknowledged (set by @xavierleroy on 2017-09-30T14:58:15Z)
Resolution: open
Priority: normal
Severity: feature
Category: toplevel
Related to: #6704
Monitored by: @nojb @gasche @diml @dbuenzli

Bug description

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 [0].

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 [1], 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 utop-full but it means that what happens in #use has to be changed (load of ocamlcommon.cma has to be prevented) and it is difficult to detect utop-full...

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 [2] 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 [3]. This should eschew the need for toplevel support libraries (ocamlfind) or files (odig convention) in 98% of the cases.




b0-system/odig#10 (comment)

ocaml/dune#114 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.