Re: LL(1) vs LALR(1) parsers

solution@gate.net (Ken Walter)
16 Dec 1995 23:50:18 -0500

          From comp.compilers

Related articles
[18 earlier articles]
Re: LL(1) vs LALR(1) parsers gvcormac@plg.uwaterloo.ca (Gord Cormack) (1995-12-01)
Re: LL(1) vs LALR(1) parsers bridges@cs.arizona.edu (1995-12-01)
Re: LL(1) vs LALR(1) parsers mparks@oz.net (1995-12-09)
Re: LL(1) vs LALR(1) parsers maatwerk@euronet.nl (1995-12-09)
Re: LL(1) vs LALR(1) parsers sperber@informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) (1995-12-09)
Re: LL(1) vs LALR(1) parsers mparks@oz.net (1995-12-12)
Re: LL(1) vs LALR(1) parsers solution@gate.net (1995-12-16)
Re: LL(1) vs LALR(1) parsers sb@metis.no (1995-12-17)
Re: LL(1) vs LALR(1) parsers scooter@mccabe.com (Scott Stanchfield) (1995-12-18)
Re: LL(1) vs LALR(1) parsers G.A.Tijssen@eco.RUG.NL (Gert A. Tijssen) (1995-12-19)
| List of all articles for this month |

From: solution@gate.net (Ken Walter)
Newsgroups: comp.compilers
Date: 16 Dec 1995 23:50:18 -0500
Organization: Solution Technology
References: 95-11-051 95-11-138 95-11-195 95-11-231
Keywords: LL(1), LALR, errors, parse



:>napi@ms.mimos.my says...
:>
:>What is this ?. I have used both LL & LALR based tools and this
:>experience has convinced me never to use an LALR tool again. The
:>trouble with LALR tools is simple. An LALR parser has no idea about
:>the context of the syntatic structure. Hence, this leads to two
:>massive problems. (1). Writing an LALR parser needs to be done with a
:>bottom up thought process which is unnatural (well it is for me
:>anyway). (2). The error detection has no idea of the context so it
:>can't select a natural recovery point and the error meesages produced
:>are consequently usually poor.
:>
:>In summary, LL error recovery is vastly better than LALR. ...




You must have had a very poor implementation. I've worked with a
LALR(k) parser and found it much better than the LL(k) junk over all.
Any parser must address the error recovery problem. My LALR gave a
list of expected tokens and a list a productions in progress. The
parse tables could actual be used to produce a insert or delete
current token to continue the parse. Even recursive decent parsers
have problems recovering if the problem is not addressed.




Ken Walter
--


Post a followup to this message

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