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 A6F0F7F249 for ; Sat, 3 Nov 2012 16:34:26 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of didier.cassirame@gmail.com) identity=pra; client-ip=209.85.219.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of didier.cassirame@gmail.com designates 209.85.219.54 as permitted sender) identity=mailfrom; client-ip=209.85.219.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-oa0-f54.google.com) identity=helo; client-ip=209.85.219.54; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="postmaster@mail-oa0-f54.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoUBANk3lVDRVds2m2dsb2JhbABEhhe9FggjAQEBAQEICQsJFCeCHwEFIx0BGx0BAwwGAwIEBzcCAiIBEQEFARwGE4d3AQMPmzeLYk+Cd4Q4ChknDVmIdQEFDJEegRMDlXuOYxYphBI X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208";a="179995781" Received: from mail-oa0-f54.google.com ([209.85.219.54]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Nov 2012 16:34:25 +0100 Received: by mail-oa0-f54.google.com with SMTP id n9so7710411oag.27 for ; Sat, 03 Nov 2012 08:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=g/pbQnPNtRo5lMl9Xj4UMpGnj+++YA3PtsIzQbW+E8o=; b=P7BZYmIHWsiXhgY1295Shm/7YD//ZkGr9uyPSkr+UHKYIpi7HfUyeS1fBKcX40wgw4 S39mrS+y1vzOkY6Qfu2sTtlHmZGWWk8TDh18I4ZYdJtvX8WVkS7454bwYi9jQSDHk2iT IRllhYw//o/6PESzDpjo2Y+upDwFNk21yh6eOLYQhVOPmdVZFd1gs+38+rE10SUOxLDW 3H6Z4246pAPS1QnuwnES1Jdn96OFy2882mtWm6PSj9eU8JgH5jmQeeFiX3RPypXJVXRn aUPcRL7dLUiwI3hNXJLiJfk41ixez4QIume/ZLsXCOwXomZAhPzSA9xw8gK21ibI8Wfn CQGg== Received: by 10.182.172.74 with SMTP id ba10mr3929737obc.83.1351956864696; Sat, 03 Nov 2012 08:34:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.137.198 with HTTP; Sat, 3 Nov 2012 08:34:04 -0700 (PDT) In-Reply-To: <720307009FD94454BF0EDC318177AA0D@Ganymede> References: <720307009FD94454BF0EDC318177AA0D@Ganymede> From: Didier Cassirame Date: Sat, 3 Nov 2012 16:34:04 +0100 Message-ID: To: Alain Coste Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=e89a8f839f6fac02db04cd98fcef Subject: Re: [Caml-list] Why are modules handled differently by the interpreter and the compiler --e89a8f839f6fac02db04cd98fcef Content-Type: text/plain; charset=UTF-8 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 > ** > 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 > --e89a8f839f6fac02db04cd98fcef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Alain,

I don't have that problem on my projects.<= /div>
Could you please give us a simple example of a project which expo= ses the described behaviour?

Didier

2012/11/3 Alain Coste <alaincoste@clu= b-internet.fr>
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 the=20 interpreter (for test, debugging) AND the compiler (to have program run fas= ter=20 when everything goes wright).
Now,=C2=A0when the project is divided=C2=A0in several modules,= =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 the=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=C2=A0its=20 identiifers should be referenced as M.M.foo !!
I found two possible work-arounds to this :
=C2=A0=C2=A0 - comment out all my top-level decarations of=20 module before compiling the files
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 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
=C2=A0=C2=A0 - copy all the files in one file and compile this= =20 unique file
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 this=20 process is easy to automatize, but I loose the advantages of separate=20 compilation
=C2=A0
Can somebody explain the rationale behind this=20 behavior.=C2=A0Or,=C2=A0if this is only for historical and compatibility=20 reasons, could it be possible to have an option "-please_don't_enc= apsulate" (or=20 something shorter...) for the compiler ?
=C2=A0
Alain Coste

--e89a8f839f6fac02db04cd98fcef--