On 07 April 2006 00:36, Marcin 'Qrczak' Kowalczyk wrote: > "Simon Marlow" <[EMAIL PROTECTED]> writes: >> I agree with your assessment of the problems with interruptible >> operations in GHC: that it is impossible to completely block async >> exceptions across a computation. We could certainly add a way to >> do this. Is that the substance of your objection to GHC's async >> exception mechanism? > > Regarding interruptible operations, this and one more thing that I > haven't written there: > > The fact that some function uses an interruptible operation internally > is a visible aspect of its behavior, both in GHC design and in mine.
I don't consider this to be a problem. Every API call you make has the potential to throw exceptions, and since we don't usually go to the trouble of documenting every exception that every library function can raise, the caller always has to be prepared to handle arbitrary exceptions thrown by calls to library functions. Asynchronous exceptions thrown by interruptible operations just fall into this category. BTW, I just realised a better way to express block. If block is supposed to count nesting, then we have a problem that you can still unblock exceptions even within a block by using sufficient number of unblocks, so the right way is to give block this type: block :: ((IO b -> IO b) -> IO a) -> IO a you use it like this: block $ \restore -> (do x <- takeMVar m restore (...) `catch` \e -> ...) so the only way to unblock is to restore the state of an enclosing block. Returning the restore function and using it outside the block isn't dangerous, so we don't have to play any quantified type games to prevent that. Cheers, Simon _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime