> I've got a couple of simple suggestions for the C++ parser generator.
> Firstly, yylex() should be declared as a (pure) virtual function in the
> parser interface. This would make using it re-entrantly significantly easier
> and would mean that the user does not have to declare it.
Actually, the parser was not really meant to be subclassed. Maybe that was an error, agreed.
> Secondly, stack.hh should be replaced with the Standard stack class. This
> will ensure that users who have move support can use move-only classes when
> interacting with Bison.
Actually it is plain standard C++ (it's a deque), and it's useful. What is painful though is that it is a separate file. I'd like to merge it into the header file once for all (but backward compat will have to be maintained in some way).
Where do you use move semantics? Are you using some C++-11 compiler?
> Thirdly, I suggest that Bison should generate it's own AST classes, with
> inheritance being used to link rules which have alternatives. This would
> solve, mostly, the problem of the semantic types only being POD data types.
Yes, indeed, but that's a whole new project you asking for here. Bison is a parser generator, not yet a parser-and-ast generator.
Have you experienced the %variant mode in Bison development version? It works well, and avoids this nasty POD issue. Have a look at http://www.lrde.epita.fr/~akim/download/bison-2.4.570-7a582.tar.bz2. Look for variant in the documentation. The following example shows what you can do. I need to polish and publish this :( Help would be most welcome.