On Mon, Jul 07, 2008 at 01:51:11PM -0400, Isaac Dupree wrote:
I have type issues. Look how inconsistent these types are (I think, copied from the patch); some use forall and some use SomeException: catchAny :: IO a -> (forall e . Exception e => e -> IO a) -> IO a setUncaughtExceptionHandler :: (SomeException -> IO ()) -> IO () getUncaughtExceptionHandler :: IO (SomeException -> IO ())
setUncaughtExceptionHandler/getUncaughtExceptionHandler look like they are really part of GHC.TopHandler, which is really internal to GHC. That still needs to be sorted out properly.
catchAny :: IO a -> (SomeException -> IO a) -> IO a Then we don't even need the Rank2Types extension?
I think that's an option, yes, but we do still need ExistentialQuantification, so I'm not sure how much it buys us.
Also, according to the extensible exceptions paper p. 4 (footnote 3), `catch` with SomeException type should suffice, such that catchAny is not needed?
The reason I added catchAny as a separate function was to avoid having to use a type signature. It's not actually necessary, no.
Or was it decided that the facility to catch SomeException should be separated from the facility to catch any more-specific group of exceptions (since that implementation in the paper looks like a bit of a hack... or perhaps to warn people that it's a bad idea and should use a function with a name that's a big flashing warning)?
That footnote doesn't apply to the final definition of catch, which can catch SomeException without an ugly-looking hack.
On a different note: What about strictness?
data SomeFloatException = forall a . (Exception a) => SomeFloatException !a deriving Typeable
I don't have a strong opinion, but since we can't force all exceptions to be "deeply strict", and we can't stop people forgetting to make one strict, I don't think it buys us much. Thanks Ian