&gt; foo(); bar();<p>The whole point of composition is that foo(bar()) is foo(x) where x = bar(), which means that you can understand the combined program by understanding foo and bar independently. If you can&#x27;t represent the result of bar() as a value x then that breaks down, in which case I don&#x27;t see what this whole project is about? I mean being able to implicitly pass down a handler is cool, and there&#x27;s some value in being able to swap out e.g. a &quot;real&quot; and &quot;test&quot; version, but it sounds like the effect sequencing is still directly coupled to the code operation.<p>&gt; With monads you need to make sure that they both return the same nesting of Log[Writer] or Writer[Log], but I don&#x27;t need to care.<p>You only don&#x27;t need to care if the effects commute - and in that case you can actually automatically move them past each other in the monad world (my scalaz-transfigure library does this, at least at the proof-of-concept level). For noncommutative effects you can do the same thing if you&#x27;re willing to fix the nesting order (e.g. say that an exception <i>always</i> trumps a later log, or always doesn&#x27;t).