[latk]

In the end, everything is syntax. In the first solution, the inner sub would be called as "$inner->()" or "&$inner()". With lexical subs, we get the much nicer syntax "inner()". This decreases the syntactic pain when structuring your code to use nested functions, thus encouraging good design.

Oh, and I guess lexical subs can have prototypes, which were ignored when calling a coderef with `&` or `->()`. This allows to create really nice, but properly scoped pseudosyntax.

[jerf]

"This allows to create really nice, but properly scoped pseudosyntax."

OK, I can think of some chunks of code I've written where that would make modest sense.

While my benefit/cost threshold for adding a syntax feature is generally much higher than the Perl team's (... much, much higher...), this does seem to fit in with their other additions then. Thanks.

[chromatic]

That feature's been on the wishlist for many, many years. It was also one of the early features specified for Perl 6, if that means anything.

[prollyignored]

> This decreases the syntactic pain

    use 5.018;
    no warnings "experimental::lexical_subs";
    use feature "lexical_subs";

Don't use perl experimental features. Not portable. Not well thought.

May break horribly.

"state sub creates a subroutine visible within the lexical scope in which it is declared. The subroutine is shared between calls to the outer sub."

So you should be using "state sub"

Or use python which has non-experimental "inner functions"

[latk]

You make some very good points esp. wrt verbosity. However, I don't care about portability or not using experimental features for personal or exploratory projects: stability is silver, conciseness is gold. The "state" subs are a consequent extension of the variable declaration keywords "my", "state", and "our". I can see myself using "my subs" in the future, the other possibilities have less practical use. "my subs" are proper closures, so they are not shared.

But, somebody will probably write a "lexsub" pragma that does away with the "no warnings ...", and portability becomes less of an issue over the course of time, much like I can nowadays treat the features of v5.10 as given.

Perl had nested functions since v5, just with akward syntax. Does Python have proper <del>variable declarations</del> closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

[jerf]

Because accessing an "uninitialized" variable is a crash, rather than an implicit value, Python's need for "proper" variable declarations is much less than in a language that will happily just fill in a value. It may not be quite as good as proper Perl "use strict", but it's much closer to that level of goodness than Perl without "use strict". Python has seen fit to introduce a "use strict" for that very reason; Perl was in a world of hurt before it, Python is manifestly not.

I scare-quote "uninitialized" because what it really is is nonexistant, which isn't the same thing.

[btilly]

Perl had nested functions since v5, just with akward syntax. Does Python have proper <del>variable declarations</del> closures? That is more of a dealbraker than non-experimental nested function syntax for me ;-)

Python has had proper closures forever, just with awkward syntax. But there is nothing you can do with closures in Perl that I can't translate directly into Python code that does the exact same thing in the exact same way. (I may need to switch from a scalar to an array with 1 element so that modifications in a child scope are visible in the outer, but conceptually things remain the same.)

I'm not saying that you should use Python - I switch it up but Perl is my goto language - however you shouldn't spread incorrect rumors about Python.

[eru]

> Or use python which has non-experimental "inner functions"

Or most languages in the ML family (like OCaml or Haskell), where multi-argument functions are actually implemented as a series of nested one-argument functions.