|LL(1) vs LALR(1) parsers firstname.lastname@example.org (Odd Arild Olsen) (1995-11-04)|
|Re: LL(1) vs LALR(1) parsers email@example.com (Saileshwar Krishnamurthy) (1995-11-09)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (Sebastian Schmidt) (1995-11-10)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-10)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-14)|
|Re: LL(1) vs LALR(1) parsers email@example.com (steve (s.s.) simmons) (1995-11-15)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (Terence John Parr) (1995-11-20)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-22)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-24)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-28)|
|[18 later articles]|
|From:||firstname.lastname@example.org (Scott Stanchfield)|
|Keywords:||LL(1), LALR, parse|
|Organization:||Express Access Online Communications, Greenbelt, MD USA|
|Date:||Fri, 10 Nov 1995 14:30:13 GMT|
LL(1) becomes even more desirable when you add syntactic and semantic
predicates, as the Purdue Compiler Construction Tool Set (PCCTS) does.
The grammar becomes more readable (you don't need to have several obscure
extra rules or evil communication between the lexer and parser.)
I agree with the LL(1) arguments of "Odd Arild," especially when it comes
to debugging. PCCTS' parser generator, antlr, generates a recursive-descent
parser that is very readable. Each rule is a function, which makes it
easy to stop anywhere you want, and when walking through your parser, you
don't have to step over obscure yacc-generated code.
The grammar is actually fairly easy to construct, as antlr supports
EBNF. (You still need to do all the fun left-factoring necessary in LL --
but it's not as bad, as you can have subrules.)
For more information, follow comp.compilers.tools.pccts. The tool is
available from ftp://ftp.parr-research.com/pub/pccts. Check it out!
Return to the
Search the comp.compilers archives again.