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

[Alain Coste <alaincoste@club-internet.fr>]

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