Re: Advice on Writing a Parser Generator

John wrote:
> Yacc produces parse tables, too. What looks like a mix of code and data
> is the canned parser code + parse tables + a big switch in which it embeds
> the action code to run on reductions. This is a good thing; otherwise
> matching up the rule numbers with the action code is an error-prone
> pain in the neck.


Wouldn't it be better if the tables simply contained the addresses of
action functions? I see a whole lot of advantages in such an approach:


1. We'd get just large tables. The huge switch statements tend to drive
compilers nuts, either during parsing or during optimization.
2. It would improve separation between the yacc-generated code and the
action code. The action code can modify all parts of the parser state,
it must be written to avoid accidentally clobbering parser state, etc.
In other words, it's extremely unmodular - and if anybody exploits the
advantages of non-modularity, his code will almost certainly break with
the next change in yacc. (IIRC yacc had more than its share of
compatibility issues.)
3. Oh, and finally, we'd not have to manually match up rule numbers and
action code :-)


Regards,
Jo
[If you want to make all your yacc rules function calls, you can certainly
do so. I find that a lot of them are trivial and not worth putting out
of line, e.g.:


  expr: '(' expr ')' { $$ = $2; }


-John]

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