Simon Marlow wrote:

Avoiding exceptions because MonadIO has trouble with them is not a good enough reason, IMO. We should fix MonadIO instead.

I'm all for it! Below is a summary of the three approaches that have been proposed, as far as I can remember: 1. Make the functions in Control.Exception more polymorphic. This is part of the more general program of providing polymorphic IO described in Haskell' ticket 110. Brian Hulley attached to that ticket a version of Control.Exception that does this by introducing the MonadException subclass of MonadIO. http://hackage.haskell.org/trac/haskell-prime/attachment/ticket/110/Exceptio... 2. In another branch from this thread, I suggested adding only the following three low-level exception handling functions to Control.Exception: startDelayingExceptions stopDelayingExceptions getDelayedException This would allow exception handling to be extended arbitrarily in other libraries, with only a small addition to Control.Exception. Simon Marlow pointed out that this mechanism would lose certain optimizations that exist, e.g., for preserving tail-recursion in block. That would be a cost of this generality. (Obviously we would retain the current mechanism for IO itself.) http://www.haskell.org/pipermail/libraries/2008-February/009159.html 3. Earlier in this thread, Judah Jacobson proposed adding additional liftIO functions to MonadIO, or a subclass, that match the kinds of the exception handling functions of Control.Exception. The kinds that would be needed are: For block and unblock: * -> * For catch: * -> (* -> *) -> * For setUncaughtExceptionHandler: (* -> *) -> * The liftIO for catch is the most general, so it could be reused for the others, but that would look a little ad hoc. This approach has the advantage that it does not require any change at all to Control.Exception, but it puts more of a burden on monad authors. http://www.haskell.org/pipermail/libraries/2008-January/009034.html Any other approaches? Any opinions about which of these would be best? Thanks, Yitz