Language Bindings for Erlang Again
Tue Jun 6 09:34:38 CEST 2006
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
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
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.
More information about the erlang-questions