Re^9: Unclear about 'our' (updated)

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.

Comment on Re^9: Unclear about 'our' (updated) Download Code

Replies are listed 'Best First'.
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]

Replies are listed 'Best First'.

Re^10: Unclear about 'our' (updated)
by LanX (Saint) on Dec 29, 2022 at 12:15 UTC

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]