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