Ultra-pure map()?

[David Held]

On 12/27/2013 7:32 PM, Marco Leise wrote:> [...]
 > Side effects and altering the input object itself makes me
 > want to pull out my crucifix. You shall not have impurity in
 > your functional style code!

Why not?  There are many impure functional languages, and most 
non-functional languages that allow functional style allow mutation. 
OOP is all about hiding state, which is the opposite of referential 
transparency.  Are you saying we should never map/fold over OOP ranges? 
  That seems like an unnecessary restriction for dogma's sake. 
Obviously, map() has to be lazy to support infinite ranges.  But I 
assume that reduce() must be eager so that you actually get a result (I 
mean, it could probably be made lazy at enormous expense, but that would 
just be silly).  So, if you want side effects, I guess you have to do 
the slightly dirty trick of calling reduce() without actually reducing 
anything.

I guess the "right" thing to do would be to make a new algorithm that 
implements an eager map() but perhaps doesn't bother with the result, 
called "invoke()".  This carries none of the semantic baggage of 
well-known pure higher-order functions, and even sounds more OOP-like. 
Most of the other features of map() (like parallel iteration) are pretty 
nice to have in eager form.

Dave