RE: DSSSL side effect-freeness

["Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>]

>> So, assuming we've ruled out side effects, what is the argument against
>> laziness?
>
>Guessing:
>
>1. Implementation simplicity.
>2. Scheme compatibility.
>3. Leaves open the door for side-effectful supersets (like Jade!) (debug ).
>4. It's what most programmers expect anyhow -- few of us get to use lazy
>languages so most don't "know what they are missing." For instance I had
>to think hard to come up with a situation where a lazy language would be
>better because I am so used to thinking in terms of eager ones. Most of
>the examples of lazy programming I see are counters and other things that
>I don't use much day-to-day or else that I automatically wrap in a lambda
>without thinking about it...


I can't resist responding to #4, even though it has nothing to do with our
discussion.

I was the same way when I started using Haskell, and I suspect practically
everyone who has ever programmed in C and never programmed in a lazy
language before probably felt the same way.  But after a while the lazy
style becomes more natural and it becomes a real, honest-to-God
pain-in-the-ass sticking in a lambda everywhere it is needed, turning your
program inside out to get iterative behavior, etc.  I'm convinced that eager
evaluation is no more fundamental/intuitive than lazy evaluation is.  (But I
admit that I have reason to believe that lazy evaluation is not _more_
fundamental or intuitive than eager...)

Laziness, by which I mean the non-technical notion of simply delaying a
computation, is a very important part of all non-trivial programs and a lazy
language, and here I mean the technical notion, lets you make use of it
without encoding it by use of thunks, explicit recursions or loops.  There
is a very famous paper by John Hughes called "Why Functional Programming
Matters"

http://www.cs.chalmers.se/~rjmh/Papers/whyfp.html

which gives many _practical_ and _convincing_ examples where laziness is not
only more natural than eager evaluation, but also a big win in terms of
program modularity.  (And it also shows why higher-order functions are so
valuable.)  The paper is also very readable and enjoyable and I highly
recommend it to everyone who does any functional programming, even if it
must be with an eager language.  :)

--FC



 DSSSList info and archive:  http://www.mulberrytech.com/dsssl/dssslist