[implicit]

Sure. I've previously written up a short description of the approach here: http://andyfriesen.com/2015/06/17/testable-io-in-haskell.htm...

The general high-level approach is that your business logic functions run in some monad, constrained by the set of capabilities it requires. Each capability is represented as a typeclass.

Your type signatures say that your business actions work in every monad that supports those capabilities, so the type checker rejects any code that tries to use "unblessed" side effects.

[pka]

Thanks, that's a cool approach! I'm wondering if a free monad approach would have any advantages over this.

[tel]

It's similar and there's some endless debate over comparisons of various effect handlin systems. I like the one the op recommends because it's fast and lightweight, but free works just the same. Free is really necessary if you're going to be doing lots of introspection of the monad values where you'd still probably want to write your functions against such a typeclass stack but then translate the values out as free transformer stacks.