Re: semenatics of if/unless/while statement modifiers

Yukihiro Matsumoto wrote:

>Hi,
>
>In message "Re: semenatics of if/unless/while statement modifiers"
>    on Wed, 23 Nov 2005 00:58:00 +0900, Stefan Kaes <[e-mail]> writes:
>
>|>The current syntax rule is:
>|>
>|>  if assignment is done, a right hand side identifier is a local
>|>  variable thereafter.
>|
>|Just keep it.
>
>Hmm, I think you mean we don't have to change the rule except for
>declaring that "expr1 if expr2" has *exactly* the same semantics,
>right?
>  
>
Exactly. Although I'm a bit confused by the term RHS identifier. In 
usual compiler/language semantics  speak, this term is reserved for 
identifiers occurring on the RHS of an assignment. If I understand it 
correctly, you use it for "not occurring on the left hand side of an 
assignment"?

>But in reality, the rule becomes
>
>|>  if assignment is done, a right hand side identifier is a local
>|>  variable thereafter.  and assignment in modifier condition affects
>|>  modifying statement as well.
>
>anyway.  So let us investigate the "exactly the same semantics" rule
>more closely.  If you can explain like that, modifier explanation
>would become little bit simpler.  But it also encourages false image
>of "dynamic local variable initialization" model, that local variable
>appear on its first assignment operation.  Next time users would
>confused when they see
>
>  if false
>    a = 15
>  else
>    p a
>  end
>
>prints "nil", or expecting first "a" in
>
>   5.times do
>     p a
>     a = foo()
>   end
>
>to be a local variable at the second iteration, and so on.  Potential
>problems still remains.
>  
>
I must admit I hadn't thought of loops when I wrote down the "dynamic 
evaluation rule"

>After all, this "small" syntax change buys you small explanation
>clarity, and only allowing assignment in modifier conditions, which I
>believe is not something to be encouraged at most, at the cost of huge
>(possible but difficult) parser changes.
>
The changes are not that difficult. This could be implemented by leaving 
id references unresolved, if the id hasn't been seen before, resolving 
them on a second pass after a scope has been completely parsed. 
Obviously Perl has no problems implementing this rule.

>  I'm not exciting to change for that kind of solution.
>  
>
I can understand that.

>If the rule is like
>
>|>  if there is assignment, a right hand side identifier is a local
>|>  variable in the current scope.
>
>it serves wider range of potential problems, so that it might motivate
>me more likely.  But it still has disadvantage of ambiguity.
>
>							matz.
>  
>
Yeah, I think this rule would be better. This may have an impact on 
programs which make use of the fact that id is a local variable only 
after an assignment to id, like in

  def bar; ...  end

  def foo
    bar
    bar = 7
  end

where the first bar refers to function bar and the second bar refers to 
local variable bar.

I can't really think of a useful example using this pattern. Can someone 
else?

And this feature of Ruby contradicts all my programming instincts. 
Within a scope, an identifier should have the same meaning wherever it 
occurs in the same form. So, I have no problem with

  def foo
    bar()
    bar = 7
  end

I fail to see how your last rule introduces ambiguity. Can someone 
enlighten me please?

-- stefan