4 ms·

I have some experience with effects, mostly from noodling around with Koka and implementing a small effect-based toy language. (Which I intend to integrate into

I have some experience with effects, mostly from noodling around with Koka and implementing a small effect-based toy language. (Which I intend to integrate into a larger language I'm working on.) There are a few downsides, and they fall into four categories: 1. Effect sets get rid of external effect ordering. If you have an effect set {A, B}, you can't know if A happens before B without reading the code. Same issue as monad transformers. 2. Handlers are sometimes hard to reason about. A handler is essentially a fancy try/catch block for resumable exceptions. And construct that introduces a non-local control-flow dependency can be hard to reason about. (This is especially true as a compiler writer, haha) 3. The syntax is hard. I'm serious: how do you even represent an effect set? I went with a unison-like approach in my post, but this breaks down in an unsatisfactory if you make some other decisions. Also, what is an effect set in relation to your languages type system? Is it just a fancy enum? Should we allow other sets of types? What does an effect set mean on its own? 4. Lack of idioms and libraries. Result<T, E> is well-established - what idioms arise when programming with effects? In my experience, effects are rarely explicit, and are only used if you're trying to implement something using non-trivial control flow, like generators or cancellation.

dwohnitmok 5y ago
> If you have an effect set {A, B}, you can't know if A happens before B without reading the code. Same issue as monad transformers. Monad transformers don't have this issue. They have a well defined order in their types (e.g. `ExceptT e (StateT s)` is different from `StateT s (ExceptT e)` the latter blows away the state and aborts on an error, while the former preserves state on an error).
- isaacimagine 5y ago
  When working with monad transformers, I tend to stick to constraining functionality over unspecified monad. This essentially acts as a set (of constraints), which results in all the set-based woes that arise when effects are used. So not monad transformers themselves per se, you're right.

dwohnitmok 5y ago

> If you have an effect set {A, B}, you can't know if A happens before B without reading the code. Same issue as monad transformers. Monad transformers don't have this issue. They have a well defined order in their types (e.g. `ExceptT e (StateT s)` is different from `StateT s (ExceptT e)` the latter blows away the state and aborts on an error, while the former preserves state on an error).

isaacimagine 5y ago
When working with monad transformers, I tend to stick to constraining functionality over unspecified monad. This essentially acts as a set (of constraints), which results in all the set-based woes that arise when effects are used. So not monad transformers themselves per se, you're right.