Related articles |
---|
Q: Error detection/recovery in LEX/YACC (Help) friesend@herald.usask.ca (1993-12-17) |
re: Q: Error detection/recovery in LEX/YACC (Help) bdarr@atr-2s.hac.com (1993-12-21) |
Re: Q: Error detection/recovery in LEX/YACC (Help) neitzel@ips.cs.tu-bs.de (1993-12-23) |
Re: Q: Error detection/recovery in LEX/YACC (Help) hage@netcom.com (1994-01-18) |
Re: Q: Error detection/recovery in LEX/YACC (Help) neitzel@ips.cs.tu-bs.de (1994-01-27) |
Newsgroups: | comp.compilers |
From: | bdarr@atr-2s.hac.com (Byron Darrah) |
Keywords: | lex, yacc, errors |
Organization: | Compilers Central |
References: | 93-12-081 |
Date: | Tue, 21 Dec 1993 17:32:15 GMT |
Darryl Friesen writes:
>I need a little help with error detection/recovery/repair in either or
>both of LEX and YACC (a little snippet of code, even just a few
>productions, would be tremendously appreciated! :).
Here is a yacc production that uses the special error symbol to trap
parsing errors in a semicolon-terminated statement (as in C):
Statement : Stmt semicolon_tok
| error semicolon_tok
;
Whenever yacc encounters a parsing error, it effectively backs up the
stack util it can match the input to an error production. When it matches
such input, a call to yyerror() is made. You can supply your own
yyerror() routine, which prints whatever error messages you like. When
yyerror() returns, parsing continues just as if Statement had been
produced.
You need to select your error productions strategically, so that if a
syntax error is encountered, (1) the nonterminal that gets produced does
not affect other symbols in the production (in my example, producing an
error Statement consumes all input up to and including a semicolon, which
should mean that the next statement is ready to be parsed), and (2) Which
nonterminal to produce is not ambiguous.
> PS. Is it best to keep all (most) symbol table interactions
>(ie. lookup, insertions) in the scanner? I'm a little new
>to LEX/YACC in case you haven't noticed :)
This aspect of the design is really up to you. You should consider of
what kind of information the symbol table will make use, then figure out
where the bulk of that information fits into your program -- in the
scanner or in the parser?
I hope this helps. I didn't see any other posted responses to the
question, so I hope this is not too redundant, even though the question
was posted 4 days ago. :)
--
Byron C. Darrah | bus. mail: attn: Byron C. Darrah, Mail Station: B223
PHONE: (714) 732-9381 | Hughes Aircraft Company, GSD.
FAX: (714) 732-1953 | 1901 W. Malvern Ave.
bdarr@atr-2s.hac.com | Fullerton, California, USA
| 92634
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.