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
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
