Re: push parser

[Bob Rossi]

On Fri, Dec 15, 2006 at 10:16:57AM -0800, Paul Eggert wrote:
> >> In theory, it should be 
> >> possible to have any of the following combinations:
> >> 
> >>   impure LALR(1) pull C
> >>   pure   LALR(1) pull C
> >>   impure GLR     pull C
> >>   pure   GLR     pull C
> >>   impure LALR(1) push C
> >>   pure   LALR(1) push C
> >>   impure GLR     push C
> >>   pure   GLR     push C
> >>   (Now repeat the list for C++.)
> 
> In practice, I think nobody cares about impure parsers (i.e., parsers
> with a single global static state) except for the traditional case
> (LALR(1) pull C).  As far as I'm concerned, we can drop support for
> impure parsers, except for that special case.  Will that help simplify
> things?

I'm not sure. This is purely a maintainence decision that needs to be
made by the wise bison maintainers. I'm not interested in having my push
parser changes force any such restrictions as described above. If the 
decision is made to drop pure parser support, the push parser might have
looked much different. It's hard to say.

> I haven't been following the technical details, but as I understand it
> qthere are the following bits of specialized code.  (Let's assume
> LALR(1) C.)
> 
>    code for push parsers only
Yes
>    code for pure pull parsers only
Yes
>    code for impure pull parsers only
Yes
>    code that's identical in push and pure pull parsers only
Yes
>    code that's identical in all three parsers
Yes, and also the important case, 

code that is not identical in push and pure pull parsers

> My assumption is that the other cases (e.g., code that's identical
> in push and impure parsers only) don't occur.

Yes, this is my assumption also. 

Bob Rossi