From: Jacob Fugal <lukfugl@...>
Date: 2006-08-02T05:19:38+09:00
Subject: Re: I thought this was the one that worked?

On 8/1/06, Chad Perrin <perrin@apotheon.com> wrote:
> On Wed, Aug 02, 2006 at 04:56:53AM +0900, Jacob Fugal wrote:
> > On 8/1/06, Chad Perrin <perrin@apotheon.com> wrote:
> > >Specifically, it sounds like what you're saying here would indicate that
> > >this is a closure:
> > >
> > >  def foo
> > >    bar = 0
> > >    lambda { puts bar += 1 }
> > >  end
> > >
> > >  baz = foo
> > >
> > >and this is a closure:
> > >
> > >  def foo
> > >    lambda { puts "Hellow world!" }
> > >  end
> > >
> > >  bar = foo
> >
> > Yes, this is exactly the point we've been trying to get across. Both
> > of these are closures.
> >
> > >but this is not a closure:
> > >
> > >  foo = 0
> > >
> > >  foo.each do
> > >    puts bar += 1
> > >  end
> >
> > This is where we get into what David Black described as hair
> > splitting. Lets move away from each, and to a set of more general
> > methods:
>
> Let's not.  Hair splitting actually came up in reference to the
> distinction between the first two examples, and not in reference to the
> third.

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.

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

> unless this is a case of "the Ruby community uses a definition of 'closure'
> that is in direct contradiction of other definitions of 'closure'"

I'll repeat myself: "Since the environment is never stored, it's not
really a closure *in the implementation*. This is the hair that David
was splitting.

"But semantically, whether a block is converted to a proc or just
yielded to, the behavior regarding variable scope is identical; so if
one is a closure, it's useful to refer to the other as a closure as
well, even if it's not implemented as a true closure. In this sense,
all blocks are closures."

As you can see, I've admitted that in the *one* case of a
non-converted block it is not a true closure. But I believe semantic
terms can be more useful than rigid and narrowly defined formal
theoretical definitions. Like duck typing -- as long as it quacks just
like a real closure, it's close enough for me.

Jacob Fugal

[ruby-talk:205331]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/205331