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.

That is my position: pop/shift/unshift/push are already understood and can be applied to strings. Someone else sais that it would be great if a string could appear to be an array of chars, in general.

Re: 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 got it: You have next, last, continue to modify the looping. How about a keyword result or somesuch that is like the "return" from a function? Just give an argument to next, continue, etc. and you don't need new keywords.

Dropping off the end of the block is an implicit "continue", just as the last statement in a function is an implicit "return". If you don't give an argument to the next, last, or whatnot, it becomes an undef empty list and doesn't add anything to the result list.

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 seem to recall just this sort of optimization being discussed on one of the perl6 lists recently. So maybe you'll get it anyway. ;-)