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

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

[Alain Coste]

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

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: 2460 bytes --]

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

[Didier Cassirame]

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

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: 2636 bytes --]

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

[Didier Cassirame]

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

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

[Didier Cassirame]

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

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

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

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

[Alain Coste]

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

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




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

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

[Gabriel Scherer]

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

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

[Gerd Stolpmann]

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

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

[Grégoire Henry]

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

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

Well, here it is:

  $ ocamlmktop -o myocaml mod_use.ml
  $ cat test.ml
  let x = 53
  $ ./myocaml
        OCaml version 4.00.1

  # #mod_use "test.ml";;
  module Test : sig val x : int end
  # Test.x;;
  - : int = 53

Regards,
Grégoire

[-- Attachment #2: mod_use.ml --]
[-- Type: text/plain, Size: 935 bytes --]


open Parsetree

let filter_out_directives lb =
  List.concat
    (List.map
       (function
         | Ptop_def s -> s
         | Ptop_dir _ -> [])
       lb)

let parse_mod_use_file parse_use_file name lb =
  let modname =
    String.capitalize (Filename.chop_extension (Filename.basename name))
  in
  let items = filter_out_directives (parse_use_file lb) in
  [ Ptop_def
      [{pstr_desc =
        Pstr_module ( Location.mknoloc modname ,
                      { pmod_desc = Pmod_structure items;
                        pmod_loc = Location.none } );
        pstr_loc = Location.none }] ]

let dir_mod_use name =
  let parse_use_file = !Toploop.parse_use_file in
  Toploop.parse_use_file := parse_mod_use_file parse_use_file name;
  ignore (Toploop.use_file Format.std_formatter name);
  Toploop.parse_use_file := parse_use_file

let () =
  Hashtbl.add Toploop.directive_table "mod_use"
    (Toploop.Directive_string dir_mod_use)

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

[Gerd Stolpmann]

Cool. I suggest you submit this as a patch.

One minor error, though: In case of an exception Toploop.parse_use_file  
should also be reset.

Gerd

Am 05.11.2012 03:30:55 schrieb(en) Grégoire Henry:
> > 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?
> 
> Well, here it is:
> 
>   $ ocamlmktop -o myocaml mod_use.ml
>   $ cat test.ml
>   let x = 53
>   $ ./myocaml
>         OCaml version 4.00.1
> 
>   # #mod_use "test.ml";;
>   module Test : sig val x : int end
>   # Test.x;;
>   - : int = 53
> 
> Regards,
> Grégoire
> 
> --
> 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
------------------------------------------------------------

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

[Alain Coste]

Hello
Thank you for your answers, and for the patch. Cool for debugging without 
modifying the files !

Alain Coste

----- Original Message ----- 
From: "Grégoire Henry" <henry@pps.univ-paris-diderot.fr>
To: "Gerd Stolpmann" <info@gerd-stolpmann.de>
Cc: "Alain Coste" <alaincoste@club-internet.fr>; <caml-list@inria.fr>
Sent: Monday, November 05, 2012 3:30 AM
Subject: Re: [Caml-list] Why are modules handled differently by the 
interpreter and the compiler


>> 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?
>
> Well, here it is:
>
>  $ ocamlmktop -o myocaml mod_use.ml
>  $ cat test.ml
>  let x = 53
>  $ ./myocaml
>        OCaml version 4.00.1
>
>  # #mod_use "test.ml";;
>  module Test : sig val x : int end
>  # Test.x;;
>  - : int = 53
>
> Regards,
> Grégoire
>
> -- 
> 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