Announcing Dryverl: an Erlang-to-C binding compiler
Fri May 26 13:21:56 CEST 2006
If one merely looks at the XML schema definition, it does look too
verbose. However, if you have prior experience with EDTK, you would
discover that many EDTK limitations have been overcome by this project,
just to name a few:
1. Use of ei instead of erl_interface way of coding.
2. Ability to return "out" C-call parameters to Erlang
Erlang: get_value_from_some_api_call() -> Value::integer()
C: int some_api_call(int* value);
Returns: 0 - ok,
-1 - error
value - this is something useful to be returned
with EDTK it would be necessary to write a C-wrapper for the
some_api_call() that would look like this, as it doesn't understand
returning parameters by reference:
int some_api_call_wrapper(struct EdtkInternalState* State)
Returns: Integer value to be returned to Erlang
The ok/error code is stored in the EDTK's internal
2. Ability to define a partial set of parameters in a C function call to
be returned to Erlang:
Erlang: call_c_function(A, B, C, D, E) -> Result
C: c_function(F, G) -> result
The XML binding defines parameter marchaling rules.
4. Automatic selection of erlang:port_command/2 and erlang:port_call/3
depending on the presence of binary parameters passed to/from Erlang to
gain speed, and avoid unnecessary copying of binaries.
5. Use of hash tables for fast access to internal variables by name/id.
6. Support of XSLT-based code generators (instead of iMatrix's codegen
with proprietary syntax).
7. Support for edoc tags.
To summarize this, I believe Dryverl is a very good leap towards making
a flexible definition of Erlang/C binings using open source code
generation tools based on XSLT. Yes, it is verbose, but that
verboseness gives the programmer very good control of every aspect of
data marshaling between Erlang & C. Its main merit in taking the best
of EDTK's experience and creating a more flexible marshaling language.
Could it be done in Erlang?
It consists of three types of XML/XSLT documents:
1. XML schema that defines XML elements and constraints
2. XSLT templates used to transform a user's XML document
into Erlang & C code compilable into an C linked-in or port driver.
3. An XML document that a user needs to write in order to
define interface to some API library in C.
Of course these could be done in Erlang, but what value could Erlang's
syntax or tools add to this approach to make it less verbose?
Overall, if you have a need for implementing a C driver for Erlang, I
suggest you to try this tool, as in the long run it will save you quite
a bit of coding/debugging time.
Richard A. O'Keefe wrote:
> bryan rasmussen asked
> > Why are the bindings specified in an XML Schema?
> Romain Lenglet <> replied
> The *language* that is used to specify bindings is specified in
> an XML Schema.
> Yes, but why specify the bindings in XML?
> This is for an Erlang interface, so surely an Erlang data structure
> would have been a lot more readable?
> XML really wasn't designed to be human-readable (and by and large, it isn't)
> or human-writable (and by and large, it isn't).
> Let's face it, XML is just an over-hyped and absurdly bulky way to write
> trees, and Erlang has better ways.
> So what am I missing here?
More information about the erlang-questions