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

On Wed, Aug 02, 2006 at 01:28:45AM +0900, Jacob Fugal wrote:
> On 8/1/06, Chad Perrin <perrin@apotheon.com> wrote:
> >
> >It sounds like what you're saying is that the lexical scope of the code
> >block (proc/lambda/blah) is what makes it a closure, and not the
> >connection with, and OOPish protection/encapsulation of, something that
> >started outside the code block and went out of scope externally to the
> >code block.
> 
> No, what he's saying is that what makes it a closure is exactly that
> form of encapsulation (capture, I would say) of its surrounding
> *environment*. I think that's the key distinction here.
> 
> 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.


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


> 
> 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:
> 
>  class Foo
>    def bar
>      lambda{ baz }
>    end
>  end
> 
>  foo = Foo.new
>  bar = foo.bar
> 
>  class << foo
>    def baz
>      puts "quux"
>    end
>  end
> 
>  bar.call
>  # prints "quux"

Now you're arguing that there does, indeed, have to be a variable.
What?  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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
unix virus: If you're using a unixlike OS, please forward
this to 20 others and erase your system partition.