Then why even bother with map to begin with? And no, that isn't as clear. Go back and look at Brian's example. All map blocks need to be evaluated for each element in the list, so when you have a multi-statement block, you end up putting the result at the end, all by itself:

  map {
     ...

     $hash;
  } ...;
[download]

to make sure the block is evaluated properly. This is a side-effect, and it isn't as clear or as readable as an explicit push would be.

Then why even bother with map to begin with?

Why not? Some people bother with foreach, one could question that as well.

And no, that isn't as clear.

Once again, what's clear and what isn't is highly subjective, heavily influenced by ones experience.

All map blocks need to be evaluated for each element in the list,

Uhm, yes. That's the point of a map, isn't? And perhaps you haven't realized it, all foreach blocks are evaluated for each element of the list as well.

you end up putting the result at the end, all by itself:

Yeah, neat, isn't? That's the point of map, you know.

This is a side-effect, and it isn't as clear or as readable as an explicit push would be.

Actually, it's not a side-effect. Modifying a variable (what push does) is a side-effect.

But I understand what you are saying. It's utterly unclear to write a map this way. After all, it's also unclear to return a result from a subroutine; it's much clearer if the subroutine explicitly assigns the return value to a variable. All well written programs do.

Uhm, yes. That's the point of a map, isn't? And perhaps you haven't realized it, all foreach blocks are evaluated for each element of the list as well.

I'm referring to how map takes the result, the final statement, of each block and passes it on to the resulting list. Judging by your next statement, you understood perfectly what I was saying but still choose to be smartass anyway:

Yeah, neat, isn't? That's the point of map, you know.

But I understand what you are saying. It's utterly unclear to write a map this way. After all, it's also unclear to return a result from a subroutine; it's much clearer if the subroutine explicitly assigns the return value to a variable. All well written programs do.

Nice contrived example to try to prove your point. The subroutine equivalent would be leaving off the return statement and letting the last statement implicitly be the return value:

sub ringForward {
    ...

    $modem->send($tone, $duration);
}

sub ringForward {
    ...

    return $modem->send($tone, $duration);
}
[download]

But I guess one is just as clear as the other, right? You can easily tell whether or not you can check the return value just from looking at either one, right?