4 ms·
I'm not sure why the comment above received downvotes (I don't have enough karma to downvote). I agree that perhaps the term "reducing function" isn't entirely
by sesm 3y ago
I'm not sure why the comment above received downvotes (I don't have enough karma to downvote). I agree that perhaps the term "reducing function" isn't entirely accurate.
However, it's worth noting that transducers aren't strictly about sequence-to-sequence transformations. From its inception, the Clojure standard library was built upon the `seq` protocol, and all its collection functions were constructed using this protocol. If it were possible to implement the `seq` protocol on channels, it would address the issue. However, it's not feasible. When querying a channel about its next element, the only honest answer is, "I can't determine that without potentially waiting indefinitely until the next message comes in or the channel closes." Turning the `seq` protocol into an asynchronous IO-bound process would be problematic. This is why transducers are essential.
- thom 3y agoYes, I'm being pernickety about naming and then misusing it myself! I use 'sequence' in a very loose sense to mean any sequential stuff you might push through a stack of transducers one at a time. core.async does actually use all the reducer plumbing to fill up buffers and pass them around. But I still think the key intuition for transducers should be push-based, stepwise operation (with the option to accumulate state or short circuit, as you go). It definitely helps that you can perform the final step of whatever job you're doing and have full control over how your stuff is materialised, without any intermediate collections, but it still feels slightly secondary to me.