[Mono-list] parse generator

Jonathan Pryor jonpryor@vt.edu
09 Feb 2003 21:43:59 -0500


<snip/>

> I understand the Dragon books point about LR grammars vs LL grammars. I made
> a reference to it in an earlier message.

Sorry.  I had missed that reference.

> > To put it another way, an LR parser works by following the *reverse* of
> > a right-recursive derivation.  This allows each input token to be a
> > handle that can be used as part of the shift/reduce parsing process.
> >
> > An LL parser, on the other hand, effectively needs to read in the entire
> > file before it can start applying any reductions to avoid ambiguities,
> > leading to increased memory requirements and slower parsing.
> 
> Your conclusion about LL parsing efficiency is inaccurate IMHO. LL parsing
> isn't inefficient compared to LR parsing (both can be implemented as
> tablelookups or procedurally) unless the language in question requires
> copious amounts of lookahead/backtracking. Most languages don't. C++
> doesn't. C# doesn't.

My mistake.  It was apparently a gross over-generalization that we went
over in class.  *Worst Case* LL would need to read in the whole file. 
But that seldom occurs in programming languages (likely because no
compiler developer in their right mind would make such a grammar).

<snip/>

> Many (most?) of the well-known commmercial compilers use hand-coded
> recursive descent (RD) parsers. The ease of development, flexibility (esp in
> error handling) and performance of RD parsers based on LL(k) grammars is an
> oft-cited reason. All the same benefit that ANTLR provides.

I haven't heard about what commercial compilers use.  I do know that GCC
uses bison, though they have a hand-coded recursive decent parser for
C++.  C is apparently using the previous, bison-generated, parser.

Thank you for your commentary.  I appreciate the feedback.

 - Jon