On Wed, Jan 19, 2011 at 7:55 PM, Sebastian Fischer
<fischer@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