4 ms·

Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]

Sometimes two monads composed don't form another monad. Unlike Functors and Applicatives. Simple example, if you have a list containing functions ([Reader r a]) it forms an Applicative fine as they compose. However you can't satisfy the conditions needed to form a Monad.

danharaj 9y ago
You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.
- alphaalpha101 9y ago
  This reminds me of the 'fine-grained permissions' vs. 'broad permissions' security models. The former is more expressive, more powerful, etc. It also is technical, complicated and confusing. The latter is less powerful and less expressive, but people actually use it, because it's simple and easy to understand. Expressing effects using monad transformer stacks might be more expressive and allow finer-grained distinctions, or whatever (please elaborate what you mean, I'm interested), but it's syntactically ugly (lift), it's confusing, and it's not clear that the expressiveness you get is practically useful. In contrast, algebraic effects might 'only handle effects that trivially commute' (again, going to need more detail on this), but they're easy to understand and easy to use. They're much more likely to be a practically usable effect system that real programmers can really use in the real world in a way that doesn't convolute code with details of how you compose effects unduly.

danharaj 9y ago

You can compose monads whenever you have a distributive law for them. Usually there's an obvious one. In your example there's a distributive law that uses the same parameter for every function, this allows you to compose the monads. When there's several possible distributive laws or none, that's important. It means that either the interactions between the two effects are subtle and need to be further specified or they are completely incompatible. Algebraic effects can only handle effects that trivially commute. So monad composition is a finer, thus more expressive operation.

alphaalpha101 9y ago
This reminds me of the 'fine-grained permissions' vs. 'broad permissions' security models. The former is more expressive, more powerful, etc. It also is technical, complicated and confusing. The latter is less powerful and less expressive, but people actually use it, because it's simple and easy to understand. Expressing effects using monad transformer stacks might be more expressive and allow finer-grained distinctions, or whatever (please elaborate what you mean, I'm interested), but it's syntactically ugly (lift), it's confusing, and it's not clear that the expressiveness you get is practically useful. In contrast, algebraic effects might 'only handle effects that trivially commute' (again, going to need more detail on this), but they're easy to understand and easy to use. They're much more likely to be a practically usable effect system that real programmers can really use in the real world in a way that doesn't convolute code with details of how you compose effects unduly.