Very similar to one of the additions I proposed awhile ago. The
only difference is that my each() didn't call popFront().
http://forum.dlang.org/thread/ovbjcmogezbvsxrwfcol forum.dlang.org#post-mailman.621.1370146215.13711.digitalmars-d:40puremagic.com

I proposed the same function in D.learn, but this discussion
needs a list of use cases and usage examples, otherwise you can't
decide in vacuum.
It's named "foreach" in Scala:
http://twitter.github.io/scala_school/collections.html#foreach
Elsewhere I suggested a function that could be named tap() that's
usable to debug UFCS chains, interspersing it in the chain, to
add imperative calls to writeln. You can replace a each() with a
tap + some kind of eager consumer.
In many cases what I want to put in each() is a writef/writefln,
you can do it like this (binaryReverseArgs is in std.functional):
foo
.bar
.spam
.binaryReverseArgs!writefln("%(%s-%): %d", 5);
With a shorter flipping name it gets better:
foo
.bar
.spam
.flipTwoArgs!writefln("%(%s-%): %d", 5);
or even (http://zvon.org/other/haskell/Outputprelude/flip_f.html
) (flips only the first two args and doesn't flip the successive
ones):
foo
.bar
.spam
.flip!writefln("%(%s-%): %d", 5);
Let's say in each() you want to do something different, like
incrementing a variable:
foo
.bar
.spam
.each!(n => x += n);
Is this good enough?
If you want to double the contents of an array:
myArray.each((ref x) => x * 2);
But in D you can also use:
myArray[] *= 2;
I guess you can't use each() on opApply-based iterables, while
you can with foreach(). This makes each() less useful.
Is the following code supported? And what is each() receiving
from the associative array?
int[string] aa;
aa.each(...);
Perhaps you must use:
int[string] aa;
aa.byKey.each(...);
aa.byValue.each(...);
aa.byPair.each(...);
While arrays should be OK, but there is no index support:
int[] arr;
arr.each(...);
If you need dynamic array index support:
int[] arr;
arr.enumerate.each(...);
Is this supported?
int[10] arr2;
arr2.each(...);
Or do you have to use this?
int[10] arr2;
arr2[].each(...);
Bye,
bearophile

I think "each" is a good name but it should instead return range
that calls predicate function upon "popFront" and proxies input
argument further from "front". bearophile has been proposing it
under name "tap", but I like "each" more.

I think "each" is a good name but it should instead return range that
calls predicate function upon "popFront" and proxies input argument
further from "front". bearophile has been proposing it under name "tap",
but I like "each" more.

On this topic, do we have something like "consume" in Phobos to
eagerly iterate through the supplied range? Don't see anything
similar at first glance and it will be needed to express same
idiom via "tap"/"tee" in a readable form.

On this topic, do we have something like "consume" in Phobos
to eagerly
iterate through the supplied range?

A default "each" would do that.
Andrei

No, I don't mean iterate with predicate. I mean /dev/null thing.
My point is that `range.each!predicate` is much better replaced
with `range.tap!predicate.consume`. It keeps general rule of
range stuff being lazy and only single exception to bail out of
it has very readable clear name.
One can argue that "consume" is same as proposed "each" with
no-op predicate but I think it is very important for readability
to keep exceptional behavior (eager consumption) separated from
utility behavior (tapping with a predicate).

No, I don't mean iterate with predicate. I mean /dev/null thing.
My point is that `range.each!predicate` is much better replaced
with `range.tap!predicate.consume`. It keeps general rule of
range stuff being lazy and only single exception to bail out of
it has very readable clear name.
One can argue that "consume" is same as proposed "each" with
no-op predicate but I think it is very important for
readability to keep exceptional behavior (eager consumption)
separated from utility behavior (tapping with a predicate).

I also proposed this in the thread I linked, but it was also
rejected. I remember Andrei saying that "consume" should really
just be reduce called with no predicate, but I think that
wouldn't work for some reason...

My point is that `range.each!predicate` is much better replaced
with `range.tap!predicate.consume`. It keeps general rule of
range stuff being lazy and only single exception to bail out of
it has very readable clear name.
One can argue that "consume" is same as proposed "each" with
no-op predicate but I think it is very important for
readability to keep exceptional behavior (eager consumption)
separated from utility behavior (tapping with a predicate).

On this topic, do we have something like "consume" in Phobos to
eagerly iterate through the supplied range?

I had proposed "walk", which would be consistent with the already
existing "walkLength".
An "each()" with no arg could also do the trick, but that would
also call the "front", which means it's not the exact same
behavior (not better or worst, just different).

I don't have a solid enough experience with this style of
programming, but one opportunity of 'each' could be that it
could be specialized and achieve greater speed for some
arguments.

