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 DAA22024; Fri, 28 May 2004 03:54:37 +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 DAA22259 for ; Fri, 28 May 2004 03:54:35 +0200 (MET DST) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4S1sWSH018977 for ; Fri, 28 May 2004 03:54:33 +0200 Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3p2-20030924/3.7W) with ESMTP id KAA07147; Fri, 28 May 2004 10:54:27 +0900 (JST) Date: Fri, 28 May 2004 10:54:27 +0900 (JST) Message-Id: <20040528.105427.68533454.garrigue@kurims.kyoto-u.ac.jp> To: Alain.Frisch@ens.fr Cc: caml-list@inria.fr Subject: Re: [Caml-list] Proposal for separate compilation From: Jacques GARRIGUE In-Reply-To: References: <20040526103203.A16448@pauillac.inria.fr> X-Mailer: Mew version 4.0.64 on Emacs 21.2 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 40B69BD8.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 jacques:01 alain:01 frisch:01 alain:01 frisch:01 hash:01 mli:01 mli:01 val:01 ids:01 hash:01 generative:01 dependencies:01 incompatible:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Alain Frisch > On Wed, 26 May 2004, Xavier Leroy wrote: > > 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. 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.) * 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) The bootstrapping problem may be a show-stopper. > Since you mention the generation of the unique identifier, I guess I > missed something. 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. Jacques ------------------- 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