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: 2002-03-12 (22:00)
From: Gerd Stolpmann <info@g...>
Subject: Re: [Caml-list] The DLL-hell of O'Caml

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."  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.

An example: The old version defines a function 

(* OLD: *) val f : int -> int

and the new version changes the signature into

(* NEW: *) val f : ?option:bool -> int -> int

If "normal usage" means that f is only applied, the new version will be backwards compatible.
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
- The module defining f can be used as parameter of a functor. The new version has a different
  signature, and is not accepted as parameter any more.

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

I am not an expert, and I do not know how the optional arguments exactly work, but it is
possible that the representation of the closure f has changed, too. In general, I expect
that "source-level" compatible modifications may change the representation of values.

Inlining is another reason (only for ocamlopt), but this can be turned off.

Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:
To unsubscribe, mail Archives:
Bug reports: FAQ:
Beginner's list: