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

[Didier Cassirame <didier.cassirame@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2684 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4401 bytes --]