> To eliminate the void map ...

The thing is, for people with a clear understanding of what the parser is doing, using the side-effect of a command isn't that big of a deal. OTOH for people who are still picking up the language, not knowing the consequences of ignoring the return can realy freak you out.

I did something like the following once, thanks to cut-n-pasting someone else's solution. There was a lot of intervening code in the original case but it came down to this:

#!/usr/bin/perl -w
my @list=(4,3,2,5,1);
 # db access here for more data.
 # the numbers that follow were real ugly in the original
 # code, like $sql->return->[0][2] and suchlike...
push @list, 45, 6, 24, 43, 9, # Comma not semicolon
map {$_ *= 2} @list;
print "@list\n";
# prints:
# 8 6 4 10 2 45 6 24 43 9 4 3 2 5 1
[download]

That was how I learned about abusing void context. =) Took me quite a while to spot that little goofup. If I'd written it the "right" way with a foreach: foreach (@list) { $_ *= 2; } I would have at least got a syntax error NEAR the error.

Of course, merlyn's fancy postfix for trick: $_++ for @l; in place of the map nets you an infinite loop in this case. =)

In any case, it seems wrong to ask perl to build up a return list from the map just to ignore it. If your only job is holding a nut while someone else tightens the bolt, you use a box-wrench, not a ratchet. Using a ratchet isn't "wrong" but it is still the wrong tool for the job. =)

Of course, now that I've gotten cocky, I abuse side effects ever so often myself. I just try not to do it to at work where some poor schmuck will have to puzzle out what I did.

--
$you = new YOU;
honk() if $you->love(perl)

Starting in 5.6.0, the elements in the list returned by values() are the actual values of the hash. Before that, the elements returned by values() were copies of the values from the hash. This is mentioned in 5.6.0's perldelta documentation.