Re: [PATCH] Named symbol references

[Joel E. Denny]

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.