Speaking of which, it would be nice to have a compiler default
iteration scheme that is optimal for any range.
The current status is:
"for ( ; !r.empty ; r.popFront )" is sub-optimal for string
types, and sometimes arrays.
alias E = ElementEncodingType!Range;
"foreach(E e; range);" will create copies of elements
"foreach(ref E e; range);" will always work, but is arguably
wrong for RValue ranges
"foreach(auto ref E e; range);" is not legal, but there is an ER
requesting it, and I think it would make perfect sense to have
this.
Finally: The hand written library code
while ( decode(s, i) < s.length )
{ ... }
Is faster for strings, than the compiler's/druntime's "foreach(E
e; range);".
It would be awesome if:
foreach(auto ref E e; range);
Worked, *and* was always optimal.
The current scheme makes those who care jump through hoops, such
as in `find`'s implementation.

'each' sounds like a good idea for supporting component
programming a little more. As bearophile as already stated, you
can do something like this...
someRange.filter!foo.frobulate.each!doSomethingWithIt;
For Walter's question about parallel execution, I imagine
something like this.
// std.parallelism parallel function here.
someRange.whatever.parallel(numberOfUnits).each!doSomething
Basically it just removes a little foreach boilerplate. I don't
think the implementation needs to be much more complicated than
what Andrei wrote already, I would just pull that pretty much
as-is.
I also don't think an argument like "you can already do this with
foreach" is valid. You don't *have* to use it, and some people
might like it. I know I would appreciate having it in
std.algorithm. (I'm kind of a range fanboy.)

Because it can't be. It's not possible to present something as a
range, so that that range's consumers would process that range in
parallel. std.parallelism.parallel instead (ab)uses the opApply
implementation mechanics to execute the foreach body in different
threads.

User Ali Çehreli has posted in learn what I think is an
interesting problem:
http://forum.dlang.org/thread/lgfmbf$v7c$1 digitalmars.com
//----
This is a somewhat common little exercise: Write a function that
takes
the size of a diamond and produces a diamond of that size.
When printed, here is the output for size 11:
*
***
*****
*******
*********
***********
*********
*******
*****
***
*
What interesting, boring, efficient, slow, etc. ways are there?
Ali
//----
The reason I bring it up is that this usually leads to a
competition of whoever thinks up the most creative/concise UFCS
chain.
So here's what I'm thinking: Let's do this, but also using
each/tee/tap/consume/walk (and others?)!
I think this "real world" scenario is a good bench for seeing the
effects of mixing imperative-style statements into a
functional-style wrapper.
Maybe the result will reveal that something is awesome, or that
it is useless? That maybe something that looks like it works, is
actually subtly buggy? That maybe each turns out to be useful
past our wildest dreams?
Who knows?

So here's what I'm thinking: Let's do this, but also using
each/tee/tap/consume/walk (and others?)!
I think this "real world" scenario is a good bench for seeing
the effects of mixing imperative-style statements into a
functional-style wrapper.

As I explained in a precedent post in this thread it's hard to
design something if you don't try to use it, even something
simple as a each(). So I approve such exercises.
Bye,
bearophile

As I explained in a precedent post in this thread it's hard to
design something
if you don't try to use it, even something simple as a each().

Right on.

So I toyed around a little. I played with mostly tee/tap and
each. The first observation is that both can help make a "2D"
ufcs chain, which is pretty nice. It makes more sense (IMO) to
code it that way, than to use awkward "join", to concatenate the
"2D" range into a continuous "1D" range, eg: join(lines, "\n");
First: "tee".
I wanted to try to experience the "multiple tees" approach. I
made the code purposefully verbose, so as to better test it.
Because I wanted to process each item once, and only once, I used
the default policy of `Yes.pipeOnPop`. I did some tests with both
"tee!pred" and "tee(range, output)", but they were functionally
equivalent. Anyways, here was my first iteration:
//----
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=>' '.repeat(N - a).write())() //leading spaces
.tee!((a)=>'*'.repeat(a).write())() //first half of
stars
.tee!((a)=>'*'.write())() //middle star
.tee!((a)=>'*'.repeat(a).write())() //second half
.tee!((a)=>writeln())() //linefeed
.reduce!"0"(0); //or consume/walk
//----
Surprise! It's wrong!
each "tee" triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the "pop down the chain.
What this means is that my "tee's" are actually executed right to
left! Talk about counter intuitive.
So *this* is correct:
//----
size_t N = 5;
chain(iota(0, N), only(N), iota(0, N).retro) //0 .. N .. 0
.tee!((a)=>writeln())() //linefeed
.tee!((a)=>'*'.repeat(a).write())() //second half
.tee!((a)=>'*'.write())() //middle star
.tee!((a)=>'*'.repeat(a).write())() //first half of
stars
.tee!((a)=>' '.repeat(N - a).write())() //leading spaces
.reduce!"0"(0); //or
consume/walk/each()
//----
Odd!
Second:
Each tee pipes a call to front, and *then* calls front again when
popped. Effectively, if you have *N* tee's in your range, you'll
call "fun" roughly N*N/2 times. Not great.
This might be an unfair assesment of "tee", because I over-used
it on purpose, but I think it *does* show that it's not scaling
well, and that it is triggering in a confusing order.
Also:
//----
size_t N = 5;
foreach ( a ; chain(iota(0, N), only(N), iota(0, N).retro))
{
' '.repeat(N - a).write();
'*'.repeat(a).write();
'*'.write();
'*'.repeat(a).write();
writeln();
}
//----
Just saying. Why would I use "tee" when I have that?
But I think I'm using "tee" wrong: The idea is to "hook" it into
a chain that actually does something. It shouldn't be the main
"doer".
---------------------------------------------
What about each?
I wrote this:
//----
chain(iota(0, N), only(N), iota(0, N).retro)
.each!(
(a) => writeln(' '.repeat(N - a), '*'.repeat(a*2+1))
)();
//----
I think this is a fair assesment of how "each" would be used? It
looks nice, and is relatively short. But then I wrote this:
//----
foreach ( a ;
chain(iota(0, N), only(N), iota(0, N).retro) )
{
writeln(' '.repeat(N - a), '*'.repeat(a*2+1)))
}
//----
Hum... you still get the same functional initial declaration, but
the "foreach" doesn't get in the way, while still keeping a clear
functional/imperative distinction.
------------------------------------------
Si that's my initial assessment.
I'm not really sold on "each". I think it'll be abused by those
that want a "1-liner" at all cost, leading to an image that "D is
nothing but horrible 1 liners!", all that without providing any
real functionality.
As for "tee": I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.

