Thanks. I don't know for what uses of IVars the difference in expressiveness is helpful, but now I get that the difference is there. Cheers, - Conal<br><br><div class="gmail_quote">On Dec 9, 2007 2:08 PM, Benja Fallenstein <
<a href="mailto:benja.fallenstein@gmail.com">benja.fallenstein@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi Conal,
<br><div class="Ih2E3d"><br>On Dec 9, 2007 6:09 PM, Conal Elliott <<a href="mailto:conal@conal.net">conal@conal.net</a>> wrote:<br>> > readIVar' :: IVar a -> a<br>> > readIVar' = unsafePerformIO . readIVar
<br>><br>> > so, we do not need readIVar'. it could be a nice addition to the<br>> libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".<br>><br>> The same argument applies any to pure function, doesn't it? For instance, a
<br>> non-IO version of succ is unnecessary. My question is why make readIVar a<br>> blocking IO action rather than a blocking pure value, considering that it<br>> always returns the same value?<br><br></div>From the rest of Marc's post, I understood the point to be that
<br>readIVar lets you do something that readIVar' does not let you do:<br>block until the IVar is written, then continue *without* first<br>evaluating the thunk in the IVar to WHNF. I haven't used IVars myself,<br>
so this isn't informed by hands-on experience, but it does sound<br>sensible to me that "block until the IVar has been written" and<br>"evaluate the thunk to WHNF" should be separable.<br><br>All the best,
<br><font color="#888888">- Benja<br></font></blockquote></div><br>