%print

[Akim Demaille]

>>>>> "Zack" == Zack Weinberg <zack@codesourcery.com> writes:

>> I'm working on another new feature, which is best described by an
>> example:
>> 
>> %print { expr_print ($$); } expr binary_expr foo_expr NUMBER

Zack> Yes, I think that would be useful, especially if it could be
Zack> used in conjunction with yyerror as well as yyprint.  Currently
Zack> we have a bunch of kludges in both to attempt to give coherent
Zack> diagnostics.

Yeah, I know this.  I'm looking at GCC currently to see how it can
make better profit out of Bison features.  Currently, it uses very
few, including the simple YYERROR_VERBOSE.

Zack> Another item for your consideration: If you look at the bottom
Zack> of c-parse.in you will see huge tables whose sole purpose is to
Zack> map from token codes chosen by cpplib and/or the reserved words
Zack> table, to token codes chosen by bison.  If we could write e.g.

Zack> %token '+' = CPP_PLUS

Zack> which would have the effect that yylex() may return CPP_PLUS and
Zack> bison takes it as a '+' token, that would be exceedingly useful.
Zack> I'm aware of the

Zack> %token '+' 12

Zack> feature, but that doesn't seem to do what I want - (a) CPP_PLUS
Zack> is an enumerated constant; (b) code inspection afterward
Zack> suggests that the specification is ignored if it clashes with
Zack> bison's internally wired token numbers, which does me basically
Zack> no good.

This is no longer true.  What is still true is that you can only have
aliases for a symbol, and one has to be a string.  But we are
rationalizing all this, and having a means to have string + id + char
might be very helpful, indeed.


Zack> I'd expect doing this to indicate to bison that yylex() will
Zack> *never* return any token code other than the ones in the
Zack> explicit list, and I'd also need to be able to tell it which one
Zack> was the EOF token.

That's already fixed in CVS Bison:

%token TOK_EOF 0 "end of file"

makes TOK_EOF be the end of file token.  Have a look at CVS Bison's
NEWS.


Zack> I'm pretty sure that a lot of bison's internal tables could
Zack> become smaller and/or unnecessary with this feature.

I'm not sure I understand your point here.  It is not very costly to
have a 256 items table to tell what chars are and are not valid
tokens.  I don't believe there is much to be gained with this, do you?
That's the only place where you will find some cost to related to this
(yytranslate).  Removing this, in addition, seems to be quite
dangerous.