in reply to Re^3: Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube
in thread Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube

I think one should always give the source when citing a quote.

I did.

Your definition seems to say that a function using global variables

Odd. Did I even even provide a definition?

I'm certain I didn't come remotely close to opining about whether globals are captured or not.

And you seem to be referring to package vars, which aren't global. Only punctuation vars and a few others deserve that name (ARGV, STDOUT, ENV, SIG, etc).

Replies are listed 'Best First'.
Re^5: Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube
by LanX (Saint) on Jul 31, 2025 at 20:10 UTC
    > I did.

    Mea culpa, my phones display is broken.

    Still that's the opinion of a WP-author, not an original source or "historical ... definition"

    > Odd. Did I even even provide a definition?

    Well you literally said so:

    > > > historical and generally accepted definition.

    and then

    > > > "whose non-local variables have been bound"

    and package vars are "non-local".

    And than I pondered about the possible meaning of "binding" in Perl.

    to be more explicit

    :~$ perl -MO=Concise,Bla::func -E'package Bla; sub func { say $x }' Bla::func: 5 <1> leavesub[1 ref] K/REFC,1 ->(end) ... yadda yadda 3 <#> gvsv[*Bla::x] s ->4 # <--- is thi +s a binding? -e syntax OK

    > And you seem to be referring to package vars, which aren't global.

    Oh my holy lord of the nitpickers ... the full qualified names are globally accessible.

    This means that package vars can be manipulated outside the sub.

    > Only punctuation vars and a few others deserve that name (ARGV, STDOUT, ENV, SIG, etc).

    And those are just implemented as package variables in main:: , b/c any other surrounding package declaration is just ignored.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    see Wikisyntax for the Monastery

      Still that's the opinion of a WP-author, not an original source or "historical ... definition"

      No, Wikipedia pages are not one author's opinion. And did you read the page? It gives the history of the term.

      Well you literally said so:

      No, as you said, that came from Wikipedia.

      And than I pondered about the possible meaning of "binding" in Perl.

      Fair. But not fair to say I claimed package vars are captured.

      Oh my holy lord of the nitpickers

      You are wrong.

      In normal circumstances, I call file-scoped my vars global, and so do many others. And others do the same for package vars.

      Neither are actually global, but that's perfectly fine in *those* situations. But clarity *is* required here.

      To what combination of file-scoped my var, package vars, and actual globals are referring when you say globals?

      And let's not forget that what appears to your example of a global variable uses our, which creates a lexically-scoped variable.

      So yeah, if you're going to ponder what constitutes a capture, requesting some specificity isn't nitpicking.

      And those are just implemented as package variables in main::

      True, but irrelevant. What makes them global is that they can be accessed from anywhere. This is not true of arbitrary variables in the root/main namespace.

        > True, but irrelevant. What makes them global is that they can be accessed from anywhere.

        All package variables can be accessed everywhere. As I said

        > > This means that package vars can be manipulated outside the sub.

        > your example of a global variable uses our, which creates a lexically-scoped variable.

        Now this is indeed "irrelevant". They create a lexical alias to a package var.

        They are still globally accessible via full-qualified name.

        > And did you read the page?

        I even cited the original sources.

        Anyway ...

        ... my original question wasn't answered, if "a function using global variables (which are "non local") is a closure"

        Given that the original sources talk about binding "free variables" which are "bound" I tend to say "kind of". They are bound in the Perl's Op-Tree to their symbol table entry.

        But a (the?) central idea of closures is that of encapsulation and protection of those variables from external manipulations and other side effects. And this is not given with with package variables.

        A way out of this conundrum is to realize that Perl is not Lisp, and that "Closure" in Perl's context is a short for "lexical closure".

        Let's have a look what Larry says in Perl Glossary

        • Closure 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. They’re called “closures” because this sort of behavior gives mathematicians a sense of closure.
        I disagree about the "anonymous", a closure doesn't loose it's features if we name it a posteriori like with *name = $sub_ref

        But this definition is certainly stressing the "lexical" character of closures, with variables which survive even out-of-scope.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        see Wikisyntax for the Monastery