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