From: matz@... (Yukihiro Matsumoto) Date: 2000-10-13T16:22:45+09:00 Subject: [ruby-talk:5499] Re: Some newbye question Hi, In message "[ruby-talk:5498] Re: Some newbye question" on 00/10/13, Aleksi Niemel� writes: |> (a) I don't like variable overriding, especially in declaration-less |> language like Ruby. | |It seems, matz, that you valuate variable non-overridingness more than |symmetry in parameter handling, if I understood correctly? In a word, yes. I want block parameters be left side expression of the assignment (or multiple assignment). That's what expected be in the beginning. |> | a = 1 |> | proc { |a| a = 99 } .call |> | a # => 99 |1 var a is created since this is the first appearance of a in the scope. |2 a is set to refer to the object 1 |3 function proc is called with an associated block | block won't be executed yet |4 variables in block's parameter list are created *if* | they do not exists in outer binding, that means | |a| is not created because it exists, as it was | created at 2 yes, that's what the assignments do. |5 a is set to refer to the object 99 |6 the proc's returning Proc object's method 'call' is | executed, which in turn executes the block passing | no arguments to it then, parameter assignment happens; a is assigned to nil 7 the block body is executed, in which a is assigned to 99. |Now I have a questions: why not bind the block's variables only at block's |body? (not in the parameter list only) So what will happen to `a'? Will the variable `a' be an isolated from outer `a'? |I think it's really weird to think one's passing a parameter when actually |the parameter has been already bound. Agreed. That's why I said: >It's one of the ugliest part of Ruby syntax, which I want to >fix in the future if I found the way to fix. In short, it's caused by my diversion of blocks as closures. It works fine most of the cases, but some flaw still remains. matz.