#!/usr/bin/perl -w
use strict;

package R;
my $R = 10;
use vars qw( $var );
$var = 20;

package main;
print "R is >>$R<<\n";

package R;
print "R is >>$R<<\n";
print "var is >>$var<<\n";
[download]

#!/usr/bin/perl -w
use strict;

{
package R;
my $R = 10;
use vars qw( $var );
$var = 20;
}

package main;
print "R is >>$R<<\n";
print "var is >>$R::var<<\n";

package R;
print "R is >>$R<<\n";
print "var is >>$var<<\n";
[download]

#!/usr/bin/perl -w
use strict;
{
package R;
my $R = 10;
use vars qw( $var );
$var = 20;
}
package main;
# print "R is >>$R<<\n";
print "var is >>$R::var<<\n";
package R;
# print "R is >>$R<<\n";
print "var is >>$var<<\n";
[download]

Variables declared with 'use vars' have package scope, so we can switch to package R again and print $var without prepending the package name, as we have to do when we're in package main. Presumably the new our works much the same way in 5.6.

I can't let the idea of lexical variables and scope go away without making at least one comment about the misunderstood and feared closure. Take a look at this:

#!/usr/bin/perl -w
use strict;

{
package R;
my $R = 10;
use vars qw( $var );
$var = 20;
sub show_R { $R };
}

package main;
print "var is >>$R::var<<\n";
print "var is ", R::show_R(), "\n";

package R;
print "var is >>$var<<\n";
print "var is ", show_R(), "\n";
[download]

See above in my reply to btrott. You have provided a great discussion, and have certainly taught me something.

Closures are cool. I've never had any trouble understanding lexical variables within some other block (like a sub). I guess I have never tried to declare a closure at file scope, so I've haven't learned to fear them. It wouldn't have worked for me (at file scope), before today, so I guess the timing is better this way. :-)

Thanks for sharing your knowledge...

Russ

    package R;
    my $R = 10;

    package main;
    my $subcode = "sub { local \$_; package R; print $R}";
    my $subref  = eval $subcode;
    &$subref;
[download]

That's why you need to make your variables package globals, presumably using the vars pragma, but probably you could also use our, in Perl 5.6. Because those package globals are in your package's namespace, so when Benchmark executes your code in the "caller's package", it's accessing the correct variables.

As for your other question:

    > P.P.S. Here are my results with the correct code. Grep is
    > still faster than the other algorithms, so the original
    > question still stands (how can Perl execute an O(N) plus
    > an O(N log N) algorithm faster than a single O(N)?)
[download]

I see.

You're right, I had been confused about lexical scope. I assumed a lexical was scoped to its package, but it is actually scoped to its enclosing block (in this case, the file).

Between your explanation and chromatic's (below), this is a great discussion!

So, I went to my Perl books to try to find this explanation (to see which sections I have apparently never read). Camel Page 107-108:

...lexically scoped declarations have an effect only from the point of the declaration to the end of the innermost enclosing block. ... But a package declaration merely declares the identity of the default package for the rest of the enclosing block.

Well, there it is. Packages do not define a namespace for lexical variables, because they do not define an enclosing block.

I believed, in my code, that lexical variables were "scoped" to their package. (I almost *never* use global variables... package globals or otherwise. Without my habit of mying every variable, I would not have stumbled across this (and lost an opportunity to learn even more)) :-)

All of a sudden, my version of reality is being updated. ;-)

I agree about my other question. grep and sort are obviously highly optimized. The coolest thing is, I haven't been able to find a crossover point (where sort grep become slower than max). No matter how large the data set, and no matter how many elements must be sorted, it is still faster to do the sort algorithm than max. It should be amazing, but this is Perl, where miracles are commonplace... :-)

Russ

    package R;
    my $R = 10;
[download]

    use R;

    package main;
    my $subcode = "sub { local \$_; package R; print $R }";
    my $subref  = eval $subcode;
    &$subref;
[download]

The point, though, is that one we've moved the declaration of $R as a lexical variable into a separate file, your code no longer does what you thought it would. Which means that it wasn't doing what you thought it was, in the first place. :)

No, that's not quite right.

In the first example, change increment() to return $data instead of undef, and then you can call error() without getting an uninitialized value error.

In the second example, simply give $data a default value, call error() before your while block, and you'll see that it prints.

Here's the code I used for an example:

#!/usr/bin/perl -w

use strict;
my $data;
my $ERROR = 0;

# error();    # uncomment this to print $data before the loop

while ( (defined $data++) && everything_is_okay() ) {
    print "looping for the $data time.\n";
    if ( $data > 5 ) {
        $ERROR++;
        error();    # print $data if there's an error
    }
}
sub everything_is_okay {
    if ( $ERROR ) {
        print STDERR "ERROR LEVEL $ERROR\n";
        exit $ERROR;
    }
    return 1;
}
sub error {
    print $data;
}
[download]

I put the defined check in there so the loop will get past the first iteration. $data++ (when $data is not initialized) evaluates to zero:

my $data;
print $data++;
[download]

Overall, nice discussion. To comment on one point you raised, though... you wrote:

    sub error {
        print $data; # oops, doesn't work!
    }
[download]

Well, it *does* work. If you try it, you'll see that it works just fine, because it's a lexical variable... lexical to the scope of the file. And the error sub is defined in the file, so $data is visible there.

That's not to say that it's recommended, of course, because it can definitely cause you problems. Particularly when using mod_perl. You'll get the dreaded "variable may not stay shared" message, because essentially you've defined a closure.

That said, though, good points.

As it turns out, almost all my code has to run under mod_perl...