Now I see it. Thanks.
Thanks also for the reference. Nice paper!
So now where do I stand?
I still think that being forced to handle exceptions in the IO monad is (sometimes) inconvenient, but I can now see why it is required for a rigorous language semantics. My problem relates to wanting to be able to effect some level of recovery in one library component for errors that arise in another. I thought about returning the entire set of exceptions, but I see that the implementation penalty is probably too high.
I assume the suggested mapException function [sect 5.4] remains unproblematic ... is it (or some equivalent) actually implemented? I could imagine it being useful for mapping errors into a common framework; e.g. to catch exceptions from an XML parser and return a common "XML error" exception, incorporating information from the original as additional diagnostic.
I think that the suggested unsafeIsException is appealing, since it allows some level of recovery action without (I think) opening up the insecurities of unsafePerformIO. The idea that the semantics of programs that do no raise exceptions is not affected is particularly appealing.
#g --
At 14:46 14/06/04 +0100, Keith Wansbrough wrote:
> I can't see any fundamental reason why exception handling has to occur in > the IO monad.
Read the paper _A Semantics for Imprecise Exceptions_. The problem is that the evaluation order of Haskell would have to be fixed for this not to lose referential transparency. What is the value of
catchExcept (show (makeExcept "E1" + makeExcept "E2")) (\x -> x)
? Haskell wouldn't be "purely functional" any more.
http://research.microsoft.com/~simonpj/Papers/imprecise-exn.htm
--KW 8-) -- Keith Wansbrough <[EMAIL PROTECTED]> http://www.cl.cam.ac.uk/users/kw217/ University of Cambridge Computer Laboratory.
------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
_______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
