Re: Reductions during Bison error handling

[Paul Hilfinger]

 > I think that under all circumstances, the default reduction rules should be
 > as though the result of, for n >= 1,
 >     x: x_1 ... x_n
 > is the same as
 >     x: x_1 ... x_n { $$ = $1; }
 > 
 > Is that what happens in your example?
 > 
 > -- That is, the default selections that Bison makes use of (first rule in
 > the order) may look funny, because it depends not only on the grammar, but
 > also on how it is presented (the rule order) and even the type of parser
 > algorithm used (LALR(!) etc). (Also, error token shifting in LALR(1) is
 > different from that of LR(1) (but not reductions).) But that's just how
 > things are.

I'm not sure we are talking about the same thing here.  When I said
"default reduction", I was referring to the purely internal device of
labeling one of the most popular reductions in a state arbitrarily the
"default" and storing it specially (in yydefact) in order to compress
the parse tables.  I was not refering to the default ACTION ($$ = $1;).

Error recovery in Bison is not done as documented in the manual in the
first place.  In addition, I was pointing out (in effect) that the
code in question makes even MORE obscure and unpredictable what is
going on (unnecessarily so).

The documentation says that when I am in this situation:

    Parse Stack:  s1  s2 ... sk ... sn  <-top   Lookahead: X

and the action for lookahead X in sn is "parsing error", then we are
supposed to 

1. pop the stack back to the first state that allows shifting
   the token `error' (let's say sk), 
2. shift 'error' (giving, let's say, state sk'), 
3. delete tokens until we have a new lookahead (Y) that is legal for 
   state sk', 
4. Proceed normally.  

All nice and clean (although as Corbett and others have pointed out,
not all that conducive to great error recovery---hence the term "panic
mode"). 

What ACTUALLY happens is that step (1) is replaced with

1'. pop the stack back to the first state that allows *some non-error 
    action OTHER THAN A DEFAULT REDUCTION on* the token `error' (let's
    say sk),

1.1'. if the indicated action for sk and the error token is a
    reduction, perform the reduction and proceed normally.

I was basically pointing out that since "default reduction" is not a
user-visible concept in Bison, the effect of the capitalized clause in 
1.1' is unpredictable from a Bison user's point of view.  The effect
of removing the "#if 0"s around the yyerrdefault code would be to
convert 1' into something a little more predictable:

1''. pop the stack back to the first state that allows *some non-error 
    action on* the token `error' (let's say sk),

Admittedly, not all that much more predictable, since unfortunately it
is also hard for a user to understand when Bison will choose to use a
default reduction for an erroneous token and when it will use an error
entry (it is always harmless to use a default reduction, since Bison
normally never shifts past a viable prefix before reporting an error).

All this is leading me to wonder if perhaps it might make sense
instead to actually correct Bison's panic-mode error recovery to work
as documented.

Paul Hilfinger