Named references suggestion

[Sasha Unknown]

I'm writing because I found
> The named references feature is experimental. More user feedback will help to 
> stabilize it.
text in the manual.

Named references is indeed very useful feature (both implicit and with
explicitly declared names).
Especially handy because numbers may change (hard to control them):
> "on" "ready" action { /*here $action is $3*/ }
> "onready" action { /*here $action suddenly becomes $2*/ }

However, when using named references, the following kind of ambiguity
was unexpected and distorting for me:
> expression_list: %empty | expression_list "," expression 
> {...$expression_list...}
> expression: ... | "(" expression ")" {...$expression...}
> statement_list: %empty | statement_list statement {...$statement_list...}
> statement: ... | "while" "(" expression[condition] ")" statement 
> {...$statement...}

I mean that while ambiguity between component symbols (...: exp "+"
exp {...$exp...}) is really unresolvable (as bison really doesn't know
which component to choose), ambiguity between result symbol and
component symbol is, per my opinion, something "fictional": as result
component is referenced by $$ anyway (there is probably no need for
user to reference it with longer name), in case of
result-symbol-VS-component-symbol ambiguity, bison, per my humble
opinion, should prefer component symbol (if there is need to have
named reference to result symbol at all).

To not break existing behavior, I'd introduce new variable, so that,
for instance:
> %define give.name.to.result.component true //current behavior, default
> %define give.name.to.result.component false //don't give name to result 
> component, so that expression_list: %empty | expression_list "," expression 
> {$$ = combine($expression_list, $expression);} and expression: ... | "(" 
> expression ")" {$$=$expression;} won't create any ambiguity.