[PATCH] Named symbol references

[Alex Rozenman]

Hi,

Please review the new version of the change. I would like to describe some
points / issues I needed to address. Please see it as an invitation to
continue our discussion.

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.

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.

3. Default symbolic names and scope.
When the '[]' part is omitted, the symbol name itself can be used
symbolically:
        term: term '*' fact { $$ = $term * $fact; } ;
Currently all the names of RHS (all symbol names + all defined symbolic
names) are considered to be a single visibility scope. $name reference is
considered to be valid, iff it's found exactly once among all these
identifiers. Otherwise, "not found" or "ambiguous" error messages are
generated. It is quite possible to make another decision and consider, for
example, that when a symbolic reference is defined (symbol [name]), the
symbol itself is hidden, and even when an empty symbol reference is defined
(symbol [], not allowed currently), the symbol name is hidden from the
scope. My personal opinion here is that, strict, simple and clear rules are
the best.

4. Symbolic names for mid-rule action.
When '[]' syntax is used after mid-rule action, the semantic value of the
action can be accessed symbolically. For example:
      exp : exp { $$ = $exp; }[left] + exp[right] { $$ = $<type>left +
$right; }
Please note, that first "$exp" is unambiguous, because the second "exp" is
not visible at this point.

5. Testing.
I added new test group (named_ref) with two tests - one for correct grammar
and one for error messages. I will add more when the syntax and semantics
will be approved.

P.S.
I also fixed a bug, when a broken error message was generated in the
following case:
    LHS: RHS { x = $<type>N; }
where N is greater than len(RHS). Error message was cut in the middle (like
"integer out of bounds: $<type") and the integer itself was not shown.
Should I submit a standalone patch for this ?

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

0001--Implement-support-for-named-symbol-references.patch
Description: Binary data