Unsafe hGetContents

[Duncan Coutts]

On Tue, 2009-10-06 at 15:18 +0200, Nicolas Pouillard wrote:

> > The reason it's hard is that to demonstrate a difference you have to get 
> > the lazy I/O to commute with some other I/O, and GHC will never do that. 
> >   If you find a way to do it, then we'll probably consider it a bug in GHC.
> > 
> > You can get lazy I/O to commute with other lazy I/O, and perhaps with 
> > some cunning arrangement of pipes (or something) that might be a way to 
> > solve the puzzle.  Good luck!
> 
> Oleg's example is quite close, don't you think?
> 
> URL: http://www.haskell.org/pipermail/haskell/2009-March/021064.html


I didn't think that showed very much. He showed two different runs of
two different IO programs where he got different results after having
bypassed the safety switch on hGetContents.

It shows that lazy IO is non-deterministic, but then we knew that. It
didn't show anything was impure.

As a software engineering thing, it's recommended to use lazy IO in the
cases where the non-determinism has a low impact, ie where the order of
the actions with respect to other actions doesn't really matter. When it
does matter then your programs will probably be more comprehensible if
you do the actions more explicitly.

For example we have the shoot-yourself-in-the-foot restriction that you
can only use hGetContents on a handle a single time (this is the safety
mechanism that Oleg turned off) and after that you cannot write to the
same handle. That's not because it'd be semantically unsound if those
restrictions were not there, but it would let you write some jolly
confusing non-deterministic programs.

Duncan