Re: Locations suggest

[Akim Demaille]

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

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

John> That example is a perfect case for including line/col tracking
John> in flex itself.  

I really don't think so, there is way too much dependency wrt the
underlying system, and the choices of the user.

For instance: do col starts at 0 or 1?  I'm no kidding, Emacs has
column 0 but line 1.

When you read `foo\n\r' what is the location of \r?  On the next line,
or it is part of the current?

What do you call a space?  This is critical: the scanner skips the
spaces, of course, which also means that there locations are skipped.
So you must know what the user considers a space.  Likewise with
comments, which can even be implemented as start conditions!

Some people will tell you they need (c0, l0) + wdith, not (c0, l0) +
(c1, l1).  And you cannot convert from one to the other without having
the text handy.



Implement it if you wish.  But it will not be used, because it is
- dependent upon the system
  (yet I am surprised that Hans did not complain about yylineno which
   stupidly thinks eol is `\n' while everybody knows modern OSes use
   `\r'...)

- dependent upon the lexical structure of the input (tell me how you
  expect to handle tabs: single char?  Walks by 4 spaces? by 8?)

- dependent upon the use

- dependent upon the taste of the user.




All we need a means to implement what we need.  We already have it.
All the rest is pushing an additional burden onto you, for extremely
limited added value.

In addition, it is more expensive to have Flex do it for us: it
duplicates the walks through yytext.


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

This is wrong for some applications where it is the width (number of
chars, including the possible other eol) that matters.  I'm sure Hans
can make long comments about that.