Language Bindings for Erlang Again

[Romain Lenglet]

Michel Urvoy wrote:
> I had a look to that post, last month.
> The only point I wonder is why experiment Dryverl on a C
> binding, that is already improved, instead of  another
> language that is not covered.

Which one? We already have: Java, Ada, Python, Lisp... What do 
you miss? It is quite easy to develop a new library in your 
preferred language to interact remotely with an Erlang node, 
similar to erl_interface and j_interface.
This is really simple: you need to implement functions to 
encode/decode terms into/from the external format, and handle 
the simple (AFAIK) protocols.

In addition, if in your language you can read and write from the 
standard input and output, then you can already implement C port 
programs. That's it. I don't know of any useful programming 
language that prevents one from reading and writing from the 
standard input and output, but if you know one you may list it 
as "not covered".


But maybe what you meant is that you want "intimate" bindings 
between Erlang code and code in another languages, even more 
intimate than C port drivers?

One limitation/advantage (depending on the viewpoint) of the 
Erlang emulator is that all the emulator internals are insulated 
from any kind of extension, even to the most intimate (C port 
drivers). One cannot directly interact with the emulator 
internals to spawn processes, etc.
C port drivers have only a limited API to interact with the 
emulator, and guess what? That API is in C.
So, if your intent is to implement port drivers in other 
languages than C, you will have anyway to have small stubs in C, 
at least to define your driver entry struct, with the right 
function pointers.
It should be feasable for instance to write your driver in Java, 
compile it to binary using GCJ, and add C stubs to make it a C 
port driver (to make the emulator call the right static methods 
in your program).

My first point is: Erlang/C bindings are for now needed as a 
basis to implement bindings to any other kind of language as C 
port drivers. If you don't really need the efficiency (and the 
complexity!) of port drivers, you can write an 
erl_interface-like library in your language.

My second point is: do not expect to have soon a way to bind 
intimately Erlang and other languages (even C), like using 
Java's JNI or Python/C API, because the internals of the 
emulator are not accessible, and making them accessible seems 
not to be planned, and is certainly not a trivial task.

IMHO, I am not sure anyway that opening the internals is a good 
idea. This lets the Erlang/OTP developers free to make big 
changes in the emulator without having to bother 
about "too-intimate" interfaces that may be broken by the 
changes. For instance, switching from one thread to multiple 
threads in the R11Bx emulator may have been difficult or 
impossible if such internal details affected extensions.
I prefer having an emulator that is able to undercome big changes 
easily and transparently, than having efficient, intimate 
extension mechanisms.
Erlang already has its share of legacy parts... the port driver 
API being one of them. ;-)



The long term, right approach would be to open the internals of 
the emulator a little, but by reifying them cleanly, and to let 
users write and load/unload dynamically their own BIFs. To 
define the cleanest interface, C may not be the "primary" 
language here, but Ulf Wiger proposed to use Felix instead.
A lot of work has to be done on this. Your contributions in code 
and ideas will be welcome.


Regards,

-- 
Romain LENGLET