Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED!nerds-end From: Ivan Godard Newsgroups: comp.compilers Subject: Re: LR(1) Parsing : Error Handling & Recovery Date: Wed, 16 Jul 2014 16:39:09 -0400 (EDT) Organization: A noiseless patient Spider Lines: 33 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-07-024@comp.compilers> References: <14-07-023@comp.compilers> NNTP-Posting-Host: news.iecc.com Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: miucha.iecc.com 1405543149 75315 2001:470:1f07:1126:0:676f:7373:6970 (16 Jul 2014 20:39:09 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Wed, 16 Jul 2014 20:39:09 +0000 (UTC) Keywords: parse, errors Posted-Date: 16 Jul 2014 16:39:09 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1314 On 7/9/2014 5:00 PM, Seima Rao wrote: > How far is impressive error handling & recovery possible by LR(1) > parsers ? > > What would be good references for the subject? > > As an aside, do the famous compilers use LR(1) parsing ? LR1 was an experiment. The way to get apt error messages out of one is to add error production rules. Unfortunately that process explodes the state space, resulting in generally poor quality compilers. As a practical matter, natural languages are pretty much LL1 (German verbs excepted) so people are reasonably familiar to quasi-linear parsing. A recursive descent LL1 parser can be written in less time than a LR1 grammar for the same language can be debugged, if it ever is. For those that really really believe in parser-generators, high-quality generators exist for LL1 too. Nearly all languages yield to LL1 techniques (the formal proofs that a language is not LL1 are irrelevant), often by introducing a few union-productions into the lexer; examples have been shown here, such as DOI=1 in Fortran. The great advantage of a recursive-descent parser is that you can do most semantic analysis on the fly while you are at it, and can emit apt and copious error messages at the point where the source first goes off the rails. You can even do a decent job of recovery: for example, an unrecognized identifier can be used to search for an approximate match in the current dictionary (also built on the fly) to fix a typo, thereby avoiding the cascade of irrelevant diagnostics typical of YACC parsers. FWIW, I recall hearing that GCC switched from LR1 (LALR?) to recursive-descent a few years back. You couldn't pay me to work on a YACC-based front end.