Re: %destructor feedback

[Joel E. Denny]

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