I thought this was the one that worked?

[Jacob Fugal]

That's an impressive bit of gymnastics.

Gymnastics? What exactly did I twist?

I don't buy it as satisfying
the requirements of a closure, though, at this point. Self is just
something within the current scope, and we're back to an absurdly broad
redefinition of "closure".

What current scope are you referring to here? If you mean the scope
that was current when the block was created, then why does that not
make it a closure? Why is self different than some other variable
named b? If you don't mean the scope that was current when the block
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.

Methods are "functions" in the technical, broadly interpreted computer
science definition of the term. They're just a special case of
"function" that requires more specific conditions to qualify as
"methods". A method is a function: a function is not necessarily a
method.

Ok, we're using different definitions of function. That's why I put
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.

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.

Jacob Fugal

 

[ara.t.howard]

No, I don't think it's "an absurd thing to say" -- it just doesn't have m= uch
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':

en=C2=B7close Audio pronunciation of "enclose" ( P ) Pronunciation Ke=
y (n-klz) also in=C2=B7close (n-)
tr.v. en=C2=B7closed, en=C2=B7clos=C2=B7ing, en=C2=B7clos=C2=B7es

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: =E2=80=9CEvery=
one of
those darkly clustered houses encloses its own secret=E2=80=9D (Charl=
es Dickens).

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


ref: http://dictionary.reference.com/browse/enclose


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 i=
t.
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: =E2=80=9CEvery=
one of
those darkly clustered houses encloses its own secret=E2=80=9D (Charl=
es 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 tha=
t
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
--=20
we can never obtain peace in the outer world until we make peace with
ourselves.
- h.h. the 14th dali lama

 

[ara.t.howard]

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

 

[Jacob Fugal]

Actually, if you go back and read David's post [ruby-talk:205331],
which is the first reference to hair splitting in this thread, you'll
see that he clearly believes both of the first two examples to be
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."

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 Fugal

 

[Chad Perrin]

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.

What current scope are you referring to here? If you mean the scope
that was current when the block was created, then why does that not
make it a closure? Why is self different than some other variable
named b? If you don't mean the scope that was current when the block
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?

Ok, we're using different definitions of function. That's why I put
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.

 

[Chad Perrin]

Actually, if you go back and read David's post [ruby-talk:205331],
which is the first reference to hair splitting in this thread, you'll
see that he clearly believes both of the first two examples to be
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."

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.

 

[ara.t.howard]

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

 

[Chad Perrin]

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?

 

[Chad Perrin]

On Wed, 2 Aug 2006, Chad Perrin wrote:
=20
=20
because 'enclose' does not imply 'closed forever':

We're discussing "closures", not "enclosures".

=20
en=C2=B7close Audio pronunciation of "enclose" ( P ) Pronunciation= Key =20
(n-klz) also in=C2=B7close (n-)
tr.v. en=C2=B7closed, en=C2=B7clos=C2=B7ing, en=C2=B7clos=C2=B7es
=20
1. To surround on all sides; close in.
=20
2. To fence in so as to prevent common use: enclosed the pasture.
=20
3. To contain, especially so as to envelop or shelter: =E2=80=9CEv= ery one of
those darkly clustered houses encloses its own secret=E2=80=9D (Ch= arles=20
Dickens).
=20
4. To insert into the same envelope or package: enclose a check wi= th=20
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.

=20
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 li= ke
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".

--=20
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
"There comes a time in the history of any project when it becomes necessa=
ry
to shoot the engineers and begin production." - MacUser, November 1990

 

[ara.t.howard]

. . .

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

 

[Jacob Fugal]

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.

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?

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


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 Fugal

 

[Jacob Fugal]

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 Fugal

 

[Chad Perrin]

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.

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]

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.

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

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.

 

[Eric Armstrong]

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.

On Tue, Aug 01, 2006 at 02:05:17PM +0900, Just Another Victim of the Ambient Morality 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?

 

[Eric Armstrong]

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

Thanks much for that!

 

[Eric Armstrong]

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.

 

[Chad Perrin]

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.

 

[Chad Perrin]

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.

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.

 

[Chad Perrin]

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.

Err, it seems self-evident to me, and I don't know how to make it
clearer.

 

[Eric Armstrong]

Bye bye.

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.