A pure readIVar would be just like lazy I/O, with similar drawbacks. With readIVar, the effect that lets you observe the evaluation order is writeIVar; with hGetContents it is hClose. Conclusion: it's probably no worse than lazy I/O.
Actually, it's considerably better.
+: implementation may not evaluate something that may terminate/block, anyway IVar may change from blocking to non-blocking, unlike most pure expressions. This is only meaningful if trying to evaluate it would prevent it from gaining a value. It can only have such an effect (helping the IVar gain a value) if the same thread would do any IO (if it wasn't for the unnecessary evaluation). IO is generally observable, so getting stuck on a normal non-terminating expression wouldn't be any more acceptable than getting stuck on an IVar in that case. ... all assuming unsafeInterleaveIO doesn't exist, because it's unsafe, so the semantics are undefined of when it gets evaluated relative to later normally-sequenced IO actions, if it will be eventually evaluated for sure -- right? Nevertheless its intended use generally assumes that it will be evaluated as if its evaluation might not terminate, i.e. as late as possible. If it is in fact (a finite amount of) non-blocking IO, then evaluating it early will only have consequences on when the IO happens (and therefore its effect/result), not directly on the program's non-termination or actions. It gets more confusing the more I think about it! to modify Simon's example, it looks to me like treating readIVar as potentially non-terminating, and writeIVar as potentially having side-effects, is enough: main = do --irrelevant x <- newIVar let y = last [1..] print "test" --was irrelevant writeIVar x 3 print y Isaac
main = do --irrelevant x <- newIVar let y = last [1..] print "test" --was irrelevant writeIVar x 3 print y
Exactly. The termination concern doesn't seem to have to do with readIVar.
On Dec 4, 2007 11:56 AM, Isaac Dupree
A pure readIVar would be just like lazy I/O, with similar drawbacks. With readIVar, the effect that lets you observe the evaluation order is writeIVar; with hGetContents it is hClose. Conclusion: it's probably no worse than lazy I/O.
Actually, it's considerably better.
+: implementation may not evaluate something that may terminate/block, anyway
IVar may change from blocking to non-blocking, unlike most pure expressions. This is only meaningful if trying to evaluate it would prevent it from gaining a value. It can only have such an effect (helping the IVar gain a value) if the same thread would do any IO (if it wasn't for the unnecessary evaluation). IO is generally observable, so getting stuck on a normal non-terminating expression wouldn't be any more acceptable than getting stuck on an IVar in that case.
... all assuming unsafeInterleaveIO doesn't exist, because it's unsafe, so the semantics are undefined of when it gets evaluated relative to later normally-sequenced IO actions, if it will be eventually evaluated for sure -- right? Nevertheless its intended use generally assumes that it will be evaluated as if its evaluation might not terminate, i.e. as late as possible. If it is in fact (a finite amount of) non-blocking IO, then evaluating it early will only have consequences on when the IO happens (and therefore its effect/result), not directly on the program's non-termination or actions.
It gets more confusing the more I think about it!
to modify Simon's example, it looks to me like treating readIVar as potentially non-terminating, and writeIVar as potentially having side-effects, is enough:
main = do --irrelevant x <- newIVar let y = last [1..] print "test" --was irrelevant writeIVar x 3 print y
Isaac _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
participants (2)
-
Conal Elliott -
Isaac Dupree