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 mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by sympa.inria.fr (Postfix) with ESMTPS id 04C447F249 for ; Sat, 3 Nov 2012 16:21:54 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alaincoste@club-internet.fr) identity=pra; client-ip=93.17.128.22; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="alaincoste@club-internet.fr"; x-sender="alaincoste@club-internet.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of alaincoste@club-internet.fr) identity=mailfrom; client-ip=93.17.128.22; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="alaincoste@club-internet.fr"; x-sender="alaincoste@club-internet.fr"; x-conformance=sidf_compatible Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp23.services.sfr.fr) identity=helo; client-ip=93.17.128.22; receiver=mail4-smtp-sop.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: AucAAD02lVBdEYAWlGdsb2JhbABEi1agQQOXGyMBAQEBCQsJCRQDJIIZFAEBTiwCCAIICRQ5AQQaRQIBAgMBh32YRaB9kVxhA6kv X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208,217";a="161255582" Received: from smtp23.services.sfr.fr ([93.17.128.22]) by mail4-smtp-sop.national.inria.fr with ESMTP; 03 Nov 2012 16:21:53 +0100 Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2317.sfr.fr (SMTP Server) with ESMTP id 0BA33700006D for ; Sat, 3 Nov 2012 16:21:53 +0100 (CET) Received: from Ganymede (247.171.13.109.rev.sfr.net [109.13.171.247]) by msfrf2317.sfr.fr (SMTP Server) with SMTP id AB7D37000064 for ; Sat, 3 Nov 2012 16:21:52 +0100 (CET) X-SFR-UUID: 20121103152152702.AB7D37000064@msfrf2317.sfr.fr Message-ID: <720307009FD94454BF0EDC318177AA0D@Ganymede> From: Alain Coste To: caml-list@inria.fr Date: Sat, 3 Nov 2012 16:21:49 +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_03CF_01CDB9DF.53708120" X-Validation-by: alaincoste@club-internet.fr Subject: [Caml-list] Why are modules handled differently by the interpreter and the compiler This is a multi-part message in MIME format. ------=_NextPart_000_03CF_01CDB9DF.53708120 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 t= est, debugging) AND the compiler (to have program run faster when everythin= g goes wright). Now, when the project is divided in several modules, each module being a st= ructure written in a .ml file (with possibly a signature in a .mli file), y= ou 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 ref= er to its identifiers with M.foo, in the standard way. The compiler adds one level of "modularity", as it encapsulates the content= s of the file with "module M ...end". So now its identiifers should be refe= renced as M.M.foo !! I found two possible work-arounds to this : - comment out all my top-level decarations of module before compiling th= e files needs to be undone and redone every time I want to reuse the in= terpreter 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 onl= y for historical and compatibility reasons, could it be possible to have an= option "-please_don't_encapsulate" (or something shorter...) for the compi= ler ? Alain Coste= ------=_NextPart_000_03CF_01CDB9DF.53708120 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello,
Back to a problem which I have always found annoying in= OCaml.=20 I hoped the version 4.0 would solve it, but it seams nothing=20 changed..
While developping a project, It's interesting to use th= e=20 interpreter (for test, debugging) AND the compiler (to have program run fas= ter=20 when everything goes wright).
Now, when the project is divided in several m= odules,=20 each module being a structure written in a .ml file (with possibly a signat= ure=20 in a .mli file), you can't simply use the interpreter and the compiler on t= he=20 same files.
The interpreter loads the modules with their names (say= M),=20 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 now i= ts=20 identiifers should be referenced as M.M.foo !!
I found two possible work-arounds to this :
   - comment out all my top-level decarations= of=20 module before compiling the files
           = needs=20 to be undone and redone every time I want to reuse the interpreter for test= ing=20 after a change in the the program
   - copy all the files in one file and compi= le this=20 unique file
           = this=20 process is easy to automatize, but I loose the advantages of separate=20 compilation
 
Can somebody explain the rationale behind this=20 behavior. Or, if this is only for historical and compatibility=20 reasons, could it be possible to have an option "-please_don't_encapsulate"= (or=20 something shorter...) for the compiler ?
 
Alain Coste
------=_NextPart_000_03CF_01CDB9DF.53708120--