[Haskell-cafe] Re: [Haskell] IVar

[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