|Simple constant folding in bison parser email@example.com (1992-08-05)|
|Re: Simple constant folding in bison parser firstname.lastname@example.org (1992-08-10)|
|constant folding at parse time email@example.com (1992-08-17)|
|Re: constant folding at parse time firstname.lastname@example.org (1992-08-17)|
|Re: Simple constant folding in bison parser email@example.com (1992-08-17)|
|Re: constant folding at parse time firstname.lastname@example.org.EDU (Tim Pierce) (1992-08-19)|
|Re: constant folding at parse time email@example.com (1992-08-20)|
|Re: constant folding at parse time firstname.lastname@example.org (1992-08-21)|
|From:||email@example.com (Dale R. Worley)|
|Organization:||MIT Dept. of Tetrapilotomy, Cambridge, MA, USA|
|Date:||Mon, 10 Aug 1992 19:48:49 GMT|
firstname.lastname@example.org (Jeremy Fitzhardinge) writes:
One thing that occured to me was that the grammar can be made to recognize
simple constant expressions, and generate a parse tree node for the value
of the expression rather than the nodes for the operator and constant
This is handled by duplicating all the nonterminals into a ".c"
(constant expression) and ".nc" (non-constant expression) version:
expression : expr.c
expr.c : factor.c
| expr.c '+' factor.c
expr.nc : factor.nc
| expr.nc '+' factor.nc
| expr.nc '+' factor.c
| expr.c '+' factor.nc
factor.c : CONST
| '(' expr.c ')'
factor.nc : VAR
| '(' expr.nc ')'
Really, what you're doing is constructing a synthesized (passed-upwards)
attribute (constant vs. non-constant), but most LALR parser generators
don't support that. When you're parsing C, you want a lot of these
attributes, and you want the attributes to control some aspects of the
parsing. The result is that some productions are cloned 6 or 8 times.
Dale Worley Dept. of Math., MIT email@example.com
[This certainly works, but I'd think it'd be a lot easier to handle
synthesized attributes in the value cells, where they're easy to
construct and pass up the tree. -John]
Return to the
Search the comp.compilers archives again.