[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: named references
From: |
Joel E. Denny |
Subject: |
Re: named references |
Date: |
Sun, 8 Mar 2009 16:20:05 -0400 (EDT) |
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.
- named references, Alex Rozenman, 2009/03/06
- Re: named references,
Joel E. Denny <=
- Re: [PATCH] Re: named references, Joel E. Denny, 2009/03/20
- Re: [PATCH] Re: named references, Akim Demaille, 2009/03/20
- Re: [PATCH] Re: named references, Joel E. Denny, 2009/03/20
- Re: [PATCH] Re: named references, Joel E. Denny, 2009/03/20
- Re: [PATCH] Re: named references, Alex Rozenman, 2009/03/22