I thought this was the one that worked?

Ruby
81

On Wed, Aug 02, 2006 at 05:19:38AM +0900, Jacob F. wrote:

Yes, this is exactly the point we’ve been trying to get across. Both
This is where we get into what David Black described as hair
closures. When he mentions hair splitting, it’s directly in relation
to the third form – an unconverted (yielded to) block.

You were right, up to the point where you said “When he mentions hair
splitting”. The problem at that point that prompted him to mention hair
splitting was the fact that I was balking at defining that second
example as a “closure”. I’ve now come to the conclusion that the second
example is a closure according to at least some, valid from a given
perspective, interpretations of the meaning of “closure”. Thus, I quit
splitting that hair and said “Okay, so I’ll stipulate that the second
example can be called a closure, depending on interpretation.”

If you’re calling the distinction for the third example “hair
splitting”, I’m just going to have to call you flat-out “wrong”

Did you read my explanation? I called it hair-splitting for the same
reason David did – because it can be argued both ways. I gave both
reasons. If you want to debate that point, please reply with more
specifics.

See above.

82

On Wed, Aug 02, 2006 at 05:28:40AM +0900, [email protected] wrote:

On Wed, 2 Aug 2006, Chad P. wrote:

It’s not lexical scoping if that “a” variable is separate from the “a”
variable in the enclosing scope.

yes. it is, because there is no ‘a’ in the enclosing dynamic scope:

harp:~ > cat a.rb
a = 42

If there’s no “a”, then perhaps you can tell me what the hell that is.

83

On Wed, 2 Aug 2006, Chad P. wrote:

If it doesn’t provide what OOPish programmers would call “protection”, it’s
not a closure. How can it be a closure if it’s not closed?

because ‘enclose’ does not imply ‘closed forever’:

en·close Audio pronunciation of “enclose” ( P ) Pronunciation Key
(n-klz) also in·close (n-)
tr.v. en·closed, en·clos·ing, en·clos·es

  1. To surround on all sides; close in.

  2. To fence in so as to prevent common use: enclosed the pasture.

  3. To contain, especially so as to envelop or shelter: â??Every one

of
those darkly clustered houses encloses its own secret� (Charles
Dickens).

  4. To insert into the same envelope or package: enclose a check

with the
order.

ref: Enclose Definition & Meaning | Dictionary.com

take the first def

  1. To surround on all sides; close in.

nowhere does it say that what has been ‘closed in’ cannot be opened
again. a
box encloses it’s contents - yet you may open it up to put more things
in it.
it remains a perfect ‘enclosure’ of it’s contents.

the second doesn’t really apply…

the third

  3. To contain, especially so as to envelop or shelter: â??Every one

of
those darkly clustered houses encloses its own secret� (Charles
Dickens).

houses ‘enclose’ - people and things can move freely in and out of them

same goes for number 4

i think the critical thing you are muddying the waters with is the fact
that
no definition of enclosure implies and sort of static or frozen jail
like
container. consider the phrase

‘we escaped from the storm into the enclosure of our tent’

enclosures surround - they do not mummify.

-a

84

On Wed, 2 Aug 2006, Chad P. wrote:

If there’s no “a”, then perhaps you can tell me what the hell that is.

it’s not that there is no ‘a’, it’s that there is no enclosing scope.
the
beginning of the ‘def’ introduces a new scope that is not ‘contained’ by
the
previous one. this is basic ruby.

-a

85

On 8/1/06, Chad P. [email protected] wrote:

example as a “closure”. I’ve now come to the conclusion that the second
example is a closure according to at least some, valid from a given
perspective, interpretations of the meaning of “closure”. Thus, I quit
splitting that hair and said “Okay, so I’ll stipulate that the second
example can be called a closure, depending on interpretation.”

Ok, I’ve tried my bit at patience. I am certain now that you are being
intentionally stubborn and difficult.

Let me quote from the message I referenced.

You said, “I don’t see how it’s still a closure if the ‘bar = 1’ is
removed from foo.”

He replied, “It’s a closure because it carries the context of its
creation with it.”

He certainly didn’t hair-split around that.

He then proceeded to the “hair-splitting section”:

Some subtle but possible interesting hair-splitting:

Of course, not all blocks end up getting turned into Proc objects;
some remain just syntactic constructs:

a = 1
[1,2,3].each {|x| puts x + a }

I guess you could debate whether that block is a closure, since it
never leaves the context where it’s created

I can’t see how you can interpret his “hair-splitting” as not
referring to his reference to non-converted blocks.

Jacob F.

86

