Re: Can shift/reduce problems be eliminated?

Carl Cerecke <cdc@maxnet.co.nz>
7 Jan 2003 23:28:06 -0500

          From comp.compilers

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)
Re: Can shift/reduce problems be eliminated? bje@redhat.com (Ben Elliston) (2003-01-07)
| List of all articles for this month |

From: Carl Cerecke <cdc@maxnet.co.nz>
Newsgroups: comp.compilers
Date: 7 Jan 2003 23:28:06 -0500
Organization: TelstraClear
References: 02-12-121 02-12-137 03-01-018
Keywords: parse
Posted-Date: 07 Jan 2003 23:28:06 EST

Roman Shaposhnick wrote:


> Just out of curiosity: don't you consider this to be exactly the case
> for hand-written recursive parser ? From my experience, once you have
> more hacks than grammar in your .y file, hand crafted recursive parser
> might save you from additional trouble, because you have a complete control
> over how it works. Or may be mixed approach is even better...


Paolo wrote:
> Aren't you better off using bison's new GLR parser support?


The parser has to be in Java, so bison (all of it anyway) is out. The
tables it generates are still useful though.


I ended up writing a GLR parser generator (in python) that takes the
bison foo.output parser description file and creates a Java parser.
An ambiguous AST is built, and then disambiguated (Disambiguation
can't easily be done on the fly.) This was the only way I could think
of to have a robust parse (one that I could trust was correct) rather
than have many yucky hacks on a LL/LR parser. I did try for weeks with
a LL(k) parser generator before deciding that it was not the way to
go. The language is also still in the standardisation process, so
some changes in the grammar are probable (though not likely to be very
large - I hope).


Unfortunately, due to commercial sensitivity, I can't name the language.


Cheers,
Carl.


Post a followup to this message

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