You absolutely can, if only you're willing to break the rules. :) (Note that this does NOT break referential transparency as long as you're not dependent on th

You absolutely can, if only you're willing to break the rules. :) (Note that this does NOT break referential transparency as long as you're not dependent on the program's debug output for correctness of the rest of the program.) include System.IO.Unsafe (unsafePerformIO) include Control.DeepSeq (deepseq) (unsafePerformIO $ putStrLn "OES NOES") `deepseq` doStuff VVV EDIT: blocking would also block doStuff owing to the deepseq, which means that your program might take longer to complete but will either return a consistent result or none at all. Similarly, if it causes an exception, at least it won't have failed silently. Moreover, none of these complaints are any worse than those you'd find in another language and both cases are esily detected (i.e., you immediately know when referential transparency is broken), so it's still fundamentally safe as a debugging aid. Let me state that another way: if there is no evidence that putStrLn fails, the result of the above is identical to the result of "doStuff" alone. (Anyhow, upvoted your comment because your statement is certainly correct, even if I claim it doesn't invalidate my initial claims about debugging :) )