[PRL] laziness

[Johan]

David A. Herman wrote:
> I've got a few questions about laziness:
> 
> 1) Does laziness fuse multiple traversals?

I would tend to think so

> 2) Will it "automatically" buy me better performance?

Potentially yes, Empirically no. We tend not to write programs that lop 
off whole sub-computations, and when we do, this goal is so explicit 
that  little is gained through doing it automatically. (see okasaki's 
book)

However, there is (IMHO) a a big win in clarity / expressiveness. "if" 
becomes a function, not syntax...

Or my all-time-favotite: LU decomposition. See pages 6 /7 of
http://www.dcs.gla.ac.uk/fp/workshops/fpw97/EllmenreichLeng.ps

> 3) Is laziness a magic bullet, or an undebuggable pain?

udebuggable pain... unfortunately.  Performance is not predicable my 
mortals (partially because strictness is not predictable by machines)

try the following on for size:

foldl f acc []  = acc
foldl f acc (hd:tl) = foldl f (f hd acc) tl

nice and tail-recursive. however

foldl (+) 0 [0 .. 10000000]

fails to terminate: runs out of memory.

Unfortunately, this is a real problem, for any program that deals with 
large data sets.  Knowing where to force strict evaluation is hard; alot 
harder than knowing where to delay.  This has bit me several times, to 
the point of forcing me to abandon haskell for ocaml (not without cost: 
type classes rock).  And I used to think of myself as a haskell compiler 
hacker...

> All right, long-winded way of saying, if I'm writing a side-effect-free
> (or mostly so) program transformation engine, am I better off using a
> strict or lazy language?

hrm. All the same, unless your datasets are going to be large, i'd go 
lazy.  And if they do end up killing your performance (or even your 
ability to perform) you can always port to ocaml in an afternoon.