Re: [PATCH] Named symbol references

[Akim Demaille]

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

 >> 1. Syntax
 >> Joel's proposed "bracket" syntax is implemented. It looks like the
 >> following:
 >> exp: exp[left] + exp[right] { $$ = $left + $right; } ;
 >> I decided, for now, not to allow named reference for rule's LHS, because (1)
 >> '$$' is already very short, clear and has stable semantics, whatever the
 >> symbol order in RHS; (2) in mid-rule actions, the '$$' has a different
 >> semantics, and it is currently not possible to assign to actual '$$'; Should
 >> we decide to remove this limitation by enabling symbolic names for LHS ?
 >> Please advice.

 > Your requirement that $$ and @$ always be used for the LHS somehow feels 
 > cleaner to me at the moment.  I think I can train my brain to ignore the 
 > LHS symbol name when I see the $exp or $term in your examples:

 >   exp : exp { $$ = $exp; }[left] + exp[right] { $$ = $<type>left + $right; }

 >   term: term '*' fact { $$ = $term * $fact; } ;

 > Does this bother anyone?

I am not really comfortable with that, but I can live with it.


 >> 2. Lexical definition.
 >> As for now, I defined the symbolic reference as a non empty ID, allowing
 >> exactly the same char set as for symbol names. It is because, the symbol
 >> names themselves are playing role of symbolic references, when '[]' is
 >> omitted. Now, we have a minor problem with dots (I faced it when trying to
 >> compile my existing big grammars for Verilog and VHDL). In semantic action
 >> code we may have: $name.field, where '.field' is a reference to a field of
 >> %union component, which is a struct. If dots are allowed in symbolic named,
 >> all the name is eaten by the ID. The obvious solution here is
 >> "($name).field". I just needed to change it in my grammars by a regexp.

 > 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.  For example, the user would have to write 
 > $[my.name] and @[left].first_line, which I think are clear.  Bison would 
 > complain that $my.name and @left.first_line have syntax errors immediately 
 > following the $ and @.

 > On the other hand, this bracket notation is perhaps slightly more verbose.  
 > Maybe your way is ok considering the following observation.  Let's say a 
 > user writes $name.field and means that field is a member of $name.  
 > Because this user has clearly forgotten how Bison treats ".", he probably 
 > has not chosen name.field as the name of any symbol.  Thus, rather than 
 > quietly misunderstanding the user's intentions, Bison would complain that 
 > it doesn't recognize $name.field.  Seeing this complaint, the user would 
 > have an opportunity to correct his mistake.  If we want to be really 
 > helpful, Bison could even detect a "." in an unrecognized name and remind 
 > the user of this issue.

 > I'm not sure which of those approaches is better.

Personally, I would accept only dot-less names without brackets, but
accept dots within brackets.  It is not common to use dots in names,
and I venture that those who do don't have many symbols with dots:
only some of them.  So I feel that requiring the bracket is too
expensive.  So I would accept $name.field as denoting $[name].field.
But if you feel this is really taking chances for the user, maybe we
can peek at the field name, and warn only when it happens to be an
existing symbol name?

But then again, I can live with your second proposal.  The first is
too expensive imho.