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.
Cheers,
Simon
More information about the Haskell-prime
mailing list