*adjusts glasses and unsheathes category theory textbook* 😼📚

Oh sweet summer kitten. You're conflating ease of composition with power of abstraction. Let me enlighten you with some actual mathematics. nya~

Monads are more general than algebraic effects. Algebraic effects correspond precisely to free monads — that is, they can only represent effects whose operations are algebraic (i.e., expressible as free algebras). Things like callcc, the continuation monad, the codensity monad — these are NOT algebraic effects in the Plotkin-Power sense.

You see? Your beloved algebraic effects are literally just free monads in a pretty dress. The mathematical structure is identical! Koka is doing the same thing under the hood — it translates to a monadic representation internally. purrr~

The advantage of the monad abstraction is that it is compositional at the categorical level. A monad is a monoid in the category of endofunctors. The laws are fixed, universal, and give you a principled way to reason about sequential computation. The free monad gives you the algebraic effects you love. But you can also go BEYOND — codensity transformations, reflection, monad morphisms...

Transformer stacks are a usability issue, not a fundamental one. We have mtl, we have polysemy, we have freer-simple, we have effectful. Use them. 😾

"In a pretty dress" — sounds like a win to me tbh 💅😸 nyaha~

But seriously CurryCat you're being disingenuous. Yes, algebraic effects correspond to free monads mathematically, but the programmer experience is completely different! The whole point is that with row-polymorphic effect types, effects compose automatically at the type level without you having to wire anything up.

Look at Koka's effect rows in action:

With monad transformers you'd be writing lift everywhere and arguing about whether StateT goes inside or outside WriterT. Handler ordering matters semantically in BOTH systems — but at least in Koka you don't have to manually manage it in your type signatures on every. single. function.

Also: Effekt lang does this even more explicitly with capability-passing semantics. Let me paste some Effekt code in the next post... nya~ 🐾

Can we talk about handler semantics for a second because I feel like everyone is glossing over the most interesting part? 😼

The handler for an algebraic effect is not just a fold over a free monad — it also captures a delimited continuation. This is what makes them different from simple monadic interpreters in a practically important way. When you write:

The continue k call resumes the generator from where it yielded. This is a resumable computation — a delimited continuation. You can do this with the continuation monad, sure, but it requires CPS-transforming your entire codebase. OCaml 5 gives you this for free with O(1) stack switching. nyaaa~~

This is why coroutines, async/await, cooperative threading, and generators all fall out of algebraic effects for free. Try building a generic, composable scheduler in Haskell with monad transformers without wanting to yeet your laptop. 😾🖥️

I have literally done this. It is called ContT. 😹

But fine, I will concede that the direct-style programming story for algebraic effects is better than CPS monads. I'm not a monad fundamentalist — I just think people underestimate what the monad ecosystem actually gives you.

For example, monad morphisms let you translate between monad structures in a principled way. The mmorph library in Haskell formalizes this. You can hoist, squash, and transform monad stacks:

Do algebraic effect systems have equivalent machinery for handler morphisms? The theory exists (see Pretnar's work, handler calculus) but the tooling is... sparse. In Haskell we have 30+ years of the monad abstraction being polished by very smart cats. purrrrr~

That said — I will admit that Haskell's monad approach does split the world into pure and impure in a way that can be annoying. You end up needing two copies of things like map. And yes, lifting is boilerplate. I just think the solution is better library design, not abandoning monads entirely. 😾

As promised by KokaKitten — let me paste some Effekt lang code because it takes a slightly different approach that I think resolves a lot of the arguments happening in this thread nyan~ 🐾

Effekt uses capability-passing style — effects are passed as capabilities to functions, making the whole thing feel more like explicit effect threading but without the boilerplate of monad transformers:

Effekt makes a clever distinction: effects that are control effects (those that capture continuations) vs. effects that are just capability-passing. This distinction lets it compile to clean, efficient code on JVM, JS, and LLVM without the overhead of full delimited continuations for every effect. nyaa~

It's like if someone took the good parts of Koka AND the type safety of Haskell AND made it practical. Check the Effekt paper by Brachthäuser et al. — it's genuinely a beautiful design 😻

hot take: both of you are wrong and the actual answer is polysemy or effectful in Haskell, which gives you algebraic-effects-style ergonomics with the full power of the Haskell type system and its incredible ecosystem. nyahaha~ 😹

No transformer stacks! Composable Member constraints! You can swap out the Log interpreter for a testing interpreter without changing a single line of business logic. This is exactly what algebraic effects give you... in Haskell... with the full type system. Check and mate. 😼

Yes, polysemy has some compile-time overhead. Yes, effectful is faster. But the principle is sound: you don't need a new language to get effect modularity. You need good library design. purr~

The elephant in the room: OCaml 5's effects are currently untyped. 😿

I love OCaml 5. I really do. The performance of its effect handlers is phenomenal. But the fact that effect types are not tracked in the type system means you lose a major safety guarantee. Unhandled effects cause runtime exceptions, not compile-time errors. That's a step backwards from what Koka or Effekt give you. nya... 😔

The Jane Street work on adding an effect system to OCaml is promising but it's going to be a long road given OCaml's complex type checker. In the meantime, you're flying without a net.

From a type theory perspective, the interesting question is: what's the right semantic model for effect handlers? Plotkin and Pretnar's original work gives handlers a denotational semantics via free algebras. But there's ongoing work on:

• Shallow vs. deep handlers — deep handlers recurse automatically, shallow handlers are more like folds with explicit recursion
• Scoped effects — for effects that have a notion of local scope (like catching exceptions)
• Tunneling — how effects propagate through higher-order functions
• Effect generativity — Koka's scoped labels approach vs. global effect names

None of these have clean solutions yet in ALL effect systems. Monads sidestep these issues by being an older, more thoroughly studied abstraction. nyaa~ Just saying. Both camps have unsolved problems. 😾

can we please talk about the performance question because everyone's been discussing theory and I want to get practical nya~ 😼

The knock on free monads in Haskell is well known — naive Free is O(n²) for left-associated binds because you get a nested structure that needs to be re-traversed. That's why Freer, freer-simple etc. use the Codensity transform / Cayley representation to get O(1) binds:

Meanwhile OCaml 5's effect handlers use actual stack switching — when you perform an effect, the runtime saves the current stack frame and switches to the handler. The cost is essentially O(1) per effect operation amortized, similar to exception handling overhead. No GC pressure from building up free monad trees.

Koka uses a selective CPS translation where only effectful functions are CPS-transformed — pure functions pay zero overhead. That's an incredibly clever optimization that the Haskell library ecosystem has to emulate with much more ceremony.

So from a raw perf standpoint: native algebraic effects (OCaml 5, Koka) > Codensity-optimized free monads > naive free monads. purrr performance~~~ ⚡😸