[Haskell-cafe] Re: [Haskell] IVars

Conal Elliott conal at conal.net
Sun Dec 9 12:09:36 EST 2007


(moving to haskell-cafe)

> 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".

The same argument applies any to pure function, doesn't it?  For instance, a
non-IO version of succ is unnecessary.  My question is why make readIVar a
blocking IO action rather than a blocking pure value, considering that it
always returns the same value?

  - Conal

On Dec 8, 2007 11:12 AM, Marc A. Ziegert <coeus at gmx.de> wrote:

> 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 --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20071209/9b4ac068/attachment.htm


More information about the Haskell-Cafe mailing list