On Tue, 2009-03-17 at 12:59 +0100, Ketil Malde wrote: > Duncan Coutts <duncan.cou...@worc.ox.ac.uk> 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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe