Announcing Dryverl: an Erlang-to-C binding compiler

[Serge Aleynikov]

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
     Example:
        Erlang:  get_value_from_some_api_call() -> Value::integer()

                     invokes

        C:       int some_api_call(int* value);
                 Returns: 0    - ok,
                         -1    - error
                         value - this is something useful to be returned
                                 to Erlang

    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
                  State structure

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.

etc.

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.

Regards,

Serge

Richard A. O'Keefe wrote:
> bryan rasmussen asked
>         > Why are the bindings specified in an XML Schema?
> 
> and
> Romain Lenglet <rlenglet@REDACTED> 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?