Christian, Levin, Akim and all,
Keep in mind that most of the CPU time is usually spent on lexer side. So it
would make sense to optimize that first. However that's one of the issues
where you quickly realize that a split parser/lexer design is in the way. If
they were tied together, you could
The problem isn't exactly infinite recursion, at least not as far
as Bison is concerned. The error/warning messages are indeed
suboptimal. Bison reports a constellation of symbols/rules as
being "useless."
When most people (myself included) see this message, they usually
assume that this means
of the form:
a: b ;
and that have no action code (other than the default action of $$ = $1).
The symbol b can be either a nonterminal or a token. Such unit
reductions serve only to symbolically "rename" the symbol at the top of
the stack. These "no-op" reduce operations can simply be omitted with
no ill effect. There are lots of other good things that come from doing
this, but that should be a separate discussion.
David
David M. Warme, Ph.D.
Principal Computer Scientist
Group W, Inc.
Fairfax, Virginia, USA.
___
help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
ps other similar tables) if we contributed a declaration
(like the one shown above) that would permit the user to force
generation of tables he or she really wants/needs?
David
David M. Warme, Ph.D.
Principal Computer Scientist
Group W, Inc.
Fairfax, Virginia, USA.
