This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
Improve the toplevel API #7589
Comments
This will be used by {T,Opt}opmain. The signature of this function is
largely suboptimal. But we take care not to introduce any new type
dependency like Lib.Name.t because this module is used and visible by
downstream packages while those may not have have access to
`compiler-libs`'s module because of the expunge process. Maybe once
all this will be improved see ocaml#7589.
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
|
I don't think much has changed since @dbuenzli wrote that list, I guess my only question(s) (wrt. the staleness of this issue is): does someone care? Is some work planned on this issues? @dbuenzli, @jeremiedimino: AFAIK you're the only two person to have shown interest in the toplevel in the recent past. What do you say? |
|
With @NathanReb we are planning to do some work on the toplevel API as part of the mdx work. That should solve at least 4. The expunge problem feels like it would deserve its own ticket. |
|
The problems stills exists, the toplevel experience is still crap. Someone took the time to write down what the problems are but feel free to close this. |
|
Improving the toplevel API experience would be excellent. Particularly the point about loading modules on the fly without explicit |
We expose a function to access the information in the Topdir API since this partially solves point 2 of ocaml#7589. A small change to misc.mli is needed to avoid exposing Misc in {T,Opt}optdirs interfaces.
This will be used by {T,Opt}opmain. The signature of this function is
largely suboptimal. But we take care not to introduce any new type
dependency like Lib.Name.t because this module is used and visible by
downstream packages while those may not have have access to
`compiler-libs`'s module because of the expunge process. Maybe once
all this will be improved see ocaml#7589.
We expose a function to access the information in the Topdir API since this partially solves point 2 of ocaml#7589. A small change to misc.mli is needed to avoid exposing Misc in {T,Opt}optdirs interfaces.
This will be used by {T,Opt}opmain. The signature of this function is
largely suboptimal. But we take care not to introduce any new type
dependency like Lib.Name.t because this module is used and visible by
downstream packages while those may not have have access to
`compiler-libs`'s module because of the expunge process. Maybe once
all this will be improved see ocaml#7589.
We expose a function to access the information in the Topdir API since this partially solves point 2 of ocaml#7589. A small change to misc.mli is needed to avoid exposing Misc in {T,Optt}optdirs interfaces.
In particular this takes into account the libraries that were
fully linked in the toplevel executable via `-linkall`.
Note that in {T,Optt}opdirs module we take care not to expose `Lib`
since these modules are visible in the repl but `Lib` won't be because
of the expunge process (see ocaml#7589).
|
This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc. |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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 Expose more compiler-libs internals in Toploop #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-fullbut it means that what happens in #use odig.top 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 pkg_top_init.ml files (odig convention) in 98% of the cases.
Thanks.
--
[0] https://github.com/dbuenzli/odig/blob/0df18d782f219237de917bbcc149fab7d393ac75/src/byte/odig_ocamltop.ml#L9-L28
[1] http://erratique.ch/software/odig/doc/Odig.html#VALload
[2] b0-system/odig#10 (comment)
[3] ocaml/dune#114 (comment)
The text was updated successfully, but these errors were encountered: