what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
You can make them from MVars. On Dec 2, 2007 8:03 PM, Conal Elliott <conal@conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________ Haskell mailing list Haskell@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? On Dec 3, 2007 12:29 AM, Lennart Augustsson <lennart@augustsson.net> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <conal@conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________ Haskell mailing list Haskell@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 On Dec 4, 2007 6:25 AM, Conal Elliott <conal@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@augustsson.net> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <conal@conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@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@haskell.org [mailto:haskell-bounces@haskell.org] On Behalf Of Lennart Augustsson Sent: 04 December 2007 08:19 To: Conal Elliott Cc: haskell@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@conal.net<mailto:conal@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@augustsson.net<mailto:lennart@augustsson.net>> wrote: You can make them from MVars. On Dec 2, 2007 8:03 PM, Conal Elliott <conal@conal.net<mailto:conal@conal.net>> wrote: what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't. _______________________________________________ Haskell mailing list Haskell@haskell.org<mailto:Haskell@haskell.org> http://www.haskell.org/mailman/listinfo/haskell _______________________________________________ Haskell mailing list Haskell@haskell.org<mailto:Haskell@haskell.org> http://www.haskell.org/mailman/listinfo/haskell
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 On Dec 4, 2007 8:25 AM, Simon Peyton-Jones <simonpj@microsoft.com> 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.
Simon
*From:* haskell-bounces@haskell.org [mailto:haskell-bounces@haskell.org] *On Behalf Of *Lennart Augustsson *Sent:* 04 December 2007 08:19 *To:* Conal Elliott *Cc:* haskell@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@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@augustsson.net> wrote:
You can make them from MVars.
On Dec 2, 2007 8:03 PM, Conal Elliott <conal@conal.net> wrote:
what became of (assign-once) IVars? afaict, they were in concurrent haskell and now aren't.
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@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@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. On Dec 8, 2007 7:12 PM, Marc A. Ziegert <coeus@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@haskell.org http://www.haskell.org/mailman/listinfo/haskell
_______________________________________________ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
participants (5)
-
Conal Elliott -
Lennart Augustsson -
Marc A. Ziegert -
Paul Johnson -
Simon Peyton-Jones