Parallel streaming in Haskell: Part 4 – Conditionals and non-blocking evaluation
channable.comIrrelevant to article content, but did anyone else find the cookie UX on this site infuriating?
Yes. I could not tell whether I was enabling or disabling cookies. I don't know whether that was badly done, or a dark pattern.
Oof, I don’t think that’s intentional. I’ve passed it on to the frontend team!
No reject all button => clicking back button
I thought that Arrows (https://www.haskell.org/arrows/) can handle conditionals, and the splitting and joining of concurrent streams of computation?
Is there something novel about this approach that is distinct from Arrows?
Arrows don’t really _do_ anything. Just like monads, they’re just a generic interface and their behaviour depends entirely on the instance implementation.
You can have stream transformers that fit in de arrow class, and parallel composition might then mean that things are done concurrently. How that compares to our approach entirely depends on the exact stream transformer implementation.
Note that the ConduitT type that we use doesn’t really fit in the Arrow class, due to the additional parameter for the return type.
Arrows do imply certain behaviours, if the laws are to be satisfied. For example, they require synchronous streams. This means one can't really do things like coalescing very easily.
I never really used Arrows, let alone stream transformers with an Arrow interface, but yes that makes sense. With the conduit library you’d use ZipConduit which has the same characteristics.
On reddit, in reply to the first blog post, someone asked how ZipConduit compared to our parallel streams. Maybe that’s helpful for hosh as well. https://www.reddit.com/r/haskell/comments/10339fe/comment/j2...