[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Re: named references

From: Akim Demaille
Subject: Re: [PATCH] Re: named references
Date: Fri, 20 Mar 2009 09:58:09 +0100

Le 18 mars 09 à 22:33, Alex Rozenman a écrit :

Hi Akim,

Hi Alex,

Please note that "asymmetric renaming" warning is not implemented (yet).
I'm not sure asymmetric will be understandable in error messages.
Maybe "partial" would be more appropriate?
You may consider it "disabled" in the following examples. Actually,
I am not sure that it would be helpful.
I subscribe to Joel's ideas about this, I would really prefer that we
have this warning.  Actually, we didn't we make this an error?

It was error my very first version. Things changed since then :) "Partial"
is also not so clear.

Yes, I agree.

I will think about other name. By the way, would you
like to fix something in the formulation of errors in my previous mail ? Are
braces "( .. )" in secondary message appropriate ?

I don't have this mail here, but I remember I didn't like too much the parens. I prefer that to use indentation in the following lines to give additional details. Something like

1.1-9: type mismatch
  left operand type: int
  right operand type: string

But we can discuss this later.

/* a real ambiguity reported regardless of dots, note that dots cannot
   be a reason for these ambiguities */
if_stmt: IF expr THEN stmt.list ELSE stmt.list FI
          { $if_stmt = new IfStmt($expr, $stmt.list, $stmt.list); };
interpreter.ypp:74.43-52: reference is ambiguous: `$stmt.list'
Really, I do not like the fact that `.' be part of such ids, I'm very
much against it.  It departs completely from the usage $ in many
languages starting with shell scripts. This is going against years of education of our eyes, to me $stmt.list definitely means $ [stmt].list.

Just to clarify my position. Actually, current implementation is very
straight forward: I see all the symbols in the production and check whether an ambiguity possible. In the example above, there is no other possibility to read $stmt.list but only as $[stmt.list], because $stmt is not present. Why should we raise errors when there is no ambiguity possible ? Again, $[stmt.list] is also perfectly valid. Let's wait to see what will be Joel's

I believe we had a consensus on this, regardless of the existence of stmt.list as a symbol name, even though stmt is not a symbol name, bison should read $stmt.list as $[stmt].list and report an error. I see at least two reasons for this choice.

The first one, and to my eyes by far the most important (even though it's just a matter of taste and the second point is actually more pragmatic), it goes against years of training in shell, Perl etc. I conjecture that the eyes of most programmers (at least those from the Unix world) give a higher precedence to $ than to ".".

And second, this is more robust to changes. $stmt.list means $ [stmt].list, whatever the context, while with your implementation, depending on the rule, it may change, depending on the names introduced. Worse yet, a single action might see it's meaning change because of changes in the rule itself.

Really, while I do appreciate that everyday programs do-what-I-mean when I type silly things on the command line, I do not like this here.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]