Re: too many warnings from Bison CVS for Pike

[Joel E. Denny]

On Mon, 6 Feb 2006, Joel E. Denny wrote:

> On Mon, 6 Feb 2006, Akim Demaille wrote:
> 
> > I have long been wanting a means to name
> > the symbols, instead of numbering them.  Something like
> > 
> >     exp(res): exp(lhs) '+' exp(rhs) { $res = $lhs + $rhs; }

I'm working on a grammar right now with very long RHS's.  Counting the 
symbols to figure out which n to use in $n is getting tedious.  I'm 
looking forward to the above feature.

In many of my productions, the symbols have unique names.  For example:

  bison_spec: definition_section rules_section user_subroutines

In this case, it would be nice to have some notation that declares the 
semantic value names the same as the symbol names.  This is tedious:

  bison_spec(bison_spec):
   definition_section(definition_section)
   rules_section(rules_section)
   user_subroutines(user_subroutines)

I like the conciseness of:

  bison_spec(): definition_section() rules_section() user_subroutines() {
    $bison_spec = new Node();
    $bison_spec->addNode( $definition_section );
    $bison_spec->addNode( $rules_section );
    $bison_spec->addNode( $user_subroutines );
  }

As in your example, you can fill in the parentheses where needed to avoid 
conflicting names.  Bison should issue an error for conflicting names as 
in:

  exp(): exp() '+' exp()

Actually, with or without this concise notation, Bison should probably 
issue an error in the case of conflicting names.

> > We should then look for a syntax that makes explicit what symbols are
> > unused, e.g., 
> > 
> >     exp(): exp(lhs) '+' exp(rhs) { display ($lhs + $rhs); }
> 
> Visually, this notation really looks a lot nicer than the ones I 
> suggested.

My notation ($<>n and $<>$) is beginning to bother me because you can 
write it anywhere in a semantic action... even multiple times unless we 
check for that.  I like that your notation allows exactly one place to 
declare that a semantic value will not be used.  Also, it feels more like 
a declaration.  However, it conflicts with my suggestion for identical 
symbol and semantic value names.  Moreover...

> However, I do have one concern about what will happen in 
> practice.
> 
> Imagine how a bison user would write a new grammar.  After learning the 
> new notation, he'd probably start by writing each rule something like:
> 
>   exp(): exp() '+' exp()
> 
> After writing the grammar, he'd go back and fill in the actions:
> 
>   exp(sum): exp(op1) '+' exp() { $sum = $op1; }
> 
> But if he forgot his $3, bison would never warn him.  In other words, this 
> practice could circumvent the warnings altogether.

... this still concerns me.

> Yes, we could come up with other variations, such as 
> `exp(!)', but I think the same problem might occur.

This idea is growing on me.

To put all these ideas together, imagine the Bison user who writes one of 
these by default:

  bison_spec(): definition_section() rules_section() user_subroutines()
  exp(): exp() '+' exp()

If he's naively writing the empty parentheses because he figures he'll 
have to write them eventually anyway, he won't hang himself by 
inadvertently suppressing important unused value warnings.  Instead, he's 
basically just declaring that he doesn't like $$ and $n but he hasn't 
thought through alternative names yet in the case of conflicts.

Of course, a Bison user might write this by default:

  bison_spec(!): definition_section(!) rules_section(!) user_subroutines(!)
  exp(!): exp(!) '+' exp(!)

This Bison user is surely intentionally suppressing warnings, and 
hopefully he understands the danger.

Joel