On Sunday 23 November 2003 09:32 pm, Mathieu Bouchard wrote:
> On Mon, 24 Nov 2003, T. Onoma wrote:
> > This WILL brake code. Consider:
> >   a = [1,2,3]
> >   a.each { |x| i = x + i.to_i }
> >   p "#{i}"  # => "6"
> >   a = [1,2,3]
> >   a.each { |x| i = x + i.to_i }
> >   p "#{i}"  # => "12"  # => Doh! It's not 6 anymore!
>
> The current policy on the value of i is that i doesn't exist in the
> outerscope, so currently it doesn't matter that its value is not 6,
> because the variable isn't available at all so the first p i doesn't do
> anything.
>
> #<NameError: (eval):1: undefined local variable or method `i'>
>

In the current system, yes, but I was demonstrating the new proposed system, 
which will do as I have shown. And is very different from the current 
behavior, as you have pointed out, even though, as you also point out, it is 
a rather dumb example. Nonetheless it easy to imagine otherwise: an internal 
counter that clashes with another intenal counter later on.

>
> I think the actual problem would be more with code that does things like
> this:
>
> def foo(n)
>   (0...n).map {
>     proc {a=0; proc{a+=1;a}}[]
>   }
> end
>
> I expect this code to produce n distinct counters that will each produce
> their own independent sequence 1,2,3,4,5,... when called repeatedly. If it
> becomes impossible to do this anymore, then I won't be able to honestly
> say that Ruby really supports closures.

Hmm...there would have to be an exception made for lambdas. Another minus.

-t0