This is a well written paper that provides insight into advanced principles of programming language design. The paper will be most informative to those who have a background in formal language theory.

The paper is devoted to how a specific set of principles leads to the design of a language. The paper is divided into the following chapters: Introduction, Overview, Design Goals, Modularity, Type Polymorphism, Static Environments, Imperative Parts of APPLE, Recursive Data Types, How Control Structures Complement Data Types, Streams, Implementation, and Conclusions.

Although the APPLE language includes statement forms, it is a functional language because there are no global variables. Variables to which values may be assigned are local to functions. The subject of the paper and the obvious restrictions on its length forced the authors to cope with the difficulties of using the language in examples without first defining the language syntax. The “Rosetta Stone” that solved this dilemma was the definition and use of our old friend the “stack” abstract data type. Using this well-known example and relying on the knowledge base of the intended reader, enough of the forms of the language are exhibited.

The chapter on Type Polymorphism left me dissatisfied. Two methods were proposed, the familiar operator overloading and the unfamiliar use of formal parameter names for operators of parameter types. The latter was said to be vastly preferable. However, operator overloading was explained in great detail, and the formal parameter names had very few words of explanation.

On the more trivial level of the concrete representation of APPLE’s lexical and syntactic rules, I think that identifers are case sensitive. The delimiters of the language are all in the ASCII character set.

The authors’ own words are the most succinct characterization of APPLE. “APPLE programs are composed and analyzed by inductive reasoning rather than by mental simulation of execution. We believe that this is the most valuable contribution to programming style and programmer effectiveness that a programming language can make.” I agree with the authors’ sentiments, but I am afraid that APPLE programmers will not exist in effective numbers for many years. When I first read the description of APPLE in the paper I was repelled by the formality of the language. But rereading it several times made me overcome that feeling. It grew on me.