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 XAA29210; Tue, 12 Mar 2002 23:00:52 +0100 (MET) 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 XAA30756 for ; Tue, 12 Mar 2002 23:00:51 +0100 (MET) Received: from moutng1.kundenserver.de (moutng1.kundenserver.de [212.227.126.171]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g2CM0oT14675 for ; Tue, 12 Mar 2002 23:00:50 +0100 (MET) Received: from [212.227.126.160] (helo=mrelayng0.kundenserver.de) by moutng1.kundenserver.de with esmtp (Exim 3.22 #2) id 16kuKA-0005Q5-00; Tue, 12 Mar 2002 23:00:50 +0100 Received: from [80.129.98.168] (helo=ice.gerd-stolpmann.de) by mrelayng0.kundenserver.de with asmtp (Exim 3.22 #2) id 16kuK9-0000xJ-00; Tue, 12 Mar 2002 23:00:49 +0100 Received: from ice (gerd@localhost [127.0.0.1]) by ice.gerd-stolpmann.de (8.12.1/8.12.1) with ESMTP id g2CM0mXb003408; Tue, 12 Mar 2002 23:00:48 +0100 Date: Tue, 12 Mar 2002 23:00:47 +0100 From: Gerd Stolpmann To: Jeff Henrikson Cc: caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml Message-ID: <20020312230047.M1173@ice.gerd-stolpmann.de> References: <3C8C9FE1.2060904@gerd-stolpmann.de> <000d01c1c95b$866bc060$0b01a8c0@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <000d01c1c95b$866bc060$0b01a8c0@mit.edu>; from jehenrik@yahoo.com on Tue, Mar 12, 2002 at 01:19:07 +0100 X-Mailer: Balsa 1.2.1 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 2002.03.12 01:19 Jeff Henrikson wrote: > > In O'Caml replacing library X by a newer version usually means that > > all libraries Y that depend on X must be recompiled. And there is no > > guarantee that Y can be compiled at all. I do not see any chance to > > change this, it is a consequence of strict typing. > > I don't see this. I can believe that consequences of implementation choices which have been made prohibit this. For hypothetical > example, inlining behavior which could not be disabled on public interfaces would be a problem. (I don't think this particular > thing happens in ocaml.) But I certainly don't see "a consequence of strict typing." Can you give a specific example? Usually, a new version of a library modifies the signature. Ok, these are often only minor modifications: some new functions, new optional arguments etc., and normally the new version is "source-level" compatible with the old version. "Source-level" means that "normal" usage does not cause incompatibilities. An example: The old version defines a function (* OLD: *) val f : int -> int and the new version changes the signature into (* NEW: *) val f : ?option:bool -> int -> int If "normal usage" means that f is only applied, the new version will be backwards compatible. But there are cases where the compiler indicates a typing error: - You can pass f as such around. This makes a difference because the type of f is different and the deduced types will be different, and it may happen that the deduced types cannot be accepted, because sometimes the optional argument is automatically dropped and sometimes not. - The module defining f can be used as parameter of a functor. The new version has a different signature, and is not accepted as parameter any more. So one precondition of replacing the library is that the signatures are identical. Even small changes cannot be tolerated. I am not an expert, and I do not know how the optional arguments exactly work, but it is possible that the representation of the closure f has changed, too. In general, I expect that "source-level" compatible modifications may change the representation of values. Inlining is another reason (only for ocamlopt), but this can be turned off. Gerd -- ---------------------------------------------------------------------------- Gerd Stolpmann Telefon: +49 6151 997705 (privat) Viktoriastr. 45 64293 Darmstadt EMail: gerd@gerd-stolpmann.de Germany ---------------------------------------------------------------------------- ------------------- 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