From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by sympa.inria.fr (Postfix) with ESMTPS id 6E54F7F249 for ; Sat, 3 Nov 2012 17:57:44 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alaincoste@club-internet.fr) identity=pra; client-ip=93.17.128.20; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alaincoste@club-internet.fr"; x-sender="alaincoste@club-internet.fr"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of alaincoste@club-internet.fr) identity=mailfrom; client-ip=93.17.128.20; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alaincoste@club-internet.fr"; x-sender="alaincoste@club-internet.fr"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp23.services.sfr.fr) identity=helo; client-ip=93.17.128.20; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="alaincoste@club-internet.fr"; x-sender="postmaster@smtp23.services.sfr.fr"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AusAABxMlVBdEYAUk2dsb2JhbABEhheFP6BBA44mAYh0IwEBAQEJCQsJFAMkghkFAQEFCAEBGTUsAQEDBQIEDQQEAQEKIQICFAEECBIcCBkIAgECAwEKh10DE6cIiEQNiVSLGWgBhSgyYQOUJo0IiAGBYw X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208,217";a="179999371" Received: from smtp23.services.sfr.fr ([93.17.128.20]) by mail1-smtp-roc.national.inria.fr with ESMTP; 03 Nov 2012 17:57:43 +0100 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2309.sfr.fr (SMTP Server) with ESMTP id 89FBF7000077 for ; Sat, 3 Nov 2012 17:57:43 +0100 (CET) Received: from Ganymede (247.171.13.109.rev.sfr.net [109.13.171.247]) by msfrf2309.sfr.fr (SMTP Server) with SMTP id 0A6FA7000062 for ; Sat, 3 Nov 2012 17:57:42 +0100 (CET) X-SFR-UUID: 20121103165743428.0A6FA7000062@msfrf2309.sfr.fr Message-ID: From: Alain Coste To: caml-list@inria.fr References: <720307009FD94454BF0EDC318177AA0D@Ganymede> Date: Sat, 3 Nov 2012 17:52:51 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.6109 X-Antivirus: avast! (VPS 121103-0, 03/11/2012), Outbound message X-Antivirus-Status: Clean Content-Type: multipart/alternative; boundary="----=_NextPart_000_0420_01CDB9EC.0AEEE060" X-Validation-by: alaincoste@club-internet.fr Subject: Re: [Caml-list] Why are modules handled differently by the interpreter and the compiler This is a multi-part message in MIME format. ------=_NextPart_000_0420_01CDB9EC.0AEEE060 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, When debugging, it's faster to #use the source files than first compiling t= hem, and then #loading the resulting .cma file. The solution #use_as_module would be fine in that it would have the same be= havior as the compiler. But IMHO preventing the compiler from encapsulating the code in module M = =3D struct ... end seems however interesting, for at least two reasons : - when I need a module at an "interior level" I write module Q =3D ... e= nd. 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. S= o the compiler creates an extra (and for me parasitic) level of encapsulati= on. Alain Coste ----- Original Message -----=20 From: Didier Cassirame=20 To: Alain Coste=20 Cc: caml-list@inria.fr=20 Sent: Saturday, November 03, 2012 4:55 PM Subject: Re: [Caml-list] Why are modules handled differently by the inter= preter and the compiler Unless you are doing something like this: module M =3D struct (* body of module *) end in file m.ml ? I used to do something like that, but it's redundant with the automatic b= undling 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 loo= k for an existing module within the current scope, or search for a file nam= ed myModule.ml, and if found, wrap its content in the following manner :=20 module MyModule =3D ( struct (* content of ml file *) end : sig=20 (* content of mli file *) end) or simply module MyModule =3D 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 e= xpect the issue which you described. Cheers, didier 2012/11/3 Didier Cassirame Hi Alain, I don't have that problem on my projects. Could you please give us a simple example of a project which exposes th= e described behaviour? Didier 2012/11/3 Alain Coste Hello, Back to a problem which I have always found annoying in OCaml. I hope= d 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 eve= rything goes wright). Now, when the project is divided in several modules, each module bein= g a structure written in a .ml file (with possibly a signature in a .mli fi= le), you can't simply use the interpreter and the compiler on the same file= s. The interpreter loads the modules with their names (say M), and you c= an refer to its identifiers with M.foo, in the standard way. The compiler adds one level of "modularity", as it encapsulates the c= ontents of the file with "module M ...end". So now its identiifers should b= e referenced as M.M.foo !! I found two possible work-arounds to this : - comment out all my top-level decarations of module before compil= ing 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 advan= tages 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 h= ave an option "-please_don't_encapsulate" (or something shorter...) for the= compiler ? Alain Coste ------=_NextPart_000_0420_01CDB9EC.0AEEE060 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Hi,
When debugging, it's faster to #use the source files th= an=20 first compiling them, and then #loading the resulting .cma file.
The solution #use_as_module would be fine in that it wo= uld=20 have the same behavior as the compiler.
 
