Simon Marlow wrote:
Certainly you can observe non-strictness, that's not the point. The point is that you can also observe more than just non-strictness using interact, and I don't think that is desirable. For example:
interact (\xs -> let z = length xs in "Hello World\n")
Now, Haskell is a pure language, so it shouldn't matter whether the implementation evaluates z or not, as long as it is careful not to violate the non-strict semantics by turning a terminating program into a non-terminating one. A parallel Haskell implementation might happily spawn off another thread to evaluate z for example. An optimistic implementation might evaluate z for a fixed amount of time before continuing with the main thread of evaluation.
BUT in the presence of lazy I/O this simply isn't true any more. Why? Because z is not pure; evaluating it has a side-effect. And yet it has type Int. Am I the only one who thinks this is wrong?
I don't know what everyone else thinks, but I do not see your problem. There is nothing impure about z. According to non-strict semantics we have (\xs -> let z = length xs in "Hello World\n") _|_ = "Hello World\n" So every implementation has to make sure that this equation holds. You know it is not enough for optimistic evaluation to `avoid _|_' by evaluating eagerly only for a fixed amount of time. You also have to bail out if evaluation raises an exception. This in particular if eager evaluation causes a black hole: reevaluation at some later time may yield a perfectly fine value. Likewise the presence of lazy IO forces you to test if the value is currently available or needs to be read from some handle; the presence of lazy IO adds another sort of black hole. Yes, the presence of lazy IO makes optimistic evaluation more complicated, but I do not see that it compromises the purity of the language in anyway (whatever purity is ;-). Olaf -- OLAF CHITIL, Dept. of Computer Science, The University of York, York YO10 5DD, UK. URL: http://www.cs.york.ac.uk/~olaf/ Tel: +44 1904 434756; Fax: +44 1904 432767