Re: [PATCH] Named symbol references

[Alex Rozenman]

Hi Joel, Akim and All,

I will summarize two remaining issues to give a chance to continue our
discussion.


1. Visibility of explicitly defined symbol references.

Joel has proposed that every explicitly defined name will completely hide
the corresponding symbol:
a)  exp: exp[left] '+' exp[right] { $$ = $left + $right; } // correct (both
approaches)
b)  exp: exp[left] '+' exp { $$ = $left + $exp; } // correct, possibly
warning
c)  exp: exp '+' exp { $$ = $exp + $exp; } // incorrect, ambiguity error
(both approaches)
d)  exp : '(' exp[e] ')' { $$ = $exp; } // incorrect, $exp is hidden,
"reference not defined" error

My initial approach was to see all the symbols and references as a single
scope of visibility:
a)  exp: exp[left] '+' exp[right] { $$ = $left + $right; } // correct (both
approaches)
b)  exp: exp[left] '+' exp { $$ = $left + $exp; } // incorrect, ambiguity
error for second $exp
c)  exp: exp '+' exp { $$ = $exp + $exp; } // incorrect, ambiguity error
(both approaches)
d)  exp : '(' exp[e] ')' { $$ = $exp; } // correct, no ambiguity is possible

I tend to agree with Joel's; I feel that in most real cases, users will
barely notice the difference.


2. Syntax of symbol references in semantic action code (aka dots in symbol
references).
How to reference a symbol with dots (dots are perfect valid character in
bison symbol names) inside of semantic actions? If dots are parsed as a part
of $ (or @) construct like $symbol.name, it will be not possible to access
fields of structs like $symbol.field, which are very common. If dots are not
allowed in symbol references, how to access symbol with dots ?

Currently, we have two approaches:
a)  (Joel's approach). Dots are allowed in explicitly defined symbol names.
Inside of semantic actions mandatory syntax like $[symbol] and
$[symbol.with.dots] is used. User must write $[names] even when there are no
any dots in symbol names in his grammar.
b)  (My current approach, slightly changed comparing to my previous mail):
Dots are allowed in explicitly defined symbol names. By default,
$name.suffix is parsed as a field access. Syntax $[symbol.subname].field is
supported in order to make it possible to reference a symbol or a symbolic
name with dots.

I feel that (b) is much more aesthetically pleasing, and we must keep it
possibly to write plain $left and $exp (as we did in all our examples here,
in this discussion). If someone has an opinion on this issue, please came
up.

Best regards, Alex Rozenman

On Fri, Feb 13, 2009 at 9:16 PM, Joel E. Denny <address@hidden>wrote:

> On Fri, 13 Feb 2009, Alex Rozenman wrote:
>
> > > Ugh.  This may come up frequently with locations.  For example,
> > > @left.first_line seems right, but it's wrong.
> > > This makes me wonder if Bison should require brackets after $ and @ as
> in
> > > the following:
> > >   exp: exp[left] + exp[right] { $$ = $[left] + $[right]; } ;
> > > If we say that the brackets following $ and @ are not optional, there
> > > should never be confusion.
> >
> >
> > I totally agree that it may come up very frequently. It seems like my
> > original solution with ($name).field was wrong, because it would affect a
> > lot of code, even when there is no single dot in symbol names.
>
> Ok.
>
> > On the other
> > hand, it is not a good practice to pollute semantic action code (which is
> > "C" code, still) with additional foreign (and mandatory) syntax. I think
> > about an intermediate solution, that may look like the following:
> > 1. Dots are not allowed in (explicitly declared) symbol references, so
> every
> > field reference like "$name.field" will be compiled smoothly.
> > 2. If one needs to reference a symbol containing dots, it may be
> > accomplished by (a) explicitly defined symbolic reference without dots,
> or
> > (b) by $[some.symbol] syntax.
>
> As I see it, the issue boils down to the following questions.  Do we want
> a notation that, when employed correctly, looks perfectly unambiguous in
> every situation?
>
>  $[name]
>  $[name].field
>  $[name.subname]
>
> Or do we want a notation that looks more aesthetically pleasing but also
> sometimes looks ambiguous?  By ambiguous, I mean that the user who doesn't
> remember or isn't aware of all these issues and the rules we've chosen may
> easily become confused.
>
>  $name          // looks fine
>  $name.field    // looks ambiguous
>  $name.subname  // looks ambiguous
>
> If we go with the latter choice, then we also must choose which of the
> above ambiguous references is wrong and require that it be rewritten.
> Your proposal, I believe, is that the following should be correct:
>
>  $name
>  $name.field
>  $[name.subname]
>
> Is that right?
>
> None of these possibilities is completely satisfying to me.  However, I
> have a feeling that your proposal will appeal to most users in most
> situations even if it creates some confusing cases.
>
> Akim, what do you think?
>
> > if I write:
> > >   pair: item[first] item { $$ = new_pair($first, $item); }
> > > Bison reports that $item is ambiguous?  That seems ok because $item is
> > > slightly confusing here.  However, what about the following?
> > >  lhs: rhs[r] { $$ = $rhs; }
> > > It seems like Bison shouldn't permit $rhs here.  The user has promised
> to
> > > call it $r instead.  Can we just add another check after the ambiguity
> > > check passes?
> > >
> >
> > Please allow me to disagree with you. If we say that explicit "r" hides
> the
> > "rhs" symbol (that's *factually* happens, whatever the error message will
> > say), why then we have an ambiguity in the first case ?
>
> Prior to your previous email, I had always thought that a new name would
> hide the old name completely.  I demonstrated this in the $rhs versus $r
> example above.  I feel that this approach is the base from which we should
> start.
>
> When I received your previous email and read about your current approach,
> I noticed that it might be useful if Bison also detected ambiguities while
> including hidden names.  I demonstrated this in the $item versus $first
> example above.  I agree that $item does not seem ambiguous in this
> example.  However, the asymmetry there looks too much like an accident to
> me.  Why would the user rename one item but not the other?  I think the
> asymmetry would look even more error-prone in a longer more complex RHS.
>
> Bison's error message in the $item versus $first example could be
> different than the usual error message about ambiguous references.
> Perhaps something like "asymmetric renaming of $item".  To be clear, I
> don't think Bison should report asymmetric renaming if the semantic action
> doesn't actually reference $item.  Also, maybe an error is too strict.
> It could be just an optional warning.  In that case, it wouldn't have to
> be implemented now.  Once implemented, if the warning never actually
> proved useful in practice, we could later remove it.  It's just a guess on
> my part anyway.
>
> I hope that makes my view a little clearer.
>
> If anyone else has opinions on any of these issues, please jump in.
>



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