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