From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id NAA15969; Wed, 20 Mar 2002 13:59:37 +0100 (MET) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id NAA16620 for ; Wed, 20 Mar 2002 13:59:36 +0100 (MET) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2KCxZP14859; Wed, 20 Mar 2002 13:59:35 +0100 (MET) Received: from user-0ccegg9.cable.mindspring.com ([24.199.66.9] helo=flapdragon.homeip.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16nfgX-0001Z8-00; Wed, 20 Mar 2002 04:59:21 -0800 Subject: Re: [Caml-list] Functorizing large collections of modules From: "Yaron M. Minsky" To: Alain Frisch Cc: Francois Pottier , Caml list In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Evolution/1.0.2 Date: 20 Mar 2002 07:59:20 -0500 Message-Id: <1016629161.10273.60.camel@dragonfly.localdomain> Mime-Version: 1.0 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 2002-03-20 at 06:24, Alain Frisch wrote: > On Wed, 20 Mar 2002, Francois Pottier wrote: > > > > Another example of this weakness is the lack of support for namespaces. > > > > It is true that O'Caml has little support for resolving name conflicts > > in a modular way, because the semantics of the module language is too > > intimately tied with the underlying file system. I suppose a CM-like tool > > would help, but I think this issue is separate from the one above. > > > It seems that the new -pack feature of ocamlc/ocamlopt (see CVS) addresses > the issue. What kind of extra support for namespace would be needed ? > > Concerning the global parametrization, maybe a variation around -pack > could solve the problem. ocamlc -pack would take a list of modules > A1,...An (.cmo+.cmi) and a list of interfaces S1,...,Sm (.cmi) and produce > a functor parametrized by interfaces S1,...Sm and returning a > bundled version of A1,...,An This seems like a plausible solution, although ideally I think the shape of this multi-module functor should be described in a file, not just on the command-line. So you could have a file with a kind of dummy functor: library.ml module M(ZZp:ZZpSig) = struct end and the compiler would add the appropriate modules to the end of the struct, in whatever order is specified on the command-line. One wonders, of course, whether this can easily be implemented without tossing out separate compilation. If not, then maybe some kind of hack where you do a manual substitution to make this work would be the right idea, as suggested by Francois. y -- |--------/ Yaron M. Minsky \--------| |--------\ http://www.cs.cornell.edu/home/yminsky/ /--------| Open PGP --- KeyID B1FFD916 (new key as of Dec 4th) Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916 ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners