From: Justin Collins <collinsj@...>
Date: 2006-08-02T08:23:44+09:00
Subject: Re: [SPAM]  Re: I thought this was the one that worked?

--------------070903040105060109080309
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Chad Perrin wrote:
> On Wed, Aug 02, 2006 at 07:45:05AM +0900, Just Another Victim of the Ambient Morality wrote:
>   
>> "Chad Perrin" <perrin@apotheon.com> wrote in message 
>> news:20060801190919.GB30216@apotheon.com...
>>     
>>> On Tue, Aug 01, 2006 at 10:20:06PM +0900, Just Another Victim of the 
>>> Ambient Morality wrote:
>>>       
>>>> "Chad Perrin" <perrin@apotheon.com> wrote in message
>>>>         
>>>>>  2. If a lambda has the ability to access its context, but there isn't
>>>>>  any context to access, is it still a closure?
>>>>>           
>>>>     How about this:
>>>>
>>>> 3. If a lambda has the ability to access its context and nothing's around 
>>>> to
>>>> use it, does it still make a closure?
>>>>
>>>>     I think 3 is a better characterization than 2.  Here's some code to
>>>> demonstrate:
>>>>         
>>> I don't.  A closure is a closure whether you use it or not, just as a
>>> remote control for the TV is a remote control for the TV whether you use
>>> it or not.  What's actually relevant to the discussion is more like the
>>> question of whether a remote control for the TV is still a remote
>>> control for the TV if it was built with no TV on which it could operate.
>>>       
>>     I think 3 is a better example because in all the examples of (alleged) 
>> closures we've given each other, there usually was a TV... I mean, a 
>> context...
>>     
>
> That's why I went back to correct my analogy, such that in the new
> version the TV exists, and the mechanism for a relationship between the
> remote and the TV exists, but the actual existence of anything to pass
> back and forth does not.  The TV is context, but the channel, volume,
> and power variants of the TV are what the context contains, and the
> buttons on the remote are its interaction with those things.
>
>
>   
>>     The two code blocks (not Ruby blocks) above look similar but are very 
>> different.
>>     The "if" keyword is a language construct and does not take a block.  I 
>> cannot change the behaviour of "if."
>>     In contrast, "each" is not a keyword and is not a language construct.  I 
>> may redefine (or define!) it and change its behaviour.  It is a simple 
>> method and, within it, created its own scope which is outside the closing 
>> scope of the closure (block) passed in...  We don't see that here but that's 
>> not relevant.  It happens nonetheless...
>>     
>
> Okay, so the fact that .each has its own scope differentiates it from a
> situation involving a mere conditional statement.  I'll stipulate that
> for now (I'll probably agree more thoroughly later, when I've had a
> chance to consider the mechanics of scope for methods such as "each").
> If such a relationship to a method is a necessary precondition of an
> idiomatic Ruby "block", complete with a thus-enclosing scope that ends
> while the block persists, I think we may finally have an almost-explicit
> case for *why* and *how* an idiomatic Ruby "block" is, necessarily, a
> "closure" -- assuming of course David's suggestion of a closed lexical
> scope as the necessary ingredient of a closure, rather than specifically
> the de-scoped variable within that lexical scope.
>
> That's some interesting, complex set of explanations for how a closure
> is achieved, but it's valid as far as I can see, and it does indeed seem
> to indicate that all Ruby blocks are closures.
>
> Thank you.
>
>   
<snip>

Does that mean this enormous thread is drawing to a close (pun possibly 
intended)? :)

-Justin

--------------070903040105060109080309--