Announcing Dryverl: an Erlang-to-C binding compiler

[Richard A. O'Keefe]

Romain Lenglet <rlenglet@REDACTED> wrote:
	XSLT is a nice standard language for writing transformations.

It is a language.  True.
It is a language for writing transformations.
It is not a de jure standard, but it's true that it is a de facto one.
"Nice", however, doesn't really fit in that sentence.
Not without some emphatic negatives attached rather closely.

I described XML as absurdly bulky and not humanly readable.
The same could be said of XSLT, if one wished to demonstrate
the art of underemphasis.

XSLT is an unholy mix of at least three different syntaxes, not just
different in detail, but working on different principles.  It includes
two different subsets of XPath, with not-quite-compatible semantics.

I have half a dozen XSLT implementations on my machine.
But I found that writing XML transformations in Scheme was SEVEN TIMES
SHORTER.  Heck, even writing transformations in *C* was about five times
shorter.  (Mind you, that's with my own dvm2 library, but still...)
About the only thing that could make me write XSLT would be very large
sums of money, or possibly a gun to my head.

	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>
	        }
	
When I said that Erlang had better ways than using XML, I wasn't confining
myself to pure Erlang data structures.  The design of little languages is
an art that should not be lost just because XML exists.  The great merit
of little languages is that they can help us three major ways:

    (1) They can make it much easier to write what we do want.
        (1a) This requires them to be easy to WRITE, so that there is
             very little there that is not necessary.
        (1b) It also requires them to be easy to READ, so that it is
             easy for people to see whether we have written what we meant
             to write.
    (2) They can make it much harder to write what we do NOT want.
        (2a) They can make large classes of mistakes simply inexpressible.
        (2b) They can have specially tailored polymorphic type systems
             (possibly including effects or state in the type system)
             which make it easy to check for semantic errors.
    (3) They can decouple semantics from processing.

As far as I can see, doing this kind of stuff in XML buys you (3).
*POSSIBLY*, if it were all done using markup in such a way that a Schema
could check a lot of it, it could buy you some of (2a).  But XML Schemas
don't buy you any of (2b), and not only does XML not help with (1a) or (1b),
it actively sabotages any gains we might have had there.

	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.

Well, no, because XSLT isn't particularly good at transforming text.

	In Erlang, if we roughly follow the same structure as for DOM, 

A good way to support little languages in Erlang is through Leex and Yecc.