Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007589OCamltoplevelpublic2017-07-19 23:462019-01-11 09:11
Assigned To 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0007589: Improve the toplevel API
DescriptionI 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 0006704) 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.


[0] [^]

[1] [^]

[2] [^]

[3] [^]

TagsNo tags attached.
Attached Files

- Relationships
related to 0006704acknowledged Expose more compiler-libs internals in Toploop 

-  Notes
There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2017-07-19 23:46 dbuenzli New Issue
2017-09-30 16:58 xleroy Severity minor => feature
2017-09-30 16:58 xleroy Status new => acknowledged
2019-01-11 09:11 nojebar Relationship added related to 0006704

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker