pcre, bifs, drivers and ports

[Romain Lenglet]

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 
BIFs.

-- 
Romain LENGLET