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

> 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

[download]

> 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

Replies are listed 'Best First'.
Re^6: Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube
by ikegami (Patriarch) on Jul 31, 2025 at 23:16 UTC

    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.

[reply]
[d/l]
[select]
      > 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

[reply]
[d/l]

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

        No, it's not about protection. Quite the opposite. Capturing allows a variable to be manipulated beyond its normal lifetime. That reduces the protection the variable has compared to one that wasn't captured.

        Closures are about access and life-time. Capturing attaches data to functions. In a way, closures are similar to objects which attach functions to data.

[reply]

In Section Meditations