Re^7: Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube

[LanX]

> 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.

[ikegami]

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.

[LanX]

Did you read the original quotes explaining the etymology?

see Re^3: Yet Another Program on Closures ~ Steven Lembark ~ TPRC 2025 - YouTube (UPDATE Etymology)

> ... as a porous or an open covering of the function since free variables escape to the current environment. FUNCTION acts as a closed or nonporous covering (hence the term "closure" used by Landin).

[ikegami]

I have now. The paper/quote shows that the closure uses a captured environment ("binding environment") instead of the environment that exists where the closure is called ("activation environment"). The environment of a closure is therefore fixed ("closed"). And that this is the source of the name closure.

Did *you* read it? Cause it defines a closure in terms of what variables it can access, just like I said.