Proposal: Make unsafeInterleaveST safer

Currently, unsafeInterleaveST is considerably less safe than unsafeInterleaveIO. Specifically, very careful discipline is required to make code using it thread-safe. This means that unsafeInterleaveST actually behaves like unsafeDupableInterleaveIO. See Edward Kmett's blog post from several years ago [*] for details. I propose that we should 1. Make unsafeInterleaveST behave only as unsafely as unsafeInterleaveIO, and 2. Add a new unsafeDupableInterleaveST function implementing the current unsafeInterleaveST behavior. The alternative would be to leave unsafeInterleaveST alone and add a new unsafeNonDupableInterleaveST, but that seems like an absolutely terrible mismatch of names. Since any currently-correct code using unsafeInterleaveST will continue to work (albeit more slowly), I don't think that's justified. Thanks, David [*] https://www.schoolofhaskell.com/school/to-infinity-and-beyond/older-but-stil... f

We ended up just making this change unilaterally. The previous
situation was just too horrible. Sorry for the noise.
David
On Tue, Mar 21, 2017 at 3:46 PM, David Feuer
Currently, unsafeInterleaveST is considerably less safe than unsafeInterleaveIO. Specifically, very careful discipline is required to make code using it thread-safe. This means that unsafeInterleaveST actually behaves like unsafeDupableInterleaveIO. See Edward Kmett's blog post from several years ago [*] for details.
I propose that we should
1. Make unsafeInterleaveST behave only as unsafely as unsafeInterleaveIO, and
2. Add a new unsafeDupableInterleaveST function implementing the current unsafeInterleaveST behavior.
The alternative would be to leave unsafeInterleaveST alone and add a new unsafeNonDupableInterleaveST, but that seems like an absolutely terrible mismatch of names. Since any currently-correct code using unsafeInterleaveST will continue to work (albeit more slowly), I don't think that's justified.
Thanks, David
[*] https://www.schoolofhaskell.com/school/to-infinity-and-beyond/older-but-stil... f
participants (1)
-
David Feuer