Working around the brittle bindings problem

Working around the brittle bindings problem

[Jon Harrop]

Just occurred to me that one possible solution to our brittle bindings problem 
might be to parameterize the whole library over the external calls that are 
made. That could at least make the compiled code dependent only upon the 
version of the OCaml compiler itself and not each separate library.

Is it possible to do this using a functor? I might have to wrap the entire 
library in one giant functor but that would let the user apply the functor to 
a suitable library module in order to obtain a working implementation. Am I 
right in thinking that the result would depend only upon my interface and no 
upon the library itself (e.g. LablGL)?

If this is correct then it is probably solvable. The next best solution would 
be to open source the shim that automates this gore.

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Working around the brittle bindings problem

[Jacques Garrigue]

From: Jon Harrop <jon@ffconsultancy.com>

> Just occurred to me that one possible solution to our brittle
> bindings problem might be to parameterize the whole library over the
> external calls that are made. That could at least make the compiled
> code dependent only upon the version of the OCaml compiler itself
> and not each separate library.
> 
> Is it possible to do this using a functor? I might have to wrap the
> entire library in one giant functor but that would let the user
> apply the functor to a suitable library module in order to obtain a
> working implementation. Am I right in thinking that the result would
> depend only upon my interface and no upon the library itself
> (e.g. LablGL)?

This looks like a good idea. This way you can choose the set of
functions you depend upon. This means essentially copying and
trimming down mlis. Then you just need to provide the source code for
the linking bits, that is a big functor application.

This would protect you from checksums changing due to the addition of
new functions, or from compatible changes in function types (i.e.,
types are equal according to ocaml expansion rules). This will not
protect you from a real change in function type at the interface (like
the addition of a new tag in a type, or of an extra optional
argument), or from a change in the compiler itself.
If you want maximal protection, you should apply the same approach to
standard library modules too, so that compiler changes that do not
alter the .cmi format would be allowed, but this is going to be painful.
There may also be a performance hit as the function calls get a bit
more costly (this should only matter for really fast functions, not
for openGL calls).

Jacques Garrigue

Re: [Caml-list] Working around the brittle bindings problem

[Jon Harrop]

On Friday 25 January 2008 02:31:13 you wrote:
> This looks like a good idea. This way you can choose the set of
> functions you depend upon. This means essentially copying and
> trimming down mlis. Then you just need to provide the source code for
> the linking bits, that is a big functor application.
>
> This would protect you from checksums changing due to the addition of
> new functions, or from compatible changes in function types (i.e.,
> types are equal according to ocaml expansion rules). This will not
> protect you from a real change in function type at the interface (like
> the addition of a new tag in a type, or of an extra optional
> argument), or from a change in the compiler itself.
> If you want maximal protection, you should apply the same approach to
> standard library modules too, so that compiler changes that do not
> alter the .cmi format would be allowed, but this is going to be painful.
> There may also be a performance hit as the function calls get a bit
> more costly (this should only matter for really fast functions, not
> for openGL calls).

Awesome! I'll try to get this done ASAP. I think I'll leave the dependency 
upon the compiler because it would be too painful to remove, as you say, but 
the rest should be doable and will make my recompilation nightmares a thing 
of the past!

I'll post back with my findings... :-)

-- 
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e

Re: [Caml-list] Working around the brittle bindings problem

[Alain Frisch]

Jon Harrop wrote:
> Just occurred to me that one possible solution to our brittle bindings problem 
> might be to parameterize the whole library over the external calls that are 
> made.

Indeed, that's a brilliant idea. Btw, it has been suggested to you a few 
weeks ago.

http://groups.google.com/group/fa.caml/msg/cc6adc628b396b06:
> What you can do is to ship your library as a single module abstracted
> over all its dependencies (that is, a functor which takes as arguments
> modules from the stdlib and other dependent libraries). You can put in
> the interface whatever you expect from these modules, so the same
> functor could be used with future versions if they only add new fields
> (but not new constructors or record fields, for instance). Again, some
> Camlp4 hack could somewhat automate this. 



-- Alain