[Haskell-cafe] Re: Functional programming for processing of largeraster images

[Neil Mitchell]

Hi,

I happen to like laziness, because it means that when I'm not thinking
about performance, I don't have to think about evaluation order _at
all_. And since my computer is a 750Mhz Athlon with Hugs, I never find
any need to worry about performance :) If it ever becomes an issue I
can move to GHC or buy a faster computer without too much hassle.

> 1) What's the advantage of being able to define if2?
What about &&, || ? Should they be "built in"? What about and, which
is just && a lot of times, should that be lazy? At what point do you
say no? Should I be able to define implies correctly?

> 3) "Lazy lists as glue" can easily be replaced by force/delay lists + an
> extension to pattern matching where pattern matching against [a] forces the
> argument and the syntax [h|t] is used as in Prolog, instead of h:t (This
> would also free : to be used for "with type" or "with partial type" instead
> of ::)
That seems like more "thought" when writing the program, maybe its
worth it, maybe its not, but it doesn't seem as "neat" as what we
already have.

> 4) Other examples of the utility of laziness can turn out to be impractical
> chimera. For example, the famous repmin replaces the traversal of a tree
> twice with the dubious "advantage" of traversing it "only once" and the
> building up of a cluster of expensive thunks instead, and since the thunks
> effectively encode the structure of the tree, evaluation of them effectively
> constitutes the second traversal. So nothing's gained except difficulty of
> understanding the all-too-clever code (very bad software engineering
> practice imho), more heap consumption, and more time consumption.
Laziness doesn't have to be exploited in complex ways - minimum = head
. sort is a nice example. isSubstr x y = any (isPrefix x) (inits y) is
another one. Often by just stating a definition, laziness gives you
the performance for free. Of course, if you wanted to think harder
(and I never do), you can write better performing and strict-safe
versions of these, but again its more effort.

The other thing you loose when moving to strictness is the ability to
inline functions arbitrarily - consider:

if2 c t f = if x then t else f

Consider the expression:
if2 True 1 undefined

Now lets inline it and expand it, and in Haskell we get 1, which
matches the evaluation. In strict Haskell the inlining is now invalid,
and thats quite a useful optimisation to make. While it seems that
compilers can get round this, my concern is for the poor programmer -
this nice property of viewing functions as just "replace this with
that" has disappeared.

I suspect that in years to come, lazy languages will also have the
upper hand when it comes to theorem proving and formal reasoning, but
I guess thats a matter for future consideration.

While laziness may not be all good, its certainly not all bad :)

Thanks

Neil