On Wed, Aug 02, 2006 at 05:33:50AM +0900, Jacob Fugal wrote:
> On 8/1/06, Chad Perrin <perrin / apotheon.com> wrote:
> >On Wed, Aug 02, 2006 at 05:07:33AM +0900, Jacob Fugal wrote:
> >> On 8/1/06, Chad Perrin <perrin / apotheon.com> wrote:
> >> >In any case, this can happen in Ruby:
> >> >
> >> >  class Foo
> >> >    def bar
> >> >      lambda { puts "quux" }
> >> >    end
> >> >  end
> >> >
> >> >  foo = Foo.new
> >> >  bar = foo.bar
> >> >
> >> >  bar.call
> >> >
> >> >. . . so I don't see your point.  Cut out the middleman, and it still
> >> >works.
> >>
> >> Ah, but you're still using self in that example. Who is the receiver
> >> of the call to puts inside the block? It's self.
> >
> >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 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.

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?


> 
> >> There is no such thing as a "function" in ruby; they are all methods.
> >
> >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.

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.

-- 
CCD CopyWrite Chad Perrin [ http://ccd.apotheon.org ]
Brian K. Reid: "In computer science, we stand on each other's feet."