On Thu, 20 Oct 2005, Paul Eggert wrote:
"Joel E. Denny" <[EMAIL PROTECTED]> 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
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison