Re: why are locations dictated by bison?

[Akim Demaille]

| Akim Demaille wrote:
| >Sorry, you're wrong: it is _thanks_ to Flex that I can use a class
| >here.  I _want_ one for the rest of my application.  Don't tell me how
| >I have to make my application, I know better than you (even if I'm
| >wrong).  You pretend you can make it simpler to me; I'm asking you to
| >send the scanner I sent _simplified_ thanks to your work.
| ...
| >#define YY_USER_INIT                         \
| >  do {                                               \
| >    yylloc->begin.filename = current_file;   \
| >    yylloc->end.filename = current_file;     \
| >  } while (0)
| >
| >#define YY_USER_ACTION                               \
| >    yylloc->column (yyleng);
| 
| I can only give the suggestion I made:
| 
| In addition to the YY_USER_INIT and YY_USER_ACTION, one has two macros
| YY_LOCATION_BEGIN and YY_LOCATION_END executed at the same spots. 

I have nothing against this, but really, that's not what I call a
feature...  But we agree, that's the only reasonable one.

Oh, BTW, my code is wrong: you cannot use YY_USER_INIT safely, since
if the same scanner is run onto another file, it will keep the old
name.  I need to do that in the parser (I'm using a reentrant
parser/scanner), in the axiom.

So there remains only a single macro here.

| If one
| decides to use %locations, but does not define those macros, they will
| record into some default structure the info you have written out by hand.

How do you know if yylloc is a pointer (case reentrant), or directly
the structure (case not reentrant).  How do you know that the user is
not coding locations in yylval?  That's what non Bison users do to
track locations.

| This Flex default locations structure will be synched with the new Bison
| locations default. 

Flex cannot make assumptions over yylloc, just as it cannot make
assumptions over yylval.  If you break that, I guarantee the future
maintainers of these tools will hate you.  Don't tie the others' hand.

| The %locations command may have options telling which
| type of data to record (line/column/position/file info/begin-end).

Sure.  You end up typing as much data as doing it by hand, but in a
different language, using a different language than plain C, so more
to learn.

Please, show me how you simplify a scanner, then we can talk.  You
have good ideas, I _agree_ it would be great.  I claim it is not
possible.  Prove me wrong!  Show me!

| Thus the simplification of your code would be to use %locations instead of
| YY_USER_INIT and YY_USER_ACTION macros, and then you do not need to put in
| locations actions into the rules, except to override the default.

I don't follow you here.  Show me.

| In view of that you already use std::operator new() and such C++ stuff, the
| locations overhead is likely to be insignificant.

As far as *I*'m concerned, I agree.