Related articles |
---|
Getting rid of backups in flex. robertminsk@yahoo.com (2002-01-17) |
Re: Getting rid of backups in flex. esmond.pitt@bigpond.com (Esmond Pitt) (2002-01-18) |
Re: Getting rid of backups in flex. casse@netcourrier.com (=?ISO-8859-15?q?=22Cass=E9=.Hugues@free.fr,@free.f) (2002-02-06) |
Re: Getting rid of backups in flex. dube@dino04.iro.umontreal.ca (Danny Dube) (2002-02-16) |
Re: Getting rid of backups in flex. esmond.pitt@bigpond.com (Esmond Pitt) (2002-02-28) |
Re: Getting rid of backups in flex. clint@0lsen.net (2002-03-17) |
Re: Getting rid of backups in flex. fjh@cs.mu.OZ.AU (2002-03-19) |
From: | Esmond Pitt <esmond.pitt@bigpond.com> |
Newsgroups: | comp.compilers |
Date: | 28 Feb 2002 00:10:21 -0500 |
Organization: | Melbourne Software Company Pty Ltd |
References: | 02-01-070 02-02-017 02-02-041 |
Keywords: | lex |
Posted-Date: | 28 Feb 2002 00:10:21 EST |
Danny Dube wrote:
>
> Adding the following error-catching regular expression:
> ..
> (as someone suggested previously) is not correct because this
> expression would take precedence on the normal regular expressions
> when the input would start with a single-digit integer. For example,
> if the input starts with:
> 9),...
> the automaton would do a match of length 2 and return `tError' instead
> of matching the length 1 string "9" and returning `tInt'.
I think that was my suggestion, and it contained a typo. What I really
advocate is a single final rule
. return yytext[0]
to catch (a) all single-char special chars and (b) all lexical errors,
which are handed to the parser to deal with as syntax errors. Apart from
keeping the size of the state machine down, you get the benefit of the
parser's error-recovery if any, rather than just lamely printing out
'illegal character %c'.
EJP
Return to the
comp.compilers page.
Search the
comp.compilers archives again.