Re^3: will you explain what's going on?

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? :)

Comment on Re^3: will you explain what's going on? Select or Download Code

Replies are listed 'Best First'.
Re^4: will you explain what's going on? by ysth (Canon) on Oct 27, 2004 at 11:58 UTC
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]

Replies are listed 'Best First'.

Re^4: will you explain what's going on?
by ysth (Canon) on Oct 27, 2004 at 11:58 UTC

{
   my $q;
   BEGIN {
      # runs at compile time when the outer block hasn't  been entered
      $q = 42;
   }
   print $q; # prints 42
}
[download]

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]

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]

[reply]
[d/l]
[select]