what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________ Haskell mailing list Haskell <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell
You can make them from MVars.
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________
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
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?
You can make them from MVars.On Dec 2, 2007 8:03 PM, Conal Elliott <conal <at> conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't._______________________________________________
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
Good question. That must be a matter of taste, because as you say the read will always produce the same result. But it sill is a bit of a strange operation.
-- Lennart
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?On Dec 3, 2007 12:29 AM, Lennart Augustsson <lennart <at> augustsson.net> wrote:You can make them from MVars.On Dec 2, 2007 8:03 PM, Conal Elliott <conal <at> conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't._______________________________________________
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
_______________________________________________ Haskell mailing list Haskell <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell
But since the read may block, it matters *when* you perform it. For example if you print “Hello” and then read the IVar, you’ll block after printing; but if you read the IVar and then print, the print won’t come out. If the operation was pure (no IO) then you’d have a lot less control over when it happened.
Simon
From: haskell-bounces <at> haskell.org
[mailto:haskell-bounces <at> haskell.org] On Behalf Of Lennart Augustsson
Sent: 04 December 2007 08:19
To: Conal Elliott
Cc: haskell <at> haskell.org
Subject: Re: [Haskell] IVars
Good question. That must
be a matter of taste, because as you say the read will always produce the same
result. But it sill is a bit of a strange operation.
-- Lennart
On Dec 4, 2007 6:25 AM, Conal Elliott < conal <at> conal.net> 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?
On Dec 3, 2007 12:29 AM, Lennart Augustsson <lennart <at> augustsson.net> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <conal <at> conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________
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
_______________________________________________ Haskell mailing list Haskell <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell
[redirecting to haskell-cafe] Simon Peyton-Jones wrote: > But since the read may block, it matters *when* you perform it. For > example if you print "Hello" and then read the IVar, you'll block > after printing; but if you read the IVar and then print, the print > won't come out. If the operation was pure (no IO) then you'd have > a lot less control over when it happened. Well, the same can happen with any pure computation that does not terminate. It's the compiler's job to avoid that, and as far as I know ghc is pretty careful not to reorder pure computations and IO operations too much. I'd argue for adding both an IO and a pure version of readIVar to an IVar implementation. Both have their uses; the firts gives you a little extra control, while the second one can easily be evaluated on demand, at the risk of creating a mine field of potential deadlocks. Bertram
That argument doesn't totally fly since non-termination isn't considered an effect in Haskell. Bottom doesn't commute with a IO operations normally either.
But not having readIVar return 'IO a' does make me a little quesy. :)
-- Lennart
But since the read may block, it matters *when* you perform it. For example if you print "Hello" and then read the IVar, you'll block after printing; but if you read the IVar and then print, the print won't come out. If the operation was pure (no IO) then you'd have a lot less control over when it happened.
Simon
From: haskell-bounces <at> haskell.org [mailto:haskell-bounces <at> haskell.org] On Behalf Of Lennart Augustsson
Sent: 04 December 2007 08:19
To: Conal Elliott
Cc: haskell <at> haskell.org
Subject: Re: [Haskell] IVars
Good question. That must be a matter of taste, because as you say the read will always produce the same result. But it sill is a bit of a strange operation.
-- LennartOn Dec 4, 2007 6:25 AM, Conal Elliott < conal <at> conal.net> 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?
On Dec 3, 2007 12:29 AM, Lennart Augustsson <lennart <at> augustsson.net> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <conal <at> conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________
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
_______________________________________________
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
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.
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
Before we can talk about what right and wrong we need to know what the semantics of IVars should be.
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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
_______________________________________________
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
(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
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 <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
On Dec 9, 2007 5:09 PM, Conal Elliott <conal <at> conal.net> wrote: > (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? But I don't think it does. If we're single-threaded, before we writeIVar on it, it "returns" bottom, but afterward it returns whatever what was written. It's a little fuzzy, but that doesn't seem referentially transparent. Luke > - 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 > > > > > > > > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe <at> haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > >
Thanks, Luke. I'd been unconsciously assuming that the IVar would get written to (if ever) by a thread other than the one doing the reading. (Even then, there could be a deadlock.)
- Conal
On Dec 9, 2007 5:09 PM, Conal Elliott <conal <at> conal.net> wrote:But I don't think it does. If we're single-threaded, before we writeIVar on it,
> (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?
it "returns" bottom, but afterward it returns whatever what was written. It's
a little fuzzy, but that doesn't seem referentially transparent.
Luke> _______________________________________________
> - 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
> > >
> >
> >
> >
>
>
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
I would claim that it's fine to use the type
readIVar :: IVar a -> a
if you're willing to give the "right" semantics to
newIVar :: IO (IVar a)
The semantics is that sometimes when you create an IVar you'll get one that always returns _|_ when read, sometimes you'll get a proper one. Now if you happen to read an IVar and it deadlocks your program, well, sorry, you were unlucky and got a bad IVar that time.
So it's possible to explain away the deadlock as something non-deterministic in the IO monad. Doing so comes at a terrible price though, because you can no longer reason about your program.
-- Lennart
Thanks, Luke. I'd been unconsciously assuming that the IVar would get written to (if ever) by a thread other than the one doing the reading. (Even then, there could be a deadlock.)
- ConalOn Dec 9, 2007 9:37 AM, Luke Palmer <lrpalmer <at> gmail.com> wrote:On Dec 9, 2007 5:09 PM, Conal Elliott <conal <at> conal.net> wrote:But I don't think it does. If we're single-threaded, before we writeIVar on it,
> (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?
it "returns" bottom, but afterward it returns whatever what was written. It's
a little fuzzy, but that doesn't seem referentially transparent.
Luke> _______________________________________________
> - 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
> > >
> >
> >
> >
>
>
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Makes sense to me. Giving a formal semantics to the IO version of readIVar most likely is simpler (taking IO and concurrent IO as given) than the non-IO version. I didn't understand that before. Thanks for helping me get it. - Conal
I would claim that it's fine to use the type
readIVar :: IVar a -> a
if you're willing to give the "right" semantics to
newIVar :: IO (IVar a)
The semantics is that sometimes when you create an IVar you'll get one that always returns _|_ when read, sometimes you'll get a proper one. Now if you happen to read an IVar and it deadlocks your program, well, sorry, you were unlucky and got a bad IVar that time.
So it's possible to explain away the deadlock as something non-deterministic in the IO monad. Doing so comes at a terrible price though, because you can no longer reason about your program.
-- LennartOn Dec 9, 2007 7:48 PM, Conal Elliott <conal <at> conal.net> wrote:Thanks, Luke. I'd been unconsciously assuming that the IVar would get written to (if ever) by a thread other than the one doing the reading. (Even then, there could be a deadlock.)
- ConalOn Dec 9, 2007 9:37 AM, Luke Palmer <lrpalmer <at> gmail.com> wrote:On Dec 9, 2007 5:09 PM, Conal Elliott <conal <at> conal.net> wrote:But I don't think it does. If we're single-threaded, before we writeIVar on it,
> (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?
it "returns" bottom, but afterward it returns whatever what was written. It's
a little fuzzy, but that doesn't seem referentially transparent.
Luke> _______________________________________________
> - 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
> > >
> >
> >
> >
>
>
> Haskell-Cafe mailing list
> Haskell-Cafe <at> haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe <at> haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Hi Conal, On Dec 9, 2007 6:09 PM, Conal Elliott <conal <at> conal.net> wrote: > > 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? >From the rest of Marc's post, I understood the point to be that readIVar lets you do something that readIVar' does not let you do: block until the IVar is written, then continue *without* first evaluating the thunk in the IVar to WHNF. I haven't used IVars myself, so this isn't informed by hands-on experience, but it does sound sensible to me that "block until the IVar has been written" and "evaluate the thunk to WHNF" should be separable. All the best, - Benja
Thanks. I don't know for what uses of IVars the difference in expressiveness is helpful, but now I get that the difference is there. Cheers, - Conal
Hi Conal,From the rest of Marc's post, I understood the point to be that
On Dec 9, 2007 6:09 PM, Conal Elliott <conal <at> conal.net> wrote:
> > 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?
readIVar lets you do something that readIVar' does not let you do:
block until the IVar is written, then continue *without* first
evaluating the thunk in the IVar to WHNF. I haven't used IVars myself,
so this isn't informed by hands-on experience, but it does sound
sensible to me that "block until the IVar has been written" and
"evaluate the thunk to WHNF" should be separable.
All the best,
- Benja
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe <at> haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RSS Feed