bison-patches
[Top][All Lists]
Advanced

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

Re: FYI: yacc.c: YY_LOCATION_PRINT: Fix


From: Paul Eggert
Subject: Re: FYI: yacc.c: YY_LOCATION_PRINT: Fix
Date: Thu, 30 Sep 2004 10:11:09 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

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

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

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

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




reply via email to

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