The foreach loop iterates over a normal list value and sets the scalar variable VAR to be each element of the list in turn. If the variable is preceded with the keyword my, then it is lexically scoped, and is therefore visible only within the loop. Otherwise, the variable is implicitly local to the loop and regains its former value upon exiting the loop. If the variable was previously declared with my, it uses that variable instead of the global one, but it's still localized to the loop. This implicit localization occurs only in a foreach loop.

The foreach keyword is actually a synonym for the for keyword, so you can use either. If VAR is omitted, $_ is set to each value.

Update: added some formatting in the above quote.

Except the effect of local also applies to the called subroutines,as shown by the our version. perlsub says:

A local modifies its listed variables to be "local" to the enclosing block, eval, or do FILE --and to any subroutine called from within that block. A local just gives temporary values to global (meaning package)

So while local is supposed to work across calls to subroutines, it's also supposed to work on variables which are present in the symbols table. I wouldn't expect a closure to keep the name of the variable, or whatever is used to make the localization work

Yeah, Eily, I understand your point.

I am not quite sure, though, whether the sentence the variable is implicitly local to the loop and regains its former value upon exiting the loop is to be construed as meaning that it works as if the loop variable is localized with the local keyword.

Presumably the declaration with our prevents the implicit localization within the loop.
poj

Without my, Perl does not use the variable $S4 for the loop, but instead uses a new lexically variable also named $S4. Thats why the first variable $S4 is uninitialized in sub X.

So your code behaves like this:

#!env perl
use strict;
use warnings;

my $S4;

sub X {
    print "<$S4>\n";
    return $S4;
}

for my $other_variable_also_named_S4 (1 .. 2) {
    print "A: <$other_variable_also_named_S4> <", X(), ">\n";
}
[download]

Conway warns to use this construct since its 'behaviour is contrary to all reasonable expectation'.

BTW: perlcritic warns about it too.

BTW: perlcritic warns about it too.

But, then, that's hardly surprising, given that "Perl::Critic is distributed with a number of Perl::Critic::Policy modules that attempt to enforce various coding guidelines. Most Policy modules are based on Damian Conway's book Perl Best Practices."

I'm as surprised as you are. Only thing I see is that for doesn't *set* the loop variable AFAIK, but it turns it into an alias (if you had had other variables in your list, no new value would have been created, but $S4 would have pointed to the existing scalars). So it looks like the closure still looks at the previous scalar, bypassing the aliasing mechanism.

I believe you've inadvertantly created something akin to a closure (except it's not anonymous), and perl is using the current value (undef) of the lexical variable $S4 when the subroutine is defined. The variable needs to have package-level scope (which our $S4 gives you; aka "global") in order to be "live" in the subroutine. Or, better, pass it as a parameter to the function.

Some of this is hinted at in perlsub, search for the first instance of "closure", and perlref. You can read those statements in the docs without realizing the implications, until you actually run across a bug that helps it solidify.

something akin to a closure (except it's not anonymous)

In perl, a closure doesn't have to be an anonymous sub; any sub that uses lexical variables which are declared in a scope outside that sub, closes over those vars at the time the sub is created. Anonymous subs are usually more interesting, since multiple instances of the sub are often created at runtime, thus capturing multiple instances of outer lexicals. Conversely, named subs are created just once, at compile time, thus just capturing the first instance of each lexical.

Dave.

Although this is almost slightly off-topic, please note that a closure doesn't have to be anonymous (but closures are quite commonly anonymous).

++Laurent_R ++dave_the_m: yeah, I didn't originally think it had to be anonymous, but perlref said "Closure is a notion out of the Lisp world that says if you define an anonymous function in a particular lexical context, it pretends to run in that context even when it's called outside the context." Maybe I'm just misinterpreting that (maybe always anon in Lisp? dunno). Or maybe the doc wasn't worded as carefully as it could have been. Thanks for the clarification.

Point is IIRC - like others already said - that "localizing" the lexical happens by binding a new place to the symbol S4.

Localizing isn't done like in local (safe/restore) with package vars on the same place.

I'm not sure, but I seem to remember that the implementation of foreach involves an extra "frame" with an own lexpad.

The whole mess is probably a side effect of the late introduction of lexicals after Perl 4.

Best solution for your problem is to use another symbol for the loop and to copy the value to the closure var.

for my $x (1 .. 2) { 
    my $S4 =$x;
    print "A: <$S4> <", X(), ">\n";
}
[download]

> It's breaking my mental model of Perl, 

That's because Perl is kind of broken here ...

... or to phrase it better, foreach with its aliasing is a very magic beast inside Perl.

update

°) for instance How do closures and variable scope (my,our,local) interact in perl?

I have to admit ignorance of what really happens inside Perl but a small experiment sheds a bit of light on the situation:

use strict;
use warnings;

my $S4 = "aaa";

sub X {
    print "<$S4>\n";
    return $S4;
}

for $S4 (1 .. 2) {
    print "A: <$S4> <", X(), ">\n";
}
[download]

which supports the "closure theory", imho.

Update: adding to my experiment as follows

use strict;
use warnings;

my $S4 = "aaa";

sub X {
    print "<$S4>\n";
    return $S4;
}

for $S4 (1 .. 2) {
    print "A: <$S4> <", X(), ">\n";
}

$S4 = "bbb";
print "B: <", X(), ">\n";
[download]

which seems to confirm the theory that the loop variable is implicitly localized.