Global symbol "$var" requires explicit package name at p03.pl line 3.
Execution of p03.pl aborted due to compilation errors.
[download]

my $var;    # compile time component inserts variable into scratchpad
            # of the scope
$var = 1;   # run-time component assigns the value
[download]

use strict;
test();
#print "$var\n";  # Global symbol "$var" requires explicit...
exit;

my $var = 1;
sub test
{
  print "var was undef\n" if $var eq undef;
  print "var was '$var'\n";
  $var++;
  print "var is now '$var'\n";
}
[download]

var was undef
var was ''
var is now '1'
[download]

Roger,

I really like most of your explanation, which is much clearer than my attempt, but I am not sure that I agree completely. Lexicals are not inserted into any symbol table as far as I know, so I think that portion of the explanation may be erroneous.

,welchavw

Hi welchavw, thanks for pointing out that my variables are not inserted into symbol table, instead they are inserted into scratchpads. There are a few excellent references on this topic:

1. Advanced Perl Programming (Oreilly)

The my variables are inserted into the 'scratchpad' of the scope, not the package symbol table.

2. Perl lexical my variables.

The my operator declares the listed variables to be lexically confined to the enclosing block, ...

...

This doesn't mean that a my variable declared in a statically enclosing lexical scope would be invisible. Only dynamic scopes are cut off. For example, the bumpx() function below has access to the lexical $x variable because both the my and the sub occurred at the same scope, presumably file scope.



    my $x = 10;
    sub bumpx { $x++ }
[download]

Excellent reply, thanks! ++
Minor nitpick... $var eq undef is the same as $var eq '':
perl -e'$var="";print "ooh" if $var eq undef'

- ><iper (who recently decided to log in...)

use japh; print;
[download]

Neat failure, thanks for posting. Here's a try at an explain. That $var is compiled prior to test(), thus test() can refer to it (you can't move $var after test()), acting as a closure, as has been noted (++). However, as other posters have noted, line 6 does not get executed, so the assignment is never performed. The value of $var is undefined when printed, as a result.

Now, I actually rather believe that storage is allocated on-the-fly, during the call to test(), rather than at compilation-time.

Also, here's some additional test code I wroteup just to check some of my thoughts.

use strict;

&f; #"pre=> ", "post=>2"
my $v = 1;
&f; #pre=>1", "post=>3"
exit;

sub f {
  print "pre=>$v\n";
  $v += 2;
  print "post=>$v\n";
}
[download]

Here's some further code that was illustrative to me.

#this code proves that scratchpads keep lexicals around,
#not mere copies of those lexicals; something like reference
#counting of lexicals is occuring with closures - the details
#don't really matter - the $v lexical persists in both the f1
#and f2 closures, not a mere "copy" of $v.

sub f_maker {
  my $v = 1;
  my $f1 = sub {
    print "f1_pre =>$v\n";
    $v++;
    print "f1_post=>$v\n";
  };
  my $f2 = sub {
    print "f2_pre =>$v\n";
    $v++;
    print "f2_post=>$v\n";
  };
  return ($f1, $f2);
}

my ($f1, $f2) = &f_maker;
&$f1;
&$f2;
&$f1;

__OUTPUT__
f1_pre =>1
f1_post=>2
f2_pre =>2
f2_post=>3
f1_pre =>3
f1_post=>4
[download]

You exit before line 6 is reached - it is executed at runtime. You will get the behavior I think you expect by rearranging,

use strict;
{
    my $var = 1;
    sub test {
        print "var was '$var'\n";
        $var++;
        print "var is now '$var'\n";
    }
}

test();
exit 0;
[download]

You're missing my point, comment it out and see what happens.

I agree the behavior is strange. It seems that Perl is processing the declaration at compile-time, which is why the variable exists when the sub is declared, but isn't processing the assignment until that line is reached in runtime, which never happens.

Perhaps you've touched on an area where the right thing to do is ambiguous, so Perl's idea of what to do differs from yours.

Several people have already shown you ways to make this work, by making sure the my statement precedes the call to test in both compile- and run-time.

my has both compile-time and run-time effects. See Abigail's comment in Unusual Closure Behaviour, though that's not directly related to your problem. [and damn those spelling variations]

When the my line is commented out, I suspect that Perl is not complaining about the missing declaration because of the compile-time effect, even though the line is never executed.

-QM
--
Quantum Mechanics: The dreams stuff is made of

I think you are likely confused by the fact that $var seems to be legally declared before the subroutine, but the subroutine is called before $var is declared. And yet, in the subroutine, $var has not been initialized to 1.

In this case, the entire script is parsed and the my declaration is noted at compile time. The initialization of $var happens at runtime, except in your case you've exited before that point.