From: Jacob Fugal <lukfugl@...>
Date: 2006-08-02T05:07:33+09:00
Subject: Re: I thought this was the one that worked?

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. :)

> > 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.

> > Even then, an empty environment can't exist in Ruby. There's always at
> > least one "variable" in the environment that will be accessible in the
> > closure: self. Take the following example:
[snip example]
>
> Now you're arguing that there does, indeed, have to be a variable.
> What?

No, I'm not saying there *has* to be a variable for it to be a
closure. I'm simply demonstrating that in Ruby there always *will* be
a variable: self.

> 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.

There is no such thing as a "function" in ruby; they are all methods.
When you make a method call without an explicit receiver, that method
is called with a receiver of self. Even puts; the Kernel module
defines a puts method, which is mixed into the Object class, so all
objects have access to that puts method. That's what some other
posters were demonstrating when they used all that trickery redefining
puts for the object's singleton. You're still using self. I was just
trying to make that dependence on self more explicit by using a
non-standard method like baz.

Jacob Fugal