Announcing Dryverl: an Erlang-to-C binding compiler

[David Hopwood]

Romain Lenglet wrote:
> Richard A. O'Keefe wrote:
> 
>>Yes, but why specify the bindings in XML?
[...]
> 
> 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. 

I don't see the point of this extra layer. (Actually, I don't see
the point of trying to encode programming language code in XML, ever.)

> 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?"

No, but I would be strongly inclined to write it as

#include "dryverl.h"
...

CCV(major_status) = gss_acquire_cred(
                        &CCV(minor_status),
                        CCV(desired_name),
                        CCV(time_req),
                        CCV(desired_mechs),
                        CCV(cred_usage),
                        &CCV(output_cred_handle),
                        &CCV(actual_mechs),
                        &CCV(time_rec));

if (GSS_CALLING_ERROR(CCV(major_status))) {
    dryverl_failure_atom(GSS_CALLING_ERROR_TO_STRING(CCV(major_status)));
}

which is certainly more readable than either of the versions above --
and can be expanded to much the same thing just by running it through
the C preprocessor.

I would also try to get rid of the need for CCV() if at all possible
(maybe by telling Dryverl any information it needs about a variable
only at its declaration, rather than every use).

-- 
David Hopwood <david.nospam.hopwood@REDACTED>