[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: push parser

From: Bob Rossi
Subject: Re: push parser
Date: Fri, 15 Dec 2006 14:03:53 -0500
User-agent: Mutt/1.5.12-2006-07-14

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
>    code for pure pull parsers only
>    code for impure pull parsers only
>    code that's identical in push and pure pull parsers only
>    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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]