Re^8: Unclear about 'our'

> Personally, I tend to think of closures as something you can make multiple instances of

That's a further concept, building on top of closures.

In what you show foo is a "generator" returning an anonymous sub, which is indeed enclosing $x ... but that's not necessary for a closure.

A "closure" is the combination of a sub and "enclosed"° vars from the outer scope.

you don't need generators for closures...

see also Closure (computer programming) : "Operationally, a closure is a record storing a function together with an environment."

But it's true that many - including me - often simply say "closure" for the "closure function"

> but if the code you showed was in a block, then I guess that can fit the definition of a closure too

an explicit block is just cosmetics, since the file-scope acts as a default block.

> since the subs are then the only thing to hold references to the variables.

That's bit confusing ... a sub will only hold reference to a variable form a surrounding scope if it's enclosed, i.e. explicitly used. You don't need a block to enforce this.

Consider this example, where the second bar() will fail because there is no explicit use of $var, just a symbolic reference.

Since it's not bound - here realized as the scratch pads of the sub increasing the ref-count - it can be destroyed.

NB: I just need the block here because all calls are in the same file.

use v5.12;
use warnings;
use Data::Dump qw/pp dd/;

{
    my $var = 42;

    sub foo {
        warn $var;
    }

    sub bar {
        eval 'warn $var';
    }

    foo();
    bar();
}

foo();
bar();
[download]

42 at c:/tmp/pm/closure_demo.pl line 9.
42 at (eval 1) line 1.
42 at c:/tmp/pm/closure_demo.pl line 9.
Variable "$var" is not available at (eval 2) line 1.
Use of uninitialized value $var in warn at (eval 2) line 1.
Warning: something's wrong at (eval 2) line 1.
[download]

Cheers Rolf
_{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :)

Wikisyntax for the Monastery}

updates

°) lexical vars in this case, package vars are just globally available...

Comment on Re^8: Unclear about 'our' Select or Download Code

Replies are listed 'Best First'.
Re^9: Unclear about 'our' (updated) by haukex (Archbishop) on Dec 29, 2022 at 11:24 UTC
an explicit block is just cosmetics, since the file-scope acts as a default block. I'd be surprised if the definition of a closure really is that broad, but I don't have the time to research in detail right now. Update: To clarify: I did skim the Wikipedia article before posting and it makes it pretty clear to me that definitions differ, so I suspect that simply our definitions differ. In the context of Perl, perlglossary does say that a closure is "An anonymous subroutine that, when a reference to it is generated at runtime, keeps track of the identities of externally visible lexical variables, even after those lexical variables have supposedly gone out of scope." Update 2: Ok, so I did do at least a little bit more research. The above definition of a closure is repeated across much of the Perl documentation, but then there's Persistent variables with closures that shows a named `sub` that is closer to what you showed. So like I said, I guess definitions differ.	[reply] [d/l]
Re^10: Unclear about 'our' (updated) by LanX (Saint) on Dec 29, 2022 at 12:15 UTC
In Perl it's trivial to make an anonymous sub a named one and vice versa. So what? And I think the example I showed proves my point, that the var from the outer scope is bound to the sub. > In the context of Perl, perlglossary does say that a closure is "An anonymous subroutine that, One of my biggest problems with the perldocs is that it's a collection² from different authors and sources. I like to quote `perlglossary` myself, because it's from Larry himself. But it's from the appendix of one of his books. And he sometimes values easy wording with puns over being consistent. (update: phrase reworded) But the implementation of lexical closures is the same for all subs. I envy other languages which have a more formal approach to language definition. The ECMA process dragged JS out of the mud. And those PEP discussions in Python look³ decent. AFAIK was closure invented in the context of Lisp, hence well° defined there. updates °) another extreme is PHP where "closure" always means (meant?) "anonymous sub", no matter if there are any vars involved. (I think they fixed the docs in the meantime, but this should prove my point that docs can't always reinvent fixed terminology) ²) inconsistent ³) "at least look" (I can only judge by the optics here) Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply]
Re^9: Unclear about 'our' (Generators) by LanX (Saint) on Dec 29, 2022 at 18:22 UTC
> In what you show `foo` is a "generator" returning an anonymous sub, I have to somehow correct myself, because I can't find this definition of "generator" anymore. Maybe I saw it in HOP. I tried to reference WP, but Generator (computer programming) refers to something different. That's the `yield` concept from Python (gather-take in Raku), which is not a closure maker, but syntactic sugar for an iterator. Looks like the programming world is taking over the Python interpretation, ECMA6 introduced yield too. Cheers Rolf _{(addicted to the 𐍀𐌴𐍂𐌻 Programming Language :) Wikisyntax for the Monastery}	[reply] [d/l] [select]