I thought this was the one that worked?

Ruby
21

On Tue, Aug 01, 2006 at 11:39:29AM +0900, Hal F. wrote:

Maybe you can point us to a formal definition somewhere.

How’s this?:

Closure
A “closure” is an expression (typically a function) that can have
free variables together with an environment that binds those
variables (that “closes” the expression).

I found it on this page:

Javascript Closures

I also found this:

Achieving Closure

I would have said that a closure will retain its variables
if/when they go out of scope.

Bad analogy: We might loosely define a car as “a machine that
goes places,” but it’s still a car even when it sits still.

My understanding is that the vehicle is a car, and the use of it is a
drive (to the country, or whatever). Similarly, a block of code that
can be passed around like a first-class member is a block, or lambda, or
whatever you want to call it today: if you pass it to a function as an
argument, it’s a callback, and if you lexically close it, it’s a
closure.

My impression is that you’re applying the definition too
rigidly.

I suppose that’s possible, but I really don’t think so. Do you have a
formal definition of a closure that specifically contradicts my
understanding?

22

On Jul 31, 2006, at 11:41 PM, Eric A. wrote:

over their enclosing scope.
eric

I imagine it was to avoid having to declare local variables. e.g.:

a = 1

def add_two
a = 2
return a + n
end

… hundred of lines of code later …

def b
puts a
end

Now I imagine when our hypothetical programmer wrote b he expected it
to always print the value of the top-level a.

OTOH when he wrote add_two he was expecting a to behave as a local
variable.

If defs were closures, we’d have to write

def foo
my a
or
local a
or
declare a
or
var a
end

etc. to make sure we weren’t in in-advertantly using an effectively
“global” variable

23

On Jul 31, 2006, at 11:26 PM, Chad P. wrote:

Do you still have any questions on the matter?
I’m unfamiliar with your assertion that the context has to go
have
free variables together with an environment that binds those
variables (that “closes” the expression).

In ruby this environment always exists for a block regardless of the
presence of free variables, since the declaration of the variables
that are free in the block can be added after (in time) the creation
of the closure.

I would have said that a closure will retain its variables
argument, it’s a callback, and if you lexically close it, it’s a

Your definition is consistent with what happens in ruby, it just
happens to be difficult to demonstrate with a run of the mill ruby
program. Ruby will never say “Oh this block doesn’t reference any
free variables in it’s enclosing scope, I will just create an
anonymous function instead of a closure.” It will always create the
closure in anticipation of possible changes to the enclosing
environment.

24

On Tue, Aug 01, 2006 at 11:43:32AM +0900, Logan C. wrote:

Like I said it’s hard to give you an example, but ruby creates a
def foo
baz.call

a.set_var( “Hello” )

baz.call

% ruby closure2.rb
1
Hello

That block, “lambda { puts @a }”, is still making reference to a
variable that was explicitly declared to a scope outside itself. Let’s
try this:

def foo
bar = 0
lambda { bar += 1; puts bar; }
end

baz = foo

There’s a closure. Invoking baz.call will output an iterated value.
Now have a look at this:

def foo
puts “Stuff!”
lambda { puts “Junk!” }
end

bar = foo

. . . then tell me whether it’s still a closure – and why, despite the
lack of reference within the lambda block to anything outside of it.

25

On Tue, Aug 01, 2006 at 12:47:50PM +0900, Logan C. wrote:

presence of free variables, since the declaration of the variables
that are free in the block can be added after (in time) the creation
of the closure.

I think that depends on what you mean by “creation of the closure” in
this case. Are you talking about the code used to create it, or the
assignment of the return value of the closure’s enclosing scope to a
variable?

26

On Aug 1, 2006, at 12:06 AM, Chad P. wrote:

In ruby this environment always exists for a block regardless of the
presence of free variables, since the declaration of the variables
that are free in the block can be added after (in time) the creation
of the closure.

I think that depends on what you mean by “creation of the closure” in
this case. Are you talking about the code used to create it, or the
assignment of the return value of the closure’s enclosing scope to a
variable?

