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 JAA00358; Fri, 28 May 2004 09:14:51 +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 JAA00820 for ; Fri, 28 May 2004 09:14:49 +0200 (MET DST) X-SPAM-Warning: Sending machine is listed in blackholes.five-ten-sg.com Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i4S7EmEV014446 for ; Fri, 28 May 2004 09:14:49 +0200 Received: from warp (lns-th2-5f-81-56-197-80.adsl.proxad.net [81.56.197.80]) by postfix3-2.free.fr (Postfix) with SMTP id 66355C1C2; Fri, 28 May 2004 09:14:47 +0200 (CEST) Message-ID: <001f01c44483$571c3f10$ef01a8c0@warp> From: "Nicolas Cannasse" To: , "Jacques GARRIGUE" Cc: References: <20040526103203.A16448@pauillac.inria.fr> <20040528.105427.68533454.garrigue@kurims.kyoto-u.ac.jp> Subject: Re: [Caml-list] Proposal for separate compilation Date: Fri, 28 May 2004 09:13:55 +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 nez-perce with ID 40B6E6E8.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 ids:01 hash:01 mli:01 generative:01 mli:01 dependencies:01 incompatible:01 hash:01 model:01 ids:01 cmx:01 alain's:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk [...] > > 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. > > Yes, but by doing that you are breaking two things: > * a .cmi does no longer depend only on the contents of the .mli > i.e., if you recompile twice the same library, then all the > dependencies must be recompiled, eventhough nothing has changed > (This may make bootstrapping the compiler rather complicated! > Every recompilation of the standard library would be incompatible.) That's why I'm suggesting we should still use a hash of the cmi as uid, and add a random id in order to resolve ambiguous cases only. > * one can imagine a strange situation where you generated two > differents .cmo with the same .cmi (i.e. two .ml for one .mli, and > you compiled the .mli only once). Your scheme cannot cope with this > case: the two .cmo would conflict. > (I agree this is a bit far fetched) This is clearly forbidden by both current and "improved" linking model, I'm not sure we want that "feature" :) > This looks like an attempt to solved the above compatibility problem. > Do not change the semantics of interfaces, only the compilation of > implementation. > Both imports and exports of libraries have "abstract" names (in > practice unique ids, different for import and export) and the linker > connects imports to the corresponding exports. Sound pretty powerful, > and theoretically nice. But you get bigger .cmo/.cmx, and linking is > more complex. This is also a solution, but as you told, it's more complex to implement. I'm worried also about this complexness when using Dynamic linking . Alain's idea - still not perfect - is simple enough to be worth implemented. 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