I still honestly haven&#x27;t given this enough time to digest—my Java-fu is quite rusty so I&#x27;m sort of reading between the lines on what I know about delimited continuations generally.<p>First I want to state that delimited continuations form a monad and (I believe) that in order to get the Java implementation working you need to implement that monad in the &quot;ambient monad&quot; of Java.<p>Second, I want to dissect the notion of &quot;monad&quot; as used here into two pieces. First, there is the &quot;PFP Notion&quot; of monad which tends to be represented as a data type and some associated operations. Actually, I mean this even more specifically as being aimed <i>precisely</i> at the standard library monads of Haskell. Secondly, there&#x27;s the mathematical &quot;monad&quot; which is just a qualifier assigned to any structure which satisfies the monad laws.<p>Delimited continuations are <i>definitely</i> a mathematical monad. They are represented by one PFP monad, but are generally eschewed as a style there. Why? Because delimited continuations are very &quot;large&quot; and PFP tends to favor the idea of having your data &quot;forbid invalid state&quot; so... large types are disfavored.<p>So now, to the third point: I think this is all just &quot;implementing a specific overlarge monad in Java and Clojure&quot;. It turns out that this is really convenient because overlarge things <i>always are</i>. They are of course more convenient in PFP, too. But this convenience has the price of making code difficult to treat as data, difficult to analyze statically.<p>All that said, it doesn&#x27;t mean at all that this isn&#x27;t a useful technique for implementation of monads in Java&#x2F;Clojure.<p>Four, what about composability? (Specifically, here, we mean functor composition.) Turns out that delcont composes nicely compared to the PFP-style monads. The reason why is again because of lack of restrictions on state space. Non-composability of monads is a <i>good thing</i> because it relates to non-commutativity of certain effects.<p>You can get better composability in three ways: throw out all the non-commutative effects, work with subsets of effects a particular ambient monad (see Purescript&#x27;s impl of Eff), split the specification of effects from the implementation of effects and leave the decision of ordering up to the implementer (see Haskell&#x27;s mtl).<p>If you don&#x27;t want any of the above, just realize that non-composition is telling you something and forcing you to make choices. One choice is to build a new kind of composition (monad transformer composition) which does work the way we want by being more sensitive to ordering.<p>Fifth, and finally, all the above is not to say that there&#x27;s any lack of merit to using delcont for effects. It&#x27;s a great technique. It may fit the &quot;algorithmic mind&quot; better, too.<p>I am trying to say, however, that it&#x27;s not some grand trick that frees the user from thinking about monads. You still are, you just trade one set of implementation concerns for another. But since things are still monads then the same <i>mathematical</i> techniques will translate. Which is a great thing—it means there are more tools to think about, understand, and become confident in the application of this technique.