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: Wed, 29 Sep 2004 14:34:25 -0700
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Akim Demaille <address@hidden> writes:

> Since in some cases, it is possible to consider the end of the
> previous symbol, and the start of the coming lookahead, it is tempting
> to consider that this is the location of the empty reduction.  In the
> case above it would "accurately" consider that the empty reduction
> spans one character (the white space).

That sounds a bit counterintuitive from the user viewpoint.
If empty locations contain characters, they won't seem empty.

There is typically some ambiguity as to where an empty location should
be.  For example, suppose there's an empty reduction between the
symbols "foo" and "bar" in the text "foo  bar" (with two spaces between
the foo and the bar).  Then the empty location could be just after the
"foo", or between the two spaces, or just before the "bar".  Here, the
implementation is free to decide where the empty location is: it can
be anywhere between "foo" and "bar".  But whereever the empty location
is, it should be empty.

More generally, if the parser identifies several empty locations
between "foo" and "bar", there is a constraint that the locations
should be in the correct left-to-right order required by the grammar.

> One possibility would be to add a flag to the locations,
> "results_from_an_empty_reduction", but I'm reluctant to do that.

Yes.  I think it'd be cleaner all round if empty reductions always
have empty locations.

Are you attempting to have the parser always keep track of the maximal
white space around every empty location?  That sounds like it might be
extra work in general, for all parsers, as sometimes a parser can do
an empty reduction before scanning for the next token, and adding this
requirement will force the parser to scan ahead to see how much white
space there is.  However, if this is the goal, then I suggest that
empty locations be identified by having a start position that is just
after the end of the white space, and an end position that is just
before the white space's start.  This will make it easy to distinguish
empty from ordinary locations.




reply via email to

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