I’m talking about what happens inside the ruby interpreter when it
sees that code. As far as ruby is concerned, it doesn’t know how to
make a block that isn’t a “closure”. The same code path gets followed
whether ruby sees

def foo
a = 1
lambda { … a … }
end

or

def foo
lambda { … }
end

All the “closure bookkeeping” is done whenever you create a block. No
extra bookkeeping is done whether or not you take advantage of the
fact that you have a “closure”.

27

“Chad P.” [email protected] wrote in message
news:[email protected]…

sub foo {
I’m hoping that demonstrating how it does or does not work in Perl will
make it clear what I’m talking about, based on similar syntax between
the languages, so that I can find out what does and does not work in
Ruby. Duh?

Well, I suppose the question can be directed only to those who know

Perl
but the two languages seem to be sufficiently different (despite Ruby’s
Perl
origins) that your analogies are hard to make or make clear…

within them go out of scope while the block is still in scope, I’d like
to know. If there’s some other way to “close” the block’s data while
the block is still available, I’d like to know that, too.

I'm having trouble parsing your sentences here so I am going to

pretend
that I understand you and you can tell me where I’m going wrong, okay?

These are Ruby blocks:

[1, 2, 3].each do |i|
# this is a Ruby block and
# this is a closure
end

So explain how it is a closure. Please.

Okay, I think I can do this much...

I'm going to implement the "each" method of an array using the

passed in
block, which is a closure, using the array reference operator “[]” and
the
size method…

local_variable = 2

class Array
# local_variable is outside this scope…

def each
    # local_variable is also outside this scope...

    i = 0
    while i < self.size

        # call the passed in block which is also a closure...
        yeild self[i]

        i += 1
    end
end

end

array = [1, 2, 3]

array.each do |i|
# we have access to local_variable even though this
# will be executed far away from local_variable’s scope
# because this block of code is a closure…

puts local_variable * i

end

some_local_variable = 2
func = lambda { puts some_local_variable } # a one line block and
closure

Am I to assume that some_local_variable is going out of scope outside of
the lambda declaration at some point, to create that closure?

Yes, you are.  It didn't occur to me to demonstrate that it was a

closure, only how to make blocks that are closures in Ruby. I hope the
previous paragraph demonstrated what you wanted to know…

All things that are called "blocks" in Ruby are closures.
Do you still have any questions on the matter?

Yes. Are you just failing to explain how these things are closures, or
do you not know what a closure is? You keep telling me blocks are
closures somehow, but you’re not explaining how. Saying it doesn’t make
it so. Please explain what I’m missing.

I _think_ I know what a closure is, as long as Wikipedia and all

Ruby
tutorials haven’t conspired to lie to me. Again, it didn’t occur to me
show
you that they are closures. I was only trying to show you what will
make a
closure…
So, are these closures, as you understand them? How is your
understanding different from mine?

28

On Tue, Aug 01, 2006 at 02:05:17PM +0900, Just Another Victim of the
Ambient M. wrote:

[ snip ]

I _think_ I know what a closure is, as long as Wikipedia and all Ruby

tutorials haven’t conspired to lie to me. Again, it didn’t occur to me show
you that they are closures. I was only trying to show you what will make a
closure…
So, are these closures, as you understand them? How is your
understanding different from mine?

There was some stuff to digest there, and I’ll be digesting it. As for
what I didn’t snip, I’ll try explaining a closure (as I understand it)
in different terms:

There is a variable. There is a (something we’ll call “lambda”). The
lambda uses the variable. The variable is in a scope outside of the
lambda’s scope, but available to the lambda. The variable’s original
scope “closes”, thus eliminating the variable for purposes of anything
else in the program other than the lambda, thus “closing” the code in
the lambda – thus the term “closure”. It produces circumstances that
object oriented programmers would recognize as “protection” and
“encapsulation”.

How does that mesh with your take on it?

29

On Tue, Aug 01, 2006 at 12:54:58PM +0900, Logan C. wrote:

variable.
This is one of the reasons that explicit scoping declarations are
generally a good idea: testing code with explicit lexical scoping
declarations will quickly tell you exactly what you screwed up, and
using local dynamic declarations will actually do what you surmise the
hypothetical programmer must have assumed. Autovivification is great,
as long as you use it with conscious intent for good reasons rather than
just because you’re lazy.

30

On Tue, Aug 01, 2006 at 01:21:01PM +0900, Logan C. wrote:

assignment of the return value of the closure’s enclosing scope to a
lambda { … a … }
fact that you have a “closure”.
Arrrrrrgh. We’re talking past one another. I can see where at least
some of the disconnect is occurring, but I don’t seem to be able to get
across to you what you’re not saying so that you’ll explain it.

I give up for now. I’ll just see if I can learn what’s actually going
on with blocks and closures in Ruby from some other source.

31

On Tue, Aug 01, 2006 at 12:05:50PM +0900, [email protected] wrote:

On Tue, 1 Aug 2006, Chad P. 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:

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?

I guess you could debate whether that block is a closure, since it
never leaves the context where it’s created – so there’s nothing
really remarkable about the fact that a is still visible inside it.
And every time you put its closureness to the test, so to speak,
you’ve turned it into a Proc, so technically the Proc, rather than the
block, is the closure.

(Like I said, subtle hair-splitting :slight_smile:

Let’s assume for the moment that we’ll split the hair on the side of
calling it a closure, and focus on the presence or absence of a variable
declared outside the lambda’s scope. See my above examples. I’m not
saying that’s where I’d split the hair, but it’s not where I want to
focus right now.

32

“Chad P.” [email protected] wrote in message
news:[email protected]…

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…

(“.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?

33

“Chad P.” [email protected] wrote in message
news:[email protected]…

you that they are closures. I was only trying to show you what will make
lambda uses the variable. The variable is in a scope outside of the
lambda’s scope, but available to the lambda. The variable’s original
scope “closes”, thus eliminating the variable for purposes of anything
else in the program other than the lambda, thus “closing” the code in
the lambda – thus the term “closure”. It produces circumstances that
object oriented programmers would recognize as “protection” and
“encapsulation”.

How does that mesh with your take on it?

Well, I think that meshes just fine with my take on it...
To tell you the truth, I didn't expect you to ask me what my

understanding of a closure is because I thought I had already
demonstrated
it with the code sample I gave. Of course, you’re busy digesting that
and I
appreciate it. It means you’re actually trying to understand me (rather
than just arguing at me. Something that happens all too often…).
If I may be so bold, I think that, perhaps, blocks don’t look like
closures to you because you don’t realize that methods that take blocks,
like “each,” “inject,” “collect,” etc… are methods (member functions,
if
you’re a C++ guy) and not arbitrary language constructs, like “if,”
“while,”
“for,” etc…

Now that I think about it, this whole argument can be settled with

one
simple question. If you doubt that all blocks are closures then show us
a
counter-example. Show us a “block” that is not a closure and I will
show
you how it’s not a block…

34

On Tue, Aug 01, 2006 at 06:15:10PM +0900, Just Another Victim of the
Ambient M. wrote:

you’re a C++ guy) and not arbitrary language constructs, like “if,” “while,”
“for,” etc…

I’m not exactly a C++ guy. I suppose I’m more of a Perl guy than
anything else, judging by my familiarity with languages and the
assumption of a lack of loathing (I’m as familiar with PHP as with Perl,
but I don’t like it very much, for instance). I am familiar with many
of the idioms and much of the semantic and syntactic theory of a lot of
languages, even if I don’t use them much, though. The dangers of doing
consulting and industry analysis for money. . . .

Now that I think about it, this whole argument can be settled with one

simple question. If you doubt that all blocks are closures then show us a
counter-example. Show us a “block” that is not a closure and I will show
you how it’s not a block…

Is this a closure? You tell me (and tell me how, if it is):

array.each do ||
puts “Hello world!”
end

35

On Tue, Aug 01, 2006 at 06:50:09PM +0900, Just Another Victim of the
Ambient M. wrote:

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…

Okay, let’s translate that question into the terms we’re actually
discussing.

  1. If a tree falls in the forest, and there’s no one around to hear
    it, does it still make a sound?

  2. If a lambda has the ability to access its context, but there isn’t
    any context to access, is it still a closure?

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?

Not yet. See above, re: blocks falling in a forest.

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.

It’d be pretty neat to be responsible for the creation of a new
programming koan, anyway. I’m going to go add this to my sig rotation
right now.

36

On Aug 1, 2006, at 12:39 PM, Chad P. wrote:

  1. If a lambda has the ability to access its context, but there
    isn’t
    any context to access, is it still a closure?

Hahaha, in the next conference someone should bring a stick and hit
suddenly people asking that with energy.

– fxn

37

[email protected] wrote in message
news:[email protected]…

And every time you put its closureness to the test, so to speak,
you’ve turned it into a Proc, so technically the Proc, rather than the
block, is the closure.

I would debate that it _is_ a closure because, although it's defined

where its context is, that’s irrelevant. What matters is that the block
is
passed into the “each” method of the Array class and is executed there,
where “a” is not visible. Thus, the block was executed outside of the
scope
of “a” while still having access to it. How is this possible? It’s
possible because the block that was passed in is a closure…
QED.

38

Hi –

On Tue, 1 Aug 2006, Just Another Victim of the Ambient M. wrote:

I guess you could debate whether that block is a closure, since it
of “a” while still having access to it. How is this possible? It’s
possible because the block that was passed in is a closure…
QED.

It’s not exactly passed to the method, though. You can capture it in
the method – in which case, it becomes a Proc object, and then
there’s no issue (hair-splitting or otherwise) about its being a
closure.

If you don’t capture it, you can yield to it – but then you’re
yielding to the block, not calling a Proc object derived from the
block.

It comes down to the fact that blocks are syntactic constructs, while
Procs are first-class objects.

David

39

Hi –

On Tue, 1 Aug 2006, Chad P. wrote:

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.

No; what makes something a closure, as I understand it, is that it
carries the context of its creation with it. Also, there’s actually a
difference between a block on the one hand, and a Proc or lambda on
the other. (See my last couple of posts.)

$foo = bar();
end

foo = bar

foo.call

(".call" is much prettier than “->()”)

Would you say those are both closures?

I agree with Logan that the presence or absence of actual variables
isn’t what makes something a closure. Rather, it’s a matter of what’s
actually happening in the language. To me, the distinction you’re
describing is sort of like having one class to represent arrays with
one or more elements, and another class to represent empty arrays.
(See also my example with the non-existent bar variable, which
demonstrates that lambdas created in a given context are executed in
that context, with or without local variables.)

I think of a closure as a kind of suitcase: you pack it in one place,
and unpack it somewhere else. Even if it’s empty, though, it’s still
a suitcase.

Another way to look at it is this: if you decide that the lambda in
your example above is not a closure, then you have to come up with
separate explanations for everything it does that is closure-like.
If you look at it as a closure, however, there’s nothing unaccounted
for.

David

40

Hi –

On Tue, 1 Aug 2006, Chad P. wrote:

like “each,” “inject,” “collect,” etc… are methods (member functions, if

Now that I think about it, this whole argument can be settled with one

simple question. If you doubt that all blocks are closures then show us a
counter-example. Show us a “block” that is not a closure and I will show
you how it’s not a block…

Is this a closure? You tell me (and tell me how, if it is):

array.each do ||

You don’t need the || (and hopefully that will continue to be the case
forever, though there have been some troubling allusions to the
possbiility of having it mean something some day…).

puts “Hello world!”
end

See my last couple of posts about blocks vs. Procs. To which I’ll
add: it’s not quite possible, I think, to argue that a block isn’t a
closure, because it does have its own scope – so it’s not like
arguing that, say, an if statement is a closure.

David