Re: [Caml-list] Some questions about building OCaml programs

[Gabriel Scherer <gabriel.scherer@gmail.com>]

Sorry for not respecting the format of your questions.

I don't think your perception of "A" being "sticking to the paradigm
of the toplevel" is correct; #use is more like a hack that is very
rarely used. I call #use "topfind";; routinely, to enable the
ocamlfind goodness from the toplevel: #use seems fine for
toplevel-specific scripting/configuration rather than actually being
part of the semantics of an OCaml program. Besides that, I personally
never use #use directives when using the toplevel, and I don't think
they're any form of "paradigm".

Question 1: This way of doing it (explicit "module ..." wrapping in
files) is wrong. It's working around something else, and you shouldn't
do that and expect the OCaml tools to support this use-case in any
other way that the semantics given to such code by the language: a
module (named after the name of the source file) containing a
submodule.

Question 2: I'm not sure I understand the question but I don't think
failures are global. When #use-ing, the source file argument is first
parsed as a series of toplevel sentences, then each sentence is
executed, essentially as its own bare compilation unit. This creates a
different between parsing errors and errors that happen later: parsing
errors will make the whole #use fail, and later errors will only fail
to execute the sentence but keep on executing the others, just as if
you typed them one after the other in the toplevel.
You may be asking for a different mode that parses sentences and
execute them on the fly (to avoid global syntax failure). Feel free to
open a feature request on the bugtracker (
http://caml.inria.fr/mantis/ ), knowing that working patches are
better than simple request, but that maintainers are often (rightly)
quite conservative about backward-compatibility and avoiding adding
bug and increasing maintenance costs by changing code that maybe
doesn't really need to be changed.

Question 3: the semantics model of OCaml tools is that a file foo.ml
is understood as a compilation unit who, from the point of view of the
OCaml language, is a module named Foo. Tools manipulate "compilation
units" and source code sees "modules". The reason for this choice is
that "module" is a natural semantic concept for "bunches of structure
items", which is what source files are. OCaml tools maintain this
consistent view and I don't see any reason not to (if you want to
"strip the module layer" out of a set of definitions, just use the
"open M" construction to be able to access them without qualifying by
the module name). I'm not sure what your use case is, and why it
wouldn't be satisfied by explicit "open" (maybe scripted somewhere),
but they would have to be very compelling to result in a language
change that makes thing more complex by adding a choice between two
different semantics for compilation units under certain circumstances.

Question 4: "ocaml -init foo.ml" may be what you are after. The
phrases in foo.ml will be executed from the toplevel, but silently
(you don't get the usual textual feedback where declaration interfaces
are printed). Tweaking toplevel setting from foo.ml may allow to
change this if you want, I'm not familiar with these aspects.

I think there are genuinely interesting programming language design
questions raised by interactive use-cases, but I'm not sure OCaml is
the best candidate for semantics changes aimed at interactive use.
Regarding more down-to-earth interface questions, the HOL-light people
have used the ocaml toplevel as their main user interface and they
certainly have had some requests of this kind.

On Sun, Nov 18, 2012 at 3:43 PM, "Mark" <mark@proof-technologies.com> wrote:
> on 18/11/12 9:33 AM, Gabriel Scherer <gabriel.scherer@gmail.com> wrote:
>> The long answer is part of this discussion of two weeks ago, started
>> by someone with essentially the same question:
>> https://sympa.inria.fr/sympa/arc/caml-list/2012-11/msg00024.html
>
> I didn't realise this.  Thanks.  Though that thread is only about my
> Question 1.
>
>> The short answer is that you should compile your files and use #load
>> "file.cmo";;, rather than directly #use "file.ml" which has a
>> different, less modular semantics.
>
> But what I want to do is A (i.e. stick completely within the paradigm of
> using the interpreter, without touching the 'ocamlc') and B (i.e. stick
> completely with the paradigm of the compiler, without touching the
> interpreter) with the same source code files.  Using #load is a sort of
> messy compromise between the two.  And so is a script to preprocess these
> files to chuck "outer syntax" around module bodies.  I don't really see the
> problem with enhancing 'ocamlc' to have an option for dealing with outer
> syntax.  The last part of my Question 1 asks whether it would be better to
> have an option to cater for what I want.  Do you agree that it would be
> beter to have such an option, do you think it would make no difference, or
> do you think it would actually make things worse?
>
> Mark.
>
>
>> On Sun, Nov 18, 2012 at 9:01 AM, "Mark" <mark@proof-technologies.com>
> wrote:
>>> Hi,
>>>
>>> I've got a series of interrelated questions about alternatives and
>>> what appear to be limitations in building OCaml programs.  I hope you
>>> don't mind me packaging these together into one thread.
>>>
>>> I am writing a program that runs in the OCaml toplevel, implemented as
>>> a series of modules.  Each module has a .mli source code file for its
>>> interface and a .ml source code file for its body.
>>>
>>> I would like to be able to do both of the following:
>>> A. Process the program interactively in the toplevel (using #use
>>> directives);
>>> B. Build the program into an extended toplevel (using 'ocamlc' to
>>> create .cmi and .cmo files, followed by 'ocamlmktop').
>>>
>>> QUESTION 1
>>>
>>> It seems that for A, each .mli file must have "outer module syntax",
>>> e.g. something like:
>>>    "module type <Sig> = sig <interface> end"
>>> and each .ml file must have something like:
>>>    "module <Mod> : <Sig> = struct <body> end".
>>>
>>> And it seems that for B, 'ocamlc' requires each .mli file not to have
>>> the outer syntax, i.e. to be of the form:
>>>    "<interface>"
>>> and similarly each .ml file to be of the form:
>>>    "<body>".
>>>
>>> Am I correct?  If so, why can't 'ocamlc' deal with the form for files
>>> acceptable for A?  Wouldn't it be better to have the option of
>>> 'ocamlc' allowing the syntax required for A?
>>>
>>> QUESTION 2
>>>
>>> This is just about A.  I want to have a file "main.ml" which has #use
>>> directives for all the module files, and to call "main.ml" itself
>>> using a #use directive.  It seems that a #use directive fails if there
>>> is an error in the given source code file, but not if the source code
>>> file itself contains #use directives (like my "main.ml") that fail.
>>> Why is this?  Wouldn't it be better all failures bubbled to the top?
>>>
>>> QUESTION 3
>>>
>>> This is just about B.  It seems the 'ocamlmktop' command will only
>>> incorporate what are, ultimately, modules into the toplevel.  Am I
>>> correct?  Why can't it also incorporate directives and top level
>>> definitions?
>>>
>>> QUESTION 4
>>>
>>> The 'ocaml' command can be called without a file argument, in which
>>> case a toplevel interactive session is started.  It can also be called
>>> with a source code file argument, in which case the source code file
>>> is processed through the toplevel and then the session is terminated.
>>> Is there a way to process a file but then not terminate and instead
>>> enter an interactive toplevel session (with the source code file
>>> incorporated)?
>>>
>>> Mark.
>>>
>>> --
>>> Caml-list mailing list.  Subscription management and archives:
>>> https://sympa.inria.fr/sympa/arc/caml-list
>>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>>
>>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs