While using serialized streams of data between processes is the easiest 
interoperability approach it is also the slowest of the two supported by 
Erlang run-time.  In the second approach that uses the same address 
space Erlang maintains a pool of OS threads separate from the ones 
executing Erlang byte-code that can be used to make asynchronous 
blocking calls of C functions.  If this model is used as far as I 
understand separate Caml run-times would have to be initialized per 
pooled thread managed by Erlang.  Otherwise garbage collection on the 
Caml side (that uses a single mutex) would block all pooled OS threads 
currently executing Caml closures while being garbage collected that 
would penalize performance.  Is this a feasible approach?  Would it lead 
to too much of memory overhead?  (Erlang doesn't have the same issue 
because user-level light-weight processes don't share heaps and garbage 
collection happens on a light-weight process level without stalling 
other processes).

Serge


Xavier Leroy wrote:
>> 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
> 
> _______________________________________________
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>