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 LAA10569; Fri, 28 May 2004 11:55:11 +0200 (MET DST) 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 LAA09906 for ; Fri, 28 May 2004 11:55:10 +0200 (MET DST) Received: from nef.ens.fr (nef.ens.fr [129.199.96.32]) by concorde.inria.fr (8.12.10/8.12.10) with ESMTP id i4S9t9SH017932 for ; Fri, 28 May 2004 11:55:09 +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 i4S9t8CY096571 ; Fri, 28 May 2004 11:55:08 +0200 (CEST) Received: from localhost (frisch@localhost) by clipper.ens.fr (8.12.3/jb-1.1) id i4S9t6qs014211 ; Fri, 28 May 2004 11:55:06 +0200 (MET DST) X-Authentication-Warning: clipper.ens.fr: frisch owned process doing -bs Date: Fri, 28 May 2004 11:55:06 +0200 (MET DST) From: Alain Frisch X-X-Sender: frisch@clipper.ens.fr Reply-To: Alain Frisch To: Jacques GARRIGUE cc: Caml list Subject: Re: [Caml-list] Proposal for separate compilation In-Reply-To: <20040528.105427.68533454.garrigue@kurims.kyoto-u.ac.jp> 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 11:55:09 +0200 (CEST) X-Miltered: at concorde with ID 40B70C7D.002 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 jacques:01 mli:01 dependencies:01 incompatible:01 stdlib:01 hash:01 generative:01 mli:01 -pack:01 ids:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On Fri, 28 May 2004, Jacques GARRIGUE wrote: > 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.) The method used for generating of the uid for a given unit can be decided at compile time: one could compile some interfaces (like the stdlib) with a "transparent" semantics (the uid is a hash of the name, the content of the interface, and maybe a "salt" to be used as a namespace for the library), and some with a generative semantics. The problem with the transparent semantics is the one mentionned by Xavier (several modules with the same name, same interface, different implementation, all linked together), which should be extremely rare (does it happen for the whole set of OCaml modules written so far) ? The "salt" could handle these very rare cases. > * 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) Indeed, this is a bit far fetched. Given that the two .ml have the same name, with the current scheme, you cannot link them together directly (you could -pack them, or burry them in libraries, etc...) > This looks like an attempt to solved the above compatibility problem. > Do not change the semantics of interfaces, only the compilation of > implementation. Ok, thanks. > 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. I don't see what the solution brings compared to the current scheme if one stores names (and not only uids) in compiled units. In case of name collision, how would the linker know what to do ? -- 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