Announcing Dryverl: an Erlang-to-C binding compiler

[Romain Lenglet]

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?

Not for this language, see below.

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

Apart from the better readibility of Erlang terms compared with 
XML elements, what are "Erlang's better ways?"

I actually agree with you that XML should be avoided when there 
are better alternatives (and most often there are), but I 
believe that for this language there are no better alternatives.

> So what am I missing here?

XSLT is a nice standard language for writing transformations.
And there are a lot of tools around XML (for validating 
documents, etc.).


1- I completely agree that XML makes the language verbose.
However, although Dryverl is very usable as-is, Dryverl is mainly 
intended to be the "assembly language" of binding 
specifications.
The language is very general and flexible, and is usable to 
implement any binding. There is room for higher-level languages 
for simpler, specific cases, that would be compiled into the 
Dryverl language.
>From that viewpoint, the XML specifications would be generated by 
tools from (hopely) more human-readable languages. 
Human-readibility is therefore a secondary issue for Dryverl.


2- The Dryverl language is in fact composed of XML + two 
dialects: an Erlang-XML dialect, and a C-XML dialect.
For instance, an actual piece of specification is:

      <c-call-variable name="major_status"/> =
        gss_acquire_cred(
          &<c-call-variable name="minor_status"/>,
          <c-call-variable name="desired_name"/>,
          <c-call-variable name="time_req"/>,
          <c-call-variable name="desired_mechs"/>,
          <c-call-variable name="cred_usage"/>,
          &<c-call-variable name="output_cred_handle"/>,
          &<c-call-variable name="actual_mechs"/>,
          &<c-call-variable name="time_rec"/>);
        if (GSS_CALLING_ERROR(
          <c-call-variable name="major_status"/>)) {
          <failure-atom>
            GSS_CALLING_ERROR_TO_STRING(<c-call-variable 
name="major_status"/>)
          </failure-atom>
        }

This fragment of C-XML dialect code is a call to a C GSSAPI 
function. There is as much C code text as XML elements. This 
fits XML and XSLT very well.
This is not a purely structured tree, i.e. there are not only XML 
elements: there are many large text() nodes. I am not convinced 
that "Erlang has better ways" to deal with such dialects.

In Erlang, if we roughly follow the same structure as for DOM, 
the fragment above would be written as the following Erlang 
term:

{{c-call-variable, "major_status},
    "= gss_acquire_cred(&",
      {c-call-variable, "minor_status"}, ",",
      {c-call-variable, "desired_name"}, ",",
      {c-call-variable, "time_req"}, ",",
      {c-call-variable, "desired_mechs"}, ",",
      {c-call-variable, "cred_usage"}, ",",
      "&", {c-call-variable, "output_cred_handle"}, ",",
      "&", {c-call-variable, "actual_mechs"}, ",",
      "&", {c-call-variable, "time_rec"}, ");",
  "if (GSS_CALLING_ERROR(",
    {c-call-variable, "major_status"}, ")) {",
      {failure-atom,
        {"GSS_CALLING_ERROR_TO_STRING(",
         {c-call-variable, "major_status"},
         ")"
        }
      }
    "}"
}

Is that really more readable? Is that "a better way?"
I don't think so.

Maybe a pure-Erlang-terms approach would be appropriate if all 
the language was structured (i.e. no CDATA, and only XML 
elements), but that is not appropriate for *this* language. 
Maybe you would want to define the complete grammars of those 
two dialects of C and Erlang, which would be extensions of the 
general grammars of C and Erlang, but I don't want to go into 
such troubles (since I don't need to!).


I invite you to read the project main web page, and to actually 
read the language's XML Schema:
http://dryverl.objectweb.org/
However, the page that would best answer your questions 
(the "workplan") is not yet written, sorry.

-- 
Romain LENGLET