Yes it is a closure. There is some ambiguity in the perl world about the word closure. For various reasons there isa tradition of using the word "closure" as a synonym for "anonymous sub". However the basic fact is that your subroutine addone() is a closure around the $i in the block. Try using Data::Dump::Streamer on \&addone and note that the $i will be dumped. DDS uses the internal structure of the subroutine to do its thing so this is a definitive check. If DDS doesnt dump any vars external to the subroutine then the subroutine is not a closure. If it does then it is a closure.

Where the problem arises is that the type of closure you have in the example is so trivial that it can be just as easily explained in terms of a non-closure based behaviour, that of static storage. However a close inspection will show that the code does not behave as you might expect if it really was using static code. Consider what happens if we have a call to the sub prior to the initialization of the var it binds to. Something like the following:

use Data::Dump::Streamer;

my $x=counter();
{
    my $i=1;
    sub counter { my $r=$i; $i++; $r };
}

Dump($x,\&counter)->Names(qw(x *counter))->Out();
__END__
my ($i);
$i = 1;
$x = undef;
sub counter {
  my $r = $i;
  ++$i;
  $r;
};
[download]

As you can see the value of $x is undefined. This is because named subroutines are compiled and bound to the vars they enclose at compile time. But any initialization happens at run time. If you wrapped this code in a loop you would not get a new var every time. Compare that to this:

use Data::Dump::Streamer;

{
    sub make_counter { my $i=shift; return sub { my $r=$i; $i++; $r } 
+};
}

my @counters=map { make_counter($_) } 1..5;

Dump(\@counters);
__END__
my ($i,$i_eclipse_1,$i_eclipse_2,$i_eclipse_3,$i_eclipse_4);
$i = 1;
$i_eclipse_1 = 2;
$i_eclipse_2 = 3;
$i_eclipse_3 = 4;
$i_eclipse_4 = 5;
$ARRAY1 = [
            sub {
              my $r = $i;
              ++$i;
              $r;
            },
            sub {
              my $r = $i_eclipse_1;
              ++$i_eclipse_1;
              $r;
            },
            sub {
              my $r = $i_eclipse_2;
              ++$i_eclipse_2;
              $r;
            },
            sub {
              my $r = $i_eclipse_3;
              ++$i_eclipse_3;
              $r;
            },
            sub {
              my $r = $i_eclipse_4;
              ++$i_eclipse_4;
              $r;
            }
          ];
[download]

As you can see each subroutine gets bound to a different $i (renamed by DDS to $i_ecplise_N because the various $i's are "eclipsed" by each other and DDS isn't smart enough to figure out the scoping required to de-ecplipse them). This behaviour occurs only with anonymous closures for arcane reasons in the perl internals. But its this behaviour that makes closures really interesting, so the confusion is not that hard to understand.

Anyway, a "closure" is just a subroutine that is "bound to" or "encloses" vars declared external to itself. Its a special type of reference containment that does not occur by membership of a composite but because of its use in the code of the subroutine. So if a subroutine does not refer to lexical variables that were declared outside of its body it is not a closure. If a subroutine does refer to lexical variables that were declared outside of its body then it is a closure. Note that this is strictly lexicals, its not globals (use vars qw(); or our($vars)) as globals are like symlinks, they refer to a name of variable and not the variable itself. Thus a subroutine does not bind to globals it binds to the globals name, which isnt the same thing as with lexicals where the compiler doesn't actually care what the called once the compile phase is complete, in fact the var names are only tracked for convenience (such as debugging).

I bet this was far more than you wanted to know but I hope its been more englightening than confusing.

