On Sun, 29 Jan 2006, Hans Aberg wrote: > This way of behaving, with the $$ = $1 always executed seems to have existed > up to the point I discovered the C++ problem. So probably, many C programs > rely on it. The problem is that it does not harm under C (except for some > time), but indeed may harm under C++, and it may be confusing to have > radically different behavior under C/C++. And it seems strange that a default > action should be executed when an explicit action has been given.
I agree. > > In the long run I think Bison needs different flavors of warning > > options, for users who want to be more or less picky. > > My guess is that perhaps some option is needed. It is perhaps though difficult > to motivate to C users to not have $$ = $1 always executed, if it does not > cause any harm in doing it. Beyond the C++ issue you raise, it seems that an action containing nothing but $$ = $2 ought to warn about an unused (typed) $1. Explicit code is just cleaner. I doubt seriously that any user is going to abandon bison just because he can't bear to add $$ = $1 to his actions. Bison will even tell him exactly where to do so. If he complains that he's unsure as to where the $$ = $1 was actually intended, that's the very reason he should have made it explicit in the first place. Couldn't this be a --yacc issue? That is, --yacc would implement whatever the Open Group says. Without it, bison would be free to behave well and consistently for both C and C++: don't execute $$ = $1 before an explicit action. If we're worried that some users won't want --yacc but will still want an implicit $$ = $1 for explicit actions, --yacc could accept options to specify exactly which yacc features should be implemented. For example: --yacc=auto_lhs_value,filenames --yacc=filenames --yacc where the last usage implies all yacc features. This approach makes the subtle hint that implicit $$ = $1 before explicit actions is simply an old and unfortunate idea. Joel
