pcre, bifs, drivers and ports
Tue Aug 1 05:18:24 CEST 2006
Mats Cronqvist wrote:
> it would be grand if i could write my glue code once, and
> have a tool generate a linked-in driver, a port program, a bif
> or a c-node from that. this is (i think) the goal of dryverl,
> but i'm too dense to figure it out...
I prefer letting BIFs out of the scope of Dryverl. I don't think
that it is possible to unify *nicely* BIFs, drivers, ports and
nodes. Dryverl aims at hiding the differences between drivers,
ports and nodes. Those have in common that exchanged data must
be (un)marshalled, which is not necessary with BIFs. Dryverl
explicitly considers that (un)marshalling occurs. Maybe the
Dryverl language could be modified to fit BIFs also, but I am
not sure how to do that nicely.
A reviewer of the ACM Erlang Workshop pointed me at Haskell's
GreenCard, which handles nicely the case when interfacing with C
code does not require (un)marshalling, since the Haskell
compiler generates C code which can then be finely blended with
external C code. This does not fit drivers, ports or nodes,
where the C code to integrate is isolated from the emulator and
therefore from the Erlang code, but seems to fit BIFs well.
However, this is a different goal and design than Dryverl's.
Moreover, if one day we have a way to easily write BIFs, with
cleanly reified emulator internals, etc., then we would no more
need to use drivers. Using linked-in drivers for anything else
than what this mechanism was designed for (I/O drivers!) is a
perversion, and is currently necessary only because it is
difficult to write BIFs.
Then the problem boils down to unifying BIFs, ports and nodes.
Probably it would be necessary to first develop a nice C API
which would mask the differences between mechanisms on the C
side. erl_interface is currently not sufficient nor appropriate,
since it focuses on (un)marshalling of terms, which does not fit
More information about the erlang-questions