purescript-contrib / purescript-coroutines Goto Github PK

To zip two producers. The dual can be defined for consumers, and both can be defined with fuseWith.

I'm listed as maintainer, but maybe I shouldn't be. I think this is used in Halogen, so maybe someone who uses Halogen would like to maintain this?

with the latest compiler, bower.json also needs to specify a license.

as @garyb say MonadPar constraints make this lib problematic. But fuseWithL show us that MonadPar is not needed as shown by pullFrom :: forall o m a. MonadRec m => Consumer o m a -> Producer o m a -> Process m a that use fuseWithL.

Similarly, we can do the same to Producer, let's name it pushTo with signature pushTo :: forall o m a. MonadRec m => Producer o m a -> Consumer o m a -> Process m a, it's push a producer to a hungry consumer and close immediately when the producer closed, which also practical, eg. a Http Server as consumer (write the input to socket) and the producer is route handler that yield streaming content.

I also tried to make all combinator use fuseWithL instead of fuseWith, and the test in this repo still yield expected output (eg- the effect immediately), including the cotransform test.

@paf31 can you please provides me a runnable code that show the problem you described in #15

The commented test:

main :: forall eff. Eff (console :: CONSOLE | eff) Unit
main =
  runProcess (nats $~ showing $$ printer)

Does not work for me with PureScript 0.9.1. The compiler says:

  Could not match type

    Transform t3

  with type

    Emit

while trying to match type Transform t3 String
  with type Emit t0
while checking that expression showing
  has type FreeT (Emit t0) t1 t2
in value declaration main

where t2 is an unknown type
      t1 is an unknown type
      t0 is an unknown type
      t3 is an unknown type

The README.md mentions the function runCo. However, it looks like this doesn't exist any more? This should be taken out of the README.md.

#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

This is not really a bug, but I'm wondering how to do something / asking if it's possible with the current implementation.

Is there any way to write something like the awaitForever from Data.Conduit? This would be for a Transformer type, but I don't see how you can do anything to make a transformer except by providing a pure function. I use this all the time in other streaming libraries in haskell to make something like a Transformer that can use the underlying m on the input, but I don't really see how to do this here. Am I missing something?

I know that this library was originally inspired by Coroutine Pipelines, but it seems that there is a very important construction there which generalizes everything, namely the Transducer type which is roughly equivalent to

type Transducer i o m a = Co (Coproduct (Await (Maybe i)) (Emit o)) m a

I know it would be possible if using something like this.