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 589C17F249 for ; Sat, 3 Nov 2012 16:56:33 +0100 (CET) Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=pra; client-ip=212.227.126.186; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: None (mail1-smtp-roc.national.inria.fr: no sender authenticity information available from domain of info@gerd-stolpmann.de) identity=mailfrom; client-ip=212.227.126.186; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="info@gerd-stolpmann.de"; x-conformance=sidf_compatible Received-SPF: Pass (mail1-smtp-roc.national.inria.fr: domain of postmaster@moutng.kundenserver.de designates 212.227.126.186 as permitted sender) identity=helo; client-ip=212.227.126.186; receiver=mail1-smtp-roc.national.inria.fr; envelope-from="info@gerd-stolpmann.de"; x-sender="postmaster@moutng.kundenserver.de"; x-conformance=sidf_compatible; x-record-type="v=spf1" X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAAAAM+lVDU4366jmdsb2JhbABEsQySKSMBAQEBCQsJCRIFJIIeAQEEATo0CwU7XQkSBhMJCYdmAwkKB69UA4leFIttFIYoA41diTqSGIFa X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208";a="179997019" Received: from moutng.kundenserver.de ([212.227.126.186]) by mail1-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Nov 2012 16:56:32 +0100 Received: from office1.lan.sumadev.de (dslb-094-219-212-125.pools.arcor-ip.net [94.219.212.125]) by mrelayeu.kundenserver.de (node=mrbap0) with ESMTP (Nemesis) id 0M4Tee-1T9xH12C7A-00yrpq; Sat, 03 Nov 2012 16:56:31 +0100 Received: from samsung (ip-5-146-55-186.unitymediagroup.de [5.146.55.186]) by office1.lan.sumadev.de (Postfix) with ESMTPSA id 0C838C00CF; Sat, 3 Nov 2012 16:56:31 +0100 (CET) Date: Sat, 03 Nov 2012 16:56:30 +0100 From: Gerd Stolpmann To: Alain Coste Cc: caml-list@inria.fr In-Reply-To: <720307009FD94454BF0EDC318177AA0D@Ganymede> (from alaincoste@club-internet.fr on Sat Nov 3 16:21:49 2012) X-Mailer: Balsa 2.4.11 Message-Id: <1351958190.8536.17@samsung> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Provags-ID: V02:K0:cafRpe5UnRBQQ3q9KItczmIndOzjhPL3gLjTYj2ZP8w Y+Fn1Op/VAYPN9Ka5mSynGgfnOhGOzUvlwqPWx2MyE0LObhDwD ffTT3yOLNwZulBe86sUUnXvpipFbrjm83YN5/SRnKy7YcoE1Hq cfMMCYV3cVRb+LUeqHHB1w/A9Y5RZB1AtS7OFMyXhTpB+1KRfr 5fKkP88wUmbUm5Z+uk9Divc4WvI44l8eWj6DLK9aFPIL/uZp3g VBcuJwv7pUaKrTmkJ711Kmi1v3XzhJcW+OOmrVmA+aV2el09MG 7wLOfjmjVG2Ebcec0PlCxSyEEEBkrjZVEDwKYGbAxbpe/sh5GP Ohj6Sjhex8/On6XUxNaIN4gHOfNG1n8dIuLEoMR4X Subject: AW: [Caml-list] Why are modules handled differently by the interpreter and the compiler Am 03.11.2012 16:21:49 schrieb(en) Alain Coste: > Hello, > Back to a problem which I have always found annoying in OCaml. I=20=20 > hoped the version 4.0 would solve it, but it seams nothing changed.. > While developping a project, It's interesting to use the interpreter=20= =20 > (for test, debugging) AND the compiler (to have program run faster=20=20 > when everything goes wright). > Now, when the project is divided in several modules, each module=20=20 > being a structure written in a .ml file (with possibly a signature in=20= =20 > a .mli file), you can't simply use the interpreter and the compiler=20=20 > on the same files. > The interpreter loads the modules with their names (say M), and you=20=20 > can refer to its identifiers with M.foo, in the standard way. > The compiler adds one level of "modularity", as it encapsulates the=20=20 > contents of the file with "module M ...end". So now its identiifers=20=20 > should be referenced as M.M.foo !! So far I understand that you load modules with "#use" into the toploop,=20= =20 and that you have files m.ml that also have a "module M =3D struct ...=20= =20 end" in it. Thus a definition foo is seen by the compilers as M.M.foo.=20= =20 This is how it is supposed to be. Normally you would not write the=20=20 "module M" construction within a file m.ml. Now, the outer level of module encapsulation goes away when you just=20=20 "#use" the file. Why is that? Basically, it is unsupported to load=20=20 modules directly from sources - what you really do with #use is to load=20= =20 source files. Note that you can also load compiled modules into the toploop - using=20=20 #load, and this works for files with suffixes .cmo and .cma, and now=20=20 the implicit module abstraction coming from the file is preserved. > I found two possible work-arounds to this : > - comment out all my top-level decarations of module before=20=20 > compiling the files > needs to be undone and redone every time I want to reuse=20= =20 > 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=20=20 > advantages of separate compilation >=20 > Can somebody explain the rationale behind this behavior. Or, if this=20= =20 > is only for historical and compatibility reasons, could it be=20=20 > possible to have an option "-please_don't_encapsulate" (or something=20= =20 > shorter...) for the compiler ? So, the normal development cycle is this: - compile your project - #load the resulting .cma file into a toploop (if you need many #load directives put them into a file, and #use that) - test it there This preserves the modules. #use is really of limited use - personally=20= =20 I sometimes put helpers for testing into a seperate file and #use that. What could be implemented as an extension is a #use_as_module directive=20= =20 that adds the implicit module. This could be in deed useful for=20=20 debugging, especially when it overlooks the mli file if present - if=20=20 you #load, the definition hiding of the mli file takes place, and you=20=20 cannot see unexported definitions anymore. Of course, this is sometimes=20= =20 in the way when you test things out. Now that compiler-libs is installed this extension could probably even=20= =20 be implemented outside the compiler. Anyone up for it? Gerd >=20 > Alain Coste > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs --=20 ------------------------------------------------------------ Gerd Stolpmann, Darmstadt, Germany gerd@gerd-stolpmann.de Creator of GODI and camlcity.org. Contact details: http://www.camlcity.org/contact.html Company homepage: http://www.gerd-stolpmann.de ------------------------------------------------------------=