😿 Monad Transformers: A Defense (yes I know, please read before groaning)

*long suffering sigh*

...okay fine I read it. You raise point 3 which I wasn't expecting from you. Groaning retracted conditionally. Don't make me regret this. nya~

*sees thread title*

GROAN

*reads post*

...okay the point about free monads is fair but let me push back on point 2. The "known workarounds" argument kind of falls apart at scale. The functional dependency issue with MTL isn't just an edge case — mtl makes use of functional dependencies to retain type inference, but this comes at a compositional cost when the same typeclass appears at multiple transformer layers. You can work around it but you're basically writing the effect system that effect systems solved for you.

Also the WriterT thing isn't just space leaks. The semantics are genuinely weird when combined with exceptions. If you throw in ExceptT and WriterT is above it, you lose all your log output. If WriterT is below, you keep it. The order matters and it's non-obvious. Effect systems let you specify semantics more explicitly.

First time posting in an MT thread without immediately leaving. Good sign.

What I don't see discussed enough: the actual academic connection between the two approaches. There's a paper — "Monad Transformers and Modular Algebraic Effects: What Binds Them Together" (Schrijvers et al., Haskell '19) — that formalizes exactly this. every monad transformer for algebraic operations gives rise to a modular effect handler. They're not opposites. They're duals in a precise categorical sense.

The community argues about mtl vs polysemy like they're fundamentally different paradigms. They're not. Polysemy's interpreter is a monad transformer in disguise. Effectful's Eff monad is explicitly described as "essentially a ReaderT over IO on steroids." If effectful is acceptable, you've already accepted the ReaderT pattern. You're just using a library to manage the dictionary-passing that ReaderT does manually.

Groan. (Required by forum tradition. I still read the post.)

Polysemy defender checking in. The "cryptic error messages" point lands, I won't lie. When you get a No instance for (Member (Embed IO) r) error nested inside three other constraints it's... not fun. And yes, compile times with polysemy + type-level lists are genuinely rough. I've seen 45-second incremental compile times on medium-sized polysemy projects.

But the interpreter composability is real. The thing transformers genuinely can't do easily: you can run the same Sem r a computation under completely different interpreters in the same binary. Pure interpreter for property tests with QuickCheck, IO interpreter for integration tests, mock interpreters for unit tests — all without touching the business logic. With a transformer stack you're either parameterizing over a typeclass (which you need MTL for, buying back complexity) or you're hardcoding the stack.

This is a genuinely good point and I want to acknowledge it properly. The interpreter-swap pattern for testing is real and useful. My counter: with MTL typeclasses you get the same benefit, the architecture is just different. You write against MonadState AppState m instead of Member (State AppState) r, and your test instantiates m ~ Identity while prod uses the full transformer stack. Both approaches work. MTL is more "standard library" and less extra-dependency. But polysemy wins on ergonomics for complex interpreter trees — agreed.

Where I push back: for simple CRUD apps, microservices, or any codebase that a junior Haskeller needs to navigate — transformer stacks are much more learnable. The cognitive overhead of polysemy's type-level machinery is not trivial. "It's just a list in the type" stops being reassuring when you see a type error 8 lines long. At least with transformers, Real World Haskell chapter 18 explains everything in plain english. nya~

OK I'll be the effectful shill. I switched from polysemy to effectful last year and I'm not going back, but I'll admit OP has a point about effectful basically being a ReaderT in disguise.

The effectful Eff monad is designed as essentially a ReaderT over IO, extended with data types representing effects. The key win: the concrete monad type means GHC has many opportunities for optimization — in benchmarks it runs extremely close to equivalent mtl code at default optimization levels. No INLINE pragmas needed everywhere. And you get interop with MonadUnliftIO and MonadBaseControl basically for free, which polysemy made you cry over.

The honest comparison table from my notes:

Transformer stacks win on "small, stable effect set." Effectful wins on "medium complexity IO-heavy app." Polysemy wins on "I need true interpreter composition and I'm willing to pay the price." nya~

Can you expand on this? I've always considered the lack of ContT in effect systems a genuine hole. The fused-effects docs even acknowledge that mtl provides ContT and they don't, though they note "many behaviours possible with delimited continuations (e.g. resumable exceptions) are directly encodable as effects." But that's a bit of a dodge because the encoding isn't always clean.

Also re: free monads specifically (since I'm contractually obligated to defend them): they're genuinely useful for a different problem class — DSL construction and program transformation. If you're writing an AST and you want to interpret it multiple ways, Free is a natural fit. The performance penalty is real but overblown for that use case. "Freer monads are today somewhere around 30x slower than equivalent mtl code" is the inflammatory stat that gets thrown around — but that's microbenchmark bind overhead, not application-level performance. Network IO drowns it out.

Can we zoom out for a second to the actual theoretical picture? Algebraic effects as defined by Plotkin & Pretnar have a clean semantics: effects are operations plus handlers, handlers are folds over effectful trees. Monad transformers preceded this but address the same problem class with a different formalism.

The key insight from the literature: a modular algebraic effect handler and a monad transformer for the same algebraic operations are mathematically equivalent. This is what Schrijvers et al. proved formally. So the mtl vs. effects debate is partly a taste debate dressed up as a correctness debate.

Where algebraic effects genuinely win on theory: higher-order effects like local in ReaderT or catch in ExceptT. In a purely first-order algebraic effect system, scoped operations like these have to be implemented as interpreters, losing the ability to reinterpret them later. This is the "higher-order effects problem" and it's what keeps fused-effects and polysemy from being fully algebraic in the original Plotkin sense. Katsellov did a good post on this last year.

For Haskell specifically: the ROW typed algebraic effects approach (as in Koka language) avoids all this cleanly, but Haskell doesn't natively support row types, so every effect library is approximating. Transformer stacks are a different approximation strategy, not an inferior one. nya~

GROAN (pre-emptive, not based on content)

GROAN (also retroactive)

Just use IO. Pass your config as function arguments. Use IORef for mutable state. Throw exceptions with throwIO. This is a solved problem that does not require 400 posts to discuss. I have shipped more Haskell to production than anyone in this thread and my monad stack is: IO. Flat IO. Just IO.

...that said the comparison table in #8 is accurate and fair so I'm not fully groaning. Mostly groaning. nya (begrudgingly).

This thread is going better than I expected. I thought I'd have to fight through 50 groan-only posts before anyone engaged substantively. You're all secretly type theory nerds and I love that about CGPA.

Let me try a synthesis of what we have so far:

When to use a transformer stack: Small (<4), known, stable effect set. Team unfamiliar with effect systems. High performance requirements where you can't afford even effectful overhead. Pure computation with Identity at the base. "Library API" code where you want to expose MonadX typeclasses for maximum flexibility.

When to use effectful: IO-heavy application with medium effect complexity. Need MonadUnliftIO compatibility. Want effect swapping for testing. Want performance close to mtl without the lifting boilerplate.

When to use polysemy: You need true interpreter composition. You're building something where the same program genuinely needs multiple semantically distinct interpretations. You're OK with paying the compile time cost.

When to use free monads: DSL construction. Program analysis and transformation. Cases where you want to inspect the structure of a computation before running it.

When to use flat IO (hat tip to GrumpyCatIO): You're a professional and you don't need any of this. nya~

Coming in late as a relative newcomer — I learned Haskell last year and I want to give the newbie perspective that post #7 mentioned.

I picked up transformer stacks first because Real World Haskell covered them. I understood them in a weekend. Then I tried polysemy. I spent three days confused by type errors before I got a hello-world working. The community is right that effect systems are more ergonomic once you understand them — but the learning curve asymmetry is massive. "Just learn the type-level list stuff" isn't beginner-friendly advice.

Effectful was actually friendlier because the error messages are closer to what I was used to. But I still think transformer stacks deserve a place in the ecosystem as the "introductory" approach. Maybe I'm wrong. What did other people learn first? nya~

MeownadTransformer's post #12 is getting pinned in the wiki. Locking the thread would be a crime so I'm not doing that. Continue. But if the groan-to-content ratio drops below 1:2 I'm adding a mandatory kitten pic requirement. This is a formal warning. nya~ 🐱