Re: Exceeded limits of %dprec/%merge?

[Joel E. Denny]

On Fri, 19 May 2006, Joel E. Denny wrote:

> On Fri, 19 May 2006, Derek M Jones wrote:
> 
> > > Exposing internal data structures like yyGLRStack and yySemanticOption to
> > > the user is scary.  Bison developers would then have to worry about 
> > > backward
> > > compatibility issues as we tried to evolve these structures and 
> > 
> > I take it what you mean is that by publishing an API you are essentially
> > suggesting a degree of backwards compatibility and that in this case you
> > don't want to make such a suggestion.
> 
> Yep.

I think I didn't interpret your question correctly.  I'm objecting to 
encouraging direct access to the Bison-generated internal GLR structures 
because the Bison developers should have the freedom to evolve those.  
Publishing an API that serves as a clean abstraction layer for the GSS 
(graph structured stack) is a different matter.  Of course, it would be a 
lot of work to do it right and maintain it, but it would likely be 
worthwhile.

I can see this being useful in %conflict actions.  For example, the moment 
I see an IDENTIFIER, I might be able to walk back on the stack to figure 
out how it was declared so that I know how to reduce it.  That may prevent 
the parser from ever splitting.

On Fri, 19 May 2006, Joel E. Denny wrote:
  
> Would you like to propose a
> set of functions to act as the user interface to these structures?

I meant this as an offer to you, but now my own interest in this is 
growing....

Joel