Paolo Bonzini wrote: > 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++").
Agreed, except that GRAMMAR.LANGUAGE and GRAMMAR-LANGUAGE.m4 can both run afoul of file name limitations etc, and having an internal table can avoid that. Then again, with a fixed naming scheme, users can simply drop, say, "glr.c#" in the bison lib dir and bison will automagically use it without having to know it exists (is that desirable?). And bison could postprocess the default filenames based on the platform it's on (e.g. change "lalr1.c++" to "lalr1.cxx" for DJGPP). So yes, having a more fixed way of determining skeleton based on file name would be a good idea too. > For the two grammar types currently available, let's keep it simple. Agreed.
