Re: %destructor feedback

[Joel E. Denny]

On Thu, 20 Oct 2005, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
>
> > This thread started on help-bison.  At some point, I CC'ed to
> > bug-bison. However, it eventually lost that CC and then picked it up
> > again.  Could this be why you missed messages?
>
> Yes, that's it.  It's such a long thread, though.

That's because I tend to be verbose.

> If you're thinking of proposing a coherent patch now,

It'll be a while before I write this patch.  I'd be happy to let someone 
else beat me to it.

> perhaps it'd help to summarize it before doing the full work of 
> implementing it.

For whomever ends up writing it, here's a (rather verbose) summary of this 
thread:

1. The documentation needs to state clearly that, once the bison-generated 
parser invokes a semantic action, it passes to that semantic action the 
responsibility for invoking destructors for all associated RHS semantic 
values. This is true regardless of how the semantic action terminates: 
usual success, YYACCEPT, YYABORT, or YYERROR.

2. yacc.c needs to be changed for the cases of YYACCEPT and YYABORT to 
match the above rule.

3. It needs to be decided whether destructors should be invoked 
automatically for RHS semantic values unmentioned in a semantic action. 
Here are the arguments against this feature:

a. It breaks the rule in #1 and so it's confusing.

b. It's possible that a user may have stored $5, for example, in a data 
structure in some other parser or scanner action.  Then he might try to 
destruct it via that data structure in the current semantic action.  In 
other words, his semantic action might destruct $5 without referencing the 
string `$5'.  In that case, bison wouldn't know to leave it alone, and 
that would lead to a double destructor call.  Yes, the user could provide 
a do-nothing mention of $5 to prevent that, but requiring the user to know 
to do that is seg fault prone.

c. This feature may make other desirable features impossible in the 
future.  For example, it might be desirable to provide functions that 
manipulate RHS semantic values and that accept integer parameters to 
indicate which values.  An actual parameter might be a C variable.  How 
can bison compute which value is `mentioned' by yydestruct_rhs_value(x)?

4. If it is decided that the feature in #3 should not be implemented, then 
perhaps unmentioned RHS semantic values should result in bison-time 
warnings.  There may be special cases (for example, 3.b above) in which it 
is reasonable not to use a semantic value in an action.  In such cases, 
the user may wish to disable the warning by providing a do-nothing mention 
of it.  Thus, perhaps YYUSE() should be documented as part of the user 
interface.

5. It would be convenient to provide a function to invoke destructors for 
all RHS semantic values.  Perhaps it should be called yydestruct_rhs()? 
For example, the user can invoke this before any call on YYABORT or 
YYACCEPT where he used to expect destructor invocations to be automatic. 
I am no expert on efficiency, but Wolfgang suggests that yydestruct_rhs() 
should not be a macro since that could lead to code bloat if it's repeated 
in numerous semantic actions.

Joel