Re: Proposal for lambda'ing error recovery

[Akim Demaille]

 >> From: Akim Demaille <address@hidden>
 >> Date: Mon, 18 Nov 2002 15:30:46 +0100
 >> 
 >> Well, I have not received any comment about the patch.

 Paul> Sorry, somehow I am not subscribed to bison-patches.  I'll fix that now.

 >> I really can't imagine any impact on the performance because of
 >> `register' here

 Paul> I can imagine impact, in some cases, but the problem is easy to fix:
 Paul> copy the variable from its register variable to an auto variable just
 Paul> before the call, and copy it back afterwards.

Same here.  But really, I'd like to know what kind of parser (in
particular what kind of actions is can perform) so that the mere
spilling of some variables could have a noticeable impact :(
I'm fine with the temporaries to avoid this issue though.

 Paul> More serious than the register problem is the fact that some existing
 Paul> grammars seem to assume that all actions and error recovery are in one
 Paul> procedure; I am thinking of the compatibility problem reported by Ralf
 Paul> S. Engelschall with yyreport_parse_error, which we fixed on 2002-10-11
 Paul> by moving that function body back into yyparse.  Such user code is not
 Paul> portable, of course, but I would rather not mess with that assumption
 Paul> until after a stable Bison version is out.

Err, I fail to see the relationship here, because I see no means for
the user to have some influence on this area of the code.  I did not
try to refactor the *report* SyntaxError, just the *recover* bits.

 Paul> Perhaps we can check in possibly-destabilizing changes like
 Paul> this into a separate branch?

Maybe this no longer applies?