[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] Named symbol references
From: |
Akim Demaille |
Subject: |
Re: [PATCH] Named symbol references |
Date: |
Wed, 18 Feb 2009 13:00:37 +0100 |
User-agent: |
Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.95 (gnu/linux) |
>>> "JED" == Joel E Denny <address@hidden> writes:
> As I see it, the issue boils down to the following questions. Do we want
> a notation that, when employed correctly, looks perfectly unambiguous in
> every situation?
> $[name]
> $[name].field
> $[name.subname]
> Or do we want a notation that looks more aesthetically pleasing but also
> sometimes looks ambiguous? By ambiguous, I mean that the user who doesn't
> remember or isn't aware of all these issues and the rules we've chosen may
> easily become confused.
> $name // looks fine
> $name.field // looks ambiguous
> $name.subname // looks ambiguous
> If we go with the latter choice, then we also must choose which of the
> above ambiguous references is wrong and require that it be rewritten.
> Your proposal, I believe, is that the following should be correct:
> $name
> $name.field
> $[name.subname]
> Is that right?
> None of these possibilities is completely satisfying to me. However, I
> have a feeling that your proposal will appeal to most users in most
> situations even if it creates some confusing cases.
> Akim, what do you think?
My preference goes to the last one. But, as I wrote in a previous
email, I understand your resistance, so maybe we can issue a warning
when "$foo.bar" is used and it turns out a "foo.bar" is a grammar
symbol. To remove the warning, the user needs to write $[foo.bar] or
$[foo].bar in that case.
>> if I write:
>> > pair: item[first] item { $$ = new_pair($first, $item); }
>> > Bison reports that $item is ambiguous? That seems ok because $item is
>> > slightly confusing here. However, what about the following?
>> > lhs: rhs[r] { $$ = $rhs; }
>> > It seems like Bison shouldn't permit $rhs here. The user has promised to
>> > call it $r instead. Can we just add another check after the ambiguity
>> > check passes?
>> >
>>
>> Please allow me to disagree with you. If we say that explicit "r" hides the
>> "rhs" symbol (that's *factually* happens, whatever the error message will
>> say), why then we have an ambiguity in the first case ?
> Prior to your previous email, I had always thought that a new name would
> hide the old name completely. I demonstrated this in the $rhs versus $r
> example above. I feel that this approach is the base from which we should
> start.
I agree.
> When I received your previous email and read about your current approach,
> I noticed that it might be useful if Bison also detected ambiguities while
> including hidden names. I demonstrated this in the $item versus $first
> example above. I agree that $item does not seem ambiguous in this
> example. However, the asymmetry there looks too much like an accident to
> me. Why would the user rename one item but not the other? I think the
> asymmetry would look even more error-prone in a longer more complex RHS.
> Bison's error message in the $item versus $first example could be
> different than the usual error message about ambiguous references.
> Perhaps something like "asymmetric renaming of $item".
I like this idea. In a collision, no one is allowed to use the
collided name.
> To be clear, I don't think Bison should report asymmetric renaming
> if the semantic action doesn't actually reference $item.
Indeed.
> Also, maybe an error is too strict. It could be just an optional
> warning. In that case, it wouldn't have to be implemented now.
> Once implemented, if the warning never actually proved useful in
> practice, we could later remove it. It's just a guess on my part
> anyway.
Warnings can be turned into -Werror.
Re: [PATCH] Named symbol references, Akim Demaille, 2009/02/18