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 _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison