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

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

One reason to treat .ml files as modules/structures implicitly is that
it neatly explain the .ml / .mli dichotomy : the .mli is the interface
of the module, so the .mli/.ml check is described exactly as a
semantic concept existing in the internal language. On the contrary if
you had .ml simply be "bunches of phrases", you would have to define
an ad-hoc semantics for signature matching (which would plausibly be
"encapsulate in a module and a module signature, check the interfaces
match, then include the module"). Modules are just a good match for
"bunch of phrases packed together", because modelling this is exactly
their justification.

Furthermore, your two reasons are of the form "this abstraction is not
enough for X", not "this abstraction is problematic because of X". If
we removed the "compilation units are implicit modules" convention
this wouldn't help with any of your point. In a different direction, I
think it could be useful to consider language changes¹ to solve the
second problem you mention : the difficulty of describing a functor in
a modular way.
OcamlPro had a prototype approach to attack this problem
  http://www.ocamlpro.com/blog/2011/08/10/ocaml-pack-functors.html
and we may discuss it again in the future.

¹: of course, "consider language changes" does not necessarily mean to
actually change the language, as doing nothing at all is sometimes the
best solution (as proposed in the recent "Why should I use .mli files"
discussion). We would be in an awful shape if each back pain of an
OCaml programmer had resulted in a new language feature.

On Sat, Nov 3, 2012 at 5:52 PM, Alain Coste <alaincoste@club-internet.fr> wrote:
> Hi,
> When debugging, it's faster to #use the source files than first compiling
> them, and then #loading the resulting .cma file.
> The solution #use_as_module would be fine in that it would have the same
> behavior as the compiler.
>
> But IMHO preventing the compiler from encapsulating the code in module M =
> struct ... end seems however interesting, for at least two reasons :
>    - when I need a module at an "interior level" I write module Q = ... end.
> Why treat the top-level in a non uniform way ?
>    - if my module is a functor (and I often use functors, mainly because of
> recursive modules) I have nevertheless to put everything in the functor. So
> the compiler creates an extra (and for me parasitic) level of encapsulation.
>
> Alain Coste
>
> ----- Original Message -----
> From: Didier Cassirame
> To: Alain Coste
> Cc: caml-list@inria.fr
> Sent: Saturday, November 03, 2012 4:55 PM
> Subject: Re: [Caml-list] Why are modules handled differently by the
> interpreter and the compiler
>
> Unless you are doing something like this:
>
>
> module M =
> struct
>   (* body of module *)
>
> end
>
> in file m.ml ?
>
> I used to do something like that, but it's redundant with the automatic
> bundling of values within a ml file into a module of the same name. In other
> words, when accessing the module MyModule within some code, ocaml will look
> for an existing module within the current scope, or search for a file named
> myModule.ml, and if found, wrap its content in the following manner :
>
>
> module MyModule = (
> struct
>
>   (* content of ml file *)
>
> end : sig
>
>   (* content of mli file *)
>
> end)
>
>
> or simply
>
> module MyModule =
> struct
>
>   (* content of ml file *)
>
> end
>
> if no mli file is found.
>
> In this case, if you are c&p the content of your files, then you should
> expect the issue which you described.
>
> Cheers,
>
> didier
>
> 2012/11/3 Didier Cassirame <didier.cassirame@gmail.com>
>>
>> Hi Alain,
>>
>> I don't have that problem on my projects.
>> Could you please give us a simple example of a project which exposes the
>> described behaviour?
>>
>> Didier
>>
>> 2012/11/3 Alain Coste <alaincoste@club-internet.fr>
>>>
>>> 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 !!
>>> 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 ?
>>>
>>> Alain Coste
>>
>>
>