Re: FYI: Adjust @$ for empty reductions

[Akim Demaille]

Le 6 oct. 04, à 01:44, Paul Eggert a écrit :

> Akim Demaille <address@hidden> writes:
>
> > I don't read locations as you do.  For me positions (two of which
> > are referring to the space in between characters.  The first
> > position is immediately pointing before the first character, and
> > the second is immediately the last.
>
> But Bison itself doesn't work that way, in the locations that it 
> reports.
> For example:
>
>    $ echo foo >t.y
>    $ bison t.y
>    t.y:1.1-3: syntax error, unexpected "identifier"

That's the way it reports the locations, not the way it handles them.
location_print report location in a more traditional sense of
"character".  I you look at lalr1.cc you will also find

  inline std::ostream& operator<< (std::ostream& ostr, const Location& 
loc)
  {
    Position last = loc.end - 1;
    ostr << loc.begin;
    if (loc.begin.filename != last.filename)
      ostr << '-' << last;
    else if (loc.begin.line != last.line)
      ostr << '-' << last.line  << '.' << last.column;
    else if (loc.begin.column != last.column)
      ostr << '-' << last.column;
    return ostr;
  }

This scheme is much easier to handle in the scanner.  And it does
matter, since users will have to code it.  The distance between
the boundaries of the token returned by yylex is yyleng
(except when there are newlines of course).  This is natural.

> The Bison manual also uses this tradition in its example, which
> contains this code:
>
>                        printf("Division by zero, l%d,c%d-l%d,c%d",
>                               @3.first_line, @3.first_column,
>                               @3.last_line, @3.last_column);
>
> Again, this uses last_column as the column of the last character
> in the location, not the first character after the location.

I don't see that here.  This code does not make the provision that
location_print did, that's all.
>

> > An empty location is a location such that begin = end.
>
> I prefer this sort of solution as well; that is why I used it in
> parse-gram.y.

Actually, I started it.

Another reason to prefer this, is one you gave yourself: successive
symbols should have increasing locations.  If you add non-empty
locations, they start to overlap.  It's even worse if there are
successive empty reductions, say

        foo: empty empty;
     empty;

> Also, on further thought I don't think it's that it's a
> huge backwards-compatibility issue.  I don't know of any real-world
> grammars that use Bison locations, other than Bison itself.  I suppose
> there are some, but they're relatively rare.

Agreed.

> However, we should make it clear that it is an incompatible change to
> Bison.  We need to update the documentation, and particularly the NEWS
> file, accordingly.

I do plan to complete NEWS on YYLLOC_DEFAULT.

> This raises the issue of whether the current default struct is all
> that useful.  Better would be the sort of struct defined in
> location.h.  But that is an even bigger change.

Which is what I referred to in mu previous msg.

> Perhaps it would be better to put off all incompatible changes like
> this until Bison 2.0 is released.  That is, we could release Bison 2.0
> shortly, without changing the upper bounds of locations; then we could
> design and implement a better location scheme for Bison 2.1.  I don't
> particularly care what the version numbers are called, but I do think
> it'd be nice to have a patched version before making any incompatible
> changes.

I don't agree.  I had the same plan for location.h: 2.1.  But I do not
agree with the ending boudary issue: it is a non issue.  They have
been implemented differently.  Sometimes they have been presented
differently, period.