
Are functional languages any good?
The question of the usefulness of lazy evaluation seems to have been
phrased to ask what major advances in computing have a occurred as a
secondary effect of the technique.
The small examples we all know of neat ways of utilising infinite data
structures are not really going to satisfy this questionner. We appear
to still pay a significant price in terms of implementation speed, as
well as other problems that have been mentioned, such as debugging. So
the question appears to be whether it is worth solving these problems.
I would like to suggest an area in which algorithm development will
benefit from lazy evaluation. Because the area is at the forefront of
performance requirements, the lazy functional language implementations
have had little to offer hitherto, but now that these languages execute
somewhat faster than continental drift, and languages such as SISAL are
being used in anger, I expect that advances will be seen.
One particular facility that laziness provides is the resolution of
complex data dependencies at run-time. The major work in many of the
classical algorithms (especially in number crunching) is to arrive at a
static description of the data dependencies, so that the (static)
program can be written to process the structure efficiently. One can
think of matrix processing algorithms such as Gaussian elimination, or
some of the algorithms from OR which carefully divide the network into
stages, as examples. The best documented case, as referred to earlier
in this discussion is the use of attribute grammars. Because of the
complex (input-dependent) data dependencies, it is the subject of much
research as to how to parse using attribute grammars in conventional
languages. The lazy view of the world is able to give a much cleaner
view.
It is a characteristic of applications users that they only ask for
that which they think is possible. My experience of coding applications
which have carefully crafted algorithms into lazy functional languages
is that, having specified the problem clearly in the new language
(often very close to the original mathematical model), it is possible
to open up almost a vista of new possibilities for the customer to be
able to ask. At the worst (given that lazy implementations are still
slower than fortran) this seems to improve the understanding of the
original problem. This is particularly important in the emerging world
of parallel processing, as the algorithms were devised to be
sequential.
The general provision of laziness is crucial to the process, because
I want to give the application-producer the freedom that it provides.
I find they love it.