Unsafe hGetContents

Duncan Coutts duncan.coutts at googlemail.com
Tue Oct 20 10:24:32 EDT 2009

On Tue, 2009-10-20 at 13:58 +0100, Simon Marlow wrote:

> Duncan has found a definition of hGetContents that explains why it has 
> surprising behaviour, and that's very nice because it lets us write the 
> compilers that we want to write, and we get to tell the users to stop 
> moaning because the strange behaviour they're experiencing is allowed 
> according to the spec.  :-)


> Of course, the problem is that users don't want the hGetContents that 
> has non-deterministic semantics, they want a deterministic one.  And for 
> that, they want to fix the evaluation order (or something).  The obvious 
> drawback with fixing the evaluation order is that it ties the hands of 
> the compiler developers, and makes a fundamental change to the language 
> definition.

I've not yet seen anyone put forward any practical programs that have
confusing behaviour but were not written deliberately to be as wacky as
possible and avoid all the safety mechanism.

The standard use case for hGetContents is reading a read-only file, or
stdin where it really does not matter when the read actions occur with
respect to other IO actions. You could do it in parallel rather than
on-demand and it'd still be ok.

There's the beginner mistake where people don't notice that they're not
actually demanding anything before closing the file, that's nothing new
of course.


More information about the Haskell-prime mailing list