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 KAA18297; Wed, 26 May 2004 10:32:05 +0200 (MET DST) 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 KAA18260 for ; Wed, 26 May 2004 10:32:04 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4Q8W3EV004841; Wed, 26 May 2004 10:32:03 +0200 Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA18163; Wed, 26 May 2004 10:32:03 +0200 (MET DST) Date: Wed, 26 May 2004 10:32:03 +0200 From: Xavier Leroy To: Alain Frisch Cc: Caml list Subject: Re: [Caml-list] Proposal for separate compilation Message-ID: <20040526103203.A16448@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from Alain.Frisch@ens.fr on Fri, May 21, 2004 at 06:32:23PM +0200 X-Miltered: at nez-perce with ID 40B45603.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 cmx:01 ocamlc:01 ocamlopt:01 cmx:01 model:01 ocamlopt:01 hash:01 mli:01 link-time:01 recognizes:01 linkers:01 compiler:01 compiler:01 cmo:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > Currently, a compiled unit (.cmi,.cmo,.cmx,.o) refers to another unit > through its symbolic name, as used in the source file. My proposal is > to replace these names with unique identifiers. 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. There is one thing that puzzles me in your proposal. Consider two compilation units A and B, where B refers to A. When we compile B.ml, it can be that the only thing the compiler knows about A is its interface A.cmi. This is certainly true for ocamlc. ocamlopt can take advantage of information on A's implementation, as found in A.cmx, but in the current model the presence of A.cmx isn't mandatory to compile B.ml, ocamlopt will generate less efficient but correct code if A.cmx isn't there. 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. It looks like you're going to get name collisions when several compilation units have the same interface. More generally, you haven't fully severed the connection that we have in the current system between the identifier representing the definitions of a compilation unit and the name or identifier of its interface. There are several ways to work around this issue. One is to restrict your scheme to native-code compilation (ocamlopt) and demand that A.cmx is available when compiling B.ml where B depends on A. Then, A.cmx can contain the truly unique identifier for A's implementation, and that identifier can be used in the code generated for B. But the bytecode compiler will not be able to take advantage of your scheme. Another option is to generate unique identifiers not just for the exports of a compilation unit but also for its imports. That is, compiling B.ml will use some random ident "xyz" for B's exports and another random ident "abc" for A's exports. Compiling A.ml will assign a different ident "def" to A's exports. All these (ident, name) associations are recorded in the generated .cmo and .cmx files, of course. At link-time, the linker recognizes that "abc" and "def" are two identifiers for the same thing, and equates them. (Most native-code linkers allow to identify two symbols, although I'm not sure all of them support this feature.) - Xavier Leroy ------------------- 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