&gt; I haven&#x27;t thought too much about it, but I believe that if you structure effects as continuations, then they are monadic by construction (though I may well be wrong) because the continuations themselves are monadic. But I got interested in continuations because I don&#x27;t like Haskell&#x27;s purity, and I wondered if there is an imperative construct with the same expressive power as the PFP monad, and it turns out that not only that there is one, but that it composes much better than monads.<p>I don&#x27;t see it as imperative - if anything passing continuations around is more functional. They were originally a scheme thing, no?<p>How does the stack aspect work? It&#x27;s a continuation style so you never return, so if you keep the stack frames around it&#x27;ll overflow very quickly, right? The usual solution to that is tail call elimination, but then you don&#x27;t have even the immediate stack trace. Are you doing some kind of dynamic &quot;keep the last x stack frames&quot;? (I can imagine that being useful for a trampolined monad style too).<p>I think that&#x27;s the really interesting part. As you say the styles are equivalent (even clearer when one&#x27;s using something like scalaz-stream), so it&#x27;s a question of which is easier to read&#x2F;understand. I do think the monadic style as implemented in scala has a big runtime-inspectability problem (one idea I keep toying with is a free monad style where you represent every step with a named object or class, purely so that debuggers handle them correctly). I find call&#x2F;cc style incomprehensible at the code-reading level - I&#x27;d rather have the control flow captured in a value I can inspect in a debugger than as what are effectively gotos in the code text. Maybe if you&#x27;re more used to macro-based programming then it makes more sense.