#!/usr/local/bin/perl
use strict;

my $dave = subref("dave", "oranges", "grapefruit");
$dave->("debug message");

sub subref {
        my (@stuff) = @_;
        return sub { doit(@stuff, @_) }; # <-- closure here?
}

sub doit {
        print shift, ": ", join(",", @_), "\n";
}
[download]

my $foo;

sub bar {
    $foo++;
}
[download]

It really is a closure :)

The key is that the array @stuff are only supposed to exist while new() is the current scope. But by declaring a subroutine reference that uses @stuff you are forcing perl to not garbage-collect it at the end of new()'s scope. However, the only way you can now touch this array which is in limbo is through the subroutine reference which you returned from the subroutine new().

At this moment you may wonder why not just use an object, then you aren't just limited to one method, and it is not like a class is a lot of overhead.

The answer is that someone can turn around and say, "Oh, I need a new kind of closure here" and inline it very easily within a function. (Frequently you parametrize different kinds of functions.) Creating a class is (relatively) a lot more infrastructure and verbiage.

The key words for most of the basic uses are "callback" and "handler". The callback idea is that you have people pass you some anonymous functions into your function, and then you call them at appropriate moments (sort of what you use method hooks for in OO design but you don't need to set up a class, an object, etc). The handler idea is that you set up various functions that will handle various specific cases, and when you encounter the cases you just call the handler and let it take care of things.

(It is not uncommon for what you think of as callbacks you pass into a function be handlers inside of it.)

A specific example to look at is ReleaseAction which very clearly shows how, once you have a little infrastructure code, you can do something you would normally do with a class without writing a class each time.

sub new {
   my ($class, @stuff) = @_;
   return bless sub { doit(@stuff, @_) },$class;
}
[download]

Now, if you want what i consider to be a good, everyday, pratical solution that uses a closure (not just a crazy way to make eyes go cross-eyed), then check out (the recently renamed) (jeffa) Practical Use For What jeffa Thought A Closure Was (3Re: Style Question on Closures). There are, of course, many more practical uses for closures ... this one has served me well, and i really think that it is easy to understand.

UPDATE: nope - i am wrong again. Sorry mr.dunstan. Thanks for the catch perrin.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

That's a good example of using code refs, but it's not a closure. There are no private variables (unless I missed something there).

That's a good example of using code refs, but it's not a closure. There are no private variables (unless I missed something there).

The anonymous routine (blessed or not) refers to a lexically-scoped variable in its enclosing scope. That lexically-scoped variable is magically kept alive (in the anonymous subroutine) after that enclosing scope has been exited. That is what makes an anonymous subroutine a closure.

sub makeAnonymousSub {
    sub { print "I am not a closure\n" }
}

sub makeClosure {
    my $x = shift;
    sub { print "I keep $x alive, thus I'm a closure\n" }
}
[download]


Update: This is in agreement with perrin, btw. I'm just filling in some details...

Hey! I was thinking something along those lines, just because the variables themselves are not declared -within- the closure ... only near it?

I am thinking this means:
1) There is no spoon, I mean closure.
2) That's a closure, but not an academic example of a closure.
3) Mr. Dunstan, you are mincing words to gain karma.

Zuh? -mr.dunstan

Data::Dumper is going to give out "DUMMY" as the value for any sub, not just a closure. The contents of a subroutine are represented internally with a variety byte code I believe, which would look like so much nonsense if it were printed in the contents of a Data::Dumper dump. Contrast to scalars (or hash keys or hash/array values made from scalars) and to references. Scalars eventually turn out to be some sequence of characters, and references inside a data structure can be represented with brackets and braces.

'perldoc Data::Dumper' has more info on this in the BUGS section.

As to "[t]he contents of a subroutine [being] represented internally with a variety [of] byte code", you're both right and wrong (as is so often the case when talking about internals). The internals do deal with coderefs as pointing to a bunch of bytecode, but that bytecode is not inherently serializable; it has lots of pointers in it. Moreover (without resorting to Devel:: or B:: modules), it isn't accessable with Perl code.

The perl6 analog of Data::Dumper will be able to dump coderefs as Parrot assembler (pasm); one of the cool side-effects of going to an explicit VM.

Thanks,
James Mastros,
Just Another Perl Scribe

Closure and anonymous sub -- two totally different things! An anonymous sub is a ref to a sub without a name. A closure is any sub (named or not) that refers to lexical variables defined outside of its scope.

Nearly. An anonymous sub is a sub without a name that can only be accessed via a reference (to that sub).
--

g r i n d e r
print@_{sort keys %_},$/if%_=split//,'= & *a?b:e\f/h^h!j+n,o@o;r$s-t%t#u';