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.5 required=5.0 tests=HTML_MESSAGE,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 7A56CBC0A for ; Thu, 21 Jun 2007 11:40:01 +0200 (CEST) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by concorde.inria.fr (8.13.6/8.13.6) with ESMTP id l5L9e0og001618 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 21 Jun 2007 11:40:00 +0200 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 4F8C42066E for ; Thu, 21 Jun 2007 11:39:56 +0200 (CEST) X-AuditID: c1b4fb3c-afe7ebb0000007e1-5b-467a476c5e5d Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 346B32000C for ; Thu, 21 Jun 2007 11:39:56 +0200 (CEST) Received: from esealmw115.eemea.ericsson.se ([153.88.200.6]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Jun 2007 11:39:56 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C7B3E8.2036FDED" Subject: ocaml dll in an Erlang runtime Date: Thu, 21 Jun 2007 11:39:54 +0200 Message-ID: <6616D98C65DD514BA2E1DDC5F92231550228B6EB@esealmw115.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ocaml dll in an Erlang runtime Thread-Index: Acez6B9SoC62G3ylSRyK2PhWLjoy1A== From: "Ulf Wiger (TN/EAB)" To: X-OriginalArrivalTime: 21 Jun 2007 09:39:56.0028 (UTC) FILETIME=[205FC3C0:01C7B3E8] X-Brightmail-Tracker: AAAAAA== X-j-chkmail-Score: MSGID : 467A4770.006 on concorde : j-chkmail score : XX : 5/20 0 0.000 -> 2 X-Miltered: at concorde with ID 467A4770.006 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 low-level:01 c-routines:01 runtime:01 parsing:01 numerically:01 threads:01 nodes:01 doable:01 This is a multi-part message in MIME format. ------_=_NextPart_001_01C7B3E8.2036FDED Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Would any of you be interested in prototyping a semi-tight coupling between Erlang and OCaml? A small group of Erlang programmers have started tossing the idea around, and with sufficient lack of detailed knowledge, it seems pretty reasonable. (: Motivation: We've been using Erlang in commercial products for over 10 years now, and it's taken about that long to get into a position where we're considered a viable player for mission-critical product development. In order to get there, we've also been extolling the virtues of functional programming in general, and often cited Ocaml as an example of how you don't have to sacrifice low-level performance. We feel that the ongoing paradigm shift towards multicore architectures is really helping our cause. There is much discussion about how to get all those legacy apps to work and scale on new hardware, and the advantages of functional/declarative programming are becoming more obvious. Erlang is very strong in the area of concurrency, distribution and fault-tolerance, but fairly weak when sequential performance is of the essence (especially number crunching). When Erlang performance isn't enough, we usually jump into C-routines linked into the Erlang runtime, with all the problems associated with that. Often, instead of risking system integrity, we live with the performance we can get out of Erlang. It would be nice if we could present Ocaml as a safe (and productive!) driver environment for things like parsing text-based protocols, numerically intensive tasks, and complex sequential algorithms. I've noticed that there have been some discussions about concurrency in Ocaml. From an Ocaml perspective, this binding could be a way to use Ocaml in distributed systems, where Erlang is used as a "systems glue" for supervision, load balancing, replication, etc. Idea: I'd like to explore the idea of running an Ocaml runtime in Erlang's memory space. Both languages are garbage-collected, and Erlang's linked-in driver interface allows for "drivers" that use their own threads. We could target only the multi-processor variant of Erlang, where this sort of cooperation becomes slightly easier. For a looser connection, Erlang's distribution protocol is documented, and allows for "C-nodes" (non-Erlang nodes) to connect to an Erlang cluster over TCP. One could actually start with talking via regular pipes, using a common serialization format, and then gradually making a tighter and tigher connection. I will make no false promises, like "if we do this, Ericsson will use it". I have no money to offer anyone, and we who have started looking at this on the erlang side have fairly little time to spend on it. Business as usual, in other words: no time, no money - just an idea that might be fun to explore. What say ye? Do you think it's doable? Would any of you be willing to assist, or offer advice? The Erlang docs have an Interoperability Tutorial: http://www.erlang.org/doc/tutorial/part_frame.html The Erlang Term serialization format, the Erlang Port Mapper Daemon protocol, and the Distributed Erlang protocol are documented in a slightly more obscure location. Download the source from http://www.erlang.org/download.html and read the text file otp_src_R11B-5/erts/emulator/internal_doc/erl_ext_dist.txt=20 If you feel that this is OT for the caml list, you can backmail me. Regards, Ulf Wiger Senior software architect Ericsson ------_=_NextPart_001_01C7B3E8.2036FDED Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ocaml dll in an Erlang runtime

Would any of you be interested in = prototyping a semi-tight coupling between Erlang and OCaml?

A small group of Erlang programmers = have started tossing the idea around, and with sufficient lack of = detailed knowledge, it seems pretty reasonable. (:


Motivation:

We've been using Erlang in commercial = products for over 10 years now, and it's taken about that long to get = into a position where we're considered a viable player for = mission-critical product development. In order to get there, we've also = been extolling the virtues of functional programming in general, and = often cited Ocaml as an example of how you don't have to sacrifice = low-level performance.

We feel that the ongoing paradigm shift = towards multicore architectures is really helping our cause. There is = much discussion about how to get all those legacy apps to work and scale = on new hardware, and the advantages of functional/declarative = programming are becoming more obvious.

Erlang is very strong in the area of = concurrency, distribution and fault-tolerance, but fairly weak when = sequential performance is of the essence (especially number crunching). = When Erlang performance isn't enough, we usually jump into C-routines = linked into the Erlang runtime, with all the problems associated with = that. Often, instead of risking system integrity, we live with the = performance we can get out of Erlang. It would be nice if we could = present Ocaml as a safe (and productive!) driver environment for things = like parsing text-based protocols, numerically intensive tasks, and = complex sequential algorithms.

I've noticed that there have been some = discussions about concurrency in Ocaml. From an Ocaml perspective, this = binding could be a way to use Ocaml in distributed systems, where Erlang = is used as a "systems glue" for supervision, load balancing, = replication, etc.

Idea:

I'd like to explore the idea of running = an Ocaml runtime in Erlang's memory space. Both languages are = garbage-collected, and Erlang's linked-in driver interface allows for = "drivers" that use their own threads. We could target only the = multi-processor variant of Erlang, where this sort of cooperation = becomes slightly easier.

For a looser connection, Erlang's = distribution protocol is documented, and allows for "C-nodes" = (non-Erlang nodes) to connect to an Erlang cluster over TCP. One could = actually start with talking via regular pipes, using a common = serialization format, and then gradually making a tighter and tigher = connection.


I will make no false promises, like = "if we do this, Ericsson will use it". I have no money to = offer anyone, and we who have started looking at this on the erlang side = have fairly little time to spend on it. Business as usual, in other = words: no time, no money - just an idea that might be fun to = explore.

What say ye? Do you think it's doable? = Would any of you be willing to assist, or offer advice?


The Erlang docs have an = Interoperability Tutorial:
http://www.erlang.org/doc/tutorial/part_frame.html<= /U>

The Erlang Term serialization format, = the Erlang Port Mapper Daemon protocol, and the Distributed Erlang = protocol are documented in a slightly more obscure location. Download = the source from http://www.erlang.org/download.html and read the text file = otp_src_R11B-5/erts/emulator/internal_doc/erl_ext_dist.txt

If you feel that this is OT for the = caml list, you can backmail me.

Regards,
Ulf Wiger
Senior software architect
Ericsson

------_=_NextPart_001_01C7B3E8.2036FDED--