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.
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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>

_______________________________________________
Haskell mailing list
Haskell <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell