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 RAA20783; Wed, 26 May 2004 17:13:01 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id RAA21132; Wed, 26 May 2004 17:13:00 +0200 (MET DST) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4QFCxSH024303; Wed, 26 May 2004 17:12:59 +0200 Received: from warp (lns-th2-5f-81-56-197-80.adsl.proxad.net [81.56.197.80]) by postfix4-1.free.fr (Postfix) with SMTP id 2335D11E7C4; Wed, 26 May 2004 17:12:59 +0200 (CEST) Message-ID: <003f01c44333$cf907340$ef01a8c0@warp> From: "Nicolas Cannasse" To: "Xavier Leroy" , "Alain Frisch" Cc: "Caml list" References: <20040526103203.A16448@pauillac.inria.fr> Subject: Re: [Caml-list] Proposal for separate compilation Date: Wed, 26 May 2004 17:12:07 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Miltered: at concorde with ID 40B4B3FB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; cannasse:01 warplayer:01 caml-list:01 cmx:01 ocamlc:01 ocamlopt:01 cmx:01 model:01 ocamlopt:01 hash:01 mli:01 hash:01 collision:01 cannasse:01 compiler: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. Maybe I didn't understand well, but I think I have a more easy answer : if the identifier is composed of both the hash of the cmi and the name of the module (so something like (A,hash A)) then we have name collision only when we have several compilation units with both the same name and same interface. This is more unlikely to happen, or the user is using two different implementations of the same module at the same time, and then a linker error will make him choose one (whatever the choice, the program is correctly typed but both implementations can have different semantics and then leave some bugs). Other way is to add some random data to the hash when the CMI is compiled (and of course ignore this extra-data when recompiling to avoid spending CPU ). BTW, is there any way such a proposal will end up into the caml distribution ? Best Regards, Nicolas Cannasse ------------------- 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