Re: [PATCH] Named symbol references

[Joel E. Denny]

On Wed, 28 Jan 2009, Akim Demaille wrote:

> Joel, I'm sorry to involve you in, but you demonstrated good taste in
> syntactic issues in Bison, so your opinion, if you have some time,
> would be great.

Thanks.

You may recall there was a long discussion about this among a handful of 
us around 3 years ago.  I really don't have time to get too involved in 
this again, so I'm just going to offer a proposal based on my recollection 
of the previous discussion.  I'll probably repeat some of what you two 
have already said today, but at least that will tell you where I agree.

1. Default names.

For example:

  invocation: op '(' args ')' {
    $invocation = new_invocation ($op, $args, @invocation);
  }

The old $$, @$, $n, and @n could be mixed with $name and @name 
arbitrarily, but that's up to the user.  For example, some may like the 
following better:

  invocation: op '(' args ')' { $$ = new_invocation ($op, $args, @$); }

However, sometimes default names are not sufficient because of ambiguous 
references:

  exp: exp '/' exp { $exp = $exp / $exp; } // Warn that $exp is ambiguous.
  exp: exp '/' exp { $$ = $1 / $exp;     } // Just one usage is ambiguous.
  exp: exp '/' exp { $$ = $1 / $3;       } // No warning.

2. Overriding default names.

For example:

  exp[quotient]: exp[dividend] '/' exp[divisor] {
    $quotient = $dividend / $divisor;
  }

Besides removing ambiguities, some have pointed out that this is also 
useful to abbreviate a long symbol name to make semantic actions more 
legible.

Here's why I suggest square brackets over other notations:

a. Most binary operators (like ":", "=", "/", ",", "#", etc) seem to lead 
to disagreement among us on which order of operands is best.  More 
importantly, I suspect that the user who doesn't use Bison every day would 
find himself rechecking the manual to remember the order.

b. "exp$quotient" doesn't have the order of operands problem.  I dislike 
it for two other reasons.  I find it hard to read, but aesthetics are 
perhaps the least of our worries.  More importantly, this notation seems 
to imply that locations have not been named.

c. Some have suggested "exp.quotient", but POSIX Yacc says "." is allowed 
in symbol names.

d. Everyone seems to point out that parentheses collide with EBNF.  More 
importantly, if Bison one day tries to incorporate EBNF-like functionality 
into its current non-EBNF notation, it seems clear that we should still 
use parentheses for grouping.

e. Some point out that square brackets collide with the EBNF notation for 
optionality.  However, in the Lex and Yacc world, "(...)?" is used for 
optionality, so I think we should be free to use square brackets for 
something else.

3. Suppressing warnings about unused values and possibly locations.

The idea here was that "exp[]" in a grammar production basically means 
that this occurrence of exp has no semantic value.  To say it more 
concretely, even if exp has a semantic type and a destructor, Bison should 
not warn that its value is unused in the semantic action, but it should 
warn if it is used.  "address@hidden" names the location but says there is 
no semantic value.  "exp[$dividend]" names the semantic value but says 
there is no location... in case we ever add the option to warn about 
unused locations (which could have allocated memory for, say, a file 
name).

However, I'm going to avoid further comment on the topic of unused values 
and unused locations as it seemed to cause most of the confusion in the 
last discussion.  Maybe it's just not worth all the trouble.  In any case, 
it need not be implemented initially.