Re: Locations suggest -- we're stupid

[Nikos Balkanas]

I am not sure I follow all the fuss.
IMHO there is a reason why flex treats differently '\n' from everything
else. Basically I think it is that we should do our own tracking. We can
have the knowledge of tracking built into our patterns. This is much faster
than having flex scan yytext for new lines. Sure it requires a bit more
thinking into the patterns and variables. '\n' should be referred only
explicitly and not included into variables. Sometimes doubling up of
patterns (one with spaces, the other with newlines) might be required and
more thinking into arranging the patterns. If in addition we match error on
a variable {error} which would be a literal string instead of "." (any) then
by keeping track the name of the input file we can have on the error string
filename, line offset and input string. I think that should cover all bases.
Hey, with a decent error string (6-7 chars) one can track errors on binary
input files.

My point is that we have much better knowledge to track errors based on
patterns than flex. Based on that knowledge we can be much faster than flex
can ever be. I enjoy flex's blazing speed. Let's not make it top heavy. Sure
it's compile time options. I would hate to see some of this spill into the
executable.

----- Original Message -----
From: John W. Millaway <address@hidden>
To: <address@hidden>
Sent: Friday, January 04, 2002 3:50 AM
Subject: Re: Locations suggest -- we're stupid


> Damn we're stupid. Flex reads ahead on the input stream!! In most cases,
ftell
> will report the same position for repeated calls, that position being far
ahead
> of the curent token.
>
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
>
> _______________________________________________
> Help-flex mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/help-flex
>
>