Proposal: add new forms of unsafePerformIO and unsafeInterleaveIO

[Simon Marlow]

Stefan O'Rear wrote:
> On Thu, Feb 14, 2008 at 10:54:37AM +0000, Duncan Coutts wrote:
>> This version of 'unsafePerformIO' is slightly more efficient, because it
>> omits the check that the IO is only being performed by a single thread.
>> Hence, when you write 'unsafeDupablePerformIO', there is a possibility
>> that the IO action may be performed multiple times (on a
>> multiprocessor), and you should therefore ensure that it gives the same
>> results each time.
>>
>> unsafeDupablePerformIO :: IO a -> a
>>
>>         TODO: Actually, unsafeDupableInterleaveIO is not yet documented,
>>         that will have to be fixed.
>>         
>> unsafeDupableInterleaveIO :: IO a -> IO a
> 
> I propose that unsafeDupablePerformIO be renamed to unsafePerformIO,
> since it satisfies all of the properties guaranteed of unsafePerformIO.
> GHC's unsafePerformIO guarantees more, and should be called
> unsafePerformIOAtMostOnce or something.

That's certainly a defensible position, but I'll present a counter-argument.

If you've managed to use unsafePerformIO in a way that works on a single 
processor, then you will probably be tempted to assume that it will work on 
a multiprocessor too.  Currently unsafePerformIO tries to make that true 
(although it's not foolproof, and it's quite expensive).

Look at all that stuff in the docs for unsafePeformIO about -fno-cse and 
let-floating (I think it goes too far, in fact - if your use of 
unsafePerformIO is that fragile then you're doing something wrong).  If 
unsafePerformIO was the dupable version by default, then all that goes out 
of the window if you happen to be running with two threads on an SMP.  And 
if you're writing a library, you have to assume the worst and go for the 
AtMOstOnce version - who would remember to do that?

Better for the default version to be safe in this respect, IMO.  The bugs 
we'd get from this would be really hard to track down.

Cheers,
	Simon