RE: Understanding strictness of ghc output

On 22 June 2004 15:59, Malcolm Wallace wrote:
"Simon Marlow"
writes: Nope. You can't return something without evaluating it to head normal form in Haskell. Every value that is "returned" is a value, never a thunk. If you want to return something unevaluated, you have to wrap it in a constructor.
Actually, there are two possible strategies for who evaluates a thunk to head normal form. The caller or the callee. GHC says that the callee always evaluates to HNF before returning the value. But the language does not force this implementation choice. It is equally possible for an implementation of the function to return a thunk and for the caller to evaluate it if necessary. Both strategies give the same result semantically, since if the value in question is demanded, it gets evaluated.
If a function is called, then the result has been demanded. There are no situations in which a function has been called but the caller will accept a thunk as the result without further evaluating it. So what is the advantage of returning a possibly-unevaluated result? The caller will definitely have to evaluate it, so every eval will need to loop until the value is in HNF. And what about updates? Cheers, Simon

"Simon Marlow"
If a function is called, then the result has been demanded. There are no situations in which a function has been called but the caller will accept a thunk as the result without further evaluating it. The caller would definitely have to evaluate it, so every eval will need to loop until the value is in HNF.
Indeed. So what we are talking about is a peephole optimisation, where the callee can save some work for the system overall by evaluating its result to HNF, rather than leaving it to the caller to loop and test on every iteration.
So what is the advantage of returning a possibly-unevaluated result?
There is no operational advantage. The results are indistinguishable except in performance terms. My only, rather trivial, point is that the close visual similarity of f x = x and f (C x) = (C x) means that one can /explain/ both cases in identical terms, namely that the value bound by the variable x is potentially not-yet-evaluated, and that function f builds its result without looking at the value of x. And if you implement the language naively, it even works! Just slower than it might be.
And what about updates?
What do you mean? Regards, Malcolm
participants (2)
-
Malcolm Wallace
-
Simon Marlow