[Haskell-cafe] Re: [Haskell] IVar
isaacdupree at charter.net
Tue Dec 4 14:56:10 EST 2007
>> 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,
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
More information about the Haskell-Cafe