On Wed, Aug 02, 2006 at 05:33:50AM +0900, Jacob F. wrote:

That’s an impressive bit of gymnastics.

Gymnastics? What exactly did I twist?

My statement has been divorced of context by separating it from the rest
of my brief paragraph. That context is necessary to understanding of
the statement, and answers your question. Please don’t do that.

was created, then you’re mistaken, because it is the self that was
current when the block was created that is used. This is what others
were trying to demonstrate in the examples you dismissed as having
irrelevant variables.

When you say “the scope that was current when the block was created”,
are you referring to the scope that encloses the code that would become
a closure, or are you referring to the scope of the would-be closure
itself?

function in quotes when I said it, but I can see you want to be
pedantic. By your definition, a method is indeed a function.

I’m trying to be precise. It’s lack of precision that got us into this
mess in the first place.

But I counter your last statement: in Ruby, all functions are
necessarily methods, because you can’t call a method/function without
a receiver. You can write it syntactically without a receiver, but in
that case a receiver of self is still implicit. In this sense, Ruby
has no “functions”, only methods.

That doesn’t counter my last statement at all, since I didn’t say “a
function is not necessarily a method IN RUBY”. I was referring to
functions in the generic. To properly sort this out, we need to refer
to something approaching a formal definition of a closure (which
includes more than just Ruby, and thus necessitates using terms in a
manner that apply to more than just Ruby), or we need to simply state
that the term “closure” has a different meaning in Ruby than elsewhere.
Take your pick.

87

On Wed, Aug 02, 2006 at 05:43:30AM +0900, Jacob F. wrote:

splitting was the fact that I was balking at defining that second
example as a “closure”. I’ve now come to the conclusion that the second
example is a closure according to at least some, valid from a given
perspective, interpretations of the meaning of “closure”. Thus, I quit
splitting that hair and said “Okay, so I’ll stipulate that the second
example can be called a closure, depending on interpretation.”

Ok, I’ve tried my bit at patience. I am certain now that you are being
intentionally stubborn and difficult.

You’re wrong, and you can go screw yourself if you’re going to start
assuming malicious intent on my part just because you refuse to actually
discuss the same topic as me. I’ve assumed good faith all along: you
can do the same, or you can talk to someone else, because assuming bad
faith on my part is a quick way to get >/dev/null attached to your name.

88

On Wed, 2 Aug 2006 [email protected] wrote:

enclosures surround - they do not mummify.

thinking on this a bit more i think this is the defining feature of
closures:
they represent an entry for symbol lookup in which all variables are
either
uniquely defined or undefined. that is to say that ‘a’ can exist in
many
closures and each may refer to a different, the same, or no thing. the
things, however, can move and be added and removed from each closure.

-a

89

On Wed, Aug 02, 2006 at 05:42:59AM +0900, [email protected] wrote:

harp:~ > cat a.rb
a = 42

If there’s no “a”, then perhaps you can tell me what the hell that is.

it’s not that there is no ‘a’, it’s that there is no enclosing scope. the
beginning of the ‘def’ introduces a new scope that is not ‘contained’ by the
previous one. this is basic ruby.

. . .

What does that have to do with anything?

90

On Wed, Aug 02, 2006 at 05:41:46AM +0900, [email protected] wrote:

No, I don’t think it’s “an absurd thing to say” – it just doesn’t have
much
depth. The depth is this:

If it doesn’t provide what OOPish programmers would call “protection”, it’s
not a closure. How can it be a closure if it’s not closed?

because ‘enclose’ does not imply ‘closed forever’:

We’re discussing “closures”, not “enclosures”.

 those darkly clustered houses encloses its own secret� (Charles 
 Dickens).

 4. To insert into the same envelope or package: enclose a check with 
 the
 order.

Two definitions of “closure” from the American Heritage Dictionary of
the English Language:

A bringing to an end; a conclusion: finally brought the project to
closure.

The property of being mathematically closed.

In fact, the term “closure” in computer science is derived from the
mathematical definition of “closure”, as in “a closed system”. A
closure in computer science is code and data that constitute a closed
system. As David has suggested (without specifically and explicitly
saying it outright in such terms), the data in question might consist of
a sort of “potential data” such that a closure’s referent closed scope
needn’t necessarily actually contain anything, so long as the scope
itself is theoretically present and accounted for.

i think the critical thing you are muddying the waters with is the fact that
no definition of enclosure implies and sort of static or frozen jail like
container. consider the phrase

If anything, it’s you who’s introducing pollutants to the otherwise
clearer (if not actually clear) subject by confusing “enclosure” with
“closure”.

