many many answers, many guesses...
let's compare these semantics:readIVar' :: IVar a -> a
readIVar :: IVar a -> IO 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.
and...
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:
do
writeIVar v (readIVar' w)
x<-readIVar v
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.)
- marc
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.
>
> Paul.> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>