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
