On Jul 31, 2006, at 11:26 PM, Chad Perrin wrote:

> On Tue, Aug 01, 2006 at 11:39:29AM +0900, Hal Fulton wrote:
>> Chad Perrin wrote:
>>>
>>> Am I to assume that some_local_variable is going out of scope  
>>> outside of
>>> the lambda declaration at some point, to create that closure?
>>>
>>>
>>>
>>>>   All things that are called "blocks" in Ruby are closures.
>>>>   Do you still have any questions on the matter?
>>>
>>>
>>> Yes.  Are you just failing to explain how these things are  
>>> closures, or
>>> do you not know what a closure is?  You keep telling me blocks are
>>> closures somehow, but you're not explaining how.  Saying it  
>>> doesn't make
>>> it so.  Please explain what I'm missing.
>>>
>>
>> I'm unfamiliar with your assertion that the context has to go
>> out of scope before a closure exists.
>>
>> Not trying to argue, just stating my perception.
>>
>> Maybe you can point us to a formal definition somewhere.
>
> How's this?:
>
>   Closure
>       A "closure" is an expression (typically a function) that can  
> have
>       free variables together with an environment that binds those
>       variables (that "closes" the expression).
>

In ruby this environment always exists for a block regardless of the  
presence of free variables, since the declaration of the variables  
that are free in the block can be added after (in time) the creation  
of the closure.

> I found it on this page:
>
>   http://jibbering.com/faq/faq_notes/closures.html
>
> I also found this:
>
>   http://www.perl.com/pub/a/2002/05/29/closure.html
>
>
>>
>> I would have said that a closure *will* retain its variables
>> *if/when* they go out of scope.
>>
>> Bad analogy: We might loosely define a car as "a machine that
>> goes places," but it's still a car even when it sits still.
>
> My understanding is that the vehicle is a car, and the use of it is a
> drive (to the country, or whatever).  Similarly, a block of code that
> can be passed around like a first-class member is a block, or  
> lambda, or
> whatever you want to call it today: if you pass it to a function as an
> argument, it's a callback, and if you lexically close it, it's a
> closure.
>
>
>>
>> My impression is that you're applying the definition too
>> rigidly.
>
> I suppose that's possible, but I really don't think so.  Do you have a
> formal definition of a closure that specifically contradicts my
> understanding?
>

Your definition is consistent with what happens in ruby, it just  
happens to be difficult to demonstrate with a run of the mill ruby  
program. Ruby will never say "Oh this block doesn't reference any  
free variables in it's enclosing scope, I will just create an  
anonymous function instead of a closure." It will always create the  
closure in anticipation of possible changes to the enclosing  
environment.

> -- 
> CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
> "A script is what you give the actors.  A program
> is what you give the audience." - Larry Wall
>