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 VAA09285; Wed, 20 Mar 2002 21:39:28 +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 VAA26122 for ; Wed, 20 Mar 2002 21:39:27 +0100 (MET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g2KKdP904841; Wed, 20 Mar 2002 21:39:25 +0100 (MET) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA25274; Wed, 20 Mar 2002 21:39:25 +0100 (MET) Date: Wed, 20 Mar 2002 21:39:25 +0100 From: Xavier Leroy To: Gerd Stolpmann Cc: =?iso-8859-1?Q?Johan_Georg_Granstr=F6m?= , caml-list@inria.fr Subject: Re: [Caml-list] The DLL-hell of O'Caml Message-ID: <20020320213925.A25391@pauillac.inria.fr> 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> <3C989156.6010906@gerd-stolpmann.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3C989156.6010906@gerd-stolpmann.de>; from info@gerd-stolpmann.de on Wed, Mar 20, 2002 at 02:40:38PM +0100 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > 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? A manifest module type declaration in a signature must match exactly the corresponding module type definition in the structure. But you're correct that a structure with a given signature S can always match a signature S' that is less restrictive, e.g. S has one more function than S'. Concerning the compilation of accesses inside modules: it is true that structure components are accessed primarily by position ("fetch the N-th component defined in this module"); access by name is only used by ocamlopt for calls to known functions. This doesn't conflict with the ability to forget structure components: at the same time that the compiler checks that a structure with signature S can be used with signature S' :> S, it also generates adapter code that reorders the components of the structure to match what S' expects. So, subtyping between module types and the associated generation of adapter code handles perfectly well compatible extensions of an existing module. Now, you will ask: why doesn't this work for multiple versions of a compilation unit? Why doesn't the linker check subtyping and generate adapter code? Well, it could work *if* every compilation unit came with the complete signatures of all compilation units it refers. Say, unit A references B and was compiled under the assumption B : SIGB. Then, we link A with another implementation of B that has signature SIGB'. If the linker knew both SIGB and SIGB', it could check SIGB' <: SIGB and adapt A's references to B's components accordingly. But A.cmo does not contain SIGB -- only a mention of B and a hash of SIGB. The reason is quite simple: A.cmo would be *huge* if it included a copy of the signatures of every module it refers, either directly or indirectly. (Think several megabytes.) Having only hashes of signatures, all the linker can check is hash(SIGB) = hash(SIGB'), that is SIGB = SIGB'. > 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. This is another good point: even if we allowed SIGB' <: SIGB at link-time instead of requiring SIGB = SIGB', there are many "reasonable" changes in a signature that would break subtyping, like those you mention above. And this is inevitable: these changes could break type-safety of existing programs. To summarize: I believe binary compatibility doesn't really work in a strongly, statically-typed language. It sometimes works for dynamically-typed or weakly-typed languages (Perl, C), although run-time failures are not unheard of. Copious link-time re-type-checking as in Java makes it work sometimes too, although on close examination Java's binary compatibility rules are quite complex and restrictive. Conclusion for OCaml? Forget about binary compatibility, binary-only distributions, versioning, and all that. All we need for OCaml libraries is source distribution, a standardized re-building procedure, and a place to record cross-library dependencies, so that everything that needs to be recompiled when something changes can be recompiled automatically. Something like a source RPM or Debian package, or a BSD port. I believe this is a much more reasonable objective than dreaming about binary compatibility and whatnot. Still, it's not trivial: the authors of existing OCaml libraries (myself included) have some work to do to implement fully automatic build of their libraries... - Xavier Leroy ------------------- 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