Inspired by ACTORS [7, 17], we have implemented an interpreter for a LISP-like language, SCHEME, based on the lambda calculus [2], but extended for side effects, multiprocessing, and process synchronization. The purpose of this implementation is tutorial. We wish to: 1. alleviate the confusion caused by Micro-PLANNER, CONNIVER, etc., by clarifying the embedding of non-recursive control structures in a recursive host language like LISP. 2. explain how to use these control structures, independent of such issues as pattern matching and data base manipulation. 3. have a simple concrete experimental domain for certain issues of programming semantics and style. This paper is organized into sections. The first section is a short “reference manual ” containing specifications for all the unusual features of SCHEME. Next, we present a sequence of programming examples which illustrate various programming styles, and how to use them. This will raise certain issues of semantics which we will try to clarify with lambda calculus in the third section. In the fourth section we will give a general discussion of the issues facing an implementor of an interpreter for a language based on lambda calculus. Finally, we will present a completely annotated interpreter for SCHEME, written in MacLISP [13], to acquaint programmers with the tricks of the trade of implementing non-recursive control structures in a recursive language like LISP.

Distributed systems are multi-processor information processing systems which do not rely on the central shared memory for communication. The importance of distributed systems has been growing with the advent of "computer

This paper advocates a programming methodology using message passing. Efficient programs are derived for fast exponentiation, merging ordered sequences, and path existence determination in a directed graph. The problems have been proposed by John Reynolds as interesting ones to investigate because they. illustrate significant issues in programming. The methodology advocated here is directed toward the production of programs that are intended to execute efficiently in a computing environment with many processors. The absence of the COTO construct does not seem to be constricting in any respect in the development of efficient programs using the programming methodology advocated here. The programming problems arising from use of the GOTO construct have become well known over the last decade. However, removal of the construct from traditional programming languages has been found by many to be constricting and to result in inefficient programs. A number of proposals have been advanced to allow the construct in a restricted way e.g. Knuth: 1974 and Reynolds: 19771.