Re: $$ = $1

[Akim Demaille]

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

:)  Don't be sorry :)  Diving into Bison does not seem to be something
really trivial to me, yet you applied several very pertinent patches!



| I prefer the [current code].  It makes the code faster, and there's
| no point catering to the invalid possibility.

Fine with me too.



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

It should: I see no reason for it not to have one.  It's real just
another token.


| This also suggests that we should have a zero-width location.

But anyway, we seem to agree on the conclusion.


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

That's another problem, agreed: where to initialize yylloc.
Currently, I always do that in the scanner, which is not correct
precisely because of this.  It is the parser which should handle
this.  But then again, the question is how to provide the user with
means to initialize it :(  The same goes with printing a location.

There are many open issues to solve like these :(  The optional
YYPARSE_ARGUMENT is another pain in the neck.



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

I agree.  Fetching the next lookahead is not trivially safe, since the
current reductions can, for instance, flag `foo' as a typedef, which
could be exactly what was needed by the scanner to decide whether the
current lookahead (which turns out to be foo) is a typedef or
something else.

I doubt very much that real world cases, such as a C grammar etc.,
could have so short (in distance between tokens) parser/scanner
dependencies, but...



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

Ah!  I never considered these!

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

It doesn't to me: after all, not using %type is like declaring
everybody as <int>.


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

My main concern is that it seems to be quite some work for a marginal
case: I suppose there are really few %type-less parser out there.  And
again, I prefer something more homogeneous: %type-less is
%type<int>-full.


| > BTW, stupid me, I should have looked before: this is what BYacc does
| > too:
| 
| Ah, then we're in good company....

I am amazed by the number of bugs that where recently fixed in Bison,
which, when I honestly meant report the bug to byacc's people, turned
out to be fixed there...