[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FYI: Adjust @$ for empty reductions

From: Akim Demaille
Subject: Re: FYI: Adjust @$ for empty reductions
Date: Wed, 6 Oct 2004 04:56:32 +0200

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 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

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;

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.


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

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]