Re: named references

[Joel E. Denny]

Hi Alex,

On Fri, 6 Mar 2009, Alex Rozenman wrote:

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

I can understand that permitting the LHS value to be referenced by name 
might require some work to update grammars that are already written for 
your approach.  However, it doesn't increase the work significantly when 
updating grammars written in Yacc style or when writing new grammars.  
For example:

  list[parent]: list[child] item { $parent = list_add ($child, $item); } ;

If the user really wants brevity:

  list: list[child] item { $$ = list_add ($child, $item); } ;

Your approach saves only one renaming, but then $list looks suspicious:

  list: list item { $$ = list_add ($list, $item); } ;

My biggest fear is that some poor user (probably me) is going to write 
this at some point:

  list: list item { $list = list_add ($list, $item); } ;

This is wrong for either approach, but it's such a seductive mistake, and 
Bison will not warn about it under your approach.  Moreover, in a case 
where list is buried in a complex RHS or $list is buried in a complex 
action, the mistake won't be as obvious as in this example.

I feel that, if we're going to claim that Bison reports ambiguities in 
value names, it would be unintuitive to exclude the LHS.

> 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

We're definitely not trying to change the basic parser behavior.  As I see 
it, the mid-rule issue is about detecting potential user errors.

You gave this example earlier:

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

Mid-rules can be tricky.  A confused user may have meant for the $exp to 
reference the LHS value.  Bison could be helpful here by complaining that, 
in the context of the full production, $exp is ambiguous.  The user, who 
is still confused about mid-rules, would then likely write:

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

Now Bison knows exactly what the user meant and can complain that $lhs is 
out of range.

Of course, a user who hasn't forgotten how mid-rules work would say that 
Bison should assume he meant $1 when he wrote $exp because only $1 is in 
range.  However, it's a small price for him to instead write:

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

And now the action is clearer to everyone.

By the way, by the same logic, I believe Bison should report asymmetric 
renaming for the $exp in the following even though the second exp is out 
of range:

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

> and $$
> will, as usual, mean value of mid-action symbol itself, but it looks to me
> quite inconsistent.

I agree that $$ should keep its meaning in mid-rules, but the user could 
also write a mid-rule like this:

  { $value = 1; }[value]

This use-before-declaration is a little clumsy, but it doesn't bother me 
much.

> As for lexical definition of symbol names, there is hopefully a consensus:

I believe you, Akim, and I were ultimately in agreement here.

> (a) $a.b.c is by default parsed as $[a].b.c (.b.c are fields).

Yes.

> (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!)

I agree that only symbols in the current production need to be checked.

> (c) there is "bracket" syntax $[a.b].c allowing to get rid of the warning.

Yes.

> (d) dot are allowed in explicitely defined symbol names.

If the user wants dots in his value names, I see no reason to stop him, 
but he'll have to use brackets to reference those values.

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

I think we had a consensus.  $rhs produces a warning or complaint in all 
these cases:

  lhs: r            { $rhs; } ; // unrecognized name
  lhs: rhs[val]     { $rhs; } ; // hidden name
  lhs: rhs[val] rhs { $rhs; } ; // asymmetric renaming
  lhs: rhs      rhs { $rhs; } ; // ambiguous name

However, there is no warning or complaint if $rhs is not actually 
referenced in these actions.

Thanks for all your work, Alex.