Re: Location revisited, column tracking...

[Akim Demaille]

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

>> I would personally find it useful to have an extra option
>> e.g. named %option yylocation that tells the scanner to keep track
>> of the location.  ...  I'm aware that it may be difficult to
>> implement - but I dont think it's impossible.

John> It is very easy to implement. The debate was not over locations,
John> but whether or not flex should do your work for you, whether or
John> not location tracking is featuritis. I say flex should do it,
John> and Akim says it shouldn't.

This is a correct summary, but somewhat unfaithful: I'm not against
this feature just to be against it, I'm arguing there are way too many
dependencies on use-dependent data.

In particular, I was pointing out that Flex does not know what the
user calls `end of line', it can be \n, or \r\n, or \0, or several of
them.  I was also pointing out that, in these Unicode days, Flex does
not know what the user wants to track: characters or bytes.



John> Case in point: I just added manual location tracking to a
John> scanner/parser last week. It took half a day, including
John> debugging, to get all the lines and columns correct across
John> multiple files. What a waste of time. And guess what? I used the
John> default bison yylloc definition. That means if flex had an
John> option to perform column tracking, I would have been done in
John> half a minute instead of half a day.

Actually, had the general scheme been documented, it wouldn't have
taken so long.  I had pointed a documentation that explains this into
details, copy-paste does the rest.

And what you point out is even more use-dependent that merely tracking
the cursor: location can be ranges, can be across files, depend on
what is considered a comment or white space etc.

As far as Bison is concerned, its `location_t' is pure junk.  It ought
to be composed of two position_t, instead of a single structure.