LR(n) parsers

Steve Boswell <whatis@ucsd.edu>
10 Oct 91 18:08:46 GMT

          From comp.compilers
Related articles
LR(n) parsers whatis@ucsd.edu (Steve Boswell) (1991-10-10)
Re: LR(n) parsers KARSTEN@tfl.dk (Karsten Nyblad, TFL, Denmark) (1991-10-13)
Re: LR(n) parsers goer@midway.uchicago.edu (1991-10-14)
Re: LR(n) parsers sra@ecs.soton.ac.uk (1991-10-14)
Re: LR(n) parsers anw@maths.nott.ac.uk (1991-10-14)
Re: LR(n) parsers bburshte@pyrps5.eng.pyramid.com (1991-10-14)
Re: talking about LR(n) parsers goer@midway.uchicago.edu (1991-10-15)
[11 later articles]
| List of all articles for this month |
Newsgroups: comp.compilers
From: Steve Boswell <whatis@ucsd.edu>
Keywords: yacc, parse, lisp, grammar
Organization: University of California, San Diego
Date: 10 Oct 91 18:08:46 GMT

What sort of easily-describable or commonly-occuring grammars are
ambiguous for any amount of lookahead? I'm implementing an
object-oriented parsing engine and I'd like to take all the work of
resolving ambiguity away from the end programmer. (Maybe wanting to do
this is naive, but then I gotta learn somehow. :-) Has there been any work
done on LR(n) parsing engines like this? My idea is to do a normal LR(1)
transition table & parse in parallel with all possibilities every time
there is more than one.


Thanks for any leads!
--
Steve Boswell
whatis@ucsd.edu
[What you're proposing is more or less Earley's parsing scheme, which is
quite slow. -John]
--

Post a followup to this message

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