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=1.2 required=5.0 tests=AWL,SPF_SOFTFAIL autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id BE65DBC69 for ; Mon, 25 Jun 2007 11:44:41 +0200 (CEST) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5P9ibta018362 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 25 Jun 2007 11:44:41 +0200 Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 823A4204D1; Mon, 25 Jun 2007 11:44:35 +0200 (CEST) X-AuditID: c1b4fb3e-af032bb0000007e1-ee-467f8e8349c1 Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 610AC20405; Mon, 25 Jun 2007 11:44:35 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jun 2007 11:44:34 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Caml-list] ocaml dll in an Erlang runtime Date: Mon, 25 Jun 2007 11:44:33 +0200 Message-ID: <6616D98C65DD514BA2E1DDC5F9223155022BC365@esealmw115.eemea.ericsson.se> In-Reply-To: <467B8230.9090904@inria.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Caml-list] ocaml dll in an Erlang runtime Thread-Index: Ace0o8AFkqapcSFnRreq6MOOzqUGjACYO2og References: <6616D98C65DD514BA2E1DDC5F92231550228B6EB@esealmw115.eemea.ericsson.se> <467B8230.9090904@inria.fr> From: "Ulf Wiger (TN/EAB)" To: "Xavier Leroy" Cc: X-OriginalArrivalTime: 25 Jun 2007 09:44:34.0829 (UTC) FILETIME=[70346BD0:01C7B70D] X-Brightmail-Tracker: AAAAAA== X-Miltered: at concorde with ID 467F8E85.004 by Joe's j-chkmail (http://j-chkmail . ensmp . fr)! X-Spam: no; 0.00; ocaml:01 erlang:01 runtime:01 prototyping:01 datatype:01 low-level:01 erlang:01 parsing:01 syntax:01 syntax:01 decoding:01 compiler:01 pointer:01 conceptually:01 first-order:01 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=20 > "universal" type of the dynamically-typed language, e.g.=20 > S-exprs in the case of Lisp, and provide low-level interface=20 > 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=3D>. The native code compiler in Erlang understands=20 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=20 > directions. It might be possible to encapsulate Erlang=20 > functions as an abstract Caml type, with an appropriate=20 > "apply" primitive. I don't know if this can be made to work=20 > in the other direction, e.g. encapsulate Caml functions as=20 > some opaque thing on the Erlang side. At any rate, for many=20 > applications, exchange of first-order data structures can > be enough. Function values are only passed by reference between=20 erlang nodes, so evaluating them only works if the=20 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=20 course be passed along as an opaque value. If this representation were used when communicating, it might be possible (but perhaps quite strange) to=20 represent OCaml functions in the same way, such that=20 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=20 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