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 8BFC57F249 for ; Sat, 3 Nov 2012 16:58:35 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of didier.cassirame@gmail.com) identity=pra; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="didier.cassirame@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of didier.cassirame@gmail.com designates 209.85.214.182 as permitted sender) identity=mailfrom; client-ip=209.85.214.182; receiver=mail4-smtp-sop.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 (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f182.google.com) identity=helo; client-ip=209.85.214.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="didier.cassirame@gmail.com"; x-sender="postmaster@mail-ob0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABAN8+lVDRVda2kGdsb2JhbABEhhe9FggjAQEBAQkJDQcUBCOCHgEBBAEjHQEbHQEDAQsGAwILNwICIQEBEQEFARwGE4d3AQMJBps2i2JPgneEOQoZJw1ZiHUBBQyLDWmFKIETA5QmgVWLM4MwFimEEoFj X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208";a="161257082" Received: from mail-ob0-f182.google.com ([209.85.214.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Nov 2012 16:58:30 +0100 Received: by mail-ob0-f182.google.com with SMTP id wc20so7654862obb.27 for ; Sat, 03 Nov 2012 08:58:28 -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=xGuQ9C6X8N3kuWSmqDnbtuBunAW7CYL5qB1m6vsIotM=; b=EyuYyZl0qpbG9fIsWmf2ogP1ZeFnr4/4QXXhdUokA8RssfzIBV37CrvPW0CJNrEgfn kDkoE9c8sw8opQYD6luYbLkF01z13Lv/4qhFzgDsZ40UddeCcsNnn/aYz8bgZeoNH8bx 8xJM8Xm8L1Pl9O/a3XPvKVrlol67VcnOJXiiFn7AMr+TmhK/+NPkRvhKHTlkq2+mp21j 53+/y3nfAwY2aJsF8B7BwZqAI9Q9NaoGV5f3So5xy8yE/f1udvPNFBfFMniO63PO9lIW zQq4+HK4AVUS1wAcJrpleZ7kFzuq50H4P3JLvUf/d5TGYChq7lIVUBM+66OWzQfPcMMe s2Pw== Received: by 10.182.218.37 with SMTP id pd5mr4022437obc.24.1351958308698; Sat, 03 Nov 2012 08:58:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.137.198 with HTTP; Sat, 3 Nov 2012 08:58:08 -0700 (PDT) In-Reply-To: References: <720307009FD94454BF0EDC318177AA0D@Ganymede> From: Didier Cassirame Date: Sat, 3 Nov 2012 16:58:08 +0100 Message-ID: To: Alain Coste Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=f46d04447dffbdbcb304cd9952ea Subject: Re: [Caml-list] Why are modules handled differently by the interpreter and the compiler --f46d04447dffbdbcb304cd9952ea Content-Type: text/plain; charset=UTF-8 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 > 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 > >> 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 >>> >> >> > --f46d04447dffbdbcb304cd9952ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry,=C2=A0

I meant that it would declare the content o= f 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 Ca= ssirame <didier.cassirame@gmail.com>
Unless you are doing something like this:


module M =3D
struct
=C2=A0 (* body of module *)
<= div>
end

in file m.ml ?

I used to do something like that, but it's redundan= t with the automatic bundling of values within a ml file into a module of t= he same name. In other words, when accessing the module MyModule within som= e 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 :=C2=A0


module MyModule =3D (
str= uct

=C2=A0 (* content of ml file *)

=
end : sig=C2=A0
=C2=A0
=C2=A0 (* conte= nt of mli file *)

end)


or simply<= br>
module MyModule =3D
struct

= =C2=A0 (* 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 wh= ich you described.

Cheers,

didier

2012= /11/3 Didier Cassirame <didier.cassirame@gmail.com>=
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



--f46d04447dffbdbcb304cd9952ea--