[
Home
]
[ Index:
by date
|
by threads
]
[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
[ 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