3 ms·

I'm not really understanding the comparison (or isomorphism) between coroutines and effects. Feels like comparing Lists with functions, or promises with interf

by mrkeen 3y ago

I'm not really understanding the comparison (or isomorphism) between coroutines and effects. Feels like comparing Lists with functions, or promises with interfaces.

alephaleph 3y ago
A coroutine is a computation that can `yield`, suspending itself and passing control back up to the caller. It can then be resumed at the caller's leisure. An function with an effect (in this sense) is a function which can ask a handler to `perform` some effect for it. This suspends the function and passes control to whichever handler is in scope for that call, allowing that handler to resume the function at its leisure. I suspect that you're misunderstanding what is meant by effect, because despite buzz about them and backend support for them in OCaml 5, they aren't yet implemented with syntax and type-level support in any mainstream languages I'm aware of.
- galaxyLogic 3y ago
  > An function with an effect (in this sense) is a function which can ask a handler to `perform` some effect for it. Why does it need to ask a "handler" to do something, why can't it just call a function that does the "action" for it?
  - mrkeen 3y ago
    By making effects explicit, you reap the benefit of being able to write non-effectful code. Depending on what your language tracked as an effect, you could make your business-logic always terminate, or perform no allocations, if you had effects for Mutation/GeneralRecursion/Allocation. But no, I certainly don't understand the function->handler control flow here. It has to be handler->function, otherwise you've got two handlers!
  - reuben364 3y ago
    a function will return to it's call site (or diverge), a handler doesn't necessarily have to resume from where it was invoked. There is also (sort of) dynamic scoping, where you don't have to thread the handlers through calls.
noelwelsh 3y ago
I don't know your background, so I don't know at what level to pitch an explanation. Here's an attempt that assumes some knowledge of modern PLs. Effects require 1) well-defined control flow (think of IO; you need to know in what order output occurs) and 2) manipulation of control flow (think of error handling or concurrency). We can model effects as a back-and-forth between effect handlers, which carry out effects, and the user program. The user program passes control to the effect handler to carry out some effect, and the effect handler passes control back to the user program (potentially a different part of the user program; think error handling) when the effect has been performed. Continuations give complete control over control flow, so in their full generality effects require continuations (or some equivalent like monads). Coroutines are a slightly stilted form of continuations, that you can model much, but not all, control flow with.
- zozbot234 3y ago
  Aren't coroutines generally one-shot, whereas continuations could potentially be resumed to multiple times? This seems to be a relevant difference between these concepts.
  - dkjaudyeqooe 3y ago
    No, the whole point of coroutines is that you can resume them multiple times, otherwise it's just a simple function call.
    - Rusky 3y ago
      That's not what "resume multiple times" is referring to here. You can typically only resume a coroutine once per yield, while a continuation generally allows you to return to the same place multiple times.
      - naasking 3y ago
        Roughly, coroutine = a type of continuation with all mutable state, and continuation = a type of immutable coroutine.
naasking 3y ago
> Feels like comparing Lists with functions, or promises with interfaces Functions and lists are technically isomorphic, you just replace the function with a list of (domain, codomain) pairs and function invocation then becomes list lookup. This is basically the set theory definition of a function. So yes, this comparison to the article is apt, the article is saying that you can encode effects via coroutines.
mamcx 3y ago
This is like monads, is better to not look at the definition and just get examples. I like the way is presented here: https://mikeinnes.io/posts/transducers/ https://mikeinnes.io/posts/transducers/ The main gist is that "effect" allows you to define your own "except" of "try/except/finally"
- mrkeen 3y ago
  I make use of monads as effects, and that's why I'm not getting this article. I wrote "Feels like comparing Lists with functions" for a more general audience, but in my mind I was thinking: - Effects are Monads - Continuations are one particular Monad [1] - Coroutines are probably similar? - I would use monadic effects to allow/disallow a function from making use of Coroutines. - If my effect system *itself* uses Coroutines how do I use the effect system to forbid Coroutines? [1] https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-Monad-Cont.html https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-M...

