Bison developers, While examining the "git" repository for bison, I discovered a change that will be very detrimental to our particular application that makes extensive use of bison. The relevant change is discussed here:
http://lists.gnu.org/archive/html/bison-patches/2008-11/msg00291.html We have a rather large code base (several hundred grammars, most of which weigh in as "large and complex"). All of these grammars are used in a way that depends upon having the yyrhs[] and yyprhs[] tables available. Outright removal of these tables would be a huge problem for us. Further examination yielded very confusing results, however. The patch referenced above dates from November 2008, yet looking at the latest released version of bison (version 2.4.3, dated August 2010) it appears that yyrhs[] and yyprhs[] are still being generated. Certainly parsers can be smaller and faster if bison drops tables that it doesn't need. But it would be handy if the user could specify tables that should always be produced (even when bison doesn't think it needs them), e.g.: %generate-tables yyrhs yyprhs yytname or even the following: %{ typedef short my_short; %} ... %generate-tables {my_short} yyrhs yyprhs %generate-tables yytname which would also give the user the ability to force a certain choice of type for said tables. (The temptation was to use <my_short>, but currently that syntax is used to specify %union member names, not type names, so I switched to curly braces instead.) Questions: 1. What is the current state (and future fate) of the yyrhs[] and yyprhs[] tables? 2. Would you be willing to retain the ability to generate these tables (and perhaps other similar tables) if we contributed a declaration (like the one shown above) that would permit the user to force generation of tables he or she really wants/needs? David David M. Warme, Ph.D. Principal Computer Scientist Group W, Inc. Fairfax, Virginia, USA. _______________________________________________ [email protected] http://lists.gnu.org/mailman/listinfo/help-bison
