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 MAA14695; Wed, 20 Mar 2002 12:43:36 +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 MAA14847 for ; Wed, 20 Mar 2002 12:43:35 +0100 (MET) Received: from kurims.kurims.kyoto-u.ac.jp (kurims.kurims.kyoto-u.ac.jp [130.54.16.1]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id g2KBhVP13198 for ; Wed, 20 Mar 2002 12:43:33 +0100 (MET) Received: from localhost (suiren.kurims.kyoto-u.ac.jp [130.54.16.25]) by kurims.kurims.kyoto-u.ac.jp (8.9.3/3.7W) with ESMTP id UAA08057; Wed, 20 Mar 2002 20:43:22 +0900 (JST) To: fjh@cs.mu.OZ.AU Cc: caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml In-Reply-To: <20020320222038.A3148@hg.cs.mu.oz.au> References: <000d01c1c95b$866bc060$0b01a8c0@mit.edu> <20020312230047.M1173@ice.gerd-stolpmann.de> <20020320222038.A3148@hg.cs.mu.oz.au> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20020320204322L.garrigue@kurims.kyoto-u.ac.jp> Date: Wed, 20 Mar 2002 20:43:22 +0900 From: Jacques Garrigue X-Dispatcher: imput version 20000228(IM140) Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk From: Fergus Henderson > 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. Could you specify what benefits? The current situation in OCaml is that you have to recompile all dependencies everytime you change anything in the interface. If you use a Makefile, even changing a comment will trigger a recompilation. But, in my experience most C makefiles are written in the same way meaning that you have to recompile everytime a header changes. The real problem is about how to check that binary (and semantics) compatibility is satisfied. Adding a function might be OK, but changing a type is not OK (at least not always; Jun Furuse had some work on it). The OCaml approach being to chomp all the interface in a single MD5 value, any meaningful change (including addition of a function) will prevent you from linking without recompiling. There were good remarks on the list on how a progressive hashing algorithm (allowing versioning) would be needed to improve that. > Does adding new functions to a module actually break binary backwards > compatibility in O'Caml? At least it breaks for bytecode, where simple indexes are used to get closures. But this is not the point: the compiler will not let you link anyway. I suppose this would be easily corrected if the semantics problem were solved. I have a strong feeling that what we need is a good versioning system, at the language or (probably simpler) library level. But the problem doesn't seem trivial, in particular if you want efficient checking for dynamic linking. Cheers, Jacques Garrigue ------------------- 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