Re: future of lazy programming

jhc0033@xxxxxxxxx wrote:
If it's just a matter of defaults, why doesn't GHC have a compiler flag
for choosing your preferred default per file?


Well, one answer is that it isn't just a matter of defaults. The
discussion up to this point has implied that choosing strict versus lazy
evaluation semantics is entirely symmetric. That's not the case. In
fact, lazy is correct, while strict is often more efficient, but
occasionally incorrect in that programs that produce a result in lazy
evaluation semantics will loop with strict evaluation. It turns out one
NEVER wants strict evaluation semantics; one really wants lazy evaluation
semantics, with perfect strictness analysis. (But perfect strictness
analysis is almost certainly undecidable, so the question is whether we
want to approximate it by sacrificing efficiency, or correctness.)
That's the first part of the motivation for wanting lazy evaluation
semantics, rather than an option. It's not terribly appealing to have a
compiler flag that might break your programs.

Furthermore, whether strictness is correct or not is unfortunately not a
local property. So part of the interest in building a good compiler for
lazy evaluation semantics is also that the compiler can do that sort of
analysis needed to decide between strict semantics and lazy semantics.
For example, GHC does strictness analysis and turns a whole bunch of most
Haskell programs into strict evaluation (assuming optimization is turned
on, which is a mistake many people make when complaining about the number
of strictness annotations they need). Assuming -- and it's a big
assumption -- that it does strictness analysis well enough, this frees
software developers to write code that is correct in local ways, and
guarantees that code will still be correct when composed into larger
programs. The same can't be said of strict evaluation languages; there,
in addition to knowing that a function returns the right outputs for all
inputs, you also need to know something about order of evaluation to know
that your code will work. Equational reasoning about programs is broken
with strict semantics.

The proclamations that lazy evaluation semantics is dead are certainly
overblown in this thread. I am being careful to say "semantics" though;
certainly the implementation technique of always using lazy evaluation
all of the time IS dead, and good riddance to it. But no one really does
that, except in interpreted environments and such where we aren't
concerned about efficiency.

--
Chris Smith
.

Relevant Pages