Re: Getting rid of backups in flex.

Esmond Pitt <esmond.pitt@bigpond.com>
28 Feb 2002 00:10:21 -0500

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.