Re: error-tokens and locations?

[Paul Eggert]

Ian Badcoe <address@hidden> writes:

> Which always accesses Rhs[1] (presumably not useful when
> there are no tokens to merge).

In the yacc parser, Rhs[1] always happens to be the token (or
end-of-file) just after the empty nonterminal, and Rhs[1] always
happens to the nonterminal (or start-of-file) just before the empty
nontermial, so the default YYLLOC_DEFAULT should work, if your
initial action sets the start-of-file location correctly.

> Neither does it make any provision for N=0

It shouldn't have to, as described above.

> and also does nothing to correctly handle any empty locations which
> may appear within Rhs when N>0.

Yes, this leads to locations that (while correct) are wider than they
have to be, as I described in my previous message.

> I guess people should probably always use something like that
> example you showed me in the bison source.  Maybe the default in the
> skeleton file should resemble it was well?

Could be, yes.

> I thought you just told me it wasn't using the locations of the
> adjoining tokens?

Hmm, I wasn't trying to tell you that -- sorry if there was confusion.

> I'm getting the impression YYLLOC_DEFAULT (, , N=0)
> is expected to work these cases out (as opposed to just being passed the
> results in later merges).

Yes.

> Personally I would prefer it if YYLLOC_DEFAULT (had a better name and :) )
> was purely a merge operation and any other operations, if required, were
> defined as other macros, but I guess it's 15 years too late to make that
> kind of decision?

We can make improvements, even if we maintain YYLLOC_DEFAULT under its
current name.

> I don't know what sort of text system or source files GNU projects
> use for documentation.

It's texinfo format <http://www.gnu.org/software/texinfo/>; see
the file doc/bison.texinfo.

> this case:
> 
> P : NON_EMPTY1 EMPTY NON_EMPTY2
> 
> is clearly ambiguous.

It's not ambiguous in the way that Bison yacc parser currently
behaves.  The location of EMPTY starts at the beginning of NON_EMPTY2,
and ends at the end of NON_EMPTY1.  Any code using @2, the location of
EMPTY, can decide for itself which of those two boundaries to use.

The GLR parser says that the location of EMPTY is all bits zero.  This
is easier to explain (though a bit less useful I suppose), and perhaps
the yacc parser could be adjusted to use this rule instead.  However,
this would require changes to YYLLOC_DEFAULT.  We've been a bit
reluctant to do that, for historical reasons.