That's pretty much the distinction I'd make as well, although I usually phrase it another way: for is for generic iteration, map is specifically a transformation.

A surefire way to annoy me and lose points when we get sample code is people who for whatever reason use map in void context rather than a proper for loop (it doesn't say "LOOK I R IDIOMATIC CODERZ", it says "ITERATION: UR DOIN IT WRONG" (and yes, I do have a lolcat based scale for applicants :)).

The cake is a lie.
The cake is a lie.
The cake is a lie.

I have done some research on best practices regarding map. I wanted to ask at one point why we don't just use map instead of foreach. However I found a few nodes about that subject where, as you just did, map in a null context was brought up. However, I am not sure I understand what that means. Could you describe what map in a null context is?

-Actualize

Using map but not capturing the returned values:

map { something( $_ ) } @somelist;

In recent versions that's been optimized (basically the return values are silently discarded rather than a temporary list built and then discarded later) so it's not as blecherous performance wise.

However it really buys you nothing to use it instead of a for loop here, because you've now muddled the conceptual waters (Was it at one point using the returned values and changed? Did they plan on possibly using them at some point?) and makes the code harder to understand (rather than the important thing (what's being iterated over) being up front, you've got to read past the details (what's being done for each item) to find out). It's along the lines of using passive or active voice in a sentence ("The cow jumped over the moon." vs "The moon was jumped over by the cow"); using the wrong one can shift what the reader takes as the emphasis to the wrong part.

The cake is a lie.
The cake is a lie.
The cake is a lie.

I think I get it: Why use a gun to kill a cockroach when you have a perfectly good shoe. Since you don't get the benefits of mapping the data, and as such you are wasting time and space, it's better that you use "for".

So, if I am understanding you correctly,

• for: used for iterating an action over a series of items.
• map: used when one needs to create create a table of data which will be used at a future time.
-Actualize

Using for has the following advantages:

• you have more control and options over loop execution (last, next, etc.)
• you can use your own more descriptive named lexical instead of $_
• it's more readable (especially for non-perl experts)

my @result = map { f($_) ? g($_) : () } @list;

# or:
my @result;
for (@list) {
  push(@result, g($_)) if (f($_));
}

my @result = map { g($_) } grep { f($_) } @list;

But that's just me . . .

The cake is a lie.
The cake is a lie.
The cake is a lie.

Oh definately, because once you put more than one statement into a map, you have violated a bigger stylistic rule.
In that case, I will either pull the logic into a subroutine and call it from the map (assuming that I may need to reuse it), or switch to a for loop.
actually, I will switch to a foreach loop. I find that always using foreach for the

for $var (@list)

form and for for the c-style form adds to the grokiness of my code.
UPDATE: should have looked closer at the body of the for there, I agree with Fletch on that one


-pete
"Worry is like a rocking chair. It gives you something to do, but it doesn't get you anywhere."

I have not done much with perl profiling, but when doing a performance comparison, don't you need to return the same results? It looks like the test_for returns the number of elements in the post-push array, whereas test_map returns the new array, at least if I am reading push correctly.

Update:Note that I am not saying that the results will change much. In fact, here are mine for 60 seconds. test_for2 does a return of the array at the end of the test function.

     s/iter for2  map  for
for2   2.70   --  -1%  -1%
map    2.68   1%   --  -0%
for    2.67   1%   0%   --
Benchmark: running for, for2, map for at least 60 CPU seconds...
       for: 61 wallclock secs (61.37 usr +  0.02 sys = 61.39 CPU) @  0.37/s (n=23)
      for2: 61 wallclock secs (61.37 usr +  0.03 sys = 61.40 CPU) @  0.37/s (n=23)
       map: 62 wallclock secs (61.48 usr +  0.03 sys = 61.51 CPU) @  0.37/s (n=23)

Update 2: Would some kind monk be willing to comment on if it is sufficient to just define the raw function (as in the OP), or would you also need to have the function return into a context of some sort. In other words, should there be another layer of function call here to force list context to make this a valid comparison?

The speed increase involves minimizing resource intensive tasks such as sorting. Instead of of running code every time you iterate over a loop, you perform a map on the data once storing the output into an array. Then you can use the information from the array. The classic example would be the Schwarzian transform .