in reply to Re: Insensitive Scoundrel
in thread Insensitive Scoundrel

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

Replies are listed 'Best First'.
Re^3: Insensitive Scoundrel
by tadman (Prior) on Sep 27, 2002 at 01:07 UTC
    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.
[reply]
[d/l]
      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.
[reply]
      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.

[reply]
        Just a minor nitpick: not giving an argument should implicitly pass the empty list, not undef - just like you do when you want an iteration of a map to "disappear" from the result list. </nitpick> :-)

        Makeshifts last the longest.

[reply]
Re: Re: Re: Insensitive Scoundrel
by chromatic (Archbishop) on Sep 26, 2002 at 23:44 UTC

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

[reply]
Re: Re: Re: Insensitive Scoundrel
by jordanh (Chaplain) on Sep 28, 2002 at 16:53 UTC
    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.

[reply]

      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. ;-)

[reply]

In Section Meditations