AW: [Caml-list] Why are modules handled differently by the interpreter and the compiler

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Am 03.11.2012 16:21:49 schrieb(en) Alain Coste:
> Hello,
> Back to a problem which I have always found annoying in OCaml. I  
> hoped the version 4.0 would solve it, but it seams nothing changed..
> While developping a project, It's interesting to use the interpreter  
> (for test, debugging) AND the compiler (to have program run faster  
> when everything goes wright).
> Now, when the project is divided in several modules, each module  
> being a structure written in a .ml file (with possibly a signature in  
> a .mli file), you can't simply use the interpreter and the compiler  
> on the same files.
> The interpreter loads the modules with their names (say M), and you  
> can refer to its identifiers with M.foo, in the standard way.
> The compiler adds one level of "modularity", as it encapsulates the  
> contents of the file with "module M ...end". So now its identiifers  
> should be referenced as M.M.foo !!

So far I understand that you load modules with "#use" into the toploop,  
and that you have files m.ml that also have a "module M = struct ...  
end" in it. Thus a definition foo is seen by the compilers as M.M.foo.  
This is how it is supposed to be. Normally you would not write the  
"module M" construction within a file m.ml.

Now, the outer level of module encapsulation goes away when you just  
"#use" the file. Why is that?  Basically, it is unsupported to load  
modules directly from sources - what you really do with #use is to load  
source files.

Note that you can also load compiled modules into the toploop - using  
#load, and this works for files with suffixes .cmo and .cma, and now  
the implicit module abstraction coming from the file is preserved.

> I found two possible work-arounds to this :
>    - comment out all my top-level decarations of module before  
> compiling the files
>             needs to be undone and redone every time I want to reuse  
> the interpreter for testing after a change in the the program
>    - copy all the files in one file and compile this unique file
>             this process is easy to automatize, but I loose the  
> advantages of separate compilation
> 
> Can somebody explain the rationale behind this behavior. Or, if this  
> is only for historical and compatibility reasons, could it be  
> possible to have an option "-please_don't_encapsulate" (or something  
> shorter...) for the compiler ?

So, the normal development cycle is this:

  - compile your project
  - #load the resulting .cma file into a toploop (if you need many #load
    directives put them into a file, and #use that)
  - test it there

This preserves the modules. #use is really of limited use - personally  
I sometimes put helpers for testing into a seperate file and #use that.

What could be implemented as an extension is a #use_as_module directive  
that adds the implicit module. This could be in deed useful for  
debugging, especially when it overlooks the mli file if present - if  
you #load, the definition hiding of the mli file takes place, and you  
cannot see unexported definitions anymore. Of course, this is sometimes  
in the way when you test things out.

Now that compiler-libs is installed this extension could probably even  
be implemented outside the compiler. Anyone up for it?

Gerd


> 
> Alain Coste
> --
> 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



-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
------------------------------------------------------------