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...

#???4?67?9101112?14 15 16 ::: A stream, some of whose elements are unde#ned. Figure 12-1 Typical streams. In#nite Objects Several inventions led to the developmentofLisp-based distributable systems. Clearly, one of the most importantwas Lisp itself #McCarthy 65#. Another, less well known contribution was Peter Landin's description of streams #Landin 65#. Streams are possibly in#nite sequences of values. Sequences are a familiar idea in computer science---for example, linked lists are an implementation of sequences. Conceptually, a stream is a sequence with no last element. Streams are typically arguments to functions; those functions act on each element of the stream, producing another stream as output. In a Lisp-like system, the constituentvalues of a stream can be atomic symbols, #nite lists, or themselves streams. One value that might occur in a stream is bottom #?#, the unde#ned v