From: Jacques Garrigue <garrigue@math.nagoya-u.ac.jp>
To: jon@ffconsultancy.com
Cc: caml-list@inria.fr
Subject: Re: [Caml-list] Working around the brittle bindings problem
Date: Fri, 25 Jan 2008 11:31:13 +0900 (JST) [thread overview]
Message-ID: <20080125.113113.104032782.garrigue@math.nagoya-u.ac.jp> (raw)
In-Reply-To: <200801242140.06785.jon@ffconsultancy.com>
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
next prev parent reply other threads:[~2008-01-25 2:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-24 21:40 Jon Harrop
2008-01-25 2:31 ` Jacques Garrigue [this message]
2008-01-25 4:10 ` [Caml-list] " Jon Harrop
2008-01-25 7:21 ` Alain Frisch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20080125.113113.104032782.garrigue@math.nagoya-u.ac.jp \
--to=garrigue@math.nagoya-u.ac.jp \
--cc=caml-list@inria.fr \
--cc=jon@ffconsultancy.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox