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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
