Re: Locations suggest

[Akim Demaille]

>>>>> "John" == John W Millaway <address@hidden> writes:

Akim> I think it is not a good because there are too many different
Akim> ways locations have to be computed.  And yet for the sole
Akim> yylineno, flex is not satisfying.  Rather, you should depend on
Akim> the various hooks to have your scanner compute what you need.

John> The line number will be the number of newlines encountered
John> (i.e., plus one), and the column is the number of characters
John> encountered since the previous newline. What else do you have in
John> mind?

For a start, the example I sent is more precise and keeps tracks of
the initial/final line/column.  In some case you need to keep track of
the file name too.  And be ready to keep stacks of them if you have an
include facility.  And you don't want to have Flex compute some
variables, and your parser/scanner completely obfuscated because of
glue code between the two concepts of location.  Worse: it's expensive.

In other words, what is needed is good hooks and a documentation that
explains how to explain them to reach the goal.


As for Flex, yet using yylineno has a very negative impact on the
scanner.  So bad, that I refuse to use it.  It might be a bug, I don't
know, but:

/tmp % cat foo.l                                                 nostromo 18:06
%option yylineno
%%
foo ;
/tmp % LANG=C flex -p foo.l                                      nostromo 18:06
%option yylineno entails a large performance penalty
REJECT entails a large performance penalty
/tmp % sed -n '/line/!p' foo.l > bar.l                           nostromo 18:06
/tmp % LANG=C flex -p bar.l                                      nostromo 18:09

for some reason, it results in having Flex using a fixed size buffer,
which I find not acceptable.

OTOH, maybe there are cases where the scheme I proposed is broken for
internal reasons.  AFAICS, it has always been right.