Unsafe hGetContents

Simon Marlow marlowsd at gmail.com
Tue Oct 20 10:45:09 EDT 2009

On 20/10/2009 15:24, Duncan Coutts wrote:
> 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.

If the parallel runtime reads files eagerly, that might hide a resource 
problem that would occur when the program is run on a sequential system, 
for example.


More information about the Haskell-prime mailing list