Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| Related articles |
|---|
| Can shift/reduce problems be eliminated? ashwin21_99@hotmail.com (Ashwin) (2002-12-30) |
| Re: Can shift/reduce problems be eliminated? clint@0lsen.net (Clint Olsen) (2002-12-31) |
| Re: Can shift/reduce problems be eliminated? vugluskr@unicorn.math.spbu.ru (2002-12-31) |
| Re: Can shift/reduce problems be eliminated? cdc@maxnet.co.nz (Carl Cerecke) (2002-12-31) |
| Re: Can shift/reduce problems be eliminated? gah@ugcs.caltech.edu (glen herrmannsfeldt) (2003-01-04) |
| Re: Can shift/reduce problems be eliminated? bonzini@gnu.org (2003-01-04) |
| Re: Can shift/reduce problems be eliminated? vugluskr@unicorn.math.spbu.ru (2003-01-04) |
| Re: Can shift/reduce problems be eliminated? cdc@maxnet.co.nz (Carl Cerecke) (2003-01-07) |
| [1 later articles] |
| From: | Clint Olsen <clint@0lsen.net> |
| Newsgroups: | comp.compilers |
| Date: | 31 Dec 2002 23:43:54 -0500 |
| Organization: | AT&T Broadband |
| References: | 02-12-121 |
| Keywords: | yacc, parse |
| Posted-Date: | 31 Dec 2002 23:43:54 EST |
Ashwin wrote:
> Also, I get quite a few reduce/reduce conflicts. I guess this is
> unavoidable. Is there a way to completely eliminate reduce/reduce
> conflicts by rearranging the grammar (while adhering to the original
> specs)?
You definitely don't want to leave reduce/reduce conflicts unless you know
how yacc decides which production to reduce and whether that is the correct
thing to do. You'd probably have to transcribe the grammar into yacc in
the same order and even then there are no guarantees.
You can factor the grammar to eliminate the ambiguity. Factoring will
create extra productions and some extra work in your semantic actions but
it guarantees that later modifications to your grammar won't break your
parser.
-Clint
Return to the
comp.compilers page.
Search the
comp.compilers archives again.