On Thu, 29 Sep 2005, Eric Mahurin wrote:

> You should be able to free x as soon as the enclosing methods completes,
> right?

what if there is no eclosing method - eg. you are at the top level and

   def method &block
     yield
   end


   method do
     f = open 'gigantic', 'r'
     memory_leak = f.read
   ensure
     f.close
   end

every single method available at the top level would leave it's block
variables in the top level forever!  after a few method calls
'local_variables' would return a list 10,000 items long.  they could never be
gc'd.  it's true that lambda's keeps vars from being gc'd - but this approach
would prevent every named var of every top-level method called with a block
from being re-claimed.  consider open as an example - how easy to leak a
buffer...

i also don't like how you are limited to making local what the designer of the
block allowed - eg.  only a, b, and c are not leaked here

   def method &block
     yield 1,2,3
   end

   method{|a,b,c| p [a,b,c]; d = 42}

so there's no way for client code to keep something local...  or am i missing
something?

> How about this one:
>
> def foo
>  a = [1,2,3]
>  lambda { x = 42 }
> end
>
> f = foo
> f.call # => 42
> eval("a",f.binding) # => [1,2,3]

well that's a different beast - you created the lambda explicitly.  i'm
worried about implicit pervasives.

> When you start passing around blocks/lambdas, you prevent all of the
> variables in surrounding scope from being GC'ed because of the #binding
> link.  All for the sake of an eval on the binding.  I think this is a larger
> issue than the one you are discussing.

agreed.

> There are several ways you could treat variables within blocks:
>
> - local if not in surrounding scope (now in 1.8)
> - local with no relation to surrounding scope (2.0 args)
> - local and intialized to same value in surrounding scope
> - same scope as surrounding scope (2.0 other variables)
>
> I think it is hard to pick from these.  You can make an argument that any of
> these are useful.  It would be nice to be able to control this more
> directly, but this may also reduce readability.

if the aim is to unify lambda and methods then the move must be towards local
vars only no?  perhaps with a more capable Binding or Scope object?  it's
tough to say what matz it thinking - i'd like to hear before i say much
more.

i suppose we'd adapt to whatever came up - but it seems like a dangerous
change.

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| Your life dwells amoung the causes of death
| Like a lamp standing in a strong breeze.  --Nagarjuna
===============================================================================