Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] The DLL-hell of O'Caml
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Fergus Henderson <fjh@c...>
Subject: Re: [Caml-list] The DLL-hell of O'Caml
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 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?

> > Can you
> > give a specific example?
> Usually, a new version of a library modifies the signature. Ok, these
> are often only minor modifications: some new functions, new optional
> arguments etc., and normally the new version is "source-level" compatible
> with the old version. "Source-level" means that "normal" usage does not
> cause incompatibilities.

In Mercury and C++, often changes are not completely source-level
compatible, but nevertheless preserve binary compatibility.
For example, adding a new function may introduce new ambiguity errors in
existing source code, in case the same name occurs in a different module.
However, binaries will always refer to the fully-qualified name, so they
won't be affected by such ambiguities.

> But there are cases where the compiler indicates a typing error:
> - You can pass f as such around. This makes a difference because the type of f is different
>   and the deduced types will be different, and it may happen that the deduced types cannot
>   be accepted, because sometimes the optional argument is automatically dropped and sometimes
>   not.

Well, if you changed the interface to `f', e.g. by adding an optional
argument, that is not a binary-backwards-compatible change.
The same happens in C++ if you add an optional argument.

> So one precondition of replacing the library is that the signatures are
> identical. Even small changes cannot be tolerated.

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.

Does adding new functions to a module actually break binary backwards
compatibility in O'Caml?

Fergus Henderson <>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <>  |     -- the last words of T. S. Garp.
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: