Re: Bison and C++

[Robert Anisko]

> * use enums instead of #define's, they don't polute the global namespace.

I agree with that. Maybe could we go a little further, and put
all Bison stuff into a dedicated namespace? I don't know if this
would be really useful, but, that's an idea.

> * 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)

Actually, since we want to output c++ classes, I don't see any good
reason to write non pure parsers. Anybody sees something?
Parser tables and other variables will of course become class members.

> * I guess it is possible to create the parser as a template, instead of
the
> #define YYSTYPE as it is used in c.

That could be done as well for locations. I like this idea, but maybe
some people don't want templates? I don't know.

> * 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.

Using c++ containers instead of all those c arrays sounds good to me.
I have no idea of how this could change the parser performance, however.
STL is usally very efficient, isn't it?

> * 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 should be no linking problems anymore when using several
c++ classes.

Moreover, using multiple c++ parsers can be done very cleanly. One
idea is to provide an abstract base class for all parsers, and use
inheritance at parser generation. Things would be a lot easier for
users this way.

> * 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.

Ouch. Of course, this is seducing, but it is far beyond the generation
of c++ parsers. Also, this is much more work. Proposals of this kind
are definitely for Akim...

Anyway, are you sure that they are really that many languages that would
benefit from Bison? Many languages already have their parser generators.

> * 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.

Cleanly structure Bison more? Hey, that sounds like a heavy
decision to take...

Robert Anisko