RE: DSSSL side effect-freeness

Subject: RE: DSSSL side effect-freeness
From: "Frank A. Christoph" <christo@xxxxxxxxxxxxxxxxxx>
Date: Wed, 4 Feb 1998 21:01:58 +0900
>> So, assuming we've ruled out side effects, what is the argument against
>> laziness?
>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

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

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.  :)


 DSSSList info and archive:

Current Thread
  • RE: DSSSL side effect-freeness
    • Frank A. Christoph - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id GAA09003Wed, 4 Feb 1998 06:55:04 -0500 (EST) <=
      • <Possible follow-ups>
      • Lassi A. Tuura - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id LAA21225Tue, 10 Feb 1998 11:52:13 -0500 (EST)
        • W. Eliot Kimber - from mail1.ability.netby (8.8.5/8.6.12) with ESMTP id MAA21736Tue, 10 Feb 1998 12:34:09 -0500 (EST)