(moving to haskell-cafe)<br><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 libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
<br><br>The same argument applies any to pure function, doesn't it? For instance, a non-IO version of succ is unnecessary. My question is why make readIVar a blocking IO action rather than a blocking pure value, considering that it always returns the same value?
<br><br> - Conal<br><br><div class="gmail_quote">On Dec 8, 2007 11:12 AM, Marc A. Ziegert <<a href="mailto:coeus@gmx.de">coeus@gmx.de</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;">
many many answers, many guesses...<br>let's compare these semantics:<br><div class="Ih2E3d"><br>readIVar :: IVar a -> IO a<br></div>readIVar' :: IVar a -> a<br>readIVar' = unsafePerformIO . readIVar<br><br>
so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".<br>but the other way:<br><br>readIVar v = return $ readIVar' v<br><br>
does not work. with this definition, readIVar itself does not block anymore. it's like hGetContents.<br>and...<br><br>readIVar v = return $! readIVar' v<br><br>evaluates too much:<br> it wont work if the stored value evaluates to 1) undefined or 2) _|_.
<br> it may even cause a 3) deadlock:<br><br>do<br> writeIVar v (readIVar' w)<br> x<-readIVar v<br> writeIVar w "cat"<br> return x :: IO String<br><br>readIVar should only return the 'reference'(internal pointer) to the read object without evaluating it. in other words:
<br>readIVar should wait to receive but not look into the received "box"; it may contain a nasty undead werecat of some type. (Schrödinger's Law.)<br><br>- marc<br><br><br><br><br><br>Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
<br><div><div></div><div class="Wj3C7c">> Conal Elliott wrote:<br>> > Oh. Simple enough. Thanks.<br>> ><br>> > Another question: why the IO in readIVar :: IVar a -> IO a, instead<br>> > of just readIVar :: IVar a -> a? After all, won't readIVar iv yield
<br>> > the same result (eventually) every time it's called?<br>> Because it won't necessarily yield the same result the next time you run<br>> it. This is the same reason the stuff in System.Environment
returns<br>> values in IO.<br>><br>> Paul.<br></div></div><div><div></div><div class="Wj3C7c">> _______________________________________________<br>> Haskell mailing list<br>> <a href="mailto:Haskell@haskell.org">
Haskell@haskell.org</a><br>> <a href="http://www.haskell.org/mailman/listinfo/haskell" target="_blank">http://www.haskell.org/mailman/listinfo/haskell</a><br>><br><br><br></div></div></blockquote></div><br>