Re: laziness in functional programming

[Greg Meredith <lgreg.meredith@biosimilarity.com>]

John, et al,

The last statement is not true. Laziness is relatively new as the default
evaluation strategy in more mainstream functional languages. You can always
effect it with "thunks" (wrapping things up in lambdas), but it's not a
standard semantic in the dynamic functional languages (Lisp, Scheme, Dylan,
...) nor is it standard in the ML family of the statically typed functional
languages (ML, OCaml, F#, ... ). Scala gives a keyword to cause this to be
the evaluation strategy. Haskell is fairly unique as a high profile
functional language with the property that evaluation is lazy unless forced
to be eager.

Note that while laziness may be wiser from the point of view of not tripping
over potentially divergent computations, it is often very challenging to get
lazy code to be memory efficient (because you must pay for the deferred
computation in space). Moreover, laziness appears to give very brittle
performance characteristics, in the sense that small changes to lazy
algorithms can result in dramatic differences in performance
characteristics. Unfortunately, there seems to be a "no free lunch" theorem
behind this.

If ever there were a place where theory could help practice, this is one
(hint, hint). Finding good conceptual tools to aid in the design of *
appropriately* lazy algorithms for large scale computations would be a real
boon. There is no dirth of experience papers of the form "We (computational
biologists, computational financiers, machine learning theorists, ...)
thought we'd give Haskell a try. We loved the productivity, but we found
that there was a significant cost in optimizing our code to meet production
level memory and other resource requirements."

Best wishes,

--greg

On Thu, Mar 19, 2009 at 7:24 AM, John Baez <john.c.baez@gmail.com> wrote:

> Bill Lawvere wrote:
>
>
> I don't know the technical meaning of "lazy"; was it an attempt to avoid
> the
> > processing speed and ram needed to take account of the composition with
> > inclusion maps, etcetera?
> >
>
> No, "lazy evaluation" is a strategy of putting off computations until their
> results are known to be necessary.  The opposite is called "eager
> evaluation".  Laziness is often wiser.
>
> For example, a programming statement
>
> x:=y
>
> calls for the value of x to be set equal to y.  A strategy of eager
> evaluation will do this right away, while lazy evaluation will put off
> doing
> it until the variable x is used in some other task.  If x is never used,
> this saves work.
>
> I think most functional programming languages either delay evaluation in
> this way, or give the user the option to do this.
>
> Best,
> jb
>
>
>


-- 
L.G. Meredith
Managing Partner
Biosimilarity LLC
806 55th St NE
Seattle, WA 98105

+1 206.650.3740

http://biosimilarity.blogspot.com