Thanks for the update/correction ... although saying that I'm wrong is merely semantics. The URL you point to leaves me with the impression that Larry is implying that this could change in the future - whether that is within Perl5 (as the implication at the time could have been) or Perl6, is left open. Given that, I would suggest that any statement implying that this code "works" is misleading. It happens to work with a current version of perl, but is open to breakage under newer versions of perl (including PONIE), with Larry not sounding too concerned about it.

I'm somewhat curious if intervening memory usage could clobber this trick - e.g., calling IsMatrix early, then using 200MB of memory, then coming back and calling IsMatrix a second time. Or does this trick make Perl think it's static (closed-off scope with lexical references in a global sub), thus leaking memory where, without the if 0, it would not be a memory leak? (I realise that "memory leak" is debatable here.)

No, that's not how Perl manages memory. I've dug into this code lately, so here's a slightly fuller explanation that only has a few oversimplifications (as far as I know).

When Perl compiles a subroutine, it attaches a couple of arrays to the subroutine. These are lexical pads. The first array holds several other arrays. The first contained array holds the names of all lexical variables. The second contained array holds the values of all lexical variables. (I believe subsequent contained arrays hold values on recursion, but I haven't dug that deeply.)

The compile-time effect of my is to create an entry in the pad, storing the appropriate name in the first contained array and making a space in the second contained array for the value of that lexical variable.

The run-time effect of an assignment to a lexical variable is to store the appropriate value in the second contained array. If there's a conditional, though, that assignment won't happen.

For reasons of optimization, I believe that Perl doesn't reset all elements in the contained arrays to undef when it leaves a subroutine. Thus if your assignment doesn't happen due to a false conditional, you could see an old value persist through invocations.

As far as I know, the memory won't change location; if you use up megabytes of heap memory elsewhere, there should be no effect on the lexical pads unless you exhaust all real and virtual memory and then you have bigger problems.

It cannot be clobbered, and there are no memory leaks in either case. It's an effect of how the pads for lexical variables are maintained by the Perl core. Larry didn't want to promise this will always work, but it's very unlikely to break, since it's kind of an accidental feature of the Perl guts architecture. A lot would have to change to break it.

Makeshifts last the longest.

It may very well be gone someday in perl5. Really. Don't use it. Also note that the staticness is relative to the pad, not the function; for instance, the data does not persist for recursive calls to the function.