On Mon, Mar 16, 2009 at 7:55 AM, Jake McArthur
I think it depends on what we want to take "unsafe" to mean. In my opinion, the word "unsafe" should really only be used in cases where using the function can case an otherwise well-typed program to not be well-typed. I'm pretty sure I haven't yet seen a case where this applies to unsafeInterleaveIO.
I don't think unsafeInterleaveIO on its own can do this. However, I disagree with your description of what "unsafe" should be used for. "unsafe" calls out the need for the programmer to prove that what they are doing is safe semantically, instead of the compiler providing those proofs for you. Whether that is due to type safety (unsafeCoerce) or breaking the assumptions of the compiler (unsafePerformIO, unsafeInterleaveIO, unsafeIOToST), depends on the situation. For example, unsafePerformIO can make your program not type-safe, but it's convoluted to do so; in fact, at monomorphic types it can't break type safety. That's not what makes it unsafe at all. It's unsafe because it breaks the rule that pure values don't have side effects, so that the effects inside the unsafePerformIO might get executed more than once, or not at all, depending on how the compiler decides to evaluate the pure value returned. And what happens could depend on the optimization settings of the compiler, the timing of the machine you are running on, or the phase of the moon. -- ryan