Proposal: Add newUniqueSTM to Data.Unique

[Edward Kmett]

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>