{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreibcipitaekchr3icmzhs4orzqmmlpxjazmdjlpyb2zxkm46okz4mi",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mlea4c673mo2"
  },
  "path": "/t/category-transformers/14054#post_4",
  "publishedAt": "2026-05-08T15:15:02.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "Concisely: Many monad transformers are based on `CatFunctor`s on Kleisli categories.\nLook at the type of `Kleisli . mapM . runKleisli`.\n\nShould we stop using monads?\n\nFor a long time I believed that “lambda calculus enriched with effect E” would have semantics in the Kleisli category of E. But that can’t be true, since models of lambda calculus are cartesian closed categories and Kleisli categories are almost never cartesian closed. This hints at why Kleisli arrows might not be an ergonomic way to program. Instead, theoreticians painstakingly examine questions like “Is the cartesian closed sub-category C of D also closed under the monad E: D → D?”\n\nI once tried using arrows for a model that used the `RWST` monad as effect, hoping that arrows would make documentation of data flow neater. But it turned out that do-notation is far more ergonomic in Haskell. For example, you can sprinkle let-bindigs and shared variables anywhere, have multi-parameter monadic functions, versus tedious funneling of data with `(&&&)` and `(***)`.",
  "title": "Category transformers"
}