Re: [PATCH] Re: named references

[Alex Rozenman]

Hi Akim,


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

  > /* 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
opinion.


> You do support $<stmtptr>[stmt.list]?
>
Yes, of course.

-- 
Best regards,
Alex Rozenman (address@hidden).