Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!news.glorb.com!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: Thu, 17 Jul 2014 13:03:16 -0700 Organization: A noiseless patient Spider Lines: 32 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <14-07-027@comp.compilers> References: <14-07-023@comp.compilers> <14-07-024@comp.compilers> <14-07-026@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 1405628154 73296 2001:470:1f07:1126:0:676f:7373:6970 (17 Jul 2014 20:15:54 GMT) X-Complaints-To: abuse@iecc.com NNTP-Posting-Date: Thu, 17 Jul 2014 20:15:54 +0000 (UTC) Keywords: parse, LALR, errors Posted-Date: 17 Jul 2014 16:15:54 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:1317 On 7/17/2014 10:15 AM, Evangelos Drikos wrote: > But, I guess they could say the same thing if they replaced the hand > coded Fortran parser with a LALR parser. I've compared recently an > enhanced LALR parser with gfortran; the former has better error > recovery and in many cases more accurate error messages whereas the > latter sometimes just prints the cliche "Unclassifiable Statement". It is my understanding (admittedly not based on personal experience) that adding good error handling to LALR parser generator rules leads to rule explosion and difficulties in producing a consistent rule set without odd corner cases. Can you comment? If possible, can you give a sense of the difference in rule-set size and parser performance between your improved error set and one for the same language with no error productions at all? BTW: the Univac 1108 Fortran II compiler had, as many batch compilers did, a cut-off so that if the compiler went completely off the rails it would stop printing errors and append "Not all errors listed" as a final message. You guessed it: at SINTEF (NTH, Trondheim) circa 1974 we had a Fortran program whose *only* diagnostic was: "Not all errors listed". Ivan [The problem with LALR error recovery is that the generated parser combines states that are the same if your program is valid, but they are from different grammar rules, so you'd want to produce different error messages. The size of LR(1) parser tables was an issue on a 64K PDP-11, but they're trivial now, and I don't know of any reason other than inertia to use LALR rather than LR(1). -John]