Re: [PATCH] Named symbol references

[Alex Rozenman]

Hi Akim, Joel and all.

It's very interesting that several people came up with very similar
approaches regarding this issue. I would suggest to use Joel's syntax with
brackets plus default names support; exactly like you suggested. Inside of
brackets both name, $name and @name will be allowed, having equal semantics,
at first.

If there will be no objections on your side, I would like to prepare new
version of the patch, paying addition attention to accurate error messages
in case of name ambiguities. I also will try to add some tests to the
regression suite.

Thank you very much for your comments.

Akim, could you please answer on my question regarding a bootstrapping
problem, just if you have time. It is very disturbing issue, I spent many
hours trying to understand it - without success. I've sent it to bison-help
mailing list, but had no answer there yet.
Please see it here:
http://lists.gnu.org/archive/html/help-bison/2009-01/msg00020.html.

Kind regards,
Alex Rozenman


On Thu, Jan 29, 2009 at 2:27 AM, Joel E. Denny <address@hidden>wrote:

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



-- 
Best regards,
Alex Rozenman (address@hidden).