Announcing Dryverl: an Erlang-to-C binding compiler

Vlad Dumitrescu vladdu55@REDACTED
Mon May 29 10:25:51 CEST 2006


Hi,

> -----Original Message-----
> From: Romain Lenglet

> 2- by using different lexical tokens for the elements with
> different types, which would be equivalent to always giving
> different names to elements that have different types (e.g.
> add "di-" and "eo-"
> prefixes):

I apologize for barging into the discussion, but I don't agree with
this statement.

What you say is true for xslt because it describes the grammar as
directly as a parse tree.

If using a "normal" domain specific language, the definition will of
course include such duplication of definitions, but this need not be
visible at the syntactic level.

Something like (very simplified)

    expr -> 'decode' decode_input : {decode, '$2'}.
    expr -> 'encode' encode_input : {encode, '$2'}.

    decode_input -> 'map' map_d: {decode_input, '$2'}.

    encode_input -> 'map' map_e: {encode_input, '$2'}.

    map_d -> id_ref_d: ['$1'].
    map_d -> id_ref_d ',' map_d: ['$1'|'$3'].

    map_e -> id_ref_e: ['$1'].
    map_e -> id_ref_e ',' map_e: ['$1'|'$3'].

    id_ref_d -> 'decode_op': decoding.

    id_ref_e -> 'encode_op': encoding.


will work nicely as intended.

Whether this is better or worse than xslt is completely another issue.

Note: the C language isn't context-free either and yacc grammars can
handle it. The semantic checking has only to be moved as a separate
step after the parsing. I agree it's not very nice, but it works.

regards,
Vlad



More information about the erlang-questions mailing list