We discuss the use of the lazy evaluation scheme as coding tool in some algebraic manipulations. We show --- on several examples --- how to process the infinite power series or other open-ended data structures with co-recurrent algorithms, which simplify enormously the coding of recurrence relations or solving equations in the power series domain. The important point is not the "infinite" length of the data, but the fact that the algorithms use open recursion, and the user never thinks about the truncation. 1 Introduction This article develops some applications of the functional lazy evaluation schemes to symbolic calculus. Neither the idea of non-strict semantics, nor its application to generate infinite, open structures such as power series, are new, see for example [1, 2], some books on functional programming ([3, 4]), etc. The lazy evaluation (or call by need is a protocol which delays the evaluation of the arguments of a function: while evaluating f(x) the code for f is entered, ...

The major question examined by this paper is whether sufficient fine-grain parallelism can be obtained from programs written in a lazy functional language. To answer this question, we have implemented a prototype compiler based on a novel approach to strictness analysis (called abstract demand propagation) and we have compared this implementation strategy (optimized lazy) with other implementations, viz., pure lazy and lenient. Although the optimized lazy implementation improves significantly the efficiency of the resulting programs over the pure lazy approach, it was found that little parallelism can effectively be identified. This remains true even when a new notion of laziness --- speculative laziness --- is introduced, notion well suited to parallel machines as it based on a parallel notion of head-strictness instead of the traditional sequential one. Our experiments also showed that when a program's result is known to be finite, then strictness analysis can generate almost as mu...

Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

Many popular myths have evolved about functional programming languages and their power of expression; one such myth is that "functional languages cannot construct arbitrary cyclic data structures at run-time" and therefore that functional languages are not appropriate for problems which require efficient representations of dynamically-specified cyclic graph structures (such as a route-finding robot in a maze). This myth persists despite ample published work to the contrary (see for example [All89]) and is a recurring subject of debate [USE]. We provide a survey of some of the related work in this area; we then build on this work by presenting methods for both the dynamic construction of complex cyclic structures and their direct manipulation using circular programming techniques. 1 Introduction "A" "B" "C" "D" Figure 1: A small, directed, cyclic graph If one were asked to use a functional language to construct the directed graph given in Figure 1 then the resulting code might typically...

ing out and studying those patterns of computation as useful objects in their own right leads to further insights into the nature of computation. The list operators studied later in these notes follow this approach. ffl Functional programs are usually an order of magnitude more concise than their imperative counterparts. Besides being shorter, they can be much more readable. The functional community like to cite studies that show the number of bugs per line is more or less constant, independent of the level of the language in use. Higher-level languages encode more concept per line, and therefore have relatively fewer bugs. ffl Functional programs are often more akin to formal specifications than their conventional counterparts. A good notation goes a long way towards solving the problem[47]. ffl Lazy evaluation permits a new approach to some algorithms. It is a simple but powerful idea that can remove the need for explicit backtracking, and can allow the programmer to manipulate in...

What is a non-strict functional language? Is a non-strict language necessarily lazy? What additional expressiveness brings non-strictness, with or without laziness? This paper tries to shed some light on these questions. First, in order to characterize non-strictness, different evaluation strategies are introduced: strict, lazy, and lenient. Then, using program examples, how these evaluation strategies differ from each other is examined, showing that non-strictness, even without laziness, allows a more general use of recursive definitions. We also report on a small experiment that we performed to examine how, in practice, laziness was used in a number