On Jan 9, 2008, at 2:52 PM, Rick DeNatale wrote:

> Looking at eval.c, it looks like lambda actually copies information
> from the invocation stack, not just from the current frame. In the
> leaky finalizer case we have the following on the stack when
> leaky_finalizer is called, with the binding represented in hash
> notation.
>
> leaky_finalizer   :self => Class
> finalizer               :self => Class
> new                      :self=> Class, :object => the new Array  
> instance
> code which called Array.new
>
> The leak free finalizer lambda was created once at a time when no
> instance to be finalized was on the stack.

yeah i think that may be true - but it doesn't make sense.  the

   def leaky_finalizer
     lambda{}
   end

is the current paradigm for preventing lambdas from enclosing a  
reference to an object.  what you are saying is that this call  
encloses a local variable from another (the calling in the this case)  
function.

how would that not be a bug?  why enclose a variable that cannot  
possible be reached in the code ran?  this seems, to me just like this  
code

   void * leak (){ return(&malloc(42)) }

i just cannot image why lambda would crawl up the stack outside the  
current function.  if that is true then they are useless and *any*  
invocation means every object in memory at the time of creation can  
never be freed while that lambda exists.  doesn't that seem  
excessive?  also i use tons of lambdas in code that does not leak so  
this just seems impossible.

nevertheless you may be right!

cheers.

a @ http://codeforpeople.com/
--
we can deny everything, except that we have the possibility of being  
better. simply reflect on that.
h.h. the 14th dalai lama