91

On Wed, 2 Aug 2006, Chad P. wrote:

it’s not that there is no ‘a’, it’s that there is no enclosing scope. the
beginning of the ‘def’ introduces a new scope that is not ‘contained’ by the
previous one. this is basic ruby.

. . .

What does that have to do with anything?

because in the original code

a = 42

def m
puts a
end

‘a’ will only be lexically scoped - and throw and error of course. the
previous def of ‘a’ is totally superfluous - i was just pointing out
that the
failure of ruby to find ‘a’ is going to be a failure of lexical scoping
rules
because there is no enclosing scope (well nothing named in it yet) where
an
‘a’ is defined.

regards.

-a

92

Chad P. [email protected] writes:

On Wed, Aug 02, 2006 at 12:45:46AM +0900, Marshall T. Vandegrift wrote:

I’m joining the party late, but try this example:

Why? Why should we keep trying unnecessarily complex examples that
introduce a bunch of variables (in the statistical study sense of the
term) that are not strictly relevant to the point under consideration?

In the hope that eventually an example might satisfy your all your
criteria and demonstrate why Ruby blocks are closures. And at the
point I posted no one had yet provided an example where the
closure-creation was implicit in the block being a block. I thought
your confusion might be in how

lambda { puts bar+=1 }

explicitly creates an anonymous function which explicitly encloses a
particular variable (environment) while

array.each { puts "bar!" }

does so implicitly.

That’s not very useful. The Wikipedia “description” (it’s not a
dictionary, and as such doesn’t strictly speaking aim to “define” the
terms contained within it) is, for purposes of this discussion,
nigh-uselessly broad and lacking in coherent detail.

How’s this one from the Free On-line Dictionary of Computing?:

closure

1. <programming> In a reduction system, a closure is a data
   structure that holds an expression and an environment of
   variable bindings in which that expression is to be
   evaluated. The variables may be local or global. Closures are
   used to represent unevaluated expressions when implementing
   functional programming languages with lazy evaluation. In a
   real implementation, both expression and environment are
   represented by pointers. [1]

Only if you accept a description of a closure as a definition. As I
implied elsewhere, however, “has four limbs” may be an accurate
description of a human, but the fact “dog” fits that description doesn’t
make it a human.

Oh, I see the problem: metaphysically you’re more of an essentialist
and I’m more of a functionalist. Alas, this can only end in tears. :wink:

Seriously though, does the FOLDOC definition satisfy you? Because if
so, all the examples demonstrate that a Ruby block contains (1) an
expression (the code in the block) and (2) an environment of variable
bindings. Even if that environment is empty[2] when the block is
created, the environment is /still there/, as the examples which
populate the environment after the fact demonstrate.

[1] closure from FOLDOC

[2] Except that it always contains self, etc etc etc.

93

On Wed, Aug 02, 2006 at 06:00:28AM +0900, Marshall T. Vandegrift wrote:

In the hope that eventually an example might satisfy your all your
criteria and demonstrate why Ruby blocks are closures. And at the

The equivalent of line noise, distracting from the actual point of
discussion, doesn’t help.

1. <programming> In a reduction system, a closure is a data
   structure that holds an expression and an environment of
   variable bindings in which that expression is to be
   evaluated. The variables may be local or global. Closures are
   used to represent unevaluated expressions when implementing
   functional programming languages with lazy evaluation. In a
   real implementation, both expression and environment are
   represented by pointers. [1]

It, like basically every other definition I’ve run across, doesn’t
actually address the salient points. May I please speak with David
again? He at least was discussing something precise enough to be
on-topic for the point of contention.

Only if you accept a description of a closure as a definition. As I
implied elsewhere, however, “has four limbs” may be an accurate
description of a human, but the fact “dog” fits that description doesn’t
make it a human.

Oh, I see the problem: metaphysically you’re more of an essentialist
and I’m more of a functionalist. Alas, this can only end in tears. :wink:

I’m also more of a prescriptivist than a descriptivist in natural
linguistic terms. I like precision in my understanding when discussing
technical topics. “It shares some characteristics with something
someone once called a closure!” isn’t enough for me.

94

On 8/1/06, Chad P. [email protected] wrote:

On Wed, Aug 02, 2006 at 05:33:50AM +0900, Jacob F. wrote:

On 8/1/06, Chad P. [email protected] wrote:

That’s an impressive bit of gymnastics.

Gymnastics? What exactly did I twist?

My statement has been divorced of context by separating it from the rest
of my brief paragraph. That context is necessary to understanding of
the statement, and answers your question. Please don’t do that.

