On 12-Mar-2002, Gerd Stolpmann <info@gerd-stolpmann.de> 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 <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
-------------------
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