Re: 10-exercise-parse-param.patch

[akim]

On Fri, Oct 25, 2002 at 06:55:28PM -0700, Paul Eggert wrote:
> I'm following up to:
> <http://mail.gnu.org/pipermail/bison-patches/2002-October/001247.html>.
> 
> > From: Akim Demaille <address@hidden>
> > Date: 21 Oct 2002 09:57:52 +0200
> 
> > Let's start with the yyerror problem: what should we pass to it?  I
> > would say all the %parse-param, but what about the %lex-param?
> 
> Sure: yyerror needs to know everything that it can.

Actually, I'm worrying too much: I fail to see what could be
given to yylex, and not to yyparse.  It seems clear to me that only
%parse-param must be passed to yyerror.  It is up to the user to
pass to yylex what yylex might need when using yyerror.
>
> > And what if there are doubles?
> 
> You mean, double-precision floating point?  I don't see why they
> should be handled differently from other types.  But I suspect that I
> am misunderstanding you.

I was trying to imagine what rule could be used as to the arguments to
pass to yyerror, and was considering that we might need the union of
lex-params, and parse-params.  But in this framework, what was to be
done of things that are passed both to lex- and parse-param?  How do
you decide they are `the same'.

But the point is now void: only %parse-param is needed.
 
> > Another possibility would be to cease the `yyerror' approach, and have
> > something like:
> > 
> > %error {
> >   location_print (@$);
> >   fprintf (stderr, "%s", yy_error_message);
> >   exit (1);
> > }
> 
> Something like that would be reasonable, but I don't fully understand
> the issues. 

One issue is that I wanted to spare the user the need to redeclare her
yyerror when she adds some new %parse-param, or add/remove %locations.
Another is I'd like to avoid the need to depend too much on the order
the parameters are passed to yyerror (in particular the day we have
some %import).  But maybe I'm going too fast.  I'll stick to yyerror
for now.

> I suppose that the generated file would define yyerror if
> you used %error, and would remain compatible with POSIX otherwise
> (i.e. you'd need to define your own yyerror).
> 
> Hmm, how would %error interact with YYERROR?

Precisely because of all these problems, we will probably have to
move away from POSIX for extensions, i.e., using POSIXLY_CORRECT etc.
will disable these extensions.  But people using this interface will
already know that.  Just as %pure-parser already frees us from some
POSIX issues.

> Also, would %error replace the need for YYERROR_VERBOSE?, or would
> that be done by some other means?

YYERROR_VERBOSE in itself is another big problem.  Should we pass the
list of the valid tokens to the user so that she can forge the error
message herself?  Should we pass the semantic value of the lookahead
to make better messages?  Too many possibilities, and in addition,
proper yysymprint design should probably help.  But there are issues
to address before, so I'm not eager to reconsider YYERROR_VERBOSE:
it will stick as is for the time being.

> > Something similar to %printer and %destructor.
> 
> Sorry, I don't know how these work.  (They're not documented yet.)

If you're interested, have a look at the tests that use them (sorry, I
don't remember which one it is, grep %print in tests/*.at).  I don't
plan to document them at all since I'm not sure of the interface yet.
Well, that of %destructor is OK I think, but that of %pinter is probably
not definitive (I'd like to use it for many things, including yydebug:
we could have reduction be much more detailed, including sem values.  In
other words, we need different verbosity levels via different yydebug
values.  But then the question is: do we leave the decoding of yydebug
to the user via an `if' in %printer, or are *we* in charge of this?
Still too many questions, and not enough time, and this is not prioritary).
> 
> > But of course, we have to keep POSIX compatibility, plus backward
> > compatibility under some form.
> 
> Yes, we need to be compatible not only with POSIX, but also with
> previous versions of Bison.

Yes, I know this.  But I have not discarded the possibility that some day
yacc.c no longer be maintained in the sense that new features will be
included in it.  Maybe only a lalr1.c will be the one with new features,
and then, there will not be such issues any longer.