|LL(1) vs LALR(1) parsers email@example.com (Odd Arild Olsen) (1995-11-04)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (Saileshwar Krishnamurthy) (1995-11-09)|
|Re: LL(1) vs LALR(1) parsers email@example.com (Sebastian Schmidt) (1995-11-10)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-10)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-14)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (steve (s.s.) simmons) (1995-11-15)|
|Re: LL(1) vs LALR(1) parsers email@example.com (Terence John Parr) (1995-11-20)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-22)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-24)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-28)|
|Re: LL(1) vs LALR(1) parsers email@example.com (1995-11-28)|
|Re: LL(1) vs LALR(1) parsers firstname.lastname@example.org (1995-11-28)|
|[16 later articles]|
|From:||"steve (s.s.) simmons" <email@example.com>|
|Keywords:||parse, LALR, LL(1)|
|Organization:||Bell-Northern Research Ltd.|
|Date:||Wed, 15 Nov 1995 13:39:07 GMT|
> Why do compiler design text book authors only describe recursive parsers
> as a step stone on their way to bottom up parsers? I know that LALR allows
> for more complex grammars, but many languages can be described by LL(1)
> grammars. If LL(1) can yield faster, smaller and more understandable
> parsers with better error handling for many languages, why isn't this
> method more elaborated? (Holub, as an example, presents full grammar and
> compiler listings for a bottom-up C-compiler, not for top-down).
That is, the automated parsers use a great deal of automata theory
which helps build on the computer science foundation. Recursive descent
parsers are a small matter of programming (SMOP). I do notice among
peers in industry that people are no longer snubbing the idea of writing
a recursive parser when it is appropiate.
Remember you don't take a compiler course to learn how to build a
compiler, surprise... Most people never write a compiler. You take
it for the following reasons:
- Improving your comp. sci. background to understand
automata theory with a very good application.
- Understanding what a compiler may do (or not do) for
- Learning about big system software, data structures, etc.
[I agree that few CS students will write a conventional compiler, but we all
end up having to decode some sort of input language in an application. -John]
Return to the
Search the comp.compilers archives again.