Re^2: Nailing down closures!

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.

Comment on Re^2: Nailing down closures! Download Code

Replies are listed 'Best First'.
Re^3: Nailing down closures! by oylee (Pilgrim) on Oct 04, 2006 at 02:45 UTC
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?	[reply]

Replies are listed 'Best First'.

Re^3: Nailing down closures!
by oylee (Pilgrim) on Oct 04, 2006 at 02:45 UTC

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?

[reply]