Proposal: Add newUniqueSTM to Data.Unique

Edward Kmett ekmett at gmail.com
Fri Apr 27 18:21:46 CEST 2012


On Fri, Apr 27, 2012 at 6:24 AM, Simon Marlow <marlowsd at gmail.com> wrote:
>
> That concern was why the discussion last time had turned toward reverting
>> to the previous IORef version, which is safe under a wider array of
>> conditions.
>>
>
> So the options are:
>

[...]

 2. Use atomicModifyIORef;
>    no way to generate uniques in STM
>

The difference is if you unsafeIOtoSTM . atomicModifyIORef the runtime
system doesn't panic and shut everything down, but if we unsafePerformIO .
atomically we do.

This makes me lean very heavily towards option 2, as the only contract that
we have on Uniques are that they are unique, so if the transaction played
back in an edited context, you'd just get a different Unique.

This would let you get Uniques in IO and unsafePerformIO, and unsafeIOtoSTM
should let it work in STM.

-Edward
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20120427/df1f9e69/attachment.htm>


More information about the Libraries mailing list