If demerphq's great post lost you, let me try a simpler example. There's really no difference between an "anonymous" closure and one that isn't. I think it's really a misnomer in the perl docs to link it so closely to anonymous functions. I read somewhere (looked but couldn't find the reference) that the sub keyword is really just doing this behind the scenes (apart from forward declarations, anyway):

sub foo { print "hello world" };

# more or less equivalent to:
BEGIN {
  *foo = sub { print "hello world" };
}
[download]

The reason that such a distinction is made between "regular" subroutine declarations and anonymous subroutine declarations is that most of the utility of having closures in the language comes from applying them to anonymous subroutines that are assigned multiple times on the fly.

Consider the following example with simple counters. The anonymous subroutine created in the counter_gen subroutine is compiled only once, but each time counter_gen is called, the resulting reference winds up using a different copy of $j. The anonymous subroutine gets a copy of the lexical environment at the time it is assigned. This allows me to create two counters with different starting points using the same code. However, in usage, they work just like the regular, named counter created earlier.

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

my $i = 1;
sub counter_i { $i++ }

sub counter_gen {
    my $j = shift;
    return sub { $j++ }
}

my @counters = ( \&counter_i, counter_gen(5), counter_gen(10) );

for ( 1 .. 10 ) {
    for my $c ( @counters ) {
        print $c->(), " ";
    }
    print "\n";
}
[download]

Prints

1 5 10
2 6 11
3 7 12
4 8 13
5 9 14
6 10 15
7 11 16
8 12 17
9 13 18
10 14 19
[download]

yes, it is a closure.

Talking about books, Object Oriented Perl (among others) by Damian Conway also treats them, if you are interested.

Cheers, Sören

Explanation: Objects are data associated with subroutines. Inside-out Objects (or closures) are subroutines associated with data.

See Achieving Closure.

Closures are sometimes called "inside out objects."

Hmm, interesting. I've always associated the term "inside out objects" specifically with the technique of using closures as the implementation of an object's storage, instead of storing data directly in the object (as described ably in Re: Tutorial: Introduction to Object-Oriented Programming).

But your usage of the term certainly makes sense, and seems more generally applicable. Now I wonder which one came first? I have a feeling it's the more general definition, but I'm curious if anybody out there knows for sure?

Closues are sometimes called "inside out objects."

By whom? I know 'inside out objects' as a technique to store object attributes in lexical, class-wide, hashes - one hash per attribute.

No closures involved.

Perl --((8:>*

Simon Cozens... see the article I linked to above.

Since this terminology seems to be at least slightly controversial, and I'm not 100% sure about my understanding, and this whole thread is about "nailing down" perhaps you could link to something beginner-oriented that espouses your views of inside-outs?

No closures involved.

Why do you need object attributes then if you never use them?

Going by the code you have posted elsewhere your InsideOut attribute handlers are actually closures. At least iirc, you use lexical hashes to store the attribute values and these hashes are declared outside of the subs that reference them, therefore those subs are closures. (Dump one of them with DDS and see what happens).

---
$world=~s/war/peace/g

By whom? I know 'inside out objects' as a technique to store object attributes in lexical, class-wide, hashes - one hash per attribute.

See this post for one example.

I don't think it's original to Barrie though. It's a analogy I've come across several times outside the Perl world in either direction (closures are inside out objects, objects are inside out closures) depending on who knows what.

Not that I think it's a particularly good analogy mind...

(defun foo (n) 
   (labels ((f (i) (+ i m)))
           f)
)
[download]

sub foo {
   my $n = shift;
   sub f { 
       my $i = shift;
       return $i+$n;
   }
   return \&f;
}
[download]

sub foo {
   my $n = shift;
   my $f = sub { 
       my $i = shift;
       return $i+$n;
   };
   return $f;
}
[download]

But this will not work, because the inner sub "f" is really global and the closure won't behave like you want it to. The solution is to make f anonymous:

This may be of some relevance here...

No, the result is 4! It certainly prints 4 on my machine.

The closure variable $i is initially set to 1, gets incremented by addone, then added to the parameter $y, which is 2. Answer 4.

Actually, the output is:

Global symbol "$i" requires explicit package name at ./z.pl line 13.
Execution of ./z.pl aborted due to compilation errors.
[download]

Try some more tests - e.g., move the $i=10 line inside the braces, and suddenly you'll get 13. That's because you're now affecting the same lexical $i that addone is using. Hopefully that will help cement the idea :-)

Note that not all anonymous subs are closures. That's just one really great use of anonymous subs. For example:

use File::Find;
find(sub { rmdir $_ || unlink $_ }, @ARGV);
[download]

The wikipedia definition could use a little explication. So a closure is a procedure and an environment in which to execute that procedure (the environment of the program at the time the closure is created). This is irrespective of whether or not the closure is bound to a name or is anonymous, whether the environment is empty, or contains bindings.

So what's an environment? The 'lexical environment' is what the procedure uses to look up variable references. In other words, a symbol table, a mapping between symbols and values. Naturally, variable declarations add to/pollute the environment. Going back to your case above, the addone closure's environment could be represented as a hash of 'i' => 1. The environment could be affected by many things, import declarations in Java/Scheme, using namespace in C++, #include <foo> in C, use Food::Bare, declaring more variables, etc. Now, let's say addone didn't have a reference to $i - then it's local environment would just happen to be empty.

Using this definition of closure, every procedure or sub you write is a closure. In the addone example, there are two bindings for $i, one in the closure's local environment (which is checked first), and another in the top level environment, when you set $i=10. When you invoke addone, we first check the environment packaged up with the addone closure for an entry for $i. We find that there is an entry for $i=>1, we increment that local entry for $i, (which doesn't affect the outer lexical environment's entry for $i=>10), and then return $i + 2.

If this is the definition of closure you're more interested in, you should definitely learn more about free and bound variables and scoping and its effects on the environment. Maybe learn Scheme, even ;-).

Hope that helps!

Allen

Using this definition of closure, every procedure or sub you write is a closure.

I don't think using this broad a definition helps clarify the term or how closures are used in Perl. Within Perl at least, the term "closure" refers to a subroutine that references lexical variables outside it's own scope. This has a very specific meaning and a very specific application.

# doesn't reference anything outside the scope of the subroutine scope

sub not_a_closure {
  my $i;
  $i++;
  return $i
}

# references a package variable, not a lexical variable

our $global;
sub also_not_a_closure {
  $global++;
  return $global;
}

# a closure -- references a lexical outside the scope

my $lexical;
sub a_closure {
  $lexical++;
  return $lexical;
}

# anonymous closure generator -- references a new variable each time

sub closure_generator {
  my $fresh_lexical;
  return sub {
    $fresh_lexical++;
    return $fresh_lexical;
  }
}
[download]

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

This is a pretty late reply ;-).

I feel that you may be missing the point. Let's say you are writing an interpreter for a language with closures and have to come up with an exact specification of how code using closures should run. Well, language designers need to guarantee reasonable, consistent behavior when a programmer passes functions around - namely, if those functions have free variables, how should those free variables be resolved? It so happens that there is a reasonable, consistent, way to implement function passing, and it involves creating this notion of a closure, which is executable code + some data (the environment) that you use to resolve any free variables within the executable code, if need be. It all boils down to a construct that language designers came up with to formally describe what happens when you pass functions into other functions.

Ask yourself - does Perl really need its own personalized definition of a closure? Why not use the one that's already in use in the PL community?