Re: [Haskell-cafe] What unsafeInterleaveIO is unsafe

On Tue, 2009-03-17 at 12:59 +0100, Ketil Malde wrote:

Duncan Coutts writes:

...

...

[..] I have a sneaking suspicion [exceptions] actually *is* `unsafe'. Or, at least, incapable of being given a compositional, continuous semantics.

...

Basically if we can only catch exceptions in IO then it doesn't matter, it's just a little extra non-determinism and IO has plenty of that already.

Couldn't you just substitute "catch exceptions" with "unsafePerformIO" here, and make the same argument?

This puzzled me, until I realized you meant `unsafeInterleaveIO'. That's pretty much the argument that is made for unsafeInterleaveIO.

Similarly, can't you emulate unsafePerformIO with concurrency?

Assuming you mean unsafeInterleaveIO, not quite. GHC's scheduler is fair, so you are guaranteed after forkIO $ a that a's side effects will happen eventually. On the other hand, after unsafeInterleaveIO $ a you have basically no guarantee the RTS will ever get around to scheduling a. (In fact, if you write it just like that in a do block, rather than saying x <- unsafeInterleaveIO $ a you are pretty much guaranteed that the RTS won't ever feel like scheduling a. It'll even garbage collect a without ever executing it.)

Further, couldn't you, from IO, FFI into a function that examines the source code of some pure function, thus being able to differentiate funcitions that are normally "indistinguishable"?

Regular IO is good enough for this.

I've tried to follow this discussion, but I don't quite understand what's so bad about unsafeInterleaveIO - or rather, what's so uniquely bad about it. It seems the same issues can be found in every corner of IO.

jcc