[ruby-talk:12684] Re: Order, chaos, and change requests :)

Yukihiro Matsumoto wrote:
> ...
> |As far as my post in ruby-talk:12563, this approach would handle
> |the 'shadowed parameters' and 'imports', but not the 'exports'.
> 
> I personally don't prefer the concept of exporting local variable out
> of closed scope.  Maybe my feeling was caused by misunderstanding.
>

That surprises me, based on your comments in ruby-talk:12599
(Note that I do not expect this 'exporting' to apply to method definitions.)

> |1. If you were designing Ruby over again, what would do with the
> |   scoping of variables in blocks?
>
> I wouldn't enable block local variable, at least by default.  It's for
> making closure/proc object usable (imagine closure without local
> variables), but I now think I should have made it optional.

And also in ruby-talk:5552
>  (3) a local variable names appeared AFTER the lambda.
>      Since it's easy to forget about block scope rules, some (or even
>      most) expect the values of block local variables preserved after
>      the block.  When he meets the `undefined local variable' error,
>      he should go back before the block and initialize the variable.

Since block-local variables *are* enabled by default, the only
way I can think of to reverse that effect without breaking older
scripts is to introduce the optional capability to mark the
variable as an 'export' (or whatever) so that its value is
propagated past the block scope. 
(This is like your implicit scope propagation idea, except it would 
be explicit to make it optional and allow for backward compatibility.)

This would have the same effect as initializing the variable 
right before the block started - but with exports it is effectively
done from within the block.

> |2. Is there really a big enough problem with what we have now to merit
> |   changing things?
>
> I believe so.  Many, including even me, are struck by the bugs like
>
>  loop do
>    id = 25
>    break
>  end
>  p id


Again, the 'exports' would address this very issue while maintaining
backward compatibility...

How the exporting is signified can be discussed, but I think it is an
important complement to the ability to declare block-locals. 
Consider again the  '[ruby-talk:04388] Scope surprise'  thread.

So, even if you could declare block-locals, the above problem
would not go away - it is a different problem, one in which Ruby is
creating a block-local by default when you wish it were a regular local.

Although I already mentioned a couple of ways to denote/declare such 
exports, I think a third way could be using ':=' as an assignment to 
indicate the scope-propagating effect. (This is the opposite of your
offer to make that denote a block-local effect). 
Or maybe '::=' since '::' is the scope operator?

loop do
 id ::= 25  # creates/updates 'id' in outer scope also
 break
end
p id  # 25

 
Guy N. Hurst



-- 
HurstLinks Web Development    http://www.hurstlinks.com/
Norfolk, VA  23510            [phone] FAX [phone]
PHP/MySQL - Ruby/Perl - HTML/Javascript