From: Fergus Henderson <fjh@cs.mu.OZ.AU>

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

Could you specify what benefits?
The current situation in OCaml is that you have to recompile all
dependencies everytime you change anything in the interface.
If you use a Makefile, even changing a comment will trigger a
recompilation.
But, in my experience most C makefiles are written in the same way
meaning that you have to recompile everytime a header changes.

The real problem is about how to check that binary (and semantics)
compatibility is satisfied. Adding a function might be OK, but
changing a type is not OK (at least not always; Jun Furuse had some
work on it).
The OCaml approach being to chomp all the interface in a single MD5
value, any meaningful change (including addition of a function) will
prevent you from linking without recompiling.
There were good remarks on the list on how a progressive hashing
algorithm (allowing versioning) would be needed to improve that.

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

At least it breaks for bytecode, where simple indexes are used to get
closures.
But this is not the point: the compiler will not let you link anyway.
I suppose this would be easily corrected if the semantics problem were
solved.

I have a strong feeling that what we need is a good versioning system,
at the language or (probably simpler) library level. But the problem
doesn't seem trivial, in particular if you want efficient checking for
dynamic linking.

Cheers,

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