RE: Q1. reducing grammar redundancy

"Ralf Lammel" <>
28 Feb 2005 00:46:13 -0500

          From comp.compilers

Related articles
Q1. reducing grammar redundancy (valentin tihomirov) (2005-02-20)
Re: Q1. reducing grammar redundancy (SM Ryan) (2005-02-28)
RE: Q1. reducing grammar redundancy (Ralf Lammel) (2005-02-28)
| List of all articles for this month |

From: "Ralf Lammel" <>
Newsgroups: comp.compilers
Date: 28 Feb 2005 00:46:13 -0500
Organization: Compilers Central
References: 05-02-086 05-02-088
Keywords: parse
Posted-Date: 28 Feb 2005 00:46:13 EST

Regarding [1],

You might like higher-order concepts in parser specs. For instance,
Breuer at al. have provided such rule templates in the C-based PRECC,
but parser combinators in functional programming are even more
versatile. Basically think of parameterized rules. (One operational
model would be to expand these parameterized rules just as
macros. PRECC and functional programming, normally, rather maintain
the higher-order abstractions until parse time.)

Regarding [2],

You can parameterize your rule (using [1]) in the element tag. So the
element tag floats from the argument position of a higher-order rule
to its body. Alternatively, you can use most forms of
semantics-directed parsing (or DCG, ...). That is, when you recognize
an element name, you pass it on as an attribute, which you then check
against the closing tag. This is more easily done with top-down
parsers, but I guess one can also use a global stack for pushing and
popping element tags, probably within the lexer ... Is anyone doing

You find such and other parser references in the grammaware agenda, to
be found on my web site.


> [1]
> [...]
> sqrt-> LPAREN "sqrt" NUM RPAREN; // LISP element synthax
> plus -> LPAREN "plus" NUM NUM RPAREN;
> [2]
> element -> OPEN_PAREN "element" CLOSE_PAREN // opening tag
> element // body
> OPEN_PAREN SLASH "element" CLOSE_PAREN; // closing

Ralf Lammel

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.