ocaml
feature: load modules in the repl
This PR introduces the $ dune ocaml top-level src/module.ml command. The purpose of this command is to load a particular module for interactive development. The way it differs from the other toplevel commands is that it only build the minimal amount needed to load a particular module and then it evaluates the module's source with #use. The point of this is to avoid sealing the module with the mli and thereby allowing interactive development with all the private parts of the module.
@ulugbekna this should work nicely for vscode
What's the relation between this PR and
dune top?
Just updated the PR description.
I guess this needs documentation, right?
Do you think we need something in the online manual or is the man page enough?
I guess this needs documentation, right?
Do you think we need something in the online manual or is the man page enough?
Leaving this to doc experts, but I see dune utop appears in usage.rst , so maybe worth mentioning it too?
Sidenote, dune ocaml subcommands are not very discoverable. So I agree that a quick mention would be useful:
% dune ocaml
dune ocaml: is a command group and requires a command argument.
Usage: dune ocaml [OPTION]...
Try `dune ocaml --help' or `dune --help' for more information.
% dune ocaml --help=plain
NAME
dune-ocaml
SYNOPSIS
dune ocaml [OPTION]...
OPTIONS
--help[=FMT] (default=auto)
Show this help in format FMT. The value FMT must be one of `auto',
`pager', `groff' or `plain'. With `auto', the format is `pager` or
`plain' whenever the TERM env var is `dumb' or undefined.
--version
Show version information.
Does the work with dialects?
Let me give this a try. Although I would say that this issue isn't blocking the PR.
Does it make sense to consider a utop version of the command which would launch utop directly, in the same way as dune utop does?
We could add this if there's demand for it. I personally preferred the approach of building the toplevel binary ourself, but Jeremie liked doing everything through directives more.
Also in the same direction, if indeed we have both "top" and "utop" variations of the command, does it make sense to extend those commands, intead of dune ocaml?
I would say that we should deprecate dune top and dune utop and stick to the dune ocaml subcommand for all this stuff.
There's still a few issues with this PR btw:
- It doesn't evaluate
-open Alias__module__in the toplevel - It doesn't load the warnings flags from the stanza.
- This is the biggest problem:
#directory $stanza/obj_dircontains stale artifacts that lead to some inconsistent assumptions issues.
The first two problems can be fixed with additional directives. Although if we went for the approach of building the toplevel (like dune utop) we wouldn't even this stuff :/
To solve the 3rd problem, we must prepare an object directory free of stale artifacts. The simplest way to do that is just to copy the objects into some temp dir and use that. A more clever way is to introduce rules for each modules that will setup the subdirectory with only the relevant artifacts.
@rgrinberg I was about to include it into 3.4 even with the limitations you mentioned but happy to postpone to 3.5.
The issue with the stale artifacts makes this feature not very ergonomic at the moment unfortunately. I'd rather solve this issue first
Sidenote, dune ocaml subcommands are not very discoverable. So I agree that a quick mention would be useful:
That's actually due to a bug with our fork of cmdliner. Once we update our version of cmdliner, the per command docs should appear.