Re: [Caml-list] The DLL-hell of O'Caml

[Xavier Leroy <xavier.leroy@inria.fr>]

> 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