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

Open
vicuna opened this issue Jul 19, 2017 · 6 comments
Open

Improve the toplevel API #7589

vicuna opened this issue Jul 19, 2017 · 6 comments

Comments

@vicuna
Copy link

@vicuna 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.

  1. 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].

  2. 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.

  3. 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 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.

  4. 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.

  5. 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)

dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Feb 29, 2020
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.
@github-actions
Copy link

@github-actions github-actions bot commented May 7, 2020

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.

@github-actions github-actions bot added the Stale label May 7, 2020
@trefis
Copy link
Contributor

@trefis trefis commented May 7, 2020

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?

@jeremiedimino
Copy link
Contributor

@jeremiedimino jeremiedimino commented May 7, 2020

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.

@dbuenzli
Copy link
Contributor

@dbuenzli dbuenzli commented May 7, 2020

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.

@coetry
Copy link

@coetry coetry commented Aug 25, 2020

Improving the toplevel API experience would be excellent. Particularly the point about loading modules on the fly without explicit #require statements sounds amazing.

dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 29, 2020
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.
dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 29, 2020
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.
dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 29, 2020
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.
dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 29, 2020
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.
dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 30, 2020
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.
dbuenzli added a commit to dbuenzli/ocaml that referenced this issue Sep 30, 2020
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).
@github-actions
Copy link

@github-actions github-actions bot commented Aug 27, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants