In fact, since the mechanism is mainly supposed to simplify skeleton
selection, why not have a tuple like (language, grammartype, skeleton)?
This would make it quite easy to add new grammar/parser types to bison.
Yes, but... :-)
Even with current bison capabilities, does %nondeterministic-parser
always mean the GLR skeleton should be used (for any language)?
Right now, it is. In the future, AFAIU, %nondeterministic-parser may
build a backtracking parser.
As such, perhaps the current %xxx-parser directives could then become
aliases for "%parser-type xxx" (or "%grammar-type xxx", whichever is
more appropriate).
Agreed. But then, I think it could be sensible to have all the
skeletons named "GRAMMAR.LANGUAGE", or "GRAMMAR-LANGUAGE.m4", or
something like that. In which case, the language table will not need to
contain the skeleton names anymore, but only information on availability
of the skeletons (a bitmask), and file extensions (so that .y will map
to .cc if you are using %language "C++").
For the two grammar types currently available, let's keep it simple.
Paolo
