RFC: add foreach function

[JeffBezanson]

A few times I have seen map used with a function called only for side effects, for example map(println, x). This returns a noisy and unnecessary array of nothings. I think we should have a foreach function (ala Scheme) for cases like this.

[Keno]

+1. I frequently define this function locally

[StefanKarpinski]

Yeah, seems good to me too.

[StefanKarpinski]

Should it be called foreach!? Technically no, I guess...

[tbreloff]

+1. I think it should be foreach, not foreach!. I normally define
this myself.

Related... are there methods to map many functions to one input? Should
there be? I frequently define a mapf(funcs, val) = [f(val) for f in funcs]... a no-return-value version would be nice as well.

On Mon, Oct 26, 2015 at 10:54 AM, Stefan Karpinski <[email protected]

wrote:

Should it be called foreach!? Technically no, I guess...

—
Reply to this email directly or view it on GitHub
#13774 (comment).

[jakebolewski]

+1, for the doc maybe a note when you should use foreach over map?

[malmaud]

+1, I would use this. But it does mean that map, list comprehensions, for loops, and now foreach are all constructs for running a function on each element of an array.

[JeffBezanson]

Those syntax differences seem to matter a lot to people. foreach(println, x) is much shorter than for y in x; println(y); end. In any case, in functional programming everything is just another way of running functions on things, so this doesn't worry me.

[malmaud]

Agreed all around.

[sbromberger]

I'm glad to see foreach but the order of the arguments is not intuitive to me. That is, I parse this (internally) as "for each (item in) X, apply (function) F". Having the function first seems awkward.

[tkelman]

Function first is consistent with map and allows do block notation.

[sbromberger]

The do block notation is a compelling reason to have it (if do blocks require function first in order to work), but consistency with map isn't. Map reads "map this function to these items".

[johnmyleswhite]

I don't think debating the subjectively best order of arguments is likely to prove productive.

[sbromberger]

@johnmyleswhite you're right. Sorry for following up.

[JeffBezanson]

http://docs.racket-lang.org/reference/pairs.html#%28def._%28%28lib._racket%2Fprivate%2Fmap..rkt%29._for-each%29%29