this paper will try to accomplish several goals (in parallel): We will argue that the actor model is an appropriate way to think about parallel computation. Since many actors may be actively sending or receiving messages at the same time, actors are inherently well suited to modelling parallel systems. We will present some specific actors which we feel should be included in the programmer's tool kit for writing parallel programs. We will show examples illustrating the use of these primitives. Futures are actors which represent the values computed by parallel processes. They can be created dynamically and disappear when they are no longer needed. Other actors may use the value of a future without concern for the feet that it was computed in parallel. Synchronization is provided by serializers, which protect actors with internal state from timing errors caused by interacting processes. We will show how these primitives have been implemented in Act 1. Act I has been implemented on a serial machine, but it simulates the kind of parallelism that would occur on a real multiprocessor machine. Discussion of the implementation will give a more concrete picture of the mechanisms involved and will also show what would be needed for an implementation on a real network of parallel processors. 12. Traditional techniques for parallelism have been inadequate

A trampolined program is organized as a single loop in which computations are scheduled and their execution allowed to proceed in discrete steps. Writing programs in trampolined style supports primitives for multithreading without language support for continuations. Various forms of trampolining allow for different degrees of interaction between threads. We present two architectures based on an only mildly intrusive trampolined style. Concurrency can be supported at multiple levels of granularity by performing the trampolining transformation multiple times.

#???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

Introduction This chapter initially considers pure lazy functional languages: their philosophy, advantages and disadvantages. We then examine how to develop efficient lazy functional programs. One way to achieve efficiency is to introduce impurities. In the final section the two schools of lazy functional programming, pure and impure, are assessed. The assessment centres around two partial implementations of the Hopcroft Tarjan graph planarity algorithm. Profiling tools are used to make an experimental comparison and optimisation of each program. 4.1 Lazy Functional Programming In his book [42] Reade suggests that the user of a traditional imperative language is required to do the following: 1. describe the result to be computed; 2. impose an order on the steps required in the computation; 3. create and destroy, as required, any data structures used by the computation. 74 The first item is concerned with the extensional prope