Usually once a year somebody starts a discussion on the merits of functional/lazy paradigms, etc., in an applicative context, and it is quite good. People compare Haskell and Ocaml, from time to time somebody says that - apparently - Clean has better handling of strictness issues [saying at the same time that he/she doesn't use Clean...], people divide into different philosophical branches, some complain that it would be nice to have strict Haskell, others say, that they don't care, and what is important is the provable/enforced correctness, and laziness is helpful. People say that the laziness permits to consider the conditionals as functions, others ask what for, and the discussion is usually quite interesting. And here apparently I am one of rare people - I am not proud of it, rather quite sad, who defends laziness as an *algorithmisation tool*, which makes it easy and elegant to construct co-recursive codes. Circular programs, run-away infinite streams, hidden backtracking etc. In the domain of images this can be helpful for making filters, especially infinite-response, recursive filters. For two-dimensional data this might be clumsy, but for 1D, for example for the sound generation/processing, you may transform a recurrential equation yielding Y out of X: Y[n+1] = a*X[N+1] + b*Y[n] usually (imperatively) implemented as a loop, into a stream definition: filtr a b x@(x0:xq) = y where y = (x0:yq) yq = a*xq + b*y with (*) and (+) conveniently overloaded (or replaced by specific obvious ops). In such a way you can program in 2 - 6 lines some quite exquisite musical instruments (for example the Karplus-Strong "guitar", or a flute), construct the reverberation filters, make ever-rising Shepard/Risset paradoxical sounds, etc. etc. With laziness it is a sheer pleasure and fun, without - a pain. If you wish, find my PADL talk on it... In this context, I found Clean more helpful than Haskell, for ONE reason. Clean has a primitive datatype: unboxed, spine-lazy but head-strict lists. The co-recursion works, as the construction of the tail is postponed, but there is no pollution of the space by thunks - unevaluated list *elements*. This I really do miss in Haskell... But perhaps I simply don't know how to obtain a similar behaviour? For image processing (rather: constructing, but with incremental algorithms) Clean usage of unique arrays was for me more natural than monadic stuff in Haskell, but this is probably just a question of style. I agree that here the laziness is secondary... Jerzy Karczmarczuk