Re: Bison and C++

[Hans Aberg]

At 00:09 +0200 2001/08/11, Robert Anisko wrote:
>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 think that there might be a difference between class pure and function
pure parsers: What you think of here is a class pure parser, which I figure
will be the Bison default. Different class instantiation parsers should not
collide.

But one can still think of a function pure parser: Different calls of the
parser of the same class instantiation should not collide. This might be
used in threading.

Of course, purity only applies to states that may change, so tables and
such are not part of the question.

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


Try to remove as much as is possible of the macro names: Ideally, all names
should be put in a user defined namespace. The default namespace could be
"yy". Then YYSTYPE will be named
  namespace yy {
    typedef ... stype;
  }
or whatever.

>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?

Right use the C++ containers. But you could keep the door open for people
substituting their own container at will. Also remember that C++ allows for
changing the allocators, so if one does not think that the class is
efficient enough, one can first change the allocator.

I think that the inefficiency complaints about std::vector should not be a
problem for Bison: For example, std::vector always default initializes
elements. But one can instead use vector::reserve, and then the vector is
not initialized.

Note that their is a problem if people will want to use alloca, because it
does not fit at all into C++ programming. One could not use std::vector
then. So for use with alloca, you would have to write something special.

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

Or rather for me. I think this would be difficult to do without the kind of
macro language I created. -- I recall that Akim said it was nothing for him.

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

The parser generator first generates tables for use with a state machine,
the latter which is provided by the skeleton file. So it makes sense to
make multi-language support, as one only has to change the state machine.

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

So this would follow from my approach with the macro language. But it is
clearly beyond the scope of the current approach with skeleton files.

Or try to cut down the skeleton file and put what Bison writes into macros
in your favorite macro language. Then try to use that macro language to
generate parser outputs in different computer languages. This might work if
the output language does not have a syntax which is same for arrays etc.

  Hans Aberg