[ruby-talk:16178] Re: The Block Problem -A suggestion

Jim Freeze wrote:
> ...
> Anyway, seems to me there is only one problem with leaving
> the || operator alone, and that is a user can trip themselves
> up by destroying the value of a variable. 

No worse than doing  "x = 5" when x already exists.
(Although some languages consider any reassignment as bad).

It is simply parallel assignment going on.

> Also, the altering
> of an external variable but not the creation of that variable
> seems kind of confusing.

This is a problem. Even though an assignment is being made, the 
variable disappears. Auto-exporting would fix this.

However, something you did not address are the variables
inside { } which are not in |...|.  Those behave the same
way.  

a = 0; x = 5
3.times{|a| x+=a }
# both a and x are changed.

3.times{|b| z=b }
# neither b nor z are here

I think matz indicated a desire for a flattened scope here 
(that is, auto-exporting), which I can't imagine would break any 
existing code. Maybe it is not done yet because it is hard to do?

The reason auto-export is safe, is that it can't clobber
anything. If you use z after the block in current versions of
ruby, you'd have to initialize it first anyway, since it wouldn't
exist there. As for previously existing vars of the same name,
well, ruby already uses them if they exist, so that is not new.

The only possible conflict I can imagine is if you have a method
named z. But we can use z() to avoid that conflict.


There is a separate issue - using blocks/procs as if they were
methods, with the variables being like arguments that stay local
to the block. The pending change is to use "<...>" for that.

But even "<...>" doesn't address the issue with variables like z.
(Or will it?)

What is supposed to happen to z, then? Which of the following
effects should a block using "<...>" have on z:
1) use z from the outer scope as an initial value for z inside, but 
do not propagate changes outside of the block
2) use z from the outer scope as an initial value for z inside, and 
propagate changes outside of the block (auto-export)
3) treat z as a new variable, and keep it local to the block (like methods do)
4) same as currently in effect: scope depends on whether it already exists

To make the block more like a method, it seems to require (3); but to maintain the
semblance of a closure, it seems (1) is better, which is also like a method which
is evaluated in the caller's binding (btw, it would be nice if we
could access the caller's binding inside a method without it having
to be explicitly passed in).

...
> BTW, I have read several posts asking to see code where
> someone needed to see a value exported. I am still unclear
> on this point. I suppose if you exited early from a block
> that that would create a real need for exporting a value.
> BTW, how do you exit early from a block?
> 

for example:

99.times{|x| z=x**2-3; break if z>99 }


Guy N. Hurst

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