Proposal: Add newUniqueSTM to Data.Unique

Edward Kmett ekmett at gmail.com
Wed Jan 19 20:45:12 CET 2011


Data.Unique's newUnique uses atomically internally to update a
TVar. Consequently attempting to "unsafeIOToSTM newUnique" to allocate a
Unique within an STM transaction blows you sky high.

The proposal is to split the definition of newUnique into:

newUnique = atomically newUniqueSTM

and expose newUniqueSTM.

Alternately, since bug #3838 has been resolved, we could revert to using an
IORef, which would avoid the wart of having us have an overtly IO action
detonate because of an internal implementation detail of using STM.

Since, there are two paths forward, I haven't put forward a patch, but
wanted to open a discussion.

Discussion Period: 2 weeks.

-Edward Kmett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110119/27e049cf/attachment.htm>


More information about the Libraries mailing list