I apologize. But in my defense, the rest of the paragraph (which
immediately follows) doesn’t explain what potion of what I did was
gymnastics, nor how. That’s why I separated it.

current when the block was created that is used. This is what others
were trying to demonstrate in the examples you dismissed as having
irrelevant variables.

When you say “the scope that was current when the block was created”,
are you referring to the scope that encloses the code that would become
a closure, or are you referring to the scope of the would-be closure
itself?

The scope that encloses the lambda, which was introduced by the def
keyword immediately preceding the identifier “bar”. Specific enough?

pedantic. By your definition, a method is indeed a function.
That doesn’t counter my last statement at all, since I didn’t say “a
function is not necessarily a method IN RUBY”.

Well, my original statement did include the phrase “in Ruby”, so I
thought it appropriate to try and interpret your statements within
that context, since we are discussing functions and closures IN RUBY.

I was referring to
functions in the generic. To properly sort this out, we need to refer
to something approaching a formal definition of a closure (which
includes more than just Ruby, and thus necessitates using terms in a
manner that apply to more than just Ruby), or we need to simply state
that the term “closure” has a different meaning in Ruby than elsewhere.
Take your pick.

Unfortunately, I don’t have a reference text on me, nor can I find a
source online that you might consider authoritative, so we’ll just
have to leave the formal definitions for later. But the version of
closures I learned and implemented in the University were those which,
as Ara mentioned, contain some sort of pointer to the environment in
which they were created so that they can perform name resolution using
that environment. All procs/lambdas in Ruby satisfy that condition.
The discussion of functions and methods in Ruby, imprecise as it may
be, is incidental to that, so I felt no need to be that formal or
specific about what a “function” is.

Jacob F.

95

I don’t how everyone else will react, but this
is the very first explanation I’ve seen that
gives some basis for the linguistic choice of
“closure” to describe the concept.

96

On 8/1/06, Chad P. [email protected] wrote:

On Wed, Aug 02, 2006 at 05:43:30AM +0900, Jacob F. wrote:

Ok, I’ve tried my bit at patience. I am certain now that you are being
intentionally stubborn and difficult.

You’re wrong, and you can go screw yourself if you’re going to start
assuming malicious intent on my part just because you refuse to actually
discuss the same topic as me. I’ve assumed good faith all along: you
can do the same, or you can talk to someone else, because assuming bad
faith on my part is a quick way to get >/dev/null attached to your name.

I apologize for my outburst. I was out of line in what I said. I was
assuming good faith for the majority of the conversation as well, I
was simply confused about how we could be coming to such drastically
different conclusions regarding a cited reference. I’d also like to
know how I’ve been refusing to discuss the same topic?

Jacob F.

97

Chad P. wrote:

You’re wrong, and you can go screw yourself if you’re going to start
assuming malicious intent on my part just because you refuse to actually
discuss the same topic as me. I’ve assumed good faith all along: you
can do the same, or you can talk to someone else, because assuming bad
faith on my part is a quick way to get >/dev/null attached to your name.

My first and only warning:
If I see another post like this one I’ll create a
filter that transfers your messages directly to the
trash bin.

98

On Wed, Aug 02, 2006 at 06:13:58AM +0900, Jacob F. wrote:

I apologize for my outburst. I was out of line in what I said. I was
assuming good faith for the majority of the conversation as well, I
was simply confused about how we could be coming to such drastically
different conclusions regarding a cited reference. I’d also like to
know how I’ve been refusing to discuss the same topic?

Le sigh.

Apology accepted. I’m frustrated too, so I can understand how you ended
up speaking too hastily.

In fact, I’ve probably spoken more hastily than necessary when I used
the term “refusing”. Rather, we just seem to be addressing wholly
different subtopics – talking past one another – to some extent.

Frankly, I’d like to drop this subthread at this point and focus on
those where I’ve mentioned something about why a “closure” is called a
“closure”. That’s really the heart of the matter.

99

[email protected] wrote:

http://hypermetrics.com/rubyhacker/clrFAQ.html#tag22 - would be better
for everyone’s bandwidth

Thanks much for that!

100

On Wed, Aug 02, 2006 at 06:24:18AM +0900, Eric A. wrote:

filter that transfers your messages directly to the
trash bin.

Thank you for your very one-sided view of the situation. I really enjoy
being told I’m a bad, bad man for disliking being told I’m acting
maliciously when, in fact, I am doing no such thing. Your threats mean
very little to me, particularly when your threats parrot my own reaction
to someone making unfounded accusations.