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 D57E37F249 for ; Sat, 3 Nov 2012 16:55:34 +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: AlABAME9lVDRVda2kGdsb2JhbABEhhe9FggjAQEBAQkJDQcUBCOCHgEBBAEjHQEbHQEDAQsGAwILNwICIQEBEQEFARwGE4d3AQMJBps0i2JPgneEOQoZJw1ZiHUBBQyLDWmFKIETA5QmgVWLM4MwFimEEoFj X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208";a="161256957" 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:55:33 +0100 Received: by mail-ob0-f182.google.com with SMTP id wc20so7652703obb.27 for ; Sat, 03 Nov 2012 08:55:32 -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=is9jgN/BFx2W0TuBZanXHUStZb1JIek/6OfEEm/OQEI=; b=jeISAie9q+9BWV2/ydzAFGENGB0KMnpwpjFFluOZUF36SRMfuqLJGSVV2jR3h1bdL0 Ou/5yjWd2w5hszPplhpJoZiK+0mldoPbmDCPXaXtYpC4X1OjuytUyulUEK49tgMDX1WE 3DYY0cvQVGaou8/KELvdFDS/0156fF4Decn5lE/2oTZdOclGZ/Fs/ybBkrYftGlxIvzJ jW4hfWgDJFNr8XcpnTVDVXgcamicxgaLMWBw7AZmvA0CveL8fgnbk5cDo+pkwz0YGRmy Cqd4V4ESNNuTo63Pn6ZW9Gr4saw4M3+8P6iQV82Wqx6klCX3OT/wxnSp8yndd4Tfv4LU 3AUw== Received: by 10.60.7.225 with SMTP id m1mr4063494oea.122.1351958132449; Sat, 03 Nov 2012 08:55:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.137.198 with HTTP; Sat, 3 Nov 2012 08:55:12 -0700 (PDT) In-Reply-To: References: <720307009FD94454BF0EDC318177AA0D@Ganymede> From: Didier Cassirame Date: Sat, 3 Nov 2012 16:55:12 +0100 Message-ID: To: Alain Coste Cc: caml-list@inria.fr Content-Type: multipart/alternative; boundary=e89a8fb1ef403c627504cd99481a Subject: Re: [Caml-list] Why are modules handled differently by the interpreter and the compiler --e89a8fb1ef403c627504cd99481a Content-Type: text/plain; charset=UTF-8 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 >> > > --e89a8fb1ef403c627504cd99481a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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


--e89a8fb1ef403c627504cd99481a--