[Haskell] Re: Haskell Digest, Vol 52, Issue 1

[Simon Marlow]

Rishiyur Nikhil wrote:
> Simon Peyton-Jones said:
> 
>  >  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.
> 
> But this is true of any expression in a non-strict language.
> 
> Why the special treatment of IVars?

Consider this:

  do
     x <- newIVar
     let y = readIVar x
     writeIVar x 3
     print y

(I wrote the let to better illustrate the problem, of course you can inline 
y if you want).  Now suppose the compiler decided to evaluate y before the 
writeIVar.  What's to prevent it doing that?  Nothing in the Haskell spec, 
only implementation convention.  GHC will not transform the program in this 
way, because it can have some other undesirable effects.  e.g. see

   http://hackage.haskell.org/trac/ghc/ticket/1592

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.

Cheers,
	Simon