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@haskell.org > http://www.haskell.org/mailman/listinfo/haskell >
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
