Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!otter!kers
From: kers@otter.hpl.hp.com (Chris Dollin)
Newsgroups: comp.lang.c
Subject: Re: error recovery
Message-ID: <1670015@otter.hpl.hp.com>
Date: 25 Apr 89 15:16:24 GMT
References: <1279@lzfme.att.com>
Organization: Hewlett-Packard Laboratories, Bristol, UK.
Lines: 28

Henry (Spencer) said:

| In article <4389@goofy.megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes:
| >... error-recovery in a recursive descent parser is even
| >trickier than in an LR parser!
|
| Nonsense.  If you insist on doing it as part of the parser, it gets messy,
| but there's an easy way around that.  Have the parser tell the scanner what
| kind of tokens it wants at each point, rather than just asking for "the next
| token", and do the error recovery in the scanner.  The parser always sees a
| syntactically correct program, and never has to get into the messy business
| of popping an activation stack.  With the necessary cooperation from the
| parser, this is about a page of code all told.  It works well, too -- often
| much better than the messy contortions in yacc.  (Yes, I've done both.)

I second Henry's remarks. I've done such error recovery both in-parser and
in-scanner (even the in-parser one started doing it's work by calling the
scanner), and in-scanner is *nice*. In fact this was the way I did error
recovery - sorry, repair - for an automatically generated LL(1) parser
generator [*1] several years ago.

I've not tried yacc yet, but that dreadful day looms ever closer.

Regards, Kers.
"If anything anyone lacks, they'll find it all ready in stacks."

[*1] The front-end of the parser-generator was written in Pascal, which was
also the target language. The back-end was written in Pop11.