Re: Locations suggest

[John W. Millaway]

> For a start, the example I sent is more precise and keeps tracks of
> the initial/final line/column.

That example is a perfect case for including line/col tracking in flex itself.
The example tracks line and column information more or less as flex would do
internally. But it also tracks one oddball bit of info: the final line (the
line on which the token ENDS). There is no reason to believe that this final
line is desired for most scanners, whose tokens don't span lines. That's why
this is a perfect example: Flex should track the basics (starting line/col),
and the user could add/compute whatever extra info is needed (final line/col).

>  In some case you need to keep track of the file name too.

Right, but not for every token. I would argue that filename tracking is best
left to the grammar/parser -- but this won't work for macro languages. Even so,
this decision is not for flex to make, as long as flex continues to allow the
user to do all the line/col tracking herself.

> 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.

Flex already has the per-file (per- input buffer) stack mechanism built-in, and
yylineno is part of it. I can't think of another concept of location that
doesn't use {line,column} as it's base.  

As for the built-in tracking, I have in mind something of this nature:

struct location {
    int line, column; /* optionally tracked by flex */
    YY_LOCATION_MEMBERS /* user-defined */
};


__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com