gale at sefer.org
Mon Feb 4 09:59:07 EST 2008
Simon Marlow wrote:
> 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.
2. In another branch from this thread, I suggested adding only the
following three low-level exception handling functions to Control.Exception:
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.)
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
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.
Any other approaches? Any opinions about which of these would
More information about the Libraries