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.


> 
> >> > I'm beginning to think the question of whether it's actually a closure
> >> > really IS a question for a programming koan, after all.  If so, I'm 
> >> > glad
> >> > we've at least narrowed the discussion down to this point at last.
> >>
> >>     I agree that we have finally narrowed down the discussion.  This 
> >> might
> >> have happened sooner if I had actually followed the thread...
> >
> > Unfortunately, it was David and possibly one or two others who have been
> > instrumental in narrowing it down.  You're still talking about things
> > that don't seem to bear on what I was saying at all.
> 
>     Why is this unfortunate?
>     I only assumed I had something to do with it because you came to the 
> quoted conclusion while responding to my post.  This is usually 
> reasonable...

It's not strictly speaking unfortunate in the general case -- it just
seemed that your commentary was "unfortunately" largely irrelevant to
that narrowing.  You've certainly contributed positively to the
discussion, however, with the above discussion of the .each method.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"There comes a time in the history of any project when it becomes necessary
to shoot the engineers and begin production." - MacUser, November 1990