&gt; An `IO a` would translate to a lazy value, namely a function, which could be a continuation. There&#x27;s nothing stopping you from storing a continuation in a field. You can manipulate the `a` just like any value, and the &quot;IO&quot; with handlers -- just as you do with monads.<p>I think the Java world is finally accepting that methods are not a substitute for first-class values; one of the biggest remaining problems with Java lambdas is that it&#x27;s awkward to use them with checked exceptions (e.g. do you to create a named @FunctionalInterface for each input&#x2F;output&#x2F;exception combination you want to store? You can use generics but they don&#x27;t let you abstract over arity). Handling effects this way would presumably have the same problems?<p>Put it this way: Either[MyError, A] is much more useful to me than a checked MyException, because I can use the former as a value whereas the latter I can only throw from methods. That&#x27;s the difference I&#x27;m worried about here.<p>&gt; You need monad transformers not because of ordering, but because monads don&#x27;t generally compose. Or it&#x27;s a bit reversed: because monads don&#x27;t compose they are sensitive to accidental ordering (whether you care about the order or not), which makes monad transformers tricky. With continuations you have the choice of when to be sensitive to order and when not to.<p>What does the choice look like in code then? Under monads I&#x27;d write:<p><pre><code>    Left(MyError()).liftM[WriterT[...]]
    WriterT.tell(&quot;Here&quot;.point[...])
</code></pre>
or<p><pre><code>    EitherT.left(MyError().point[...])
    Writer.tell(&quot;Here&quot;).liftM[EitherT[...]]
</code></pre>
and while it&#x27;s clunky it&#x27;s clear which one&#x27;s which. Under your approach if I write:<p><pre><code>    throwc(new MyException());
    add(Writer.class, &quot;Here&quot;);
</code></pre>
then which semantics do I get, and how do I get the other one?