[Haskell] IVars

[Marc A. Ziegert]

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
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://www.haskell.org/pipermail/haskell/attachments/20071208/fa158f42/attachment.bin