The example does not work as expected about purescript-aff-coroutines HOT 4 CLOSED

The problem appears to be in the produce function, because the produceAff function works as expected.

produce
  :: forall a r eff
   . ((Either a r -> Eff (avar :: AVAR | eff) Unit) -> Eff (avar :: AVAR | eff) Unit)
  -> Producer a (Aff (avar :: AVAR | eff)) r
produce recv = produceAff \send ->
  liftEff (recv (void <<< runAff (const (pure unit)) <<< send))

In other words, the problem is in the argument to produceAff. Here is a (verbose) version of produce that works:

produce (recv :: (Either a r -> Eff (avar :: AVAR | eff) Unit) -> Eff (avar :: AVAR | eff) Unit) = produceAff f
  where
    f :: (Either a r -> Aff (avar :: AVAR | eff) Unit) -> Aff (avar :: AVAR | eff) Unit
    f send = liftEff $ recv send'
      where
        send' :: (Either a r -> Eff (avar :: AVAR | eff) Unit)
        send' ear = void $ runAff (const (pure unit)) (send ear)

The signature of f is taken from the argument to produceAff. This clearly exposes the main puzzle of the function produce, that is: it receives a function recv that takes a function with argument (Either a r -> Eff (avar :: AVAR | eff) Unit), that is, a function in Eff, but needs, for f, a function with similar type but in Aff. So we postulate the solution send' that conforms to that signature.

Then, writing out send' with the (Either a r) argument made explicit, it is clear we have to runAff the original send function on that argument, voiding the result.

All in all it boils down to this:

void <<< runAff (const (pure unit)) <<< send

is not equal to:

\ear -> void $ runAff (const (pure unit)) (send ear)

And we need the former. So the correct definition of produce should be:

produce recv = produceAff \send ->
  liftEff $ recv \ear -> void $ runAff (const (pure unit)) (send ear)

from purescript-aff-coroutines.

Ah. I closed the issue, but obviously the change has yet to be made to the library!

from purescript-aff-coroutines.

The current version in master does not appear to behave the way you're describing:

p' :: Producer String Aff String
p' = produce \emitter -> do
  log "Working..."
  emit emitter "progress"
  log "Done!"
  close emitter "finished"

c :: Consumer String Aff String
c = consumer \s -> liftEffect (log s) $> Nothing

main :: Effect Unit
main = void $ runAff (either logShow log) $ runProcess (p' $$ c)

Produces:

Working...
Done!
progress
finished

The ordering isn't exactly right due to the way the process is fused, but you can see it is hitting each of the logs and emits as expected though.

It's very odd that the curried version does not appear to behave the same as the eta-expanded version for you... the compiler actually rewrites the former into the latter! I suspect maybe there's something else going on?

from purescript-aff-coroutines.

That is odd indeed! It must be some effect then of the package versions I've used? See the bower.json file below.
I've checked again in new project directory, this time based on the package-set psc-0.11.7-20180524 and you are quite right, there is no error then.
Same compiler version, same Node version.
It is beyond me.

{
  "name": "purescript-node-net",
  "version": "0.0.1",
  "moduleType": [
    "node"
  ],
  "ignore": [
    "**/.*",
    "node_modules",
    "bower_components",
    "output"
  ],
  "dependencies": {
    "purescript-aff": "4.1.1",
    "purescript-foreign": "4.0.1",
    "purescript-exceptions": "3.0.0",
    "purescript-debug": "3.0.0",
    "purescript-node-process": "4.0.0",
    "purescript-aff-coroutines": "6.0.0"
  },
  "devDependencies": {
    "purescript-yargs": "3.0.0",
    "purescript-node-readline": "3.0.1"
  }
}

from purescript-aff-coroutines.