On Tue, 18 Oct 2005, Wolfgang Spraul wrote:
If you define YYRHS_SIZE and YYUSER_DESTRUCTOR, why don't you also define
CLEANUP in the skeleton, as YYCLEANUP?
From the viewpoint of the bison developers, adding YYRHS_SIZE and
YYUSER_DESTRUCTOR should be very straightforward. That's why I proposed
it. Moreover, I figured it would make it very easy for the user to define
any kind of cleanup macro he wants. For example, maybe he wants CLEANUP
to remove only a specified range of semantic values: CLEANUP(2, 3).
On the other hand, perhaps no user would ever need anything different than
a full RHS cleanup. Perhaps adding YYUSER_DESTRUCTOR to the user
interface would make it too difficult to implement the automatic
destructor for unmentioned RHS semantic values (which we discussed earlier
in this thread). The inability to add such flexible manipulators for RHS
semantic values may be a good argument against that automatic destructor
feature.
Anyway, that *was* my rationale for my proposal, but it seems there may be
too many issues.
If you define YYRHS_SIZE and YYUSER_DESTRUCTOR, why don't you also define
CLEANUP in the skeleton, as YYCLEANUP?
My biggest 'real' point in all of this was the redundant cleanup code. I had
hundreds of free_this() free_that() calls and with bison's 2.1 yacc/YYABORT
behavior I don't need them anymore. Since my code is running in an embedded
environment, I appreciate every KiB that I can save.
Your CLEANUP macro would put the loop in every action, I'm not sure how well a
modern compiler would optimize this across a larger switch/case.
Sorry. I get it now.
I don't understand right now why one would not like to build this 'into' the
bison skeleton, as just another label, errorlab1_cleanup or something. Maybe
there are so many labels already you don't want even more?
Are you now talking about a YYCLEANUP macro or YYABORT_CLEANUP and
YYERROR_CLEANUP macros?
If you mean YYCLEANUP, it would need to return. Would a function call be
too inefficient?
I prefer YYCLEANUP over YYABORT_CLEANUP and YYERROR_CLEANUP. Again, my
argument is flexibility. You could use it without YYABORT or YYERROR.
However, again, we run into the problem of the proposed automatic
destructor feature. I suppose mention of YYCLEANUP could be detected as
equivalent to mention of every RHS semantic value.
For bison, I believe the order of importance on this cleanup issue goes like
this:
1. document cleanup behavior in the manual
2. make cleanup behavior consistent across YYABORT/YYERROR and all skeletons
(I guess this means _no_ auto cleanup)
3. offer more cleanup flexibility (macros)
I agree.
I believe you and I are in agreement on how the first 2 points should be
resolved. Would one of the veteran bison developers like to offer words
of wisdom?
Joel
_______________________________________________
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison