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