Re: Functional Programming & method rewriting

[revdiablo]

The observant will note the doubly nested closure

It's me again! I'm sure you'd rather not hear any more comments from revdiablo, but I'd like to point out something I observed in another post in this thread.

This is not a double closure, it's just a single closure that uses anonymous subroutines. The inner subroutines do not close around anything, because they are not stored anywhere. They are created and destroyed each time they are used. They never get a chance to create a closure.

Update: I guess this really depends on your definition of "closure". As I said in a reply to our good friend AnonyMonk, I don't generally use the hyper-technical definition that a closure is "anything that closes around a lexical", because that's true of any subroutine that is in a lexical environment. Which, if you're using lexicals in Perl, is all of them.

I prefer to think of closures as subroutines that actually use that lexical environment for more than one invocation. I think this captures the meaning most people think of, as well as a meaning that is actually useful for something.

[ihb]

About closures.

I don't generally use the hyper-technical definition that a closure is "anything that closes around a lexical", because that's true of any subroutine that is in a lexical environment.

I'm not sure how to interpret you, but it seems we view things differently. Either way a clarification probably would serve well. My definition of a closure in Perl is a subroutine that (deeply) binds a lexical variable. Whether it's called once or twice or a thousand times isn't relevant.

{ my $foo; sub foo { 1 } }      # not a closure
{ my $foo; sub foo { $foo } }   # a closure

It's not about being "hyper-technical", it's about getting at the essence of what a closure is. That the bound variables doesn't go out of scope doesn't make it less of a closure, but its closureness doesn't get used. I understand that this is your point and I can almost sympathize with it, but just almost. It would be very confusing if a subroutine first wasn't a closure, but then became one when it was returned or assigned to variable with a broader scope.

Your point is supported by that we don't usually call &foo in

my $GLOBAL = 1;

sub foo {
    ... ; 
    ... $GLOBAL ... ;
    ... ;
}

a closure. However, it is a closure and it's not wrong calling it one.

ihb

[revdiablo]

First off, I want to thank you for actually engaging in a conversation, rather than simply writing me off as whiney and pedantic. I posted about something that I wanted to discuss, not just whine about. :-)

That it doesn't go out of scope doesn't make it less of a closure, but its closureness doesn't get used.

Indeed, that's true. I suppose I shouldn't try to fight against the technical definition. Rather than saying it's not a closure, I should have said it's not very useful to talk about its closure-ness.

However, it is a closure and it's not wrong calling it one.

Ok, fair enough. I officially change my position on the matter. Again, thank you for responding. I hope our friend SpanishInquisition is not too upset about the matter to read what I've written here, so he won't think I'm a completely horrible person.