On Saturday, 28 December 2013 at 09:18:00 UTC, 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. 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
If you want to get result just now, then use 'array' function
from std.array module.
map!fun(range).array;
or
array(map!fun(range));
