yoricksijsling

3 ms·

1. 1.▲
   by yoricksijsling 4y ago

   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, someo
2. 2.▲
   by yoricksijsling 4y ago

   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
3. 3.▲
   by yoricksijsling 4y ago

   Oof, I don’t think that’s intentional. I’ve passed it on to the frontend team!
4. 4.▲
   Parallel streaming in Haskell: Part 4 – Conditionals and non-blocking evaluation(channable.com)

   75 points by yoricksijsling 4y ago|8 comments
5. 5.▲
   Parallel streaming in Haskell: Part 3 – A parallel work consumer(channable.com)

   8 points by yoricksijsling 4y ago|0 comments
6. 6.▲
   by yoricksijsling 4y ago

   Precisely. Conduits basically do everything on demand. For parallel processing the backpressure becomes a bit more complicated, in particular if you end with a sequential consumer. If you're just doing your parallel tasks when a sequen
7. 7.▲
   by yoricksijsling 4y ago

   > All the discussion of GC-friendliness of caches makes me think that there aren't any conduits that have more data than can fit in memory on a single machine. Yep! That's currently still the case. We do have some ideas to put