[Haskell-cafe] What unsafeInterleaveIO is unsafe

[Ryan Ingram]

On Mon, Mar 16, 2009 at 7:55 AM, Jake McArthur <jake at pikewerks.com> wrote:
> 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