Re: Can shift/reduce problems be eliminated?

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.

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