Re: trying out the c++ parser skeleton / b4_post_prologue

[Anthony Heading]

Hi Akim,

This is very informative - thanks!

You wrote:
> Obviously you can't add these new members in a subclass, since the
> user actions are run in the superclass.

Ah - I was certainly assuming a solution to that problem:  to achieve
what I was aiming for it would be necessary to have the actions run
with those members in scope.  

> In the end, after having tried several approaches, the driver pattern
> proved to be not only simpler, but also much more flexible and more
> powerful.

OK.  My complaints are:
 1)  The pattern is not so intuitive - the simplicity is maybe relative
 2)  The scope in which the semantic actions run seems to be wasted -
     it's not utilisable by the end-user for anything except a single
     "driver" variable.

>  > I was surprised to find, for example, that in this bison-c++, the
>  > interface to the lexer is not created as an abstract virtual function
>  > for the end-programmer to implement, but instead remains a C macro.
>
> Right.  Valid or not, the point was simply to avoid an indirection.

Very fair, and I probably agree with that call.  I meant it only as an
example where following conventions could increase ease-of-use.

> Also, in case of recursive parses, while there are several parsers,
> there is a unique driver.
> [...]
> A parser driver is not a parser.  The relationship here is not
> subclassing.  But you might be referring to some new kind of
> relationship that would need more description.

OK.  I guess there's more than one aspect to this.  Specifically,
I want to access the token table parser::yytname_[] from my
"driver" code.   This variable with many others are declared
as private members, which is a bit extreme given that they're
fully accessible in a C parser.  With a nod to the benefits
of encapsulation, I compromised by changing the skeleton to make
everything protected, which admittedly begs the question as to
the need to subclass :-).  But anyway, there's a lot of such
useful static data which it's nice to be able to bring into
scope in the way that an inheritance relationship provides.

I understand that recursive parsing demands that much of
the parser state exists in a many-to-one relationship with
the user state.  It wasn't that type of parser data that
I was thinking to inherit.

> So what exactly are you proposing?  That we generate code for a
> subclass that the user is expected to write?  How is that simpler than
> the current scheme?

Hmm.  Well, I'm wanting user actions to run in the context of the user-
controlled state, so I suppose I'm thinking that bison should write
out an implementation of a member function e.g. MyDriver::parse().
The user probably has to declare that himself.

The question of inheritance is perhaps only an implementation
artifact.  If bison were supposed to generate parsing code that
would compile within a user's class MyDriver, maybe that
might be made easier if MyDriver were required to inherit
from a bison-generated base class, which could simultaneously
make available info like e.g. the token table, but perhaps
some other data too. (Does e.g. the debug level need to be
parser-instance specific for recursive parsers?).  Obviously
though such an infrastructure class is not "the parser" in the
way that term is currently used.

Is this simpler than the current scheme?  Well, to me, yes:
the idea of filling in slots in a single user-visible hierarchy
is simpler than setting up a parser <-> parser driver
pairing.  But simplicity is all eye of the beholder, of course.
And then maybe this doesn't work at all for some reason...

> There is one feature that Hans (and I, for one) wants for quite a
> while now, and that was technically difficult until very recently:
> %define for code.  It is now at hand, and it turns out I have a patch
> almost ready for it (I have a s/r conflict to kill first).  That
> should provide knowledgeable users with more freedom.

I'll look forward to that.

Regards

Anthony