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.<div>
<div><br></div><div>As it stands <font face="courier new, monospace">unsafePerformIO newUnique</font> expands to <font face="courier new, monospace">unsafePerformIO $ atomically $ do</font> ...<div><br></div><div>which is unsound and can cause the runtime to crash out on you rather unexpectedly.</div>
<div><br></div><div>The only vote during the discussion period was a +1 for reverting to the IORef.</div><div><br></div><div>-Edward</div><div><div><br><div class="gmail_quote">On Wed, Jan 19, 2011 at 2:45 PM, Edward Kmett <span dir="ltr">&lt;<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Data.Unique&#39;s newUnique uses atomically internally to update a TVar. Consequently attempting to &quot;unsafeIOToSTM newUnique&quot; to allocate a Unique within an STM transaction blows you sky high. <div>
<br></div><div>
The proposal is to split the definition of newUnique into:</div><div><br></div><div>newUnique = atomically newUniqueSTM</div><div><br></div><div>and expose newUniqueSTM.</div><div><br></div><div>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.</div>

<div><br></div><div>Since, there are two paths forward, I haven&#39;t put forward a patch, but wanted to open a discussion.</div><div><br></div><div>Discussion Period: 2 weeks.</div><span class="HOEnZb"><font color="#888888"><div>
<br></div><div>-Edward Kmett</div>
</font></span></blockquote></div><br></div></div></div></div>