RE: "interact" behaves oddly if used interactively
Pardon? Haskell is a non-strict language. Using 'interact' is one of numerous situations where one takes advantage of non-strict semantics. (Keith just gave a different example.)
Non-strict semantics does not prescribe the evaluation order, although usually lazy evaluation is used. I suppose you are talking about optimistic evaluation, which is a mixture of eager and lazy evaluation.
Yes sorry, I meant optimistic evaluation.
That is fine and should work well with 'interact', otherwise there is something wrong with optimistic evaluation.
No, optimistic evaluation does not work well with interact, because it causes the input stream to be evaluated (and therefore demanded) earlier than you would expect. This is the problem: interact exposes more than just non-strictness, it exposes laziness. In Robert Ennals' implementation of optimistic evaluation he has to fall back to lazy evaluation for lazy I/O, precisely because of this problem. Cheers, Simon
[snip]
No, optimistic evaluation does not work well with interact, because it causes the input stream to be evaluated (and therefore demanded) earlier than you would expect. This is the problem: interact exposes more than just non-strictness, it exposes laziness.
In Robert Ennals' implementation of optimistic evaluation he has to fall back to lazy evaluation for lazy I/O, precisely because of this problem.
Or to put it another way. Optimistic Evaluation works fine with "interact". You can write programs that use interact, evaluate them optimistically, and they will behave exactly as they always did. Optimistic Evaluation takes care to never speculatively evaluate anything that could have externally visible effects. It is a guiding principle of Optimistic Evaluation that there should be no user-perceivable difference between optimistic evaluation and lazy evaluation. -Rob
Robert Ennals wrote:
No, optimistic evaluation does not work well with interact, because it causes the input stream to be evaluated (and therefore demanded) earlier than you would expect. This is the problem: interact exposes more than just non-strictness, it exposes laziness.
In Robert Ennals' implementation of optimistic evaluation he has to fall back to lazy evaluation for lazy I/O, precisely because of this problem.
Or to put it another way.
Optimistic Evaluation works fine with "interact". You can write programs that use interact, evaluate them optimistically, and they will behave exactly as they always did.
Good to hear that ;-) I still do not quite agree with Simon that 'interact' exposes anything but non-strictness. Non-strictness means that map toUpper _|_ = _|_ map toUpper ('a':_|_) = ('A':_|_) map toUpper ('a':'b':_|_) = ('A':'B':_|_) and 'interact (map toUpper)' is a great way to experience this property. However, you can also experience the property without 'interact', evaluating expressions like take 2 (map toUpper ('a':'b':undefined)) I suppose Simon finds it annoying that optimistic evaluation has to deal specially with 'interact' (or actually the primitive that really implements it). I do not find that surprising. When you define an evaluation strategy you have to define it for all language constructs, including special primitives. If many of the special primitives don't need special treatment, that is nice, but it cannot be expected in general. 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
participants (3)
-
Olaf Chitil -
Robert Ennals -
Simon Marlow