Thank you for your comments, Xavier.

(It does seem as if some prototyping will take
place in the near future.)

Xavier Leroy wrote:

> One approach is to define a Caml datatype that reflects the 
> "universal" type of the dynamically-typed language, e.g. 
> S-exprs in the case of Lisp, and provide low-level interface 
> functions to exchange values of this type.

One might also have a look at the Erlang binary type. (:

Actually, this is not as corny as it sounds.
You could pass a parsing declaration in the form
of Erlang bit syntax expressions, and compile an
encode/decode module on the fly on the Erlang side.

Examples of the bit syntax can be found here:
http://www.erlang.org//doc/programming_examples/bit_syntax.html#4

And there's a (currently experimental) new version
of binary handling called "binary comprehensions"
(c.f. list comprehensions, but on bits or bytes)

http://user.it.uu.se/~pergu/papers/erlang05.pdf

Here's a very small example of decoding with the
help of binary comprehensions, from above paper:

uudecode(UUencodedBin) ->
<<(X-32):6 || X <<- UUencodedBin, 32=<X, X=<95>>.

The native code compiler in Erlang understands 
the bit syntax and optimizes the matching, so working
directly on binary objects in Erlang is both reasonably
expressive and quite efficient.

Large binaries are reference-counted in Erlang,
and passed by pointer reference between processes
(under the covers - conceptually, they're copied).


> Function values can be difficult to exchange in both 
> directions.  It might be possible to encapsulate Erlang 
> functions as an abstract Caml type, with an appropriate 
> "apply" primitive.  I don't know if this can be made to work 
> in the other direction, e.g. encapsulate Caml functions as 
> some opaque thing on the Erlang side.  At any rate, for many 
> applications, exchange of first-order data structures can
> be enough.

Function values are only passed by reference between 
erlang nodes, so evaluating them only works if the 
right module is loaded on the remote end (a hash value
is passed along to ensure that the wrong function isn't
evaluated.) Even if it can't be evaluated, it can of 
course be passed along as an opaque value.

If this representation were used when communicating,
it might be possible (but perhaps quite strange) to 
represent OCaml functions in the same way, such that 
they cannot be confused with Erlang functions.

This would make it possible to pass function values
by reference between the two environments, but each
reference would only actually be callable in its native
environment.

In order to send an OCaml function value through the 
Erlang environment to an OCaml recipient, I guess an
appropriate encapsulation is needed, which would look
like a binary object to the Erlang side.

BR,
Ulf W