From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id D51857FB38 for ; Sun, 28 Dec 2014 21:34:40 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of jordojw@gmail.com) identity=pra; client-ip=209.85.192.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="jordojw@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of jordojw@gmail.com designates 209.85.192.176 as permitted sender) identity=mailfrom; client-ip=209.85.192.176; receiver=mail2-smtp-roc.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 (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-pd0-f176.google.com) identity=helo; client-ip=209.85.192.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="jordojw@gmail.com"; x-sender="postmaster@mail-pd0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEBAA9poFTRVcCwfmdsb2JhbABcDoNKWMZhhXsCgQsWAQEBAQERAQEJCwwIFC6EDQEBAwESKAYBGx0BAwwGBQsDOCMRAQUBHAYTGweHdQEDCQgFoxQ+MY0ZgneKGQoZJw1UhDUBAQEBAQEBAQEBAQEBAQEBAQEBAQERAQUOjzYzB4MWgRMFiUuFOIJRgX+DNYENMEqDfYgTgW81gRWDU15OgkMBAQE X-IPAS-Result: AjEBAA9poFTRVcCwfmdsb2JhbABcDoNKWMZhhXsCgQsWAQEBAQERAQEJCwwIFC6EDQEBAwESKAYBGx0BAwwGBQsDOCMRAQUBHAYTGweHdQEDCQgFoxQ+MY0ZgneKGQoZJw1UhDUBAQEBAQEBAQEBAQEBAQEBAQEBAQERAQUOjzYzB4MWgRMFiUuFOIJRgX+DNYENMEqDfYgTgW81gRWDU15OgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,656,1413237600"; d="scan'208";a="115030588" Received: from mail-pd0-f176.google.com ([209.85.192.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 28 Dec 2014 21:34:18 +0100 Received: by mail-pd0-f176.google.com with SMTP id r10so15946950pdi.21 for ; Sun, 28 Dec 2014 12:34:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mprhnFbwdItDhjr7j/dPeeleHPwR0HtMBRPLxc1pgiA=; b=R5IzbCe1chJvyhCUD8RLv4HybGNMb1Skiuo60wrPUxQxAYphHO1S0BgaCiHERFntSK XJpY2kKW8yKgWfF+5+169sQOmbpnQYdsvoH3VF4NyhIqH1KSKe4+R3E4QdCzOYfku/8P //2Vn0L2b9U9gBEjE3FVoojbhc76sx4nltNoWl8peZgzgGLB+SvkSx/5T5fYBNKigtEH U71K5f2+Uxu5c5kyV8C0nlWIZuWoqyhsU7jN/E2QvH1Ly4oU5GvjXdtdDqomOE6bNGrL 9dtejSSCNefcukbc5EeZFfVdzbBPetY3FPP6SxZdZvkAOOXryhbzuutUwDdPB1UiZbOT Cvvg== X-Received: by 10.70.47.6 with SMTP id z6mr85293819pdm.82.1419798857119; Sun, 28 Dec 2014 12:34:17 -0800 (PST) Received: from [10.180.186.117] ([166.170.41.114]) by mx.google.com with ESMTPSA id qc1sm12446234pbb.84.2014.12.28.12.34.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 28 Dec 2014 12:34:14 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jordo X-Mailer: iPhone Mail (12B436) In-Reply-To: <87d273ljxp.fsf@study.localdomain> Date: Sun, 28 Dec 2014 12:34:15 -0800 Cc: "caml-list@inria.fr" Content-Transfer-Encoding: quoted-printable Message-Id: <996F18A3-E87B-4723-A355-25A09AF4527B@gmail.com> References: <87d273ljxp.fsf@study.localdomain> To: Leo White X-Validation-by: jordojw@gmail.com Subject: Re: [Caml-list] Module aliases ideal name-spacing Thank you for the reply, Leo. One of the requirements was that developers b= e able to name their internal modules as they see fit without having to fea= r 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 appear= s in this solution you suggested, developers still must prefix their file n= ames in order to avoid collisions. That is unintuitive because it's not alw= ays clear why a file is named differently than its namespaced alias. Reader= s must examine the module alias file to know which file a module is impleme= nted in. Packs provided a solution to this and I'm hoping we may continue t= hat highly effective pattern while also enjoying the benefits of module ali= ases. Having the freedom to name modules without fear of collision outside = of your "project" seems strictly better than having to be concerned about c= ollisions outside of your project. Is there any sequence of compilation com= mands that will guard these namespaces as I've been successfully doing with= packs? Could the proper solution be to actually have packs use module alia= ses? That might allow *proper* namespacing along with the compilation benef= its of aliases. Is there any other way? I On Dec 28, 2014, at 10:15 AM, Leo White wrote: >> One set of modules that form a kind of namespaced "project" MyLib. >> --------- >>=20 >> ~/myLib/myModule.ml >> open MyLib (* This is not needed - short names are same as long *) >> (* Sees Utils belonging to MyLib *) >>=20 >> ~/myLib/utils.ml >> open MyLib (* This is not needed - short names are same as long *) >>=20 >> ~/myLib/myLib.mli and ~/myLib/myLib.ml >> module MyModule =3D MyModule >> module Utils =3D Utils >>=20 >> Another set of modules ("project") that depends on the previous project = YourLib >> --------- >>=20 >> ~/yourLib/yourModule.ml >> open YourLib (* This is not needed - short names are same as long *) >> (* Sees Utils belonging to YourLib *) >>=20 >> ~/yourLib/utils.ml >> open YourLib (* This is not needed - short names are same as long *) >>=20 >> ~/yourLib/yourLib.mli and ~/yourLib/yourLib.ml >> module YourModule =3D YourModule >> module Utils =3D Utils >>=20 >> Finally, an application "project" that uses the namespaces generated by = the previous two projects >> --------- >>=20 >> ~/myApp/myApp.ml >> let x =3D MyLib.Utils.x + YourLib.Utils.y >=20 > You can use the `-o` and `-open` command-line options to get the > behaviour you are after. If you change myLib/myLib.ml(i) to be >=20 > module MyModule =3D MyLibMyModule > module Utils =3D MyLibUtils >=20 > and make similar changes to yourLib/yourLib.ml(i), then you can use the > following commands: >=20 > cd ~/myLib > ocamlc -no-alias-deps myLib.mli > ocamlc -no-alias-deps myLib.ml > ocamlc -c -open MyLib -o myLibUtils.cmo utils.ml > ocamlc -c -open MyLib -o myLibMyModule.cmo myModule.ml >=20 > cd ~/yourLib > ocamlc -c -no-alias-deps yourLib.mli > ocamlc -c -no-alias-deps yourLib.ml > ocamlc -c -open YourLib -o yourLibUtils.cmo utils.ml > ocamlc -c -open YourLib -o yourLibYourModule.cmo yourModule.ml >=20 > cd ~/myApp > ocamlc -c -I ../myLib -I ../yourLib myApp.ml >=20 > Setting up this compilation scheme in your build system might be a bit > of effort, but it should work. >=20 > Regards, >=20 > Leo