Re: [Caml-list] ocaml dll in an Erlang runtime

[Xavier Leroy <Xavier.Leroy@inria.fr>]

> Would any of you be interested in prototyping a semi-tight coupling
> between Erlang and OCaml? [...] Do you think it's doable?

I haven't looked closely at the Erlang interop facilities, but I think
it is doable.  Here are some remarks based on previous
interoperability experiences with Caml.

The first step is to find a good mapping between data structures of
the two languages.  When both are statically typed, this can be
difficult as both type systems try to impose their views.
When at least one of the languages is dynamically typed, it's easier.

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.

Conversions between this Caml representation of the universal type and
regular Caml data structures can be written manually in Caml, or maybe
automatically generated in the style of Markus Mottl's Sexplib tool
or Jeremy Yallop's Deriving mechanism.

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.

If the Caml code and the Erlang code live in the same address space,
the actual exchange of data can be done through the C interfaces of
both languages.  This is what we did for the Caml/Java interface,
going through the Java Native Interface and OCaml's C interface.
The two GC can be made to cooperate.  However, data cycles that spawn
the two heaps will never be garbage-collected.

As others mentioned, it is possible to encapsulate Caml code and the
Caml runtime system as a DLL, at least for x86 under Linux and Windows.
For the Caml/Java interface, we used the reverse embedding: the Caml
code would link with the Java runtime system (as a library), which
would then load the Java code.

Apparently, Erlang makes it possible to communicate between separate
processes using byte streams.  This is an original feature that could
significantly simplify the interface: the Caml side could be written
entirely in Caml, bypassing low-level C interface code.

I guess that's all I can say at this point, but feel free to ask
questions.

- Xavier Leroy