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 MAA12386; Wed, 20 Mar 2002 12:20:57 +0100 (MET) 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 MAA13882 for ; Wed, 20 Mar 2002 12:20:56 +0100 (MET) Received: from mulga.cs.mu.OZ.AU (mulga.cs.mu.OZ.AU [128.250.1.22]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2KBKnP12656 for ; Wed, 20 Mar 2002 12:20:54 +0100 (MET) Received: from hg.cs.mu.oz.au (hg.cs.mu.OZ.AU [128.250.25.19]) by mulga.cs.mu.OZ.AU with ESMTP id WAA08364; Wed, 20 Mar 2002 22:20:41 +1100 (EST) Received: (from fjh@localhost) by hg.cs.mu.oz.au (8.10.2/8.10.2/SuSE Linux 8.10.0-0.3) id g2KBKcr03300; Wed, 20 Mar 2002 22:20:38 +1100 Date: Wed, 20 Mar 2002 22:20:38 +1100 From: Fergus Henderson To: Gerd Stolpmann Cc: Jeff Henrikson , caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml Message-ID: <20020320222038.A3148@hg.cs.mu.oz.au> References: <3C8C9FE1.2060904@gerd-stolpmann.de> <000d01c1c95b$866bc060$0b01a8c0@mit.edu> <20020312230047.M1173@ice.gerd-stolpmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020312230047.M1173@ice.gerd-stolpmann.de>; from info@gerd-stolpmann.de on Tue, Mar 12, 2002 at 11:00:47PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk On 12-Mar-2002, Gerd Stolpmann wrote: > > 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." I agree. It is not true of other languages with static typing, e.g. Mercury or C++. I think that rather than being a consequence of strict typing, it is a possible consequence of treating modules as more-or-less first class, if you use a representation of modules in which adding a new function does not preserve binary compatibility. Does O'Caml do that? > > 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. In Mercury and C++, often changes are not completely source-level compatible, but nevertheless preserve binary compatibility. For example, adding a new function may introduce new ambiguity errors in existing source code, in case the same name occurs in a different module. However, binaries will always refer to the fully-qualified name, so they won't be affected by such ambiguities. > 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. Well, if you changed the interface to `f', e.g. by adding an optional argument, that is not a binary-backwards-compatible change. The same happens in C++ if you add an optional argument. > So one precondition of replacing the library is that the signatures are > identical. Even small changes cannot be tolerated. Adding new functions to a module ought not break binary backwards compatibility. If it does, then you lose many of the benefits of separate compilation. Does adding new functions to a module actually break binary backwards compatibility in O'Caml? -- Fergus Henderson | "I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit" WWW: | -- the last words of T. S. Garp. ------------------- 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