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
  not.
- 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
-- 
----------------------------------------------------------------------------
Gerd Stolpmann      Telefon: +49 6151 997705 (privat)
Viktoriastr. 45             
64293 Darmstadt     EMail:   gerd@gerd-stolpmann.de
Germany                     
----------------------------------------------------------------------------
-------------------
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