Re: FYI: yacc.c: YY_LOCATION_PRINT: Fix

[Akim Demaille]

Le 30 sept. 04, à 19:11, Paul Eggert a écrit :

> Akim Demaille <address@hidden> writes:
>
> > an constraint I gave myself was to stick to the previous definition
> > of the locations, including the ill-designed YYLLOC_DEFAULT.
>
> Backwards compatibility is important, but the location of empty
> productions was never documented, and was random garbage in many
> cases.  If we define it cleanly, few Bison users will care, and the
> ones that do should welcome the change, even if the definition
> sometimes disagrees with the earlier one (when the earlier one wasn't
> garbage....).

If think you are referring to the values, the fact they were not
defined.  It is not exactly my purpose: I'm referring to the
data structure that does not provide a means to express

@$.end = @$.begin

which is basically what we need for empty rhs.  Sure, we can do that
with Bison's default locations, but not for user defined locations.
Also, Bison default locations do not include a file name, which is
quite stupid.

That's why I'm tempted to leave the current locations as they are,
and move to a cleaner default implementation of the locations, and
another set of macros so that the user could provide his own
location type.

I agree more macros would suffice, but the default values for these
macros already demonstrate how inadequate our current structures are.
So upgrading everything is tempting.

> > But with YYLLOC_DEFAULT as is today there is just no way to implement
> > that.
>
> I wouldn't worry too much about how it behaves today with empty
> productions.  Currently there is no documented behavior for empty
> productions.  So we can do what we like there, as far as I can see.
> For example, we could specify a new macro that the user can define,
> which is executed instead of YYLLOC_DEFAULT whenever an empty
> production is triggered.  Or we can implement a behavior that the user
> can't control at all.

Precisely in the latter case we need to know a bit on the location type,
that it has a "begin" and an "end".

YYLLOC_DEFAULT could also include the yylen == 0 test and the user would
have to handle the case himself.  I don't remember if YYLLOC_DEFAULT 
used
to be called in such a case, I'll check tomorrow.

> > I never experienced a situation where an empty location would have
> > to be triggered and reported to the user.
>
> I agree this should be rare, but it's possible.  More important, 
> though,
> is how empty locations combine with nonempty ones.

Definitely!  I would like to move your idea of ignoring empty locations
when unioning locations into the skeletons.  But currently I can't
(except for our default location type).

Also, we should remember that "empty" is meaningless when we have
simple line-column tracking...


> > The more I work on this location, the more I wish we'd design a nice
> > system, similar to what we have in lalr1.cc, or what bison has for
> > itself.  That's much more logical, and such a situation would be easy
> > to fix.
>
> Sounds good to me.
>
> > Maybe it's time to introduce something like %new-locations.
>
> Sorry, I don't follow.  How would that work?

Another set of macros on top of another default implementation.
Roughly, with this option, bison itself wouldn't need extra code
to implement location tracking: it would directly use the default
implementation.

I guess I should first write a documentation about it.