Hi!
On Tue, Sep 21, 2010 at 11:10 PM, Simon Marlow
So rather than admitting defeat here I'd like to see it become the norm to write async-exception-safe code.
This is also what I think. You have to make your code work with exceptions, because they will come sooner or later. So if you handle them properly, once you have this implemented, then you can easily use them also for your own stuff.
It's not that hard, especially with the new mask API coming in GHC 7.0.
Not hard? I see it almost impossible without mask. You cannot have arbitrary long cleanup functions in for example bracket because somebody can (and will) interrupt it even if you block, because some function somewhere deep bellow will unblock. And there is no way to resume after exception in Haskell. What would I also like to see in Haskell is that it would be somehow possible to see which all exceptions could your function (through used functions there) throw. In this way it would be really possible to make async-exception-safe functions (as we really do not want catch-all all around). (Of course the problem with this approach is if somebody changes underlying function it could get additional possible exception(s) to be thrown.) So it would be even better if this would be solved like pattern matching warning (so you could see if you are missing some exception through warning) or even better: that type system would enforce you to or catch or declare throwing/passing exception yourself. Similar how Java has. Because one other major Haskell's selling point is that you (are said to) know from type if and which side-effects a function has. This is the story behind IO monad. And with exceptions you do not have this information anymore. I believe this should be visible through type system. Something like: http://paczesiowa.blogspot.com/2010/01/pure-extensible-exceptions-and-self.h... ? Mitar