Re: %destructor feedback

[Joel E. Denny]

On Mon, 19 Dec 2005, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > On Mon, 19 Dec 2005, Paul Eggert wrote:
> >
> >> Akim Demaille <address@hidden> writes:
> >> 
> >> >   A
> >> >   simple macro that ignores its argument suffice to avoid the
> >> >   complaints.
> >> 
> >> YYUSE should do the trick, no?  So all we need to do is document it?
> >
> > I vote for a different macro so that the original YYUSE could easily 
> > evolve independently in case that proves to be necessary.  On the other 
> > hand, it could always be reorganized later if the need arises.
> 
> Hmm, sorry, I don't quite follow.  Nobody is supposed to be using
> YYUSE now, as it's part of Bison's reserved name space.  If we
> document it now with the current meaning, then yes we'd have to
> support that; but if we need to evolve it we can introduce a new YY*
> macro with a new name, and use the new macro internally.

Sorry for my confusing comments.

As I see it, the purposes of the public YYUSE and the internal YYUSE are 
different. The public YYUSE would be a signal to bison, and so it can hide 
its argument from the compiler.  Thus, it need only be defined as:

  #define YYUSE(e)

The internal YYUSE is a signal to the compiler instead. Thus, it has the 
cast to void.

The cast to void likely would not hurt the public YYUSE.  Thus, the two 
macros could start out as the same macro.  As we both noted above, we 
could then reorganize later if necessary.  But it just feels cleaner to me 
to keep the two separate from the beginning since they're meant for 
different purposes.

> > There was some discussion of adding a function/macro to the user interface 
> > to invoke destructors for all of $n.  This would help users update 
> > grammars that depend on the current behavior of yacc's YYACCEPT and 
> > YYABORT.
> 
> That would be nice, but I don't think it's essential for 2.2.  If
> someone (you?) can implement it quickly let's put it in, but I
> wouldn't have 2.2 wait for it.

I don't foresee this feature being useful to me.  I brought it up just as 
a reminder of what was discussed.

Joel