Re: [PATCH] Re: named references

[Akim Demaille]

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

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.