On Thursday 25 November 2004 00:29, Scott Turner wrote:
John Goerzen wrote:
I note, though, that "making an Either into a Monad" doesn't do anything to deal with asynchronous exceptions.
[ snip]
I was referring to exceptions generated by things such as signals, interrupts, certain network errors, stack problems, etc.
How would you like asynchronous exceptions to fit in? Your original request mentioned that it was annoying to have to use the IO monad for all exceptions, particularly when the exceptions occur in deterministic code. But the IO monad is plainly appropriate for asynchronous exceptions.
I think the explanation was a bit misleading. Asynchronous exceptions are exceptions that can occur *anywhere*, even in purely functional code and even if the code itself is completely free of bottoms. A good example is 'heap overflow', i.e. insufficient memory even after the GC was run. Another example are interrupts and unix signals: they can occur at any time, regardless of what the program is doing. More generally, whenever you can send a message to a thread that isn't expecting one. Control.Exception defines 'throwTo' that gets a threadId as argument. This causes the target thread to be interrupted with an asynchronous exception. Asynchronous exceptions are a rather recent addition to ghc. How they relates to your (very interesting) EitherMonad solution is not completely clear to me, either. Ben