named references

[Alex Rozenman]

Joel, Akim and All,

I am working on the new version of the patch and I would like to continue
the discussion.
As I understand from last Akim's mail his opinion is that LHS must also be
covered. I managed to create an implementation of this, and faced some
usability and implementation issues.

1. Usablity.
In real grammars, there are many rules where LHS is appearing in RHS as
well, like all kinds of recursive rules (lists, expressions, statements).
When LHS symbol is also checked for name reference resolution, it appears,
that in many cases it is impossible to use "default" names in symbol
references. You always need to add explicit "[name]". In my grammars it
affected so many places, so, IMHO it did more damage than good.

2. Implementation.
The real problem came up in mid-rule actions. If I understand bison's stack
correctly, it is not possibly to assign to rule's $LHS from within mid-rule
actions, because the entry is not existing yet. So I can not implement $LHS
access from mid-rule actions without big restructuring of bison code. It can
be suggested, that in mid-rule actions $LHS access will be forbidden and $$
will, as usual, mean value of mid-action symbol itself, but it looks to me
quite inconsistent.
In addition, there is no need to say that because of id_colon trick, the
implementation in scan-code.l was non trivial. I managed to keep my changes
as small and as local as possible, but, anyway, the code is tricky.

It would be great to hear your opinions. I will say again, $$ syntax for LHS
is already very clear and short, and it has stable well defined semantics.
Not worth the candle IMHO.

As for lexical definition of symbol names, there is hopefully a consensus:
(a) $a.b.c is by default parsed as $[a].b.c (.b.c are fields).
(b) a warning is generated when one of "a.b" and "a.b.c" symbols are defined
in the grammar (option: appearing in the current rule!)
(c) there is "bracket" syntax $[a.b].c allowing to get rid of the warning.
(d) dot are allowed in explicitely defined symbol names.

It is still not clear to me whether we have a consensus on topic of symbol
visibility and hiding. Could you clarify ?

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