[erlang-questions] Wrapping C libraries in pure Erlang

Denis Bilenko <>
Sun Apr 29 00:13:03 CEST 2007


I have started the project here
http://code.google.com/p/effi/

Right now, it is very limited and needs windows to run and msvc to compile,
but if you tolerate that it can be used to call simple functions.
Check out an example
http://effi.googlecode.com/svn/trunk/examples/msgbox.erl
it shows how to call function in an emulator's thread and in a thread from
pool (using driver_async(); must run erl with +A option)

For practical use, it lacks pointers, in/out arguments, structs and callbacks.
I also think that exposing driver_select API may be useful.
Porting to other platforms must be trivial, since libffi itself is
cross-platform.

BTW, I have found CFFI project, which does the same thing for Common Lisp.
You can read about their motivation here
http://common-lisp.net/project/cffi/manual/html_node/Tutorial_002dComparison.html
To quote that document:
> Perhaps the greatest advantage is that using an FFI doesn't obligate you to
> become a professional binding developer. Writers of bindings for other
> languages usually end up maintaining or failing to maintain complete bindings
> to the foreign library. Using an FFI, however, means if you only need one or
> two functions, you can write bindings for only those functions, and be assured
> that you can just as easily add to the bindings if need be.

The "professional binding developer" part is very relevant to Erlang.
erl_driver et al. impose too much headache for casual bindings development:
There is ERL_DRV_INT, but no ERL_UINT nor ERL_LONGLONG? (ok, this is not
really a question:)
port_call, port_command, port_control, Port ! {self(), {command, Data}},
am I missing something else - which one to use, when and why? (some answers can
be found in the list archives and in the documentation, but still, too much
low-level details)
Having easy yet powerful enough (and fast) Erlang-based middle layer will help
many library developers. I invite everyone to join the project!

Denis.



More information about the erlang-questions mailing list