Version française
Home     About     Download     Resources     Contact us    
Browse thread
Working around the brittle bindings problem
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Jacques Garrigue <garrigue@m...>
Subject: Re: [Caml-list] Working around the brittle bindings problem
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