From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=AWL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from discorde.inria.fr (discorde.inria.fr [192.93.2.38]) by yquem.inria.fr (Postfix) with ESMTP id C3F02BC6B for ; Fri, 22 Jun 2007 10:02:57 +0200 (CEST) Received: from [128.93.11.95] (estephe.inria.fr [128.93.11.95]) by discorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5M82uOx015898; Fri, 22 Jun 2007 10:02:56 +0200 Message-ID: <467B8230.9090904@inria.fr> Date: Fri, 22 Jun 2007 10:02:56 +0200 From: Xavier Leroy User-Agent: Thunderbird 1.5.0.7 (X11/20060915) MIME-Version: 1.0 To: "Ulf Wiger (TN/EAB)" Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] ocaml dll in an Erlang runtime References: <6616D98C65DD514BA2E1DDC5F92231550228B6EB@esealmw115.eemea.ericsson.se> In-Reply-To: <6616D98C65DD514BA2E1DDC5F92231550228B6EB@esealmw115.eemea.ericsson.se> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Miltered: at discorde with ID 467B8230.000 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 erlang:01 runtime:01 prototyping:01 coupling:01 erlang:01 ocaml:01 doable:01 interop:01 doable:01 statically:01 datatype:01 low-level:01 markus:01 mottl's:01 > 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