I’ve been aware of that. My demonstration was meant to show that a chain with two streams and a stream-to-stream (map) operation in between takes much more processing time than a chain with one stream and the mapping in front of or behind the stream. I had 10k items generated all at once in order to create some mass and make the runtime difference visible (1k would have been fine, too; but with just a single item the result would have been unreliable due to random influences).
Even so I made a mistake:
is not realistic, it should have been like:Multiplicate stream items
I mentioned I was thinking about a spawn
operation. The idea is a single input stream element may generate multiple output stream elements, individually mapped. So e.g. (. x .) -> (. x2 (print x) .). Each of the outputs would also be conditional - it’s a kind of antagonist of keep
. Such operation could facilitate splitting a stream: items may be marked such that consumers will recognize items that may be of relevance for them.
I dipped a toe in the water by constructing a simple item duplicator:
In the end stream-spawn
should do something like the following, but with streams.
Actually, spawn
can do anything list comprehension
can do, and more.
Perhaps spawn
is not the best of names, as it usually refers to new processes, not data items; multiply
may be better, it’s just that it could be mixed up with multiplication as an arithmetic operator.