But IMHO preventing the compiler from encapsulating the= code=20 in module M =3D struct ... end seems however interesting, for at least two = reasons=20 :
   - when I need a module at an "in= terior=20 level" I write module Q =3D ... end. Why treat the top-level in a non unifo= rm way=20 ?
   - if my module is a functor (and I often u= se=20 functors, mainly because of recursive modules) I have nevertheless to = put=20 everything in the functor. So the compiler creates an extra (and for me=20 parasitic) level of encapsulation.
 
Alain Coste
----- Original Message -----
Fro= m:=20 Didier Cassirame
Sent: Saturday, November 03, 2012 = 4:55=20 PM
Subject: Re: [Caml-list] Why are m= odules=20 handled differently by the interpreter and the compiler

Unless you are doing something like this:


module M =3D
struct
  (* body of module *)

end

in file m.ml ?

I used to do something like that, but it's redundant with the automa= tic=20 bundling of values within a ml file into a module of the same name. In ot= her=20 words, when accessing the module MyModule within some code, ocaml will lo= ok=20 for an existing module within the current scope, or search for a file nam= ed=20 myModule.ml, and if found, wrap its content in the following manner=20 : 


module MyModule =3D (
struct

  (* content of ml file *)

end : sig 
 
  (* content of mli file *)

end)


or simply

module MyModule =3D
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= =20 should expect the issue which you described.

Cheers,

didier

2012/11/3 Didier Cassirame <<= A=20 href=3D"mailto:didier.cassirame@gmail.com"=20 target=3D_blank>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 expos= es=20 the described behaviour?

Didier

2012/11/3 Alain Coste <alaincoste@club-internet.fr>
Hello,
Back to a problem which I have always found anno= ying in=20 OCaml. I hoped the version 4.0 would solve it, but it seams nothing= =20 changed..
While developping a project, It's interesting to= use=20 the interpreter (for test, debugging) AND the compiler (to have progr= am=20 run faster when everything goes wright).
Now, when the project is divided in se= veral=20 modules, each module being a structure written in a .ml file (with=20 possibly a signature in a .mli file), you can't simply use the interp= reter=20 and the compiler on the same files.
The interpreter loads the modules with their nam= es (say=20 M), and you can refer to its identifiers with M.foo, in the standard= =20 way.
The compiler adds one level of "modularity", as = it=20 encapsulates the contents of the file with "module M ...end". So=20 now its identiifers should be referenced as M.M.foo !!
I found two possible work-arounds to this=20 :
   - comment out all my top-level deca= rations=20 of module before compiling the files
          = ; =20 needs to be undone and redone every time I want to reuse the interpre= ter=20 for testing after a change in the the program
   - copy all the files in one file an= d=20 compile this unique file
          = ; =20 this process is easy to automatize, but I loose the advantages of sep= arate=20 compilation
 
Can somebody explain the rationale behind this= =20 behavior. Or, if this is only for historical and compatibil= ity=20 reasons, could it be possible to have an option=20 "-please_don't_encapsulate" (or something shorter...) for the compile= r=20 ?
 
Alain=20 Coste


------=_NextPart_000_0420_01CDB9EC.0AEEE060--