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