the FAQ states a good technical reason for avoiding map/grep in a void context. however, i think the most important reason is just that almost any time you'd want to use map or grep in a void context, what you really want is just a foreach loop or something.

map and grep have long histories as list filters that take a list in and spit a list out. using them in a void context reduces them to mere looping constructs. if you need a looping construct, foreach is almost always more appropriate. using map or grep just makes the code more confusing for no good reason.

anders pearson

I use a screwdriver to open a paint can. They make special tools just for opening paint cans, but I find that excessive--why buy and not lose another small tool, and keep it around and gather it up as part of a painting project? The screwdrivers are among the most common and versatile tools in my typical work, and I have then ready at hand.

So, why do we even have foreach and map as separate constructs when they do the same thing? Perhaps only for historical reasons. It makes sense to have a looping construct that applies a block to each item in a list. Now if the construct itself were to return a value, what would that value be? A list of all the "results" of the block makes perfect sence. So if you could use foreach as an expression rather than a statement, it would naturally be map.

And we all know that grep is a trivial usage of map. We don't really need it as a core part of the language, any more than we need chop.

—John

It's almost as if pop and shift should work on scalars, don't you think? Then you can ditch chop as being silly.

You have a bit of a point, but for is a lot more than just map. It does different things. For example:

for my $foo (@bars)
{
     next if ($foo > 10);
     last if ($foo == 42);
     $foo += 12;
}
[download]

Now, what would you expect that loop to return, if it were like a map? You can't skip or restart map in the same way, you realise, probably because it could cause some very strange behavior.

I'm all for condensation where it makes sense, but in this case, I think you're going to have a Swiss-Army-like function and no heavy lifting tools.

Careful, you're about to reinvent the lambda calculus!

This seems entirely reasonable to me.

I guess the generalization of this would be for the Perl Run-time system (the Bytecode interpreter or Parrot or whatever) to recognize when a routine is being called in a void context and to propagate down to all callees to not bother assigning to or otherwise generating any data structure that is to be returned, unless that data structure is needed for other processing.

It also might simplify Perl to then define foreach in terms of map, etc.

I think it's a perfectly sane thing to want. In Common Lisp, for example, there are functions analogous to Perl's map that accumulate a return list (e.g. mapcar, and others that don't (e.g. mapc), plus the all-encompassing Lisp map that allows one to specify what kind of sequence one wants returned (e.g. list, vector, string) or none at all. It's nice to have all that available when you don't want to write an explicit loop.