Re: $$ = $1

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 31 Jul 2002 10:44:07 +0200

> Sorry, but *why* do think we should store the lookahead on the
> stack???  The lookahead is in yychar, yylval, and yylloc.  It is not
> on the stack.

I was mistaken.  I assumed it was on the stack.  Sorry about that.
Clearly I didn't check my work enough.

> The question is whether you prefer to
> stick to the comment and implement
> 
>         if (yylen > 0) 
>           yyval = yyvsp[1-yylen];
>         else
>           yyval = yylval;
> 
> in which case the comment cannot pretend that it is `_the lookahead',
> since it is certainly the previous one, or keep the code as is, which
> just works around GCC's complaint about unitialized variable by taking
> advantage of its impossibility of complaining about uninitialized
> *slots* of arrays.

I prefer the latter.  It makes the code faster, and there's no point
catering to the invalid possibility.

> Good call!  That's definitely what we'd want!  But then again, we have
> the problem that we don't read the next lookahead ``soon enough''.

In that case I guess it's OK to have a zero-width location, just after
the previous symbol.

Here's another problem that I didn't think of earlier.  Suppose the
empty rule is reduced at the end of input.  Then there is no
"lookahead" in the usual sense: there is only the end of file symbol,
which (if memory serves -- sorry, I'm a bit rushed and am supposed to
be doing other things) doesn't have a location.  This also suggests
that we should have a zero-width location.

There is another boundary case, though.  Suppose the empty rule is
reduced at the start of input.  Then there is no previous symbol.  I
guess this would correspond to location zero.

> But why do you want it to be negative?

I was being tricky: a negative width could be used as a flag that it
was an empty production.  But on second thought, it doesn't really
help to be tricky, and the trickiness would just be extra confusion.

> My reading was that this emptiness is certainly ``full´´ of comments
> or whitespaces, skipped by the scanner.  My reading was that you
> wanted to get that space.

Yes, that was it.

> So I'd say something like
> 
>         @$ starts where @0 ends, and ends where yylloc starts
> 
> if yylloc was read :(

One possibility is to force a lookahead at that point.  But this
sounds like overkill to me.  A zero-width location is preferable
here, since it needs no lookahead.

> in a properly typed grammar, a nterm with an empty lhs without
> action cannot be typed.

But what about simple grammars that use `int' for all semantic values?
Can't they use that value?  E.g., Bison currently accepts this
grammar:

  %%
  exp: empty { printf ("empty returned %d\n", $1); };
  empty:;

And if I run the program, I get the output "empty returned -13369876"
or some such garbage like that.

It seems a bit Draconian to outlaw "empty:;", though.

However, it would be helpful for Bison to reject "empty:;" if some
other rule uses the value of "empty".  More generally, Bison should
reject a grammar that uses the semantic value of a nonterminal that is
known to be unsafe.  A nonterminal is "known to be unsafe" if it has
an actionless right-hand side that either is empty or starts with an
nonterminal that is known to be unsafe.  I don't know if it would be
easy to implement a test like that, but if done correctly I think it
would remove the need for the current "empty rule for typed
nonterminal, and no action" test, as it would apply equally well to
typed and untyped grammars.  (Easy for me to say, huh?  I haven't
looked at the code.  :-)


> The two problems I see are:
> 
> 1. Cf. the paragraph above,
> 2. Looking past the top of the stack.
> 
> If both items are checked, then we just have to fix the comment, but
> keep the code.

Yes, that sounds good to me.

> BTW, stupid me, I should have looked before: this is what BYacc does
> too:

Ah, then we're in good company....