Purity of yyerror etc.

[Akim Demaille]

Hi friends,

Here is my proposal for Bison's purity of yyerror etc.  It's a very
long but quite straightforward patch.  It is quite long because glr.c
has to be changed in zillions of little places to become pure.  It
results in a program that can have many arguments in function calls.

Paul H., I'm not sure I have fully understood when you preferred
yyval/yyloc vs. yylval and yylloc as sometimes it seems to me that
some yyval and yyloc do refer to the lookahead, but I might have
missed something.  So I respected the difference, which is why there
is b4_pure_args vs. b4_lpure_args.

There is no ChangeLog, I'd like to first have an agreement on the
protopatch, then I'll finalize it, with ChangeLog, additional
factorization, and... documentation...

When writing this patch, I considered that someone using %parse-param
requires purity, independently of %pure.  Actually, %parse-param could
imply %pure.  Hm... I had not thought about this, maybe it could
simplify the code.  Anyway, the idea were

1. if you %parse-param, then you are ready to upgrade the yyerror
   signature.

2. if you use %pure and %location, then you are ready to have yylloc
   passed to yyerror.

3. but 2. is not compatible with previous versions of Bison, so
   it applies only to users of glr.c, not those of yacc.c who do need
   a %parse-param to really trigger the really pure interface.  The
   idea is that you cannot possibly claim being %pure if don't have
   a %parse-param, at least to return the result.

Let me know if this seems correct to you.  Actually, I believe we
should deprecate %pure, as %parse-param should be exactly what is
needed.

purify.patch
Description: Text Data