[Haskell-cafe] Does laziness make big difference?
claus.reinke at talk21.com
Fri Feb 16 05:30:59 EST 2007
> So, as I understand, choosing default laziness was just experimental design decision in order to
> answer the >question: "how good lazy language can be". I am practically convinced, that lazy
> evaluation included in the >_right_ places can be extremely useful. I didn't state the question as
> "strict vs lazy", my question is different - >"default laziness with optional strict -vs- default
> strictness with optional lazy". And sorry, but the question >remains open.
at the time, lazyness was also the best-known basis for pure functional i/o (result
continuations and monads taking over later), still a hot and tricky topic then.
as for defaults, lazy evaluation is normal order strategy + sharing of arguments,
strict evaluation corresponds to applicative order strategy, and we know from
lambda-calculus that normal order strategy is normalizing (reaches a normal form
if one exists) whereas applicative order strategy is not.
on this basis, non-strictness is a safe default, with strictness to be inferred or
annotated where needed. since strictness is undecidable in general, inference
has to be approximate, and a safe default is essential.
of course, one can program in mostly strict languages - I started out in one that used
applicative order strategy, but had normal order application as well, plus the usual
\()->thunking. and as you say, modern versions of default strictness allow you to
annotate the function as non-strict, so you don't have to use special application
operators everywhere, and lazy-keywords are clearer than \()->thunks.
but from my own experience, I had to think a lot more about evaluation order
in the default-strict language than I have to in the default-non-strict language,
and what is worse, I had to do this thinking up-front, whereas now I can
think about the data-dependencies first, and do the thinking about evaluation
order later, and only on demand:-)
that is also why programs written in default-strict languages often seem to win
in performance competitions: if you get it to work at all, you'll also have put in
some thoughts on performance/evaluation order already. programs written in
default-non-strict languages can be made to "work" without worrying about
those details, so it often happens to look as if lazy programs were resource-
hungry, and a lot of extra work had to be put in to make them efficient.
but I'd put it differently: about the same amount of thought has to be put in
to make either kind of program efficient, only that with non-strict default, I
get to choose when (and whether) to put in that effort.
in other words, default-strict languages are strict in demanding evaluation-
order information early, whereas default-non-strict languages give the
programmer more leeway.
More information about the Haskell-Cafe