From: Chad Perrin <perrin@...>
Date: 2006-08-02T05:19:05+09:00
Subject: Re: I thought this was the one that worked?

On Wed, Aug 02, 2006 at 05:07:33AM +0900, Jacob Fugal wrote:
> On 8/1/06, Chad Perrin <perrin@apotheon.com> wrote:
> >On Wed, Aug 02, 2006 at 01:28:45AM +0900, Jacob Fugal wrote:
> >> You seem set in the belief that a closure is around a specific
> >> variable or group of variables. If those variables don't exist, then
> >> the closure must not exist. Unfortunately the current definition on
> >> Wikipedia (which I consider useful, but not authoritative) reflects
> >> that type of thinking.
> >
> >The current definition on Wikipedia is scattered, vague, and without
> >salient points on this matter.  I've read through the thing from end to
> >end, and the article spends an awful lot of time failing to concretely
> >define a closure.
> 
> On that, we can agree. :)

Good.


> 
> >> But the definition I learned in the University, have seen in multiple
> >> CS theory texts and to which David is referring here is that the
> >> closure is around an *environment*, regardless of what variables from
> >> that environment may or may not exist and/or be used. So even if the
> >> environment were empty, or the lambda/proc didn't reference any
> >> variables from the environment, the lambda/proc is still capturing
> >> that environment, forming a closure around it.
> >
> >That's a definition of a closure that I would at this point at least not
> >call "wrong", even if it doesn't strike me as particularly "right"
> >either, because the explanations of closures I've seen can potentially
> >be interpreted in that manner.  Even so, I'd say that to fit a strict
> >definition of a closure, the chunk of code in question needs to exit its
> >enclosing scope before it's a closure -- else it's not "closed".
> 
> I don't necessarily agree with that, but it's incidental to my point,
> so I won't argue it.

I was overhasty in the way I phrased that, I think.  I suppose the chunk
of code doesn't need to exit its enclosing scope so much as the
reference to the closure scope has to exit that scope irrevocably.


> 
> >In any case, this can happen in Ruby:
> >
> >  class Foo
> >    def bar
> >      lambda { puts "quux" }
> >    end
> >  end
> >
> >  foo = Foo.new
> >  bar = foo.bar
> >
> >  bar.call
> >
> >. . . so I don't see your point.  Cut out the middleman, and it still
> >works.
> 
> Ah, but you're still using self in that example. Who is the receiver
> of the call to puts inside the block? It's self.

That's an impressive bit of gymnastics.  I don't buy it as satisfying
the requirements of a closure, though, at this point.  Self is just
something within the current scope, and we're back to an absurdly broad
redefinition of "closure".


> 
> There is no such thing as a "function" in ruby; they are all methods.

Methods are "functions" in the technical, broadly interpreted computer
science definition of the term.  They're just a special case of
"function" that requires more specific conditions to qualify as
"methods".  A method is a function: a function is not necessarily a
method.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."