MonadPar everywhere

[garyb]

#12 is a little problematic, the introduction of MonadPar constraints on all the operations really restricts what you can do with coroutines now - you can't even run the examples as they're in Eff instead of Aff.

Additionally, it causes problems in Halogen, as there's no MonadPar instance for Free. I could make something up, but it wouldn't make much sense.

Would it possible to have a fuseWithPar or something like that for the cases where you really want it, and then restore the previous behaviour for the standard cases?

/cc @natefaubion

[paf31]

I would have liked to have used Applicative instead of MonadPar, but we still need Monad, which might not have the same Applicative instance (parallelism). Maybe we could provide a newtype with an instance for MonadPar, for any Monad (not really parallel, which we'd have to document).

[natefaubion]

Is MonadPar required for correct semantics in general? With the change, purescript-coroutines has gone from a general usage pipes/conduit-like tool, to essentially a wrapper around Aff. Would it make more sense to move some hypothetical fuseWithPar implementation + combinators to aff-coroutines?

[natefaubion]

Is MonadPar required for correct semantics in general?

The reason I ask this, is that MonadPar was introduced to solve an issue with using cotransform with Aff, wasn't it? If you had used Applicative rather than Monad (and didn't need Monad), the problem would not have been fixed in any case because Aff's Applicative instance is not parallel.

[paf31]

I agree it's not ideal. The problem is that in quite a few cases, we really do need to run the two coroutines in parallel, or we won't see effects run until some time later. This isn't just limited to cotransform, it was previously an issue with Producer and Consumer in some cases too, which is why I switched around the order in which they ran (in sequence) at one point, which was a total hack.

I'm happy to discuss alternative approaches, of course.

[natefaubion]

My alternative suggestion would be to just create a separate Control.Coroutine.Parallel module exporting the same combinators with a MonadPar constraint.

[paf31]

I'd like to avoid duplication of code if possible.

For my purposes in Thermite, I can probably fuse coroutines manually, so maybe the best solution is to just go back to the original approach, and provide additional helper functions. For example, one variant on fuse could use a Monad and a separate Applicative and take a pair of natural transformations as additional arguments.