This UFCS chain is just 2 lines long, it's not the best usage
example of each().

I'm not really sold on "each".
...
As for "tee": I'm convinced I didn't use it for its intended
function, but I think it shows its function can easily be
hijacked to do things it wasn't meant for.

You have used tee for something you think it's not very well
designed, and you have given only one usage example of each(),
and it's not the most common example.
So before taking any decision on the matter, more experiments and
usage examples are necessary, where you have longer chains. If
you have a longer chain:
items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because you
are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of items,
and you usually don't need an each there), so more usage examples
are needed. Taking a look at real world usages of foreach() in
Scala could be useful.

I think it'll be abused by those that want a "1-liner" at all
cost, leading to an image that "D is nothing but horrible 1
liners!", all that without providing any real functionality.

So before taking any decision on the matter, more experiments
and usage examples are necessary, where you have longer chains.
If you have a longer chain:
items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum
.each(...);
using a each() allows you to keep a nice column. If you use
foreach your formatting and your logic has a hiccup, because
you are mixing two different styles:
foreach (item; items
.sort()
.group
.map!(g => g[1] / double(s.length))
.map!(p => -p * p.log2)
.sum) {
// Do something imperative here.
}
But this is not a real example (it computes the entropy of
items, and you usually don't need an each there), so more usage
examples are needed. Taking a look at real world usages of
foreach() in Scala could be useful.

The former example doesn't become functional just because you
managed to use UFCS, it's just imperative code deceptively
disguised as functional code. The clear separation in the latter
example is a *good thing*.

each "tee" triggers on the call to `popFront`. It does its job
(calls pred(r.front)), and then push the "pop down the chain.
What this means is that my "tee's" are actually executed right
to left! Talk about counter intuitive.

What's the purpose of "tee", is it the same as "tap"? "tap" in
Ruby just returns the receiver after executing a block. This
would be the implementation in D:
T tap (alias block, T) (T t)
{
block(t);
return t;
}
--
/Jacob Carlborg

What's the purpose of "tee", is it the same as "tap"? "tap"
in Ruby just returns the receiver after executing a block.
This would be the implementation in D:

Yeah "tee" is a horrible name, no chance I would have guess
what it means just by the name. "tap" is much better.

I think it's meant to mimic the UNIX command with the same
name? If you know about the command, the function's purpose
seems obvious.

...and has pretty much nothing in common with it! Also I don't
see "requires UNIX familiarity to be used intuitively" warning in
Phobos docs. Actually for similar reasons "tap" is also inferior
to "each".

So I toyed around a little. I played with mostly tee/tap and each. The
first observation is that both can help make a "2D" ufcs chain, which is
pretty nice. It makes more sense (IMO) to code it that way, than to use
awkward "join", to concatenate the "2D" range into a continuous "1D"
range, eg: join(lines, "\n");
First: "tee".

Nice work! This convinced me that tee should call the lambda only upon
the first call to .front on each iteration.
Andrei

I don't think it's so complicated. It's just taking this.
someRange.mungeItHowever.each!useIt;
Instead of writing this.
foreach(someThing; someRange.mungeItHowever) someThing.useIt;
Maybe it's like the difference between writing foo(bar) and
bar.foo. It can just look a little nicer.

I'm using Ruby every day. I don't really see much point in having
"each" in D. We already have "foreach". Ruby uses "each" since it
doesn't have "foreach". It to have a "for", which is a form of
foreach, but that is just lowered to "each" anyway.
Also, I don't see a point in having "each" which is lazy.
--
/Jacob Carlborg