The title suggests that this book discusses existing polymorphic languages. Actually, it describes a new language, POLY. The text is divided into four sections. The first explains the principles that guided POLY’s design. The second presents the features of the language and explains how they were determined by the design principles. The third compares POLY to several previous languages. Finally, the closing section outlines an implementation.

The author bases his design on four principles. The Principles of Abstraction states that “any syntactic clause . . . should be able to be ‘abstracted over’ to form an abstraction body, and therefore ‘invoked’ whenever necessary.” The Principle of Data Type Completeness “requires that all values be (a) passable as parameters, (b) assignable, (c) able to form components of data structures, and (d) able to be returned from functions.” The Principles of Correspondence demands that there be a “correspondence between in-line declarations and all other parametric forms of declaration.” Fourth, he insists that the various mechanisms of his language be completely orthogonal.

POLY itself is an imperative block-structured language with two unusual features: static type checking is replaced by complete run-time type checking; and all objects, including procedures and types, are treated as values in the sense of the Principle of Data Type Completeness. The language is polymorphic in that a name may be bound to objects of different types during its lifetime. This is a consequence of the fact that all type checking is done at run-time. SNOBOL 4 is polymorphic in the same sense.

I cannot recommend this book for two reasons. First, I disagree with the way the author uses his design principles. While others have treated the same principles as guidelines, the author treats them as rules. Tennant [1] states that the principle of abstraction does not imply that all the mechanisms it suggest “are necessarily useful or desirable,” but merely that it is important “to be aware that they are possible.” With this viewpoint, mechanisms suggested by the principle must be evaluated based on their effects on implementation and the ease with which programs can be constructed and modified. Ignoring implementation concerns may be justified, but ignoring the effect a language has on the quality of software produced using that language cannot be justified. This is largely what the author has done. For example, while he praises the power of run-time type checking, he barely mentions that programs written in a language with static type checking might be more reliable.

My second objection is that the author has failed to explain alternatives to his approach thoroughly and accurately. One indication of this is the distribution of references to other languages in the text. The majority involve PASCAL, ALGOL 60 and ALGOL 68. PASCAL is the overwhelming favorite. This seems strange for a book about “polymorphic programming languages.” In fact, almost all references to languages that would be widely considered “polymorphic” occur in one six-page section of the text.

When the author does discuss alternative approaches, his own viewpoint interferes with their accurate presentation. For example, the author incorrectly complains that:

The designers of VAL state . . . that ‘VAL is applicative, that is, is value-oriented.’ From this we are led to assume that being value-oriented means that a language is necessarily applicative. As we have tried to demonstrate . . . emphasizing the virtues of having values . . . does not necessarily rule out the imperative style . . . (p. 172).

To the author, being value-oriented means upholding the Principle of Completeness. He fails to realize that applicative languages are called value-oriented because only the value produced by an operation matters, which has nothing to do with his principle. In another case, he concludes that a statement by Backus concerning “unrestricted freedom” in the lambda calculus refers to “unfettered abstraction over labels and jumps,” even though no labels or jumps exist in the lambda calculus (p. 207). Unfortunately, such misunderstandings occur too frequently in this book.