Re: FYI: default %printer/%destructor

[Joel E. Denny]

On Wed, 22 Nov 2006, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes:
> 
> > When optionality and repetitions are 
> > possible, do named semantic values even make sense?
> 
> Sure.  You can give names to the optional or repeated parts.  The
> types associated with these parts are the equivalent of the ML "'a
> option" and "'a list" parameterized types.

Sorry, I have no experience with ML.  Would you should me how this might 
look in a Bison rule?

> No, but if the quality of our notation isn't much affected either way,

There's the rub.

> > At least () for named semantic values has some precedence in Lemon.
> >
> > With all that in mind, I say we stick with parentheses:
> >
> >   a(name1): b c() d(@name2)
> >
> > For a, the value and location are $name1 and @name1.
> > For b, they are $b and @b.  
> > For c and d, the values are declared unused.
> > For d, the location is @name2.
> 
> I like the rule for 'b' -- that's simple.

Great.

> The rest works, but I'd
> like something simpler if possible.
> 
> First, I forget: why is it important that values can be declared
> "unused"?

To suppress Bison warnings about unset/unused values.  

> That's extra complexity -- is it really worth it?

I think so.  Akim originally suggested the empty parentheses so the user 
doesn't have to define the empty `#define USE(e)' we've been using in the 
test suite.  I like his suggestion because it puts more information into 
Bison's hands than USE($$) does.  For example, we can extend the 
parentheses notation to %destructor, so you can write:

  %destructor() { printf ("A TOK was discarded.\n"); } TOK

As for a rule action, the () would suppress warnings about the missing $$ 
in the %destructor action.  Unlike USE($$), Bison would be able to 
recognize the () as distinct from a mere use of $$.  For a %destructor 
then, () could also disable all %destructor-based warnings for TOK values 
in rule actions.  The logic is that, if the user has intentionally omitted 
$$ from the %destructor action, then apparently there's no need to destroy 
the value, so there's no need to warn about unset/unused TOK values in 
rule actions.

>   exp:
>       NUM             { $$ = $NUM; }
>     | '-' exp %prec NEG       { $$ = - $exp; }
>     | '(' exp ')'     { $$ = $exp; }
>     | exp#1 '+' exp#2 { $$ = $exp#1 + $exp#2; }
>     | exp#1 '-' exp#2 { $$ = $exp#1 - $exp#2; }
>     | exp#1 '*' exp#2 { $$ = $exp#1 * $exp#2; }
>     | exp#1 '/' exp#2 { $$ = $exp#1 / $exp#2; }
>     | exp#1 '^' exp#2 { $$ = pow ($exp#1, $exp#2); }

If you prefer numbers, don't even use named values.  Use $1 and $3.  I 
believe we'll continue to support them for backward compatibility 
regardless of what happens with named values.

Well known, unevolving grammars with very short RHS's as above don't 
really show how worthwhile named semantic values are.  Instead, imagine a 
very long RHS that keeps evolving.  Renumbering is a maintenance problem.

Maybe it's just me, but I prefer Hans' suggestion:

  exp/sum: exp/term1 '+' exp/term2

over

  exp#sum: exp#term1 '+' exp#term2

I can't think of any semantic reason to prefer one over the other.  The 
slash is just a little easier on my eyes.

> If it's important to say a value can be unused, that could be written
> "a#-", or something like that.

I don't much like the `-' to mean nothing.  I had originally suggested `!' 
instead, but I found a reason why I don't like it either, and that reason 
also applies to `-'.  This one post might help you catch up:

  http://lists.gnu.org/archive/html/bison-patches/2006-11/msg00039.html