Re: Disappearance of rhs[], prhs[], and user control of table generation.

[John P. Hartmann]

I need to weigh in here too.  I use Bison in "table-only" mode.  Any
change in the table structure would require me to make a corresponding
change in my post processor.  Any radical change would mean that I
would be stuck with a downlevel Bison.

On 6 April 2011 14:35, David M. Warme <address@hidden> wrote:
>
> 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.
>
>
>
> _______________________________________________
> address@hidden http://lists.gnu.org/mailman/listinfo/help-bison
>