Proposal: Add newUniqueSTM to Data.Unique

[Edward Kmett]

On Wed, Jan 19, 2011 at 7:55 PM, Sebastian Fischer <fischer at nii.ac.jp>wrote:

> Alternately, since bug #3838 has been resolved, we could revert to using an
>> IORef
>>
>
> Are there advantages of using STM now that bug #3838 does not need to be
> worked around? Would it be worthwhile to have both IO and STM interfaces for
> unique identifiers so those who want them in STM don't need to use an unsafe
> function?
>

As long as I can actually use it in STM, I don't particularly care one way
or the other if there is an STM version of the call or if I have to magic up
an unsafeIOToSTM around it. The main reason I raised this issue was because
there was a perfectly legitimate use case for the existing Unique data type
that couldn't be coded around using existing combinators from outside of the
base library.

The concern I'd have about both reverting _and_ providing an STM version
would be that similar arguments could be made for enabling more and more IO
actions inside of STM. There are a number of other idempotent or replayable
IO actions, such as creating StableNames, etc. that are 'safe' IO actions
and which could be performed in either STM or IO without consequence. I'd be
all for a proposal that provided a MonadIO-like typeclass for things that
can be performed safely in either IO or STM, but I think thats a rather
drastic shift in scope, and probably would need to be fleshed out in its own
right. In fact that sounds a bit like the ACIO monad/class used in JHC.

Does anything else in base use STM internally behind an IO facade?

-Edward Kmett

Sebastian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20110119/68d4c408/attachment.htm>