3 ms·

Are you sure you don't mean 'commute'? Monads, being endofunctors, compose just fine. Though the composition may or may not be a monad I suppose.

the-alt-one 5y ago
"Monads don't compose" is a common sentence (google it!), for example here: https://stackoverflow.com/questions/7040844/applicatives-compose-monads-dont https://stackoverflow.com/questions/7040844/applicatives-com... Maybe you already knew about this and is still asking, though?
- contravariant 5y ago
  I wasn't aware. The examples given here are all cases where the monad doesn't commute, hence my question. If two monads commute you can show that the composition of the two is (trivially) a new monad, but I'm not sure if the converse also holds.
  - kmill 5y ago
    It's not very precise talking about whether a monad commutes -- it's not clear what "commutes" should really mean (certainly not F . G = G . F since that's way too restrictive). I started working it out by hand, but then figured nLab had it somewhere, and indeed: https://golem.ph.utexas.edu/category/2017/02/distributive_laws.html https://golem.ph.utexas.edu/category/2017/02/distributive_la... F, G, and F.G are monads if and only if there is a "distributive law," which is a natural transformation G.F -> F.G satisfying some properties. It's like something that satisfies half the braiding properties, where braidings are already a weaker version of commutativity.
    - contravariant 5y ago
      That's a very interesting article, thanks. That said while FG = GF is indeed restrictive, requiring there to be a natural isomorphism between them is slightly less restrictive and just requiring the existence of a distributive law seems a bit too broad. What's preventing the existence of multiple distributive laws? Is there even anything preventing monads from always having a distributive law?
      - kmill 5y ago
        There is nothing at all preventing the existence of multiple distributive laws, and I can think of some (non-programmy) examples that have multiple possibilities. I wouldn't be surprised if some cohomology group classifies them, at least in certain settings. I don't know about whether distributive laws always exist, but what is probably true is that there's no universal distributive law -- that's in the sense that you have a function from pairs of monads to distributive laws that is natural with respect to homomorphisms of monads, whatever those are (I know there's a bicategory of monads, but that's about it).
isaacimagine 5y ago
As you said, the composition of a monad may not be a monad, which means it may not be possible to compose the result of a monadic composition with another monad. You can always trivially compose a set of effect sets (union), though.
- contravariant 5y ago
  That doesn't sound right, even if the composition fails to be a monad it's still a functor so there's no reason you couldn't keep composing with other functors (in particular other monads).
  - pdpi 5y ago
    But that is precisely why we say that functors compose (in the general case) and monads don't (again, in the general case)!
  - dllthomas 5y ago
    While getting at a real issue, people are being sloppy with what they mean by "monads" and "compose" on both sides of it. Types which are monads compose to make types that are definitely functors but maybe (probably?) not monads. That "maybe not" is what type theory people mean when they say "monads don't compose" but it's mostly not what's bugging people because... Most monads can be rewritten as monad transformers (where applying them to the identity monad reproduces the original monad), which do compose in that way, and this is often what people do in Haskell when they have code that needs multiple effects. But! Values of different types (like, say, a `WriterT t (Identity u)` and a `WriterT t (IO u)` can't be composed using the ever-so-convenient Monad interface which is the reason we wanted to make things Monads in the first place. This is what the article is discussing and it's what programmers often mean when they say "monads don't compose". The workaround in the Haskell ecosystem (at least in those parts that haven't adopted effect systems or free monads w/ interpreters) is to write as much of your logic as possible using an unspecified monad, only asking for the functionality you need by way of constraints. Constraints compose like gangbusters! Values with unifiable types that have different sets of constraints? Well, it must've been a type that satisfies all of those constraints. And the abstract type is a nice place to stick in mocks as you test the pieces of things. This shares much of the downside of effect sets, in that it is awkward to specify order ("layering"?) of effects when they do matter; it's possible to be more concrete about the types for those pieces but it does spread to the pieces that contain them and can sometimes get boilerplatey. Whether that's worth it for the added safety is going to be context dependent.

the-alt-one 5y ago

"Monads don't compose" is a common sentence (google it!), for example here: https://stackoverflow.com/questions/7040844/applicatives-compose-monads-dont https://stackoverflow.com/questions/7040844/applicatives-com... Maybe you already knew about this and is still asking, though?

contravariant 5y ago
I wasn't aware. The examples given here are all cases where the monad doesn't commute, hence my question. If two monads commute you can show that the composition of the two is (trivially) a new monad, but I'm not sure if the converse also holds.
- kmill 5y ago
  It's not very precise talking about whether a monad commutes -- it's not clear what "commutes" should really mean (certainly not F . G = G . F since that's way too restrictive). I started working it out by hand, but then figured nLab had it somewhere, and indeed: https://golem.ph.utexas.edu/category/2017/02/distributive_laws.html https://golem.ph.utexas.edu/category/2017/02/distributive_la... F, G, and F.G are monads if and only if there is a "distributive law," which is a natural transformation G.F -> F.G satisfying some properties. It's like something that satisfies half the braiding properties, where braidings are already a weaker version of commutativity.
  - contravariant 5y ago
    That's a very interesting article, thanks. That said while FG = GF is indeed restrictive, requiring there to be a natural isomorphism between them is slightly less restrictive and just requiring the existence of a distributive law seems a bit too broad. What's preventing the existence of multiple distributive laws? Is there even anything preventing monads from always having a distributive law?
    - kmill 5y ago
      There is nothing at all preventing the existence of multiple distributive laws, and I can think of some (non-programmy) examples that have multiple possibilities. I wouldn't be surprised if some cohomology group classifies them, at least in certain settings. I don't know about whether distributive laws always exist, but what is probably true is that there's no universal distributive law -- that's in the sense that you have a function from pairs of monads to distributive laws that is natural with respect to homomorphisms of monads, whatever those are (I know there's a bicategory of monads, but that's about it).

isaacimagine 5y ago

As you said, the composition of a monad may not be a monad, which means it may not be possible to compose the result of a monadic composition with another monad. You can always trivially compose a set of effect sets (union), though.

contravariant 5y ago
That doesn't sound right, even if the composition fails to be a monad it's still a functor so there's no reason you couldn't keep composing with other functors (in particular other monads).
- pdpi 5y ago
  But that is precisely why we say that functors compose (in the general case) and monads don't (again, in the general case)!
- dllthomas 5y ago
  While getting at a real issue, people are being sloppy with what they mean by "monads" and "compose" on both sides of it. Types which are monads compose to make types that are definitely functors but maybe (probably?) not monads. That "maybe not" is what type theory people mean when they say "monads don't compose" but it's mostly not what's bugging people because... Most monads can be rewritten as monad transformers (where applying them to the identity monad reproduces the original monad), which do compose in that way, and this is often what people do in Haskell when they have code that needs multiple effects. But! Values of different types (like, say, a `WriterT t (Identity u)` and a `WriterT t (IO u)` can't be composed using the ever-so-convenient Monad interface which is the reason we wanted to make things Monads in the first place. This is what the article is discussing and it's what programmers often mean when they say "monads don't compose". The workaround in the Haskell ecosystem (at least in those parts that haven't adopted effect systems or free monads w/ interpreters) is to write as much of your logic as possible using an unspecified monad, only asking for the functionality you need by way of constraints. Constraints compose like gangbusters! Values with unifiable types that have different sets of constraints? Well, it must've been a type that satisfies all of those constraints. And the abstract type is a nice place to stick in mocks as you test the pieces of things. This shares much of the downside of effect sets, in that it is awkward to specify order ("layering"?) of effects when they do matter; it's possible to be more concrete about the types for those pieces but it does spread to the pieces that contain them and can sometimes get boilerplatey. Whether that's worth it for the added safety is going to be context dependent.