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
