% perl -le 'warn "a"'
a at -e line 1.

% echo "" | perl -le '<>; warn "a"'
a at -e line 1, <> line 1.
[download]

By the way, this issue has bitten real live sites. I gave a lightning talk in YAPC::Israel::2004 about this.

You'll only get the extra info if the filehandle read from is still open. closing the file (ARGV in the case of the diamond operator) switches it off again.

P:\test>echo "" | perl -wle "<>; warn 'Erk!'"
Erk! at -e line 1, <> line 1.

P:\test>echo "" | perl -wle "<>; close ARGV; warn 'Erk!'"
Erk! at -e line 1.
[download]

Explicitly closing DATA once the loop completes is useful sometimes.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

gaal,
I read the slides from your lightning talk. They were interesting. One thing that I might add (or otherwise comment on) is the suggestion that while() doesn't localize $_. While this is true, it's probably more accurate to state that <FH>; doesn't localize $_. Because the fact is that while() isn't itself acting on $_. The action is carried out by the diamond operator implicitly spilling its guts into $_. while() doesn't really have much to do with it, though we get in the habbit of thinking that it does since the while( <> ) construct is so common, and since foreach loops default to acting upon $_.

Also commenting on your slides (not having heard the lecture), foreach is the exception as you said, but this is because foreach works in an entirely different way than while(). With respect to foreach, it is the loop construct itself that acts upon $_, in a very special way. We even write it in a very special way (if we write it out longhand):

foreach $_ ( list )
[download]

...that's how foreach deparses with B::Deparse. Your slides mention that foreach is the exception. While it is an exception, it is not the only one. map also is a looping mechanism where $_ is localized. Consider the following code:

$_ = "Test string\n";

my @array = map { $_ = chr $_ } 32 .. 64;

print $_;
__OUTPUT__
Test string
[download]

As you can see, the use of $_ inside of map works a lot like the iterator of a foreach loop, in that it serves as an alias to the elements of the input list (ok, my example doesn't demonstrate this, but it's true), and in that it is localized (my snippet shows this to be the case).

Just a few observations and additional meditations... ;)




Dave

The automatic setting of $_ comes from the combination of while() and readline. Just a plain readline won't do it. Nor does while with just any operator do the implicit assignment.

for, map, and grep: these three constructs localize $_. But in fact, map and grep are more vulnerable than foreach, because they don't give you the choice of using a lexical as your aliased iterator (iterant?). I did mention this in the talk though I guess the emphasis is stronger when you have more than the slides :)

{
   local $.; scalar tell STDOUT;
   warn "whatever";
}
[download]

I've often wished that $. could be %. instead. That way, $.{FH} could refer to <FH>, and $.{DATA} could refer to <DATA>. But this all breaks down when you start talking about lexical scalar filehandles ( <$fh> ), because how would you write that? $.{\$fh}? ...it starts looking a little ackward.

I've also often wished that it would actually "do" something when you assign a number to $. But of course this is asking way too much of the buffered IO subsystem, and when that sort of behavior is desired, it's almost always easier to just use Tie::File.




Dave

I've also often wished that it would actually "do" something when you assign a number to $.

Just think what this would mean:

$. = 10.7;
[download]

Does that mean we can now start reading from the character at position 70% on line 10? Or is that the 8th character? [And how do I get rid of the headache that just gave me?]

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

while (<>) {
  chomp;
  print $_, "\n";
}
[download]

Don't be too quick to knock your approach. I find it useful in "real" programs to use a named variable to indicate to my reader (me in most cases :) what I expect that variable to represent. This is especially useful in nested constructs where $_'s semantics change as construct boundaries are crossed.

And if I change a foreach (...) to a while (...), the magic of $_ disappears, and I might introduce bugs similar to gaal's example.

Sometimes using explicit variables helps you find logic errors too.

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