Understanding strictness of ghc output

[Malcolm Wallace]

"Simon Marlow" <simonmar at microsoft.com> writes:

> 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