Ultra-pure map()?

[Timon Gehr]

On 12/28/2013 10:17 AM, David Held wrote:
> 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.

That's news to me. OOP does not mandate a procedural programming style.

> ...
> Obviously, map() has to be lazy to support infinite ranges.  ...
> So, if you want side effects, I guess you have to do
> the slightly dirty trick of calling reduce() without actually reducing
> anything.
> ...

What's the point? There are cleaner ways of doing the same.

The implementation of map assumes that the result is independent of how 
it is iterated, and using it with callables that make it fail this 
criterion is usually at best confusing and at worst a bug.

> 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()".  ...

I wouldn't call this an 'eager map'. It's a shallow wrapper around a 
foreach loop.