Proposal: Add newUniqueSTM to Data.Unique

[Simon Marlow]

On 10/04/2012 19:56, Edward Kmett wrote:
> I was wondering if it would be possible to resolve this issue one way or
> the other. The discussion trailed off last year. Ed Yang proposed
> switching back to an IORef. and Bas benchmarked things showing a slight
> benefit to the IORef version.
>
> As it stands unsafePerformIO newUnique expands to unsafePerformIO $
> atomically $ do ...
>
> which is unsound and can cause the runtime to crash out on you rather
> unexpectedly.
>
> The only vote during the discussion period was a +1 for reverting to the
> IORef.

Thanks for the reminder.  I'll add newUniqueSTM, since I don't like the 
idea of people using unsafeIOToSTM and don't want to encourage its use.

Cheers,	
	Simon


> -Edward
>
> On Wed, Jan 19, 2011 at 2:45 PM, Edward Kmett <ekmett at gmail.com
> <mailto:ekmett at gmail.com>> wrote:
>
>     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
>
>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries