Re: Bison and C++

[Axel Kittenberger]

> So, please, go ahead, any proposals,
> suggestions, or comments are welcome.

* use enums instead of #define's, they don't polute the global namespace.
* allow to build easier pure parsers, by moving the currently global 
variables into a parser class, this one can be instanced how often the 
programmer wants, or until memory exceededs :o)
* I guess it is possible to create the parser as a template, instead of the 
#define YYSTYPE as it is used in c.
* Another brainstorm idea only, I don't know if it's too good, the parser 
stack could be realized by some more convinient c classes instead of the 
reallocation stuff inside of yyparse, like vector<> in example, but I don't 
think it will bring any performance, actually guess it would loose some.
* add #ifndef __PARSER_GRAMMAR_H__, #define __PARSER_GRAMMAR_H__, #endif to 
the generated header files, in example for a file called grammar.y, 
grammar.yy, grammar.yxx or however you call the c++ extensions. (little small 
voice cawing: grammar.cc.y :). Eithercase differently if possible, so one can 
use two bison parsers in one project. I had once to  "double use" one parser 
as actually two parsers, since an application will fail miserably at linking 
stage if it has two different bison parsers.
* There are many more languages, beside C / C++. It would be cool if 
there would be some generic "parser template description" file, telling bison 
how to create things. So projects with alternative languages just would have 
to deliver their parser template specifcation file with their source code, 
and not a whole modified version of bison, which users have to configure, 
make, make install. I know I can come with my own "bison.simple" version, but 
there are some things bison generates where it implies the result is C. Like 
the #define statements, the look of the actions, the headerfiles and the type 
names.
* Another brainstorm idea, maybe it would be nice to cleanly structure bison 
more. Having a frontend that just generates the LALR parser tables, and the 
backend that actually builds the parser code. So one part it's just a general 
LALR table generator,  and the other part is a simple code generator.

Hope you'll find some of the piled idea's fruitful, I'm currently out of 
strikes :o)

- Axel