From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 7627B7FB38 for ; Mon, 29 Dec 2014 00:25:19 +0100 (CET) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of jordojw@gmail.com designates 209.85.215.49 as permitted sender) identity=mailfrom; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f49.google.com) identity=helo; client-ip=209.85.215.49; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-la0-f49.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkBAOCQoFTRVdcxaWdsb2JhbABcDoI1gRVYBIMBw2CFewKBBAcWAQEBAQERCw4ICRIwhA0BAQMBEhEdARsdAQMBCwYDAgQHAzQCAiEBAREBBQEcBhMbB4d1AQMJCJJukEs+MYsugWuCd4obChknDVSENQEBAQEBBQEBAQEBARYBBQ6NP4IqB4JogUEFiUuICYF/gXGBRIE9ijyEDRIjgQwJg1NeHTGCQwEBAQ X-IPAS-Result: AgkBAOCQoFTRVdcxaWdsb2JhbABcDoI1gRVYBIMBw2CFewKBBAcWAQEBAQERCw4ICRIwhA0BAQMBEhEdARsdAQMBCwYDAgQHAzQCAiEBAREBBQEcBhMbB4d1AQMJCJJukEs+MYsugWuCd4obChknDVSENQEBAQEBBQEBAQEBARYBBQ6NP4IqB4JogUEFiUuICYF/gXGBRIE9ijyEDRIjgQwJg1NeHTGCQwEBAQ X-IronPort-AV: E=Sophos;i="5.07,657,1413237600"; d="scan'208";a="94860637" Received: from mail-la0-f49.google.com ([209.85.215.49]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 29 Dec 2014 00:25:18 +0100 Received: by mail-la0-f49.google.com with SMTP id hs14so10386382lab.22 for ; Sun, 28 Dec 2014 15:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vHot1kY9zrVOTPXOgYcAl/m1SgO9HmCaXpFSFeGs2FA=; b=sTZ2L6UO4f3TECdCIwtCStl9n8NOEQjdY38IFpJelL/7U1oDH3bnboj8PKCA4JXWGx qzsbzXrPoo6XL1ESogfyIOsJ9N1iID0jvvJ69ci5VLZCNZdgKhgt5BCeg0NqYuCtb+5b yME88+lIC10dPSObPvVUkGIRmasiJR4PT4zf05omXEfKRa7roPEdOnpbTY+mHdlNiq/t kTnESlKy/SmWMVRx/IPekx2VJzZpgMYStpAKJJDkViuZ4h/b5sHn8iOw9/j7SnCfG5/5 adJclxa9D6SLiA5RpjC6g6bu4Ao06/K0ByC+21Kd3QZY3ta0QdZwbtKjGo9Kx1bUgKqX EZnA== MIME-Version: 1.0 X-Received: by 10.152.87.100 with SMTP id w4mr53660232laz.71.1419809118010; Sun, 28 Dec 2014 15:25:18 -0800 (PST) Received: by 10.25.143.207 with HTTP; Sun, 28 Dec 2014 15:25:17 -0800 (PST) In-Reply-To: <874msflb48.fsf@study.localdomain> References: <87d273ljxp.fsf@study.localdomain> <996F18A3-E87B-4723-A355-25A09AF4527B@gmail.com> <874msflb48.fsf@study.localdomain> Date: Sun, 28 Dec 2014 15:25:17 -0800 Message-ID: From: Jordan W To: Leo White Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=001a11c365ae20c17e050b4f1286 X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Module aliases ideal name-spacing --001a11c365ae20c17e050b4f1286 Content-Type: text/plain; charset=UTF-8 Oh, I missed that detail. That actually could work quite nicely. Though it's a bit of a messy build script, it's something we could write generically to work well on any "project". The only remaining remnant of the "prefixed" namespace is in myLib.mli/.ml module MyModule = MyLibMyModule module Utils = MyLibUtils It would be nice to eliminate that as well, but I could imagine auto-generating these module alias mappings. This sounds like a nice workaround the namespace issue, but do you think it would be worth supporting module aliases themselves as a form of namespacing at compilation time, so that this intermediate prefixed compilation artifact isn't needed? Thank you for the help, J On Sun, Dec 28, 2014 at 1:26 PM, Leo White wrote: > Jordo writes: > > > Thank you for the reply, Leo. One of the requirements was that > developers be able to name their internal modules as they > > see fit without having to fear naming collisions. It's also required > that file names correspond directly to module names > > (or at least we retain the capability to do so). It appears in this > solution you suggested, developers still must prefix > > their file names in order to avoid collisions. > > None of the source files have prefixed names, only intermediate files > (that is why you use `-o`). For both reading the source code and using > the library through `MyLib.Foo`, the prefix does not appear. > > Regards, > > Leo > --001a11c365ae20c17e050b4f1286 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh, I missed that detail. T= hat actually could work quite nicely. Though it's a bit of a messy buil= d script, it's something we could write generically to work well on any= "project". The only remaining remnant of the "prefixed"= ; namespace is in myLib.mli/.ml

=C2=A0 =C2=A0
=C2=A0 =C2=A0 module MyModule= =3D MyLibMyModule
=C2=A0 =C2=A0 module Utils =3D MyLibUtils

It would be nice to eliminate that = as well, but I could imagine auto-generating these module alias mappings. T= his sounds like a nice workaround the namespace issue, but do you think it = would be worth supporting module aliases themselves as a form of namespacin= g at compilation time, so that this intermediate prefixed compilation artif= act isn't needed?

Thank you for the help,
J

On Sun, Dec 28, 2014 at 1:26 PM, Leo White <lpw25@cam.ac.uk> wrote:
Jordo <jordojw@gmail.com> writes:

> Thank you for the reply, Leo. One of the requirements was that develop= ers be able to name their internal modules as they
> see fit without having to fear naming collisions. It's also requir= ed that file names correspond directly to module names
> (or at least we retain the capability to do so). It appears in this so= lution you suggested, developers still must prefix
> their file names in order to avoid collisions.

None of the source files have prefixed names, only intermediate file= s
(that is why you use `-o`). For both reading the source code and using
the library through `MyLib.Foo`, the prefix does not appear.

Regards,

Leo

--001a11c365ae20c17e050b4f1286--