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 OAA13609; Wed, 20 Mar 2002 14:40:42 +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 OAA17132 for ; Wed, 20 Mar 2002 14:40:41 +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 g2KDeeP16470 for ; Wed, 20 Mar 2002 14:40:40 +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 71BEB78E0; Wed, 20 Mar 2002 14:40:39 +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 A478856F3; Wed, 20 Mar 2002 14:40:38 +0100 (CET) Message-ID: <3C989156.6010906@gerd-stolpmann.de> Date: Wed, 20 Mar 2002 14:40:38 +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: Johan Georg =?ISO-8859-1?Q?Granstr=F6m?= 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> <3C98863F.6060208@gerd-stolpmann.de> <007601c1d00f$f3b81960$0c6fa8c0@invariant.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk Johan Georg Granström wrote: >>>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. >> > > I don't understand this, can you give an example of such > a case? Oh, sorry, I was here on the wrong track. Adding a function does not break functor applications. Is there any case where module signatures must exactly match? Anyway, only being able to add functions is not sufficient. There are many possible changes of modules that would not break "source-code compatibility", but would certainly break binary compatibility, e.g. new optional arguments, new variants, new methods, etc. 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