in reply to Re: will you explain what's going on?
in thread will you explain what's going on?

No, that's incorrect:

use strict;
use warnings;

for my $bool ( 0 .. 1 )
{
    my $name = 'bob' if $bool;
    print "($name)\n";
}

[download]

The actual truth of the matter is that my has compile-time and run-time effects.

At compile time, Perl creates an entry for $namedisplay in the appropriate lexical pad. Thus every lookup for that variable will find the lexical.

At run time, Perl evaluates the condition to determine whether to assign a new value to the lexical variable. Perl doesn't (always) clear lexical variables with refcounts of zero at scope exit (it's an optimization). However, if you don't always reset your variable -- if the run-time behavior of my doesn't occur because of a false conditional -- you will (may) see the old values.

Update: Actually, I can't recreate the memory or trip the warning about it now either, so I've edited my post somewhat.

Replies are listed 'Best First'.
Re^3: will you explain what's going on?
by dave_the_m (Monsignor) on Oct 26, 2004 at 23:52 UTC
    Perl doesn't (always) clear lexical variables with refcounts of zero at scope exit (it's an optimization).
    Under normal circumstances, Perl always clears the variable; the optimisation is that it never frees it. The bug is that the run-time effect of of my is to push an instruction onto the savestack to clear the variable on scope exit. If the my is skipped, the var doesn't get cleared on scope exit, and its old value is still there at the next entry to the block. (Note that on entry to a block, my doesn't clear the variable).

    Some people have used this as a way of getting static vars, but this is officially deprecated these days.

    Dave.

[reply]
      Oh, thank you very much!++
      Now everything is on it's place.
      Final question: how can one find out the answer to the question like this one? Looking through perl source code? Because I'd like to find the answer myself but sometimes stuck into not knowing even where to look into...
[reply]
        Since this effect depends on how a lot of different pieces work, you won't find it easily in the source code. But the last paragraph of the section of perlsyn on statement modifiers says (beginning in 5.8.1, anyway):
        NOTE: The behaviour of a my statement modified with a statement modifier conditional or loop construct (e.g. my $x if ...) is undefined. The value of the my variable may be undef, any previously assigned value, or possibly anything else. Don't rely on it. Future versions of perl might do something different from the version of perl you try it out on. Here be dragons.
[reply]
[d/l]
[select]
Re^3: will you explain what's going on?
by fglock (Vicar) on Oct 26, 2004 at 23:17 UTC

    I tried the following program under Perl 5.005_03, 5.6.1, and 5.8.4 and got the same results - no "memory effect":

    use strict;
#use warnings;

for my $s ( qw( nob bob cob bob dob ) )
{
    my $name = $1 if $s =~ /(bob)/;
    warn $name || 'undef';
}

    [download]

    result:

    undef at - line 7.
bob at - line 7.
undef at - line 7.
bob at - line 7.
undef at - line 7.

    [download]
[reply]
[d/l]
[select]
Re^3: will you explain what's going on?
by maard (Pilgrim) on Oct 27, 2004 at 10:23 UTC
    At compile time, Perl creates an entry for $namedisplay in the appropriate lexical pad. Thus every lookup for that variable will find the lexical.

    Does this mean that space for all variables in all nested blocks is pre-allocated at compile time? If so that means that even lexicals in blocks of deeper level than current one are accessibe from current block (if I understood you right), i.e. 

    {
  # with some hack $a is accessible here
  { my $a; }
}

    [download]
    But I used to think (no, I don't know perl internals) that on entering each block that block's 'my' variables are created(allocated) in some 'lexicals stack', probably replacing lexicals with the same name from upper blocks.
    So this is really interesting: which of this two approaches is used in Perl?

    Perl doesn't (always) clear lexical variables with refcounts of zero at scope exit (it's an optimization).

    Reasonable. But what about initialization of variable on each loop pass? If I just write my $var;, the variable is being assigned undef (or empty list for array/hash). But my $var='foo' if $bool effect is still unclear to me. Consider this:

    use strict;

my %hash = (
    a => 'A',
    b => 'B',
    c => 'C',
    e => 'E',
    d => 'D',
);

for my $s ( qw( a b c d e ) )
{
    my $name = $1 if $s =~ /(c)/;
    $name = $hash{$s}  unless defined $name;
    warn $name || 'undef';
}

Output:
A at 7.pl line 19.
A at 7.pl line 19.
c at 7.pl line 19.
D at 7.pl line 19.
D at 7.pl line 19.

    [download]
    If $name wasn't cleared, as you say, 'c' would spread to the end of loop. Or maybe I'm just missing something obvious? :)
[reply]
[d/l]
[select]
      Most of this is implementation details that you don't need to worry about (and aren't guaranteed). The exception that comes to mind off the top of my head is that lexicals are indeed created for the first time before their containing block is entered, and you can set them via a BEGIN, INIT, or CHECK block: 
      {
   my $q;
   BEGIN {
      # runs at compile time when the outer block hasn't  been entered
      $q = 42;
   }
   print $q; # prints 42
}

      [download]
      However, changing it like so: 
      for (0..1) {
   my $q;
   BEGIN {
      # runs at compile time when the outer block hasn't  been entered
      $q = 42;
   }
   print $q || "undef"; # prints 42undef
}

      [download]
      shows that it does get restored to undef at the end of the block. Getting back to the original question in this thread, modifying it: 
      our $q = 54; # never actually used
for (0..1) {
   my $q if 0;
   BEGIN {
      # runs at compile time when the outer block hasn't  been entered
      $q = 42;
   }
   print $q || "undef"; # prints 4242
}

      [download]
      shows that keeping my from executing at runtime suppresses this clearing at the end of the block.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom