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 1D7967F249 for ; Sat, 3 Nov 2012 18:15:33 +0100 (CET) Received-SPF: None (mail4-smtp-sop.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail4-smtp-sop.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@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-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail4-smtp-sop.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwDALJQlVDRVd+2m2dsb2JhbABEwiYEA4EACCMBAQEBAQgJCwkUJ4IeAQEFQAEbHQEDCAQGBQsGBAEBAS4hAQERAQUBFAgGEwgTh1wBAw8LmyKMMYJ3hDQKGScNWYh1AQUMiw1oAYY7A5QmgVWLM4MwFimEEoFj X-IronPort-AV: E=Sophos;i="4.80,705,1344204000"; d="scan'208";a="161259570" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 03 Nov 2012 18:15:31 +0100 Received: by mail-ie0-f182.google.com with SMTP id k10so11293156iea.27 for ; Sat, 03 Nov 2012 10:15:30 -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:content-transfer-encoding; bh=BiCprVx8zys5ISHxB4UHzF+vrCDH9euLaLTWtLfC03o=; b=XQowMP6lFZAuBYovmkkr7Rr9F2F5MPeGBWbycNptnamnj6tk5mgO+lD4i7x8SNc+Wx bTsvh/99l/3zWO8TRInLRLCPiCiLGjlR7obu7rQliTOdr9P88e3RCWb2+y07geA5dMYO sZCPRxRb85vZb3yJMeGDoPbMqwuUpH9FOqFFaMCdJBMRX9p4RDdXfF4/0o7RVlHAoFsE n6Ck5GXA0+knlv7ztKfq07YDAV8xYpDC8u4GMHjnfVw9LMBCkmbRVvtkHnKj58GLghcM V3VHP6Uh31lgMoaHy6q0GpWAeD9IHihsk89mvj7DRbjSa0OaB0hnzFcTy47mMBoOPnOV YbTA== Received: by 10.50.173.34 with SMTP id bh2mr5026663igc.70.1351962930254; Sat, 03 Nov 2012 10:15:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.65.9 with HTTP; Sat, 3 Nov 2012 10:14:49 -0700 (PDT) In-Reply-To: References: <720307009FD94454BF0EDC318177AA0D@Ganymede> From: Gabriel Scherer Date: Sat, 3 Nov 2012 18:14:49 +0100 Message-ID: To: Alain Coste Cc: caml-list@inria.fr Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Caml-list] Why are modules handled differently by the interpreter and the compiler One reason to treat .ml files as modules/structures implicitly is that it neatly explain the .ml / .mli dichotomy : the .mli is the interface of the module, so the .mli/.ml check is described exactly as a semantic concept existing in the internal language. On the contrary if you had .ml simply be "bunches of phrases", you would have to define an ad-hoc semantics for signature matching (which would plausibly be "encapsulate in a module and a module signature, check the interfaces match, then include the module"). Modules are just a good match for "bunch of phrases packed together", because modelling this is exactly their justification. Furthermore, your two reasons are of the form "this abstraction is not enough for X", not "this abstraction is problematic because of X". If we removed the "compilation units are implicit modules" convention this wouldn't help with any of your point. In a different direction, I think it could be useful to consider language changes=B9 to solve the second problem you mention : the difficulty of describing a functor in a modular way. OcamlPro had a prototype approach to attack this problem http://www.ocamlpro.com/blog/2011/08/10/ocaml-pack-functors.html and we may discuss it again in the future. =B9: of course, "consider language changes" does not necessarily mean to actually change the language, as doing nothing at all is sometimes the best solution (as proposed in the recent "Why should I use .mli files" discussion). We would be in an awful shape if each back pain of an OCaml programmer had resulted in a new language feature. On Sat, Nov 3, 2012 at 5:52 PM, Alain Coste w= rote: > Hi, > When debugging, it's faster to #use the source files than first compiling > them, and then #loading the resulting .cma file. > The solution #use_as_module would be fine in that it would have the same > behavior as the compiler. > > But IMHO preventing the compiler from encapsulating the code in module M = =3D > struct ... end seems however interesting, for at least two reasons : > - when I need a module at an "interior level" I write module Q =3D ...= end. > Why treat the top-level in a non uniform way ? > - if my module is a functor (and I often use functors, mainly because = of > recursive modules) I have nevertheless to put everything in the functor. = So > the compiler creates an extra (and for me parasitic) level of encapsulati= on. > > Alain Coste > > ----- Original Message ----- > From: Didier Cassirame > To: Alain Coste > Cc: caml-list@inria.fr > Sent: Saturday, November 03, 2012 4:55 PM > Subject: Re: [Caml-list] Why are modules handled differently by the > interpreter and the compiler > > Unless you are doing something like this: > > > module M =3D > 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 ot= her > words, when accessing the module MyModule within some code, ocaml will lo= ok > for an existing module within the current scope, or search for a file nam= ed > myModule.ml, and if found, wrap its content in the following manner : > > > module MyModule =3D ( > struct > > (* content of ml file *) > > end : sig > > (* content of mli file *) > > end) > > > or simply > > module MyModule =3D > 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 (f= or >>> 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 fi= le), >>> 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 sho= uld >>> 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 >> >> >