2. Each time a block with a 'my' declaration is entered, a new instance of that lexical is created, and each time the block is exited, that instance is discarded (of course, if something else holds a reference to it, then the actual thinbg itself continues to exist, it is just not accessible via the lexical name).

I think that's quite inaccurate.While that may be what seems to happen and it may be what should happen, that's not what really happens. Lexical variables are cleared on block exit and re-used unless there are still references to them.

That means

• Lexical variables aren't discarded and recreated. They are simply cleared.

• The clearing of a lexical variable occurs when the block is exited, not when it is entered. And only if the my was executed since the block was entered.

• A new variable is created if needed when the block is exited, not when it is entered. And only if the my was executed since the block was entered.

In more details,

• Perl_save_clearsv (scope.c in perl.git) is called when my is executed [via SAVECLEARSV (scope.h in perl.git) and pp_padsv (pp_hot.c in perl.git)]. It places a directive on the stack (SAVEt_CLEARSV) to clear the variable on scope exit.

• On scope exit, Perl_leave_scope (scope.c in perl.git) is called to unwind the stack. When the SAVEt_CLEARSV directive placed by the run-time execution of my is encountered, the variable is either cleared (if SvREFCNT(sv) <= 1 && !SvOBJECT(sv)) or replaced.

These details are somewhat visible in the following example:

sub test {
   my ($reset) = @_;
   my $x if $reset;
   print ++$x, "\n";
}

test(0);  # 1
test(0);  # 2
test(1);  # 3
test(0);  # 1
test(0);  # 2
[download]

Perl 5.8.8

I think that's quite inaccurate. Lexical variables are cleared on block exit and re-used unless there are still references to them.

That is an optimization, and the documentation specifically warns against relying on it as your example does.

The "discarded" doesn't mean literally freeing the pad SV. Here:

$ perl5.10.0 -we'{ my $x; sub foo { eval q!print $x! } foo }'
Use of uninitialized value $x in print at (eval 1) line 1.
$ perl5.10.0 -we'{ my $x; sub foo { eval q!print $x! } } foo'
Variable "$x" is not available at (eval 1) line 2.
Use of uninitialized value $x in print at (eval 1) line 1.
[download]

$x is logically discarded and hence "not available" after the scope is exited, even though the SV may still stay in the pad.

Lexical variables aren't discarded and recreated. They are simply cleared.

I think that ysth has adequately answered that objection, but I would answer it this way: All of that happens under the hood; it has no user-visible effects. In any way that a perl programmer can tell, perl behaves just as ysth has described.

A word spoken in Mind will reach its own level, in the objective world, by its own weight

I personally believe that ysth has adequately answered that objection, but I would answer it this way: All of that happens under the hood; it has no user-visible effects. In any way that a perl programmer can tell, perl behaves just as ysth has described.

s/ysth has described/dave_the_m has described/.

Also "has no user-visible effects" is an overstatement; should have no user-visible effects is more accurate. The rules describe how things should work; there may be bugs, and (as in the case of my $foo if 0;) there are things you can (but shouldn't) do to expose rule violations that for various reasons won't be fixed.

"3. At the creation time of a sub that references an outer lexical" as opposed to "3. At the creation time of a sub in scope of an outer lexical" is also an optimization that also has little user-visible effect.

ysth posted (in part) to explain the low-level details behind the sub { eval '$i' } problem.
I posted to explain the low-level details behind the my $i if $expr; problem.

I don't see my post as being out of place, although I'll grant you that my opening ("I think that's quite inaccurate.") could have been worded better.