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 CAA18598; Fri, 28 May 2004 02:33:06 +0200 (MET DST) 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 CAA18031; Fri, 28 May 2004 02:33:05 +0200 (MET DST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4S0X3EV011584; Fri, 28 May 2004 02:33:03 +0200 Received: from clipper.ens.fr (clipper-gw.ens.fr [129.199.1.22]) by nef.ens.fr (8.12.11/1.01.28121999) with ESMTP id i4S0X3IG040375 ; Fri, 28 May 2004 02:33:03 +0200 (CEST) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.12.3/jb-1.1) id i4S0X1eP020349 ; Fri, 28 May 2004 02:33:02 +0200 (MET DST) X-Authentication-Warning: clipper.ens.fr: frisch owned process doing -bs Date: Fri, 28 May 2004 02:33:01 +0200 (MET DST) From: Alain Frisch X-X-Sender: frisch@clipper.ens.fr Reply-To: Alain Frisch To: Xavier Leroy cc: Caml list Subject: Re: [Caml-list] Proposal for separate compilation In-Reply-To: <20040526103203.A16448@pauillac.inria.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by amavisd-milter (http://amavis.org/) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.3.3 (nef.ens.fr [129.199.96.32]); Fri, 28 May 2004 02:33:03 +0200 (CEST) X-Miltered: at nez-perce with ID 40B688BF.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; alain:01 frisch:01 alain:01 frisch:01 caml-list:01 hash:01 mli:01 mli:01 val:01 ids:01 hash:01 generative:01 compiler:01 cmo:01 cmo:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Wed, 26 May 2004, Xavier Leroy wrote: > This is an interesting proposal. You might be interested in Martin > Elsman's PhD (DIKU, 1998), which uses techniques along these lines in > a defunctorizing, whole-program SML compiler. Thanks for the pointer. > There is one thing that puzzles me in your proposal. Consider two > compilation units A and B, where B refers to A. >... > So, what unique identifier is B going to use to refer to A's definition? > Since A.cmi is the only available info on A, that > identifier must be tied to A.cmi: either a hash of A's interface, or > some unique identifier generated when A.mli is compiled into A.cmi. If I understand the point correctly, an example would two modules MyString1 and MyString2, with myString1.mli == myString2.mli: type t = string val compare: t -> t -> unit but different implementations. One solution is simply, as Nicolas suggests, to store the original name of the compilation unit in the uid. Still, one could imagine two modules with the same name and the same interface in unrelated libraries. This would be a good argument for using reallly unique ids instead of hash. When you compile an interface a.mli, you just mark a.cmi with a fresh random uid (with possibly a check that the real content of a.cmi has been modified, otherwise don't touch the uid). This will be used to make reference to module A from b.cmo (and of course a.cmo). In other words: compilation of interfaces is given a generative semantics. Since you mention the generation of the unique identifier, I guess I missed something. -- Alain ------------------- 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