There's no sane way in which perl could handle a call to b() from the outside.

However there's nothing wrong with defining an anonymous subroutine inside another sub. Actually it's quite common, and used very often in functional programming.

Those two points are related: logically, any call to a() would redefine b() in that code, like my example below, which would only be silly. Also, that would mean that you couldn't call b() before calling a() at least once. But named subroutines are defined only once, at compile time*, which makes the whole construct iffy.

sub a {
    my $x = 3;
    *b = sub {
        print $x, $/;
    };
}
[download]

* The reasoning behind sub NAME { } constructs being realized early is so that you can call subroutines even if their definition is "later" in the code.

That's mostly true, but not very precise.

If a subroutine is defined after it is called, the call has to use parenthesis. If it doesn't, it's interpreted as a string literal (or as an error if strict subs are in effect).

$ perl -E 'say 1, foo; sub foo { 3  }'
1foo
$ perl -E 'sub foo { 3 }; say 1, foo'
13
$ perl -E 'say 1, foo(); sub foo { 3  }'
13
[download]

However it the call uses parenthesis, there's no need it has to be know at compile time at all:

$ perl -E 'eval "sub foo { 3 }"; say 1, foo();'
13
[download]

But I think for this discussion it's more important to ask when the lexical pad of sub a is being built and destroyed. As long as the a is not part of the call chain, $x is in no lex pad, and sub b can't work in a meaningful way.

Perl 6 - links to (nearly) everything that is Perl 6.

If a subroutine is defined after it is called, the call has to use parenthesis.

Not quite. If a subroutine is declared after it is called, the call has to use parenthesis. You can always define it afterwards.

>perl -wle"sub foo; foo; sub foo { print 'Hi!' }"
Hi!
[download]

Granted, it's very rare for a subroutine to be declared somewhere other than when it's being defined.

I consider it a bad idea to define a named sub within another sub

I agree 100%. Anon subs are another story. For example, I use constructs such as

sub foo {
    my $shared_with_all_recur = ...;

    local *_recur = sub {
        ...
        _recur(...);
        ...
    };

    _recur(...);
}
[download]

Aside from the fact that the approach given in your reply is 'cleaner' and therefore, to my mind, preferable to something like

sub foo {
    my $shared_with_all_recur = ...;

    my $_recur;
    $_recur = sub {
        ...
        $_recur->(...);
        ...
    };

    $_recur->(...);
}
[download]

is there any advantage to using a localized glob rather than a lexical scalar?

It leaks memory.

use Devel::Peek;

sub foo {
    my $_recur;
    $_recur = sub {
        $_recur->();
    };

    my $x;

    Dump($x);
    Dump($_recur,0);
}

foo();
[download]

SV = NULL(0x0) at 0x182a4d4
  REFCNT = 1
  FLAGS = (PADMY)
SV = RV(0x182a1e0) at 0x182a1d4
  REFCNT = 2
  FLAGS = (PADMY,ROK)
  RV = 0x2381a4
[download]

Compare the refcount of $x (which will get freed) to $_recur's (which won't).

The problem is that the sub referenced by $_recur captures $_recur, and thus you have a memory loop. If you wanted a lexical, you would need to use

sub foo {
    my $shared_with_all_recur = ...;

    my $_recur;
    $_recur = sub {
        ...
        $_recur->(...);
        ...
    };

    $_recur->(...);

    undef $_recur;
}
[download]

This is a lot messier.