Dave.

The subroutine is defined outside of the loop, and therefore sees the version of $color that exists outside of the loop, and doesn't know about the localized aliases that are taking place inside the loop.

This is a somewhat sloppy version of a closure.

The proper way to pass data into a subroutine is as a parameter. You will find that if you rewrite your snippet with that in mind, your results will be more in keeping with what you predict them to be.

use strict;

my @colors = qw ( red green blue );

my $color;  
my $light = 'on';

foreach $color (@colors) {
    print "\$color is '$color' and \$light is '$light' in loop, ";
    print_color( $color, $light );
}

####
sub print_color {
    my ( $clr, $lite ) = @_;
    print " in sub values are '$clr' and '$lite'\n";
}
[download]

Also, if you want to preserve the last value of the loops iterator variable, you should play it safe by copying it to a variable that exists at greater scope, that hasn't been a part of the localized aliasing process.

Thanks, Dave.

To answer some previous comments,

Why modify an existing program? I want to learn how to 'use strict' (to catch my tpyos) and to scope properly. This is a small, manageable program, and it's easier to understand and correct my mistakes now than after it grows. It's going to be part of a larger project that might even generate <gasp> income. So I want to write it well.

I'd like to ask 'why' too; why make the iteration variable global? Laziness. There are a few variables (including the outermost loop variable) that all the subs use , and rather than code and keep track of all the passing of parameters to subroutines, I made them global. Of course, I've spent more time trying to understand this issue than I ever would have passing parameters, but hey, that's how you learn.

What confused me was this: If I satisfy strict with

foreach my $color (@colors) {
   ...
}
[download]

then I expect $color to be local to the loop. When

my $color;
[download]

outside of the loop satisfied strict for the loop variable $color I expected $color would be available outside of the loop during iteration. It wasn't.

There's still one question unanswered - if I use 'our $color' instead of 'my $color', the subroutine can see $color. I know that 'our' scopes globally, and I thought that 'my' at the beginning of the file, outside of any block, would scope to the whole file (effectively global), but it doesn't. So why are they different?

Thanks,

Queeg

use strict;

my @colors = qw ( red green blue );
our $color;          # our makes it work, my doesn't

foreach $color (@colors) {
    print "\$color is '$color' in loop, ";
    too_lazy_to_code_passing_parameter();
}

####
sub too_lazy_to_code_passing_parameter {
    print " in sub value is '$color'\n";
}


$color is 'red' in loop,  in sub value is 'red'
$color is 'green' in loop,  in sub value is 'green'
$color is 'blue' in loop,  in sub value is 'blue'
[download]

I ran into some unexpected behaviour while adding 'use strict' to a working program.

But what I really wanted to ask is Why? What's the point of adding 'use strict' to a working program? 'use strict' is a development tool. A useful one, but starting to use it on a working program adds, uhm, nothing. OTOH, it might prevent your program from compiling, inviting you to modify the program, which might cause all kinds of bugs to creep in.

Abigail

Modifying the program is not inherently harmful, and in my opinion, modifying code that does not run under strict is usually a good idea. Not that all programs should be made to run under strict, but the fact is that it prevents a lot of subtle bugs that might not come up in normal debugging at all.

As to the problem in the original question, I'd like to ask 'why' too; why make the iteration variable global? Call-by-value is really not that expensive, and if you feel it is, use $_[0].

Modifying the program is not inherently harmful,

Not inherently harmful? I'd say a large percentage of bugs in programs comes from the fact someone modified the program. That's my point. If something is not broken, don't fix it.

but the fact is that it prevents a lot of subtle bugs that might not come up in normal debugging at all.

It was given that the program was working. I assume that the OP doesn't mean "it has bugs" when he writes "working".

Adding strictness on a working program is a bit like rebuilding the Egyptian pyramids because originally the construction workers weren't wearing safety harnesses.

Abigail