Fixing MonadIO

[Yitzchak Gale]

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/Exception.txt

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