[ruby-talk:5499] Re: Some newbye question

Hi,

In message "[ruby-talk:5498] Re: Some newbye question"
    on 00/10/13, Aleksi Niemel<[e-mail]> 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.