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 NAA16219; Wed, 20 Mar 2002 13:53:28 +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 NAA15392 for ; Wed, 20 Mar 2002 13:53:28 +0100 (MET) Received: from pD9E26647.dip.t-dialin.net (pD9E26647.dip.t-dialin.net [217.226.102.71]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2KCrQP14660 for ; Wed, 20 Mar 2002 13:53:26 +0100 (MET) Received: from hera.ffm.npc.de (hera.ffm.npc.de [192.168.130.8]) by pD9E26647.dip.t-dialin.net (Postfix STYX NPC GmbH) with ESMTP id D07AB78E0; Wed, 20 Mar 2002 13:53:20 +0100 (CET) Received: from gerd-stolpmann.de (ares.ffm.npc.de [192.168.130.32]) by hera.ffm.npc.de (Postfix HERA NPC GmbH) with ESMTP id 432BC56F3; Wed, 20 Mar 2002 13:53:20 +0100 (CET) Message-ID: <3C98863F.6060208@gerd-stolpmann.de> Date: Wed, 20 Mar 2002 13:53:19 +0100 From: Gerd Stolpmann User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: Fergus Henderson Cc: caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml References: <3C8C9FE1.2060904@gerd-stolpmann.de> <000d01c1c95b$866bc060$0b01a8c0@mit.edu> <20020312230047.M1173@ice.gerd-stolpmann.de> <20020320222038.A3148@hg.cs.mu.oz.au> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Fergus Henderson wrote: > 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 don't know Mercury but C++. Actually, it does not ensure proper typing between compilation units! The .o files do not contain types, and it is up to the programmer to include the right prototypes. > 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? It is also a matter of typing because even toplevel modules can be used to parameterize functors. So adding a new function may break functor applications. My point is not that it is impossible to flexibilize linking, but that it is not simple to do so. I think typing should be strict even across compilation units, and that the programming environment must check it. Strict typing also means to ensure compatible memory layouts but this is not the only meaning. For example, it must be still possible to hide the representation of types. > 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. I think you mean "independent compilation" here, i.e. the linker does not check proper typing. It is simple to make errors that are hard to find. You need expert knowledge to find out which changes are binary compatible and which not. Better we don't have it. Gerd ------------------- 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