by mrkeen 3y ago

I'm not really understanding the comparison (or isomorphism) between coroutines and effects. Feels like comparing Lists with functions, or promises with interfaces.

alephaleph 3y ago

A coroutine is a computation that can `yield`, suspending itself and passing control back up to the caller. It can then be resumed at the caller's leisure. An function with an effect (in this sense) is a function which can ask a handler to `perform` some effect for it. This suspends the function and passes control to whichever handler is in scope for that call, allowing that handler to resume the function at its leisure. I suspect that you're misunderstanding what is meant by effect, because despite buzz about them and backend support for them in OCaml 5, they aren't yet implemented with syntax and type-level support in any mainstream languages I'm aware of.

galaxyLogic 3y ago
> An function with an effect (in this sense) is a function which can ask a handler to `perform` some effect for it. Why does it need to ask a "handler" to do something, why can't it just call a function that does the "action" for it?
- mrkeen 3y ago
  By making effects explicit, you reap the benefit of being able to write non-effectful code. Depending on what your language tracked as an effect, you could make your business-logic always terminate, or perform no allocations, if you had effects for Mutation/GeneralRecursion/Allocation. But no, I certainly don't understand the function->handler control flow here. It has to be handler->function, otherwise you've got two handlers!
- reuben364 3y ago
  a function will return to it's call site (or diverge), a handler doesn't necessarily have to resume from where it was invoked. There is also (sort of) dynamic scoping, where you don't have to thread the handlers through calls.

noelwelsh 3y ago

I don't know your background, so I don't know at what level to pitch an explanation. Here's an attempt that assumes some knowledge of modern PLs. Effects require 1) well-defined control flow (think of IO; you need to know in what order output occurs) and 2) manipulation of control flow (think of error handling or concurrency). We can model effects as a back-and-forth between effect handlers, which carry out effects, and the user program. The user program passes control to the effect handler to carry out some effect, and the effect handler passes control back to the user program (potentially a different part of the user program; think error handling) when the effect has been performed. Continuations give complete control over control flow, so in their full generality effects require continuations (or some equivalent like monads). Coroutines are a slightly stilted form of continuations, that you can model much, but not all, control flow with.

zozbot234 3y ago
Aren't coroutines generally one-shot, whereas continuations could potentially be resumed to multiple times? This seems to be a relevant difference between these concepts.
- dkjaudyeqooe 3y ago
  No, the whole point of coroutines is that you can resume them multiple times, otherwise it's just a simple function call.
  - Rusky 3y ago
    That's not what "resume multiple times" is referring to here. You can typically only resume a coroutine once per yield, while a continuation generally allows you to return to the same place multiple times.
    - naasking 3y ago
      Roughly, coroutine = a type of continuation with all mutable state, and continuation = a type of immutable coroutine.

naasking 3y ago

> Feels like comparing Lists with functions, or promises with interfaces Functions and lists are technically isomorphic, you just replace the function with a list of (domain, codomain) pairs and function invocation then becomes list lookup. This is basically the set theory definition of a function. So yes, this comparison to the article is apt, the article is saying that you can encode effects via coroutines.

mamcx 3y ago

This is like monads, is better to not look at the definition and just get examples. I like the way is presented here: https://mikeinnes.io/posts/transducers/ https://mikeinnes.io/posts/transducers/ The main gist is that "effect" allows you to define your own "except" of "try/except/finally"

mrkeen 3y ago
I make use of monads as effects, and that's why I'm not getting this article. I wrote "Feels like comparing Lists with functions" for a more general audience, but in my mind I was thinking: - Effects are Monads - Continuations are one particular Monad [1] - Coroutines are probably similar? - I would use monadic effects to allow/disallow a function from making use of Coroutines. - If my effect system *itself* uses Coroutines how do I use the effect system to forbid Coroutines? [1] https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-Monad-Cont.html https://hackage.haskell.org/package/mtl-2.3.1/docs/Control-M...