From: Just Another Victim of the Ambient Morality <ihatespam@...>
Date: 2006-08-01T18:50:09+09:00
Subject: Re: I thought this was the one that worked?


"Chad Perrin" <perrin@apotheon.com> wrote in message 
news:20060801081459.GF28188@apotheon.com...
> On Tue, Aug 01, 2006 at 12:05:50PM +0900, dblack@wobblini.net wrote:
>> On Tue, 1 Aug 2006, Chad Perrin wrote:
>>
>> >Okay.  Looks like a closure.  It looks like a closure because of the
>> >relationship of bar to the return-value block of code.  I've been told
>> >that all blocks are closures, though -- and I don't see how it's still a
>> >closure if the "bar = 1" is removed from foo.
>>
>> It's a closure because it carries the context of its creation with it.
>> It doesn't matter whether that context has zero, one, or fifty local
>> variables; the same thing still happens.
>
> 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.  I guess that makes a certain amount of sense, but that
> seems like an absurdly broad definition of a closure.  For one thing, it
> would mean that absolutely any unnamed subroutine passed by reference in
> Perl is a closure.  In fact, by the implied definition of a closure that
> produces, this is a closure in Perl:

    This seriously sounds like an "if a tree falls in the forest, does it 
make a sound?" kind of situation.  In other words, it's a semantic 
argument...


>  sub bar {
>    sub { print "Hello world!\n" };
>  }
>
>  $foo = bar();
>
>  $foo->();
>
> (Yes, I find the dereferencing syntax in Perl to be ugly and cumbersome
> too, but that's beside the point.)
>
> That's the equivalent of this, in Ruby:
>
>  def bar
>    lambda { puts "Hello world!" }
>  end
>
>  foo = bar
>
>  foo.call
>
> (".call" is much prettier than "->()")
>
> Would you say those are both closures?

    Personally, I would call them closures, if they have access to their 
environments.
    Perhaps we can agree to call a closure a block of code that has the 
_ability_ to access variables of their enclosing scope, rather than strictly 
requiring that they take advantage of this ability?