On 6/2/13 11:41 AM, monarch_dodra wrote:
On Sunday, 2 June 2013 at 13:07:18 UTC, Andrei Alexandrescu wrote:
[1, 2, 3, 4].map!(n => n.writeln).reduce;
Andrei
One of the problems with using "map" for something such as this, is that
the resulting object is not a range, since "front" now returns void, and
a range *must* return a value. So that code will never compile (since
reduce will ask for at least input range). Heck, I think we should make
it so that map refuses to compile with an operator that returns void. It
doesn't make much sense as-is.
Hm, interesting. I'm destroyed.
Usage has to be something like:
map!((n) {n.writeln; return n;})
which is quite clunky. The idea of a "tee" range, that takes n, runs an
operation on it, and then returns said n as is becomes really very
useful (and more idiomatic). [1, 2, 3, 4].tee!(n => n.writeln). There!
perfect :)
I've dabbled in implementing such a function, but there are conceptual
problems: If the user calls "front" twice in a row, then should "fun" be
called twice? If user popsFront without calling front, should "fun" be
called at all?
Should it keep track of calls, to guarantee 1, and only 1, call on each
element?
I'm not sure there is a correct answer to that, which is one of the
reasons I haven't actually submitted anything.
I think there is one answer that arguably narrows the design space
appropriately: just like the Unix utility, tee should provide a hook
that creates an exact replica of the (portion of the) range being
iterated. So calling front several times is nicely out of the picture.
The remaining tactical options are:
1. evaluate .front for the parent range once in its constructor and then
every time right after forwarding popFront() to the parent range. This
is a bit "eager" because the constructor evaluates .front even if the
client never does.
2. evaluate .front for the parent range just before forwarding
popFront() to parent. This will call front even though the client
doesn't (which I think is fine).
3. keep a bool that is set by constructor and popFront() and reset by
front(). The bool makes sure front() is called if and only if the client
calls it.
I started writing the options mechanically without thinking of the
implications. Now that I'm done, I think 2 is by far the best.
--------
I don't think "argument-less reduce" should do what you describe, as it
would be a bit confusing what the function does. 1-names; 1-operation,
IMO. Users might accidentally think they are getting an additive
reduction :(
Good point.
I think a function called "walk", in line with "walkLength", would be
much more appropriate, and make more sense to boot!
But we run into the same problem... Should "walk" call front between
each element? Both answers are correct, IMO.
That's why I'm thinking: the moment .front gets evaluated, we get into
the realm of reduce.
Andrei
