Re: [PATCH] Named symbol references

[Akim Demaille]

>>> "JED" == Joel E Denny <address@hidden> writes:

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

My preference goes to the last one.  But, as I wrote in a previous
email, I understand your resistance, so maybe we can issue a warning
when "$foo.bar" is used and it turns out a "foo.bar" is a grammar
symbol.  To remove the warning, the user needs to write $[foo.bar] or
$[foo].bar in that case.

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

I agree.

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

I like this idea.  In a collision, no one is allowed to use the
collided name.

 > To be clear, I don't think Bison should report asymmetric renaming
 > if the semantic action doesn't actually reference $item.

Indeed.

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

Warnings can be turned into -Werror.