Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!ima!johnl From: johnl@ima.UUCP Newsgroups: comp.compilers Subject: Re: recursive-descent error recovery Message-ID: <655@ima.ISC.COM> Date: Sat, 15-Aug-87 05:10:26 EDT Article-I.D.: ima.655 Posted: Sat Aug 15 05:10:26 1987 Date-Received: Sun, 16-Aug-87 09:44:31 EDT References: <634@ima.ISC.COM> <642@ima.ISC.COM> <651@ima.ISC.COM> Sender: johnl@ima.ISC.COM Reply-To: chuck@amdahl.amdahl.com (Charles Simmons) Organization: Amdahl Corp, Sunnyvale CA Lines: 54 Approved: compilers@ima.UUCP In article <651@ima.ISC.COM> decvax!utzoo!henry writes: >> [I'd be interested in hearing what the recursive descent lexer feeds to the >> parser when the input is something like a = b + ( ; -John] > >The basic approach in the lexer is (a) give the customer what he wants, and >(b) if what he wants doesn't match what's in the input, apply some simple >heuristics to try to resynchronize. Say we've just parsed the "b", so the >parser knows we're in an expression that is part of a statement; here is >the dialogue, slightly simplified: > [Relatively long dialog deleted...] This seems like a pain. Recusrive descent with error recovery performed by the higher level entity would seem to be simpler, namely because the higher level entity knows more about what's going on. For example, suppose the expression parser has just parsed the paren. The conversation then proceeds as follows: Expression Parser: Give me a token. Lexical Analyzer: Okay, here's a semicolon. EP: A semicolon?! I didn't expect one of these. I expected an expression. Yo! User! I expected to see an expression after this parenthese at line 124. Okay... Now I've told the user it screwed up, let's recover from this sucker. The simplest thing to do, since I'm in an expression, is to toss tokens until I get to a synchronizing token like a semi. Hmmm... I've got a semi, so I'm now synchronized. Okay. Let's tell our caller that we parsed an expression successfully. Meanwhile... A while ago I suggested that one cannot write a reasonable compiler using YACC. I got no response. So let me attempt to generate some flames. I claim it is impossible to write a reasonable compiler using YACC. I base this claim on the fact that while it is important that a compiler produce a correct binary, it is nearly as important that the compiler produce reasonable error messages. I further claim it is impossible to produce reasonable error messages using YACC. So flame me and tell me why I don't know what I'm talking about. I feel the need for some edification... But what about developing the | Chuck Simmons @ Amdahl moon before we terraform Mars? | amdahl!chuck [Just because nobody ever does good error recovery in yacc parsers doesn't mean it's all that hard. What is hard is to figure out the right set of error productions to add to the grammar to catch the sorts of errors that will actually occur. Then there's the issue of what a good error message is. Some people like things like "statement required ID, CPAREN, SEMI, BLURCH, or BLAH but FNUMBER was encountered." Personally, I liked the ones in Fortran H which sounded like pronouncements from a slightly disdainful robot: "IEH247I THE STATEMENT CONTAINS A PROSCRIBED COMMON DECLARATION." -John] -- Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | cca}!ima Please send responses to the originator of the message -- I cannot forward mail accidentally sent back to compilers. Meta-mail to ima!compilers-request