Re: too many warnings from Bison CVS for Pike

[Hans Aberg]

On 29 Jan 2006, at 18:28, Joel E. Denny wrote:

> > 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.

Unused token values are pretty common: just take
  "if" A "then" B
Here, the token values of "if" and "then" will be unused in the rule  
action. If this should work, I guess you are calling for a special  
token type, say "void", and the warning should come if some non-void  
$k isn't used. But this is a separate issue from the $$ = $1 one.

> 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.

When the code placement version of %define eventually appears, then  
these issues can perhaps be resolved using it: In the old Bison  
parser version, where $$ = $1 is always invoked, the code looks like  
(in C pseudocode):
  if (yylen >= 1)
    $$ = $1;
  switch (yytoken) {
    default:
      ;
    case ...
      ...
  };
Now, if it should only be invoked for the rules that have a default  
rule, the code is simply changed to:
  switch (yytoken) {
    default:
      if (yylen >= 1)
        $$ = $1;
    case ...
      ...
  };
thus moving it inside the switch statement.

Now, with a code placement in hand, one wants to be able to put code  
at various place, including just ahead of the switch statement; call  
the macro say 'pre-switch'. Then a fix under C for those that want $$  
= $1 would a grammar '.y' file containing:
  %define pre-switch { if (yylen >= 1)  $$ = $1; }
  ...
One the actually will get two $$ = $1 performed in the default  
actions, but that should not hurt under C.

One can also from the above see what may break when using a typed C++  
parser, not using a union: Even if $$ and $1 have the same Bison  
type, extracting the correct C++ type may involve applying certain  
functions to $$ and $1. So the correct C++ statement may require  
(depending on the C++ implementation model chosen) something like the  
following (in C++ pseudocode):
  convert(<type>, $$) = convert(<type>, $1);
Then one sees that now the default action actually varies with the  
Bison type <type>. When comparing this with C and the 'union'  
implementation, one can see that is hidden by the structure of the  
'union'.

Anyway, since a code placement version will hopefully be implemented  
eventually, it may be simplest to use it, before moving ahead with  
various options, the latter will be more complicated.

  Hans Aberg