why are locations dictated by bison?

[John W. Millaway]

I had to bend over backwards to get the latest flex code to talk nicely with
bison (the next release will have a bison option), since bison will expect any
one of several possible declarations of 'yylex', depending upon user options --
No, not even dependent upon user options, but whether parser actions use @N, in
which case yylloc is passed to yylex.

As maintainer of Bison, you have strongly opposed implementing location
tracking in flex, and you believe this should be left to the user to define.
What business, then, does Bison have dictating the format of the location
tracking? Why is location tracking a parser issue?

The result of Bison's YYLTYPE mechansim is that the scanner needs to know about
parser details. This is arguably bad design -- The scanner should be completely
separate from the parser -- according to some. With that in mind, bison should
simply leave out location tracking altogether, shouldn't it?

If I may greatly simplifiy your case (over the past week) against location
tracking in flex, it rests on two arguments. (1) Location tracking is a
performance problem, and (2) there's no simple general implementation that we
could provide anyway.

To address the performance point, the following is from the bison manual,
discussing YYLTYPE:

     In order for the members of this structure to contain valid
     information, you must make `yylex' supply this information about
     each token.  If you need only certain members, then `yylex' need
     only fill in those members. 
     The use of this feature makes the parser noticeably slower.

So here we have a performance problem, caused by bison, and independent of the
scanner's implementation of location tracking! I wonder how this bison problem
compares to rescanning yytext  (i.e., looking for '\n' chars) in flex. It may
be that so much overhead is imposed in the layers above the scanner, that
improving yylineno detection will go unnoticed.

To address point (2): If there is no simple, general implementation we could
provide at the scanner level, why, then does Bison dictate both the structure
AND the scanner function prototype for location tracking (i.e., at the parser
level)?

You can answer all of these questions by defending the decision to implement
location tracking as you have done, and at all, in Bison.


__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/