Sorry to all the previous commenters, but they're all wrong. Tanktalus is close with his second bullet point, but then he says it doesn't work, which is wrong.

That piece of code makes a pseudostatic variable, ie one that persists across calls to the function.

This is known as the my $foo if 0 trick. The if undef in your code is the same thing painted green: a false condition.

This shouldn't be used in production code. Tanktalus' suggestion of using a closed-off scope is what you should replace it with.

Makeshifts last the longest.

Thanks, for that nice and surprising explanation. Looks like the dark side of perl.
Boris

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's someone being less clever than they think they are. They think that:

• $cache being assigned undef is an expensive operation, so by using "if undef", which is always false, we'll save on the actual assignment, and since perl already guarantees an uninitialised variable to be undef, it'll still be undef. This is supposedly more readable since you can still see $cache is set to undef. I would disagree - the "if undef" part is just plain confusing and should be removed. Whether you want to leave the assignment, "= undef", or not, is a matter of personal taste. In cases like this, I probably would leave it in, again, to make it explicit, but others like to play golf a bit more than I do, and would tell you to remove it, too - doesn't really matter.
• The original author also thought that this would have $cache be static or something, and so we'd generate the cache only once, no matter how many times it's called. They're definitely wrong here, too. A couple of options - move the "my $cache" line to outside the sub, or do that and also put braces around the whole thing. As an example of the latter:

  {
    my $cache = undef;
    sub IsMatrix
    {
          shift if UNIVERSAL::isa($_[0], __PACKAGE__);
          my ($child, $parent) = @_;
  
          unless ($cache)
          {
                  my %cache;
                  @cache{@matrices} = (1) x scalar(@matrices);
                  $cache = \%cache;
          }                                                             
  +                                                                 
  
          return $cache->{"${child}_$parent"};
    }
  }
  [download]

  The outter braces are the optional part. With them, $cache is only visible inside IsMatrix, without them, the variable is visible to the entire file. With the braces is closer to the original author's intent, but I'm not sure the original author's intent is really that important given these mistakes ;-)

Nothing !

I stand very much corrected, this is a cunning (mis?)feature, see Aristotle's reply below and chromatic's++ explaination

$ perl -le'print "something" if undef'
$
$ # A tumbleweed blows across my vacant screen
$ perl -le 'if (undef) {print "something"} else {print "nothing"}'
nothing
$
[download]

Perhaps it was a bizarre way of "commenting out" the undefing of $cache.

I think Tanktalus has hit the nail on the head below, it is perhaps an attempt to be more obvious than just my $cache but a fairly odd one

Cheers,
R.