From: Just Another Victim of the Ambient Morality <ihatespam@...>
Date: 2006-08-01T21:40:05+09:00
Subject: Re: I thought this was the one that worked?


<dblack@wobblini.net> wrote in message 
news:Pine.LNX.4.64.0608010732450.7358@rubypal.com...
>
>> <dblack@wobblini.net> wrote in message
>> news:Pine.LNX.4.64.0607312255430.32274@rubypal.com...
>>>
>>> Of course, not all blocks end up getting turned into Proc objects;
>>> some remain just syntactic constructs:
>>>
>>>   a = 1
>>>   [1,2,3].each {|x| puts x + a }
>>>
>>> I guess you could debate whether that block is a closure, since it
>>> never leaves the context where it's created -- so there's nothing
>>> really remarkable about the fact that a is still visible inside it.
>>> And every time you put its closureness to the test, so to speak,
>>> you've turned it into a Proc, so technically the Proc, rather than the
>>> block, is the closure.
>>
>>    I would debate that it _is_ a closure because, although it's defined
>> where its context is, that's irrelevant.  What matters is that the block 
>> is
>> passed into the "each" method of the Array class and is executed there,
>> where "a" is not visible.  Thus, the block was executed outside of the 
>> scope
>> of "a" while still having access to it.  How is this possible?  It's
>> possible because the block that was passed in is a closure...
>>    QED.
>
> It's not exactly passed to the method, though.  You can capture it in
> the method -- in which case, it becomes a Proc object, and then
> there's no issue (hair-splitting or otherwise) about its being a
> closure.
>
> If you don't capture it, you can yield to it -- but then you're
> yielding to the block, not calling a Proc object derived from the
> block.

    ...and this would be a problem if the definition of a closure is the 
calling of a Proc object derived from a block.  Alas, that is _not_ the 
definition of a closure...
    When we yield to the block, we are doing so in our method, which is 
_not_ the same scope as the scope where the block was created.  Yet, the 
block we're yielding to still has access to that other scope.  How?  Because 
it is a closure...


> It comes down to the fact that blocks are syntactic constructs, while
> Procs are first-class objects.

    I'm not sure why this has anything to do with anything...