Sorry,

I meant that it would declare the content of a ml file as described below,
if it is provided to be compilation command. ocaml (or ocamlc) will not
search for the file by itself, of course.

didier

2012/11/3 Didier Cassirame <didier.cassirame@gmail.com>

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