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

[Gerd Stolpmann <info@gerd-stolpmann.de>]

Fergus Henderson wrote:
> 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 don't know Mercury but C++. Actually, it does not ensure proper
typing between compilation units! The .o files do not contain types,
and it is up to the programmer to include the right prototypes.

> 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?

It is also a matter of typing because even toplevel modules can be
used to parameterize functors. So adding a new function may break
functor applications.

My point is not that it is impossible to flexibilize linking, but that
it is not simple to do so. I think typing should be strict even across
compilation units, and that the programming environment must check
it. Strict typing also means to ensure compatible memory layouts but
this is not the only meaning. For example, it must be still possible to
hide the representation of types.

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

I think you mean "independent compilation" here, i.e. the linker does
not check proper typing. It is simple to make errors that are hard to
find. You need expert knowledge to find out which changes are binary
compatible and which not. Better we don't have it.

Gerd

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