Marc A. Ziegert
coeus at gmx.de
Sat Dec 8 14:12:11 EST 2007
many many answers, many guesses...
let's compare these semantics:
readIVar :: IVar a -> IO a
readIVar' :: IVar a -> a
readIVar' = unsafePerformIO . readIVar
so, we do not need readIVar'. it could be a nice addition to the libraries, maybe as "unsafeReadIVar" or "unsafeReadMVar".
but the other way:
readIVar v = return $ readIVar' v
does not work. with this definition, readIVar itself does not block anymore. it's like hGetContents.
readIVar v = return $! readIVar' v
evaluates too much:
it wont work if the stored value evaluates to 1) undefined or 2) _|_.
it may even cause a 3) deadlock:
writeIVar v (readIVar' w)
writeIVar w "cat"
return x :: IO String
readIVar should only return the 'reference'(internal pointer) to the read object without evaluating it. in other words:
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.)
Am Freitag, 7. Dezember 2007 schrieb Paul Johnson:
> Conal Elliott wrote:
> > Oh. Simple enough. Thanks.
> > Another question: why the IO in readIVar :: IVar a -> IO a, instead
> > of just readIVar :: IVar a -> a? After all, won't readIVar iv yield
> > the same result (eventually) every time it's called?
> Because it won't necessarily yield the same result the next time you run
> it. This is the same reason the stuff in System.Environment returns
> values in IO.
> Haskell mailing list
> Haskell at haskell.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/haskell/attachments/20071208/fa158f42/attachment.bin
More information about the Haskell