Related articles |
---|
ANSI C grammar without shift-reduce conflict on 'ELSE' ggrares@yahoo.com (Rares GalaN) (2007-12-09) |
Re: ANSI C grammar without shift-reduce conflict on 'ELSE' cbarron3@ix.netcom.com (2007-12-09) |
Re: ANSI C grammar without shift-reduce conflict on 'ELSE' gah@ugcs.caltech.edu (glen herrmannsfeldt) (2007-12-09) |
Re: ANSI C grammar without shift-reduce conflict on 'ELSE' anton@mips.complang.tuwien.ac.at (2007-12-10) |
Re: ANSI C grammar without shift-reduce conflict on 'ELSE' anton@mips.complang.tuwien.ac.at (2007-12-10) |
Re: ANSI C grammar without shift-reduce conflict on 'ELSE' monnier@iro.umontreal.ca (Stefan Monnier) (2007-12-12) |
From: | Stefan Monnier <monnier@iro.umontreal.ca> |
Newsgroups: | comp.compilers |
Date: | Wed, 12 Dec 2007 10:35:44 -0500 |
Organization: | UseNetServer.com |
References: | 07-12-021 07-12-024 07-12-028 |
Keywords: | parse |
Posted-Date: | 12 Dec 2007 13:05:44 EST |
> For the dangling else problem an appropriately transformed grammar is
> this:
> S: Matched
> | Unmatched
> ;
> Matched: if E then Matched else Matched
> | Other_S
> ;
> Unmatched: if E then S
> | if E then Matched else Unmatched
> ;
> A nice explanation of this construction can be found at
> <http://marvin.cs.uidaho.edu/~heckendo/CS445F07/danglingElse.html>.
But then the parser is (slightly) less efficient.
Wouldn't it be nice if yacc were able to generate the same parse table?
Stefan
[If you tell yacc to use precedences to resolve the ELSE conflict, you
get a smaller parse table, but I would be astonished if there were any
real situations where the extra shift and reduce made a measurable
difference in compiler performance. -John]
Return to the
comp.compilers page.
Search the
comp.compilers archives again.