197 7 ACM Turing Award Lecture The 1977 ACM Turing Award was presented to John Backus putations called Fortran. This same group designed the first at the ACM Annual Conference in Seattle, October 17. In intro- system to translate Fortran programs into machine language. ducing the recipient, Jean E. Sammet, Chairman of the Awards They employed novel optimizing techniques to generate fast Committee, made the following comments and read a portion of machine-language programs. Many other compilers for the lan- the final citation. The full announcement is in the September guage were developed, first on IBM machines, and later on virtu- 1977 issue of Communications, page 681. ally every make of computer. Fortran was adopted as a U.S. "Probably there is nobody in the room who has not heard of national standard in 1966. Fortran and most of you have probably used it at least once, or at During the latter part of the 1950s, Backus served on the least looked over the shoulder of someone who was writing a For. international committees which developed Algol 58 and a later tran program. There are probably almost as many people who version, Algol 60. The language Algol, and its derivative com- have heard the letters BNF but don't necessarily know what they pilers, received broad acceptance in Europe as a means for de- stand for. Well, the B is for Backus, and the other letters are veloping programs and as a formal means of publishing the explained in the formal citation. These two contributions, in my algorithms on which the programs are based. opinion, are among the half dozen most important technical In 1959, Backus presented a paper at the UNESCO confer- contributions to the computer field and both were made by John ence in Paris on the syntax and semantics of a proposed inter- Backus (which in the Fortran case also involved some col- national algebraic language. In this paper, he was the first to leagues). It is for these contributions that he is receiving this employ a formal technique for specifying the syntax of program- year's Turing award. ming languages. The formal notation became known as BNF- The short form of his citation is for 'profound, influential, standing for "Backus Normal Form," or "Backus Naur Form" to and lasting contributions to the design of practical high-level recognize the further contributions by Peter Naur of Denmark. programming systems, notably through his work on Fortran, and Thus, Backus has contributed strongly both to the pragmatic for seminal publication of formal procedures for the specifica- world of problem-solving on computers and to the theoretical tions of programming languages.' world existing at the interface between artificial languages and The most significant part of the full citation is as follows: computational linguistics. Fortran remains one of the most '... Backus headed a small IBM group in New York City widely used programming languages in the world. Almost all during the early 1950s. The earliest product of this group's programming languages are now described with some type of efforts was a high-level language for scientific and technical corn- formal syntactic definition.' " Can Programming Be Liberated from the von Neumann Style? A Functional Style and Its Algebra of Programs John Backus IBM Research Laboratory, San Jose Conventional programming languages are growing ever more enormous, but not stronger. Inherent defects at the most basic level cause them to be both fat and weak: their primitive word-at-a-time style of program- ming inherited from their common ancestor--the von Neumann computer, their close coupling of semantics to state transitions, their division of programming into a world of expressions and a world of statements, their inability to effectively use powerful combining forms for building new programs from existing ones, and their lack of useful mathematical properties for reasoning about programs. An alternative functional style of programming is General permission to fair make use in teaching or research of all founded on the use of combining forms for creating or part of this material is granted to individual readers and to nonprofit libraries acting for them provided that ACM's copyright notice is given programs. Functional programs deal with structured and that reference is made to the publication, to its date of issue, and data, are often nonrepetitive and nonrecursive, are hier- to the fact that reprinting privileges were granted by permission of the archically constructed, do not name their arguments, and Association for Computing Machinery. To otherwise reprint a ,erugif do not require the complex machinery of procedure table, other substantial excerpt, or the entire work requires specific permission as does republication, or systematic or multiple reproduc- declarations to become generally applicable. Combining tion. forms can use high level programs to build still higher Author's address: 19 Saint Germain Ave., San Francisco, CA level ones in a style not possible in conventional lan- 94114. © 1978 ACM 0001-0782/78/0800-0613 $00.75 guages. 613 Communications August 1978 of Volume i 2 the ACM Number 8 Associated with the functional style of programming grams, and no conventional language even begins to is an algebra of programs whose variables range over meet that need. In fact, conventional languages create programs and whose operations are combining forms. unnecessary confusion in the way we think about pro- This algebra can be used to transform programs and to grams. solve equations whose "unknowns" are programs in much For twenty years programming languages have been the same way one transforms equations in high school steadily progressing toward their present condition of algebra. These transformations are given by algebraic obesity; as a result, the study and invention of program- laws and are carried out in the same language in which ming languages has lost much of its excitement. Instead, programs are written. Combining forms are chosen not it is now the province of those who prefer to work with only for their programming power but also for the power thick compendia of details rather than wrestle with new of their associated algebraic laws. General theorems of ideas. Discussions about programming languages often the algebra give the detailed behavior and termination resemble medieval debates about the number of angels conditions for large classes of programs. that can dance on the head of a pin instead of exciting A new class of computing systems uses the functional contests between fundamentally differing concepts. programming style both in its programming language and Many creative computer scientists have retreated in its state transition rules. Unlike von Neumann lan- from inventing languages to inventing tools for describ- guages, these systems have semantics loosely coupled to ing them. Unfortunately, they have been largely content states--only one state transition occurs per major com- to apply their elegant new tools to studying the warts putation. and moles of existing languages. After examining the Key Words and Phrases: functional programming, appalling type structure of conventional languages, using algebra of programs, combining forms, functional forms, the elegant tools developed by Dana Scott, it is surprising programming languages, von Neumann computers, yon that so many of us remain passively content with that Neumann languages, models of computing systems, ap- structure instead of energetically searching for new ones. plicative computing systems, applicative state transition The purpose of this article is twofold; first, to suggest systems, program transformation, program correctness, that basic defects in the framework of conventional program termination, metacomposition languages make their expressive weakness and their CR Categories: 4.20, 4.29, 5.20, 5.24, 5.26 cancerous growth inevitable, and second, to suggest some alternate avenues of exploration toward the design of new kinds of languages. Introduction I deeply appreciate the honor of the ACM invitation 2. Models of Computing Systems to give the 1977 Turing Lecture and to publish this account of it with the details promised in the lecture. Underlying every programming language is a model Readers wishing to see a summary of this paper should of a computing system that its programs control. Some turn to Section ,61 the last section. models are pure abstractions, some are represented by hardware, and others by compiling or interpretive pro- grams. Before we examine conventional languages more 1. Conventional Programming Languages: Fat and closely, it is useful to make a brief survey of existing Flabby models as an introduction to the current universe of alternatives. Existing models may be crudely classified Programming languages appear to be in trouble. Each successive language incorporates, with a little by the criteria outlined below. cleaning up, all the features of its predecessors plus a few more. Some languages have manuals exceeding 500 2.1 Criteria for Models pages; others cram a complex description into shorter 2.1.1 Foundations. Is there an elegant and concise manuals by using dense formalisms. The Department of mathematical description of the model? Is it useful in Defense has current plans for a committee-designed proving helpful facts about the behavior of the model? language standard that could require a manual as long Or is the model so complex that its description is bulky as 1,000 pages. Each new language claims new and and of little mathematical use? fashionable features, such as strong typing or structured 2.1.2 History sensitivity. Does the model include a control statements, but the plain fact is that few lan- notion of storage, so that one program can save infor- guages make programming sufficiently cheaper or more mation that can affect the behavior of a later program? reliable to justify the cost of producing and learning to That is, is the model history sensitive? use them. 2.1.3 Type of semantics. Does a program successively Since large increases in size bring only small increases transform states (which are not programs) until a termi- in power, smaller, more elegant languages such as Pascal nal state is reached (state-transition semantics)? Are continue to be popular. But there is a desperate need for states simple or complex? Or can a "program" be suc- a powerful methodology to help us think about pro- cessively reduced to simpler "programs" to yield a final 614 Communications August 1978 of Volume 12 the ACM Number 8 "normal form program," which is the result (reduction three parts: a central processing unit (or CPU), a store, semantics)? and a connecting tube that can transmit a single word 2.1.4 Clarity and conceptual usefulness of programs. between the CPU and the store (and send an address to • Are programs of the model clear expressions of a process the store). I propose to call this tube the yon Neumann or computation? Do they embody concepts that help us bottleneck. The task of a program is to change the to formulate and reason about processes? contents of the store in some major way; when one considers that this task must be accomplished entirely by 2.2 Classification of Models pumping single words back and forth through the von Using the above criteria we can crudely characterize Neumann bottleneck, the reason for its name becomes three classes of models for computing systems--simple clear. operational models, applicative models, and von Neu- Ironically, a large part of the traffic in the bottleneck mann models. is not useful data but merely names of data, as well as 2.2.1 Simple operational models. Examples: Turing operations and data used only to compute such names. machines, various automata. Foundations: concise and Before a word can be sent through the tube its address useful. History sensitivity: have storage, are history sen- must be in the CPU; hence it must either be sent through sitive. Semantics: state transition with very simple states. the tube from the store or be generated by some CPU Program clarity: programs unclear and conceptually not operation. If the address is sent from the store, then its helpful. address must either have been sent from the store or 2.2.2 Applicative models. Examples: Church's generated in the CPU, and so on. If, on the other hand, lambda calculus 5, Curry's system of combinators 6, the address is generated in the CPU, it must be generated pure Lisp 17, functional programming systems de- either by a fixed rule (e.g., "add 1 to the program scribed in this paper. Foundations: concise and useful. counter") or by an instruction that was sent through the History sensitivity: no storage, not history sensitive. Se- tube, in which case its address must have been sent ... mantics: reduction semantics, no states. Program clarity: and so on. programs can be clear and conceptually useful. Surely there must be a less primitive way of making 2.2.3 Von Neumann models. Examples: von Neu- big changes in the store than by pushing vast numbers mann computers, conventional programming languages. of words back and forth through the von Neumann Foundations: complex, bulky, not useful. History sensitiv- bottleneck. Not only is this tube a literal bottleneck for ity: have storage, are history sensitive. Semantics: state the data traffic of a problem, but, more importantly, it is transition with complex states. Program clarity: programs an intellectual bottleneck that has kept us tied to word- can be moderately clear, are not very useful conceptually. at-a-time thinking instead of encouraging us to think in The above classification is admittedly crude and terms of the larger conceptual units of the task at hand. debatable. Some recent models may not fit easily into Thus programming is basically planning and detailing any of these categories. For example, the data-flow the enormous traffic of words through the von Neumann languages developed by Arvind and Gostelow 1, Den- bottleneck, and much of that traffic concerns not signif- nis 7, Kosinski 13, and others partly fit the class of icant data itself but where to find it. simple operational models, but their programs are clearer than those of earlier models in the class and it is perhaps possible to argue that some have reduction semantics. In 4. Von Neumann Languages any event, this classification will serve as a crude map of the territory to be discussed. We shall be concerned only Conventional programming languages are basically with applicative and von Neumann models. high level, complex versions of the von Neumann com- puter. Our thirty year old belief that there is only one kind of computer is the basis of our belief that there is 3. Von Neumann Computers only one kind of programming language, the conven- tional--von Neumann--language. The differences be- In order to understand the problems of conventional tween Fortran and Algol 68, although considerable, are programming languages, we must first examine their less significant than the fact that both are based on the intellectual parent, the von Neumann computer. What is programming style of the von Neumann computer. Al- avon Neumann computer? When von Neumann and though I refer to conventional languages as "von Neu- others conceived it over thirty years ago, it was an mann languages" to take note of their origin and style, elegant, practical, and unifying idea that simplified a I do not, of course, blame the great mathematician for number of engineering and programming problems that their complexity. In fact, some might say that I bear existed then. Although the conditions that produced its some responsibility for that problem. architecture have changed radically, we nevertheless still Von Neumann programming languages use variables identify the notion of "computer" with this thirty year to imitate the computer's storage cells; control statements old concept. elaborate its jump and test instructions; and assignment In its simplest form avon Neumann computer has statements imitate its fetching, storing, and arithmetic. 615 Communications August 1978 of Volume 21 the ACM Number 8 The assignment statement is the von Neumann bottle- 5. Comparison of von Neumann and Functional neck of programming languages and keeps us thinking Programs in word-at-a-time terms in much the same way the computer's bottleneck does. To get a more detailed picture of some of the defects Consider a typical program; at its center are a number of von Neumann languages, let us compare a conven- of assignment statements containing some subscripted tional program for inner product with a functional one variables. Each assignment statement produces a one- written in a simple language to be detailed further on. word result. The program must cause these statements to be executed many times, while altering subscript values, 5.1 A von Neumann Program for Inner Product in order to make the desired overall change in the store, c.-~-0 since it must be done one word at a time. The program- for i .~ I step 1 until n do mer is thus concerned with the flow of words through c ---. c + iIbxila the assignment bottleneck as he designs the nest of Several properties of this program are worth noting: control statements to cause the necessary repetitions. a) Its statements operate on an invisible "state" ac- Moreover, the assignment statement splits program- cording to complex rules. ming into two worlds. The first world comprises the right b) It is not hierarchical. Except for the right side of sides of assignment statements. This is an orderly world the assignment statement, it does not construct complex of expressions, a world that has useful algebraic proper- entities from simpler ones. (Larger programs, however, ties (except that those properties are often destroyed by often do.) side effects). It is the world in which most useful com- c) It is dynamic and repetitive. One must mentally putation takes place. execute it to understand it. The second world of conventional programming lan- d) It computes word-at-a-time by repetition (of the guages is the world of statements. The primary statement assignment) and by modification (of variable i). in that world is the assignment statement itself. All the e) Part of the data, n, is in the program; thus it lacks other statements of the language exist in order to make generality and works only for vectors of length n. it possible to perform a computation that must be based f) It names its arguments; it can only be used for on this primitive construct: the assignment statement. vectors a and b. To become general, it requires a proce- This world of statements is a disorderly one, with few dure declaration. These involve complex issues (e.g., call- useful mathematical properties. Structured programming by-name versus call-by-value). can be seen as a modest effort to introduce some order g) Its "housekeeping" operations are represented by into this chaotic world, but it accomplishes little in symbols in scattered places (in the for statement and the attacking the fundamental problems created by the subscripts in the assignment). This makes it impossible word-at-a-time von Neumann style of programming, to consolidate housekeeping operations, the most com- with its primitive use of loops, subscripts, and branching mon of all, into single, powerful, widely useful operators. flow of control. Thus in programming those operations one must always Our fixation on yon Neumann languages has contin- start again at square one, writing "for i ---. ..." and ued the primacy of the von Neumann computer, and our "for j := ..." followed by assignment statements sprin- dependency on it has made non-von Neumann languages kled with i's and j's. uneconomical and has limited their development. The absence of full scale, effective programming styles founded on non-von Neumann principles has deprived 5.2 A Functional Program for Inner Product designers of an intellectual foundation for new computer Def Innerproduct architectures. (For a brief discussion of that topic, see - (Insert +)o(ApplyToAll x)oTranspose Section 15.) Applicative computing systems' lack of storage and Or, in abbreviated form: history sensitivity is the basic reason they have not Def IP - (/+)o(ax)oTrans. provided a foundation for computer design. Moreover, most applicative systems employ the substitution opera- Composition (o), Insert (/), and ApplyToAll (a) are tion of the lambda calculus as their basic operation. This functional forms that combine existing functions to form operation is one of virtually unlimited power, but its new ones. Thus fog is the function obtained by applying complete and efficient realization presents great difficul- first g and then fi and f~c is the function obtained by ties to the machine designer. Furthermore, in an effort applyingf to every member of the argument. If we write to introduce storage and to improve their efficiency on f:x for the result of applying f to the object x, then we von Neumann computers, applicative systems have can explain each step in evaluating Innerproduct applied tended to become engulfed in a large von Neumann to the pair of vectors <<1, 2, 3>, <6, 5, 4>> as follows: system. For example, pure Lisp is often buried in large IP:<< i,2,3>, <6,5,4>> = extensions with many von Neumann features. The re- Definition of IP ~ (/+)o(ax)oTrans: << 1,2,3>, <6,5,4>> suiting complex systems offer little guidance to the ma- Effect of composition, o ~ (/+):((ax):(Trans: chine designer. <<1,2,3>, <6,5,4>>)) 616 Communications August 1978 of Volume 12 the ACM Number 8 Applying Transpose (/+):((ax): <<1,6>, <2,5>, <3,4>>) provides a general environment for its changeable fea- Effect of ApplyToAll, a (/+): <x: <1,6>, x: <2,5>, x: <3,4>> tures. Applying × (/+): <6,10,12> Now suppose a language had a small framework Effect of Insert, / +: <6, +: <lO,12>> which could accommodate a great variety of powerful Applying + +: <6,22> Applying + again 28 features entirely as changeable parts. Then such a frame- work could support many different features and styles Let us compare the properties of this program with without being changed itself. In contrast to this pleasant those of the von Neumann program. possibility, von Neumann languages always seem to have a) It operates only on its arguments. There are no an immense framework and very limited changeable hidden states or complex transition rules. There are only parts. What causes this to happen? The answer concerns two kinds of rules, one for applying a function to its two problems of von Neumann languages. argument, the other for obtaining the function denoted The first problem results from the von Neumann by a functional form such as composition, fog, or style of word-at-a-time programming, which requires ApplyToAll, af, when one knows the functions f and g, that words flow back and forth to the state, just like the the parameters of the forms. flow through the von Neumann bottleneck. Thus avon b) It is hierarchical, being built from three simpler Neumann language must have a semantics closely cou- functions (+, x, Trans) and three functional forms fog, pled to the state, in which every detail of a computation a f, and/f. changes the state. The consequence of this semantics c) It is static and nonrepetitive, in the sense that its closely coupled to states is that every detail of every structure is helpful in understanding it without mentally feature must be built into the state and its transition executing it. For example, if one understands the action rules. of the forms fog and af, and of the functions x and Thus every feature of avon Neumann language must Trans, then one understands the action of ax and of be spelled out in stupefying detail in its framework. (c~x)oTrans, and so on. Furthermore, many complex features are needed to prop d) It operates on whole conceptual units, not words; up the basically weak word-at-a-time style. The result is it has three steps; no step is repee, ted. the inevitable rigid and enormous framework of avon e) It incorporates no data; it is completely general; it Neumann language. works for any pair of conformable vectors. f) It does not name its arguments; it can be applied to any pair of vectors without any procedure declaration or 7. Changeable Parts and Combining Forms complex substitution rules. g) It employs housekeeping forms and functions that The second problem of von Neumann languages is are generally useful in many other programs; in fact, that their changeable parts have so little expressive only + and x are not concerned with housekeeping. power. Their gargantuan size is eloquent proof of this; These forms and functions can combine with others to after all, if the designer knew that all those complicated create higher level housekeeping operators. features, which he now builds into the framework, could Section 41 sketches a kind of system designed to be added later on as changeable parts, he would not be make the above functional style of programming avail- so eager to build them into the framework. able in a history-sensitive system with a simple frame- Perhaps the most important element in providing work, but much work remains to be done before the powerful changeable parts in a language is the availabil- above applicative style can become the basis for elegant ity of combining forms that can be generally used to and practical programming languages. For the present, build new procedures from old ones. Von Neumarm the above comparison exhibits a number of serious flaws languages provide only primitive combining forms, and in yon Neumann programming languages and can serve the von Neumann framework presents obstacles to their as a starting point in an effort to account for their present full use. fat and flabby condition. One obstacle to the use of combining forms is the split between the expression world and the statement world in von Neumann languages. Functional forms 6. Language Frameworks versus Changeable Parts naturally belong to the world of expressions; but no matter how powerful they are they can only build expres- Let us distinguish two parts of a programming lan- sions that produce a one-word result. And it is in the guage. First, sti framework which gives the overall rules statement world that these one-word results must be of the system, and second, its elbaegnahc parts, whose combined into the overall result. Combining single words existence is anticipated by the framework but whose is not what we really should be thinking about, but it is particular behavior is not specified by it. For example, a large part of programming any task in von Neumann the for statement, and almost all other statements, are languages. To help assemble the overall result from part of Algol's framework but library functions and user- single words these languages provide some primitive defined procedures are changeable parts. Thus the combining forms in the statement world--the for, while, framework of a language describes its fixed features and and if-then-else statements--but the split between the 617 Communications August 1978 of Volume 21 the ACM Number 8 two worlds prevents the combining forms in either world foundations provide powerful tools for describing the from attaining the full power they can achieve in an language and for proving properties of programs. When undivided world. applied to avon Neumann language, on the other hand, A second obstacle to the use of combining forms in it provides a precise semantic description and is helpful von Neumann languages is their use of elaborate naming in identifying trouble spots in the language. But the conventions, which are further complicated by the sub- complexity of the language is mirrored in the complexity stitution rules required in calling procedures. Each of of the description, which is a bewildering collection of these requires a complex mechanism to be built into the productions, domains, functions, and equations that is framework so that variables, subscripted variables, only slightly more helpful in proving facts about pro- pointers, file names, procedure names, call-by-value for- grams than the reference manual of the language, since mal parameters, call-by-name formal parameters, and so it is less ambiguous. on, can all be properly interpreted. All these names, Axiomatic semantics 11 precisely restates the in- conventions, and rules interfere with the use of simple elegant properties ofvon Neumann programs (i.e., trans- combining forms. formations on states) as transformations on predicates. The word-at-a-time, repetitive game is not thereby changed, merely the playing field. The complexity of this 8. APL versus Word-at-a-Time Programming axiomatic game of proving facts about von Neumann programs makes the successes of its practitioners all the Since I have said so much about word-at-a-time more admirable. Their success rests on two factors in programming, I must now say something about APL addition to their ingenuity: First, the game is restricted 12. We owe a great debt to Kenneth Iverson for showing to small, weak subsets of full von Neumann languages us that there are programs that are neither word-at-a- that have states vastly simpler than real ones. Second, time nor dependent on lambda expressions, and for the new playing field (predicates and their transforma- introducing us to the use of new functional forms. And tions) is richer, more orderly and effective than the old since APL assignment statements can store arrays, the (states and their transformations). But restricting the effect of its functional forms is extended beyond a single game and transferring it to a more effective domain does assignment. not enable it to handle real programs (with the necessary Unfortunately, however, APL still splits program- complexities of procedure calls and aliasing), nor does it ming into a world of expressions and a world of state- eliminate the clumsy properties of the basic von Neu- ments. Thus the effort to write one-line programs is mann style. As axiomatic semantics is extended to cover partly motivated by the desire to stay in the more orderly more of a typical von Neumann language, it begins to world of expressions. APL has exactly three functional lose its effectiveness with the increasing complexity that forms, called inner product, outer product, and reduc- is required. tion. These are sometimes difficult to use, there are not Thus denotational and axiomatic semantics are de- enough of them, and their use is confined to the world scriptive formalisms whose foundations embody elegant of expressions. and powerful concepts; but using them to describe avon Finally, APL semantics is still too closely coupled to Neumann language can not produce an elegant and states. Consequently, despite the greater simplicity and powerful language any more than the use of elegant and power of the language, its framework has the complexity modern machines to build an Edsel can produce an and rigidity characteristic of von Neumann languages. elegant and modem car. In any case, proofs about programs use the language of logic, not the language of programming. Proofs talk 9. Von Neumann Languages Lack Useful about programs but cannot involve them directly since Mathematical Properties the axioms of von Neumann languages are so unusable. In contrast, many ordinary proofs are derived by alge- So far we have discussed the gross size and inflexi- braic methods. These methods require a language that bility of von Neumann languages; another important has certain algebraic properties. Algebraic laws can then defect is their lack of useful mathematical properties and be used in a rather mechanical way to transform a the obstacles they present to reasoning about programs. problem into its solution. For example, to solve the Although a great amount of excellent work has been equation published on proving facts about programs, von Neu- mann languages have almost no properties that are ax+bx=a+b helpful in this direction and have many properties that for x (given that a+b ~ 0), we mechanically apply the are obstacles (e.g., side effects, aliasing). distributive, identity, and cancellation laws, in succes- Denotational semantics 23 and its foundations 20, sion, to obtain 12 provide an extremely helpful mathematical under- standing of the domain and function spaces implicit in (a + b)x = a + b programs. When applied to an applicative language (a + b)x = (a + b) l (such as that of the "recursive programs" of 16), its X~ 1. 618 Communications August 1978 of Volume 12 the ACM Number 8 Thus we have proved that x = 1 without leaving the past three or four years and have not yet found a "language" of algebra. Von Neumann languages, with satisfying solution to the many conflicting requirements their grotesque syntax, offer few such possibilities for that a good language must resolve. But I believe this transforming programs. search has indicated a useful approach to designing non- As we shall see later, programs can be expressed in von Neumann languages. a language that has an associated algebra. This algebra This approach involves four elements, which can be can be used to transform programs and to solve some summarized as follows. equations whose "unknowns" are programs, in much the a) A functional style of programming without varia- same way one solves equations in high school algebra. bles. A simple, informal functional programming (FP) Algebraic transformations and proofs use the language system is described. It is based on the use of combining of the programs themselves, rather than the language of forms for building programs. Several programs are given logic, which talks about programs. to illustrate functional programming. b) An algebra of functional programs. An algebra is described whose variables denote FP functional pro- 10. What Are the Alternatives to von Neumann grams and whose "operations" are FP functional forms, Languages? the combining forms of FP programs. Some laws of the algebra are given. Theorems and examples are given that Before discussing alternatives to von Neumann lan- show how certain function expressions may be trans- guages, let me remark that I regret the need for the above formed into equivalent infinite expansions that explain negative and not very precise discussion of these lan- the behavior of the function. The FP algebra is compared guages. But the complacent acceptance most of us give with algebras associated with the classical applicative to these enormous, weak languages has puzzled and systems of Church and Curry. disturbed me for a long time. I am disturbed because c) A formal functional programming system. A formal that acceptance has consumed a vast effort toward mak- (FFP) system is described that extends the capabilities ing von Neumann languages fatter that might have been of the above informal FP systems. An FFP system is better spent in looking forn ew structures. For this reason thus a precisely defined system that provides the ability I have tried to analyze some of the basic defects of to use the functional programming style of FP systems conventional languages and show that those defects can- and their algebra of programs. FFP systems can be used not be resolved unless we discover a new kind of lan- as the basis for applicative state transition systems. guage framework. d) Applicative state transition systems. As discussed In seeking an alternative to conventional languages above. The rest of the paper describes these four ele- we must first recognize that a system cannot be history ments, gives some brief remarks on computer design, sensitive (permit execution of one program to affect the and ends with a summary of the paper. behavior of a subsequent one) unless the system has some kind of state (which the first program can change and the second can access). Thus a history-sensitive I I. Functional Programming Systems (FP Systems) model of a computing system must have a state-transition semantics, at least in this weak sense. But this does not 11.1 Introduction mean that every computation must depend heavily on a In this section we give an informal description of a complex state, with many state changes required for each class of simple applicative programming systems called small part of the computation (as in von Neumann functional programming (FP) systems, in which "pro- languages). grams" are simply functions without variables. The de- To illustrate some alternatives to von Neumann lan- scription is followed by some examples and by a discus- guages, I propose to sketch a class of history-sensitive sion of various properties of FP systems. computing systems, where each system: a) has a loosely An FP system is founded on the use of a fixed set of coupled state-transition semantics in which a state tran- combining forms called functional forms. These, plus sition occurs only once in a major computation; b) has simple definitions, are the only means of building new a simply structured state and simple transition rules; c) functions from existing ones; they use no variables or depends heavily on an underlying applicative system substitution rules, and they become the operations of an both to provide the basic programming language of the associated algebra of programs. All the functions of an system and to describe its state transitions. FP system are of one type: they map objects into objects These systems, which I call applicative state transition and always take a single argument. (or AST) systems, are described in Section .41 These In contrast, a lambda-calculus based system is simple systems avoid many of the complexities and founded on the use of the lambda expression, with an weaknesses of von Neumann languages and provide for associated set of substitution rules for variables, for a powerful and extensive set of changeable parts. How- building new functions. The lambda expression (with its ever, they are sketched only as crude examples of a vast substitution rules) is capable of defining all possible area of non-von Neumann systems with various attrac- computable functions of all possible types and of any tive properties. I have been studying this area for the number of arguments. This freedom and power has its 619 snoitacinummoC tsuguA 8791 of emuloV 12 eht MCA 8 Number disadvantages as well as its obvious advantages. It is There is one important constraint in the construction analogous to the power of unrestricted control statements of objects: if x is a sequence with _J as an element, then in conventional languages: with unrestricted freedom x = ±. That is, the "sequence constructor" is "±-pre- comes chaos. If one constantly invents new combining serving." Thus no proper sequence has i as an element. forms to suit the occasion, as one can in the lambda Examples of objects calculus, one will not become familiar with the style or useful properties of the few combining forms that are ± 1.5 p¢ AB3 <AB, ,1 2.3> adequate for all purposes. Just as structured program- <.4, <<B>, C>, D> <,4, ±> = ± ming eschews many control statements to obtain pro- 11.2.2 Application. An FP system has a single oper- grams with simpler structure, better properties, and uni- ation, application. Iff is a function and x is an object, form methods for understanding their behavior, so func- thenf:x is an application and denotes the object which tional programming eschews the lambda expression, sub- is the result of applying f to x. f is the operator of the stitution, and multiple function types. It thereby achieves application and x is the operand. programs built with familiar functional forms with known useful properties. These programs are so struc- Examples of applications tured that their behavior can often be understood and +:<(cid:127),2> = 3 tI:<.A,B,C> = <B,C> proven by mechanical use of algebraic techniques similar I:<A,B,C> = A 2:<A,B,C> = B to those used in solving high school algebra problems. Functional forms, unlike most programming con- 11.2.3 Functions, F. All functions fin F map objects structs, need not be chosen on an ad hoc basis. Since into objects and are bottom-preserving:f:± = ±, for allf they are the operations of an associated algebra, one in F. Every function in F is either primitive, that is, chooses only those functional forms that not only provide supplied with the system, or it is defined (see below), or powerful programming constructs, but that also have it is a functional form (see below). attractive algebraic properties: one chooses them to max- It is sometimes useful to distinguish between two imize the strength and utility of the algebraic laws that cases in whichf:x=±. If the computation forf:x termi- relate them to other functional forms of the system. nates and yields the object ,_1_ we sayfis undefined at x, In the following description we shall be imprecise in that is, f terminates but has no meaningful value at x. not distinguishing between (a) a function symbol or Otherwise we sayfis nonterminating at x. expression and (b) the function it denotes. We shall Examples of primitive functions indicate the symbols and expressions used to denote Our intention is to provide FP systems with widely functions by example and usage. Section 31 describes a useful and powerful primitive functions rather than weak formal extension of FP systems (FFP systems); they can ones that could then be used to define useful ones. The serve to clarify any ambiguities about FP systems. following examples define some typical primitive func- tions, many of which are used in later examples of 11.2 Description programs. In the following definitions we use a variant An FP system comprises the following: of McCarthy's conditional expressions 17; thus we write l) a set O of objects; 2) a set F of functions f that map objects into objects; pl -+ el; ... ;pn ~ ;ne e,+l 3) an operation, application; instead of McCarthy's expression 4) a set F of functional forms; these are used to combine existing functions, or objects, to form new functions in (401---> el ..... pn ---~ ,ne T---~ en+l). F; The following definitions are to hold for all objects x, xi, 5) a set D of definitions that define some functions in F and assign a name to each. y, yi, Z, :iZ What follows is an informal description of each of Selector functions the above entities with examples. 1 :X ~- X=<X1, ... , Xn> ""* ;1X I and for any positive integer s 11.2.1 Objects, O. An object x is either an atom, a sequence <x~ .... , Xn> whose elements xi are objects, or S:X----X=<Xb...,Xn>&n~s--~ xs;-L ± ("bottom" or "undefined"). Thus the choice of a set A Thus, for example, 3:<A,B,C> = C and 2:<A> = ±. of atoms determines the set of objects. We shall take A Note that the function symbols ,1 2, etc. are distinct from to be the set of nonnull strings of capital letters, digits, the atoms 1, 2, etc. and special symbols not used by the notation of the FP Tail system. Some of these strings belong to the class of atoms thx -- x=<x~> ~ if; called "numbers." The atom ~ is used to denote the empty sequence and is the only object which is both an x=<xl, ..., Xn> & n 2__2 ~ <x2, .... xn>; i atom and a sequence. The atoms T and F are used to Identity denote "true" and "false." id:x - x 620 Communications August 1978 of Volume 12 the ACM Number 8 Atom and g, f and g are its parameters, and it denotes the atom:x - x is an atom ~ T; x#3- ~ F; ,1, function such that, for any object x, Equals (fog) :x =f:(g:x). eq:x -- x=<y,z> & y=z----> T; x=<y,z> & >---z~--y F; ,1, Some functional forms may have objects as parameters. Null For example, for any object x, c~ is a functional form, the null:x -= x=~ ~ ,21 x~_l_ ~ F; _1_ constant function of x, so that for any object y Reverse reverse:x = x=4~ ~ ;pd Yc:y = y=l ~ 3-; x. X=<Xl, ... , Xn> ~ <Xn, ... ; XI>; -J- In particular, _T_ is the everywhere-_l_ function. Distribute from left; distribute from right Below we give some functional forms, many of which distl:x - x=<y@> >--- ;pe are used later in this paper. We usep, f, and g with and X=<.V,<21 ..... an>> >----- <<f,&> ..... <y,,%>>; ± without subscripts to denote arbitrary functions; and x, distr:x -- x=<ff,y> ---) ;~q lX ..... x., y as arbitrary objects. Square brackets ... are used to indicate the functional form for construction, X=<<yl, ... , fn>,2> ---> <<.V1,Z>, ... , <fin,a>>; ± which denotes a function, whereas pointed brackets Length <...> denote sequences, which are objects. Parentheses length:x - x=<x, ..... Xn> --+ n; x=qa >--- 0; ,1, are used both in particular functional forms (e.g., in Add, subtract, multiply, and divide condition) and generally to indicate grouping. + :x = x=<y,z> &y,z are numbers--+ y+z; ,1, -:x - x=<y,z> & y,z are numbers ~ y-z; ,1, Composition x :x -- x=<y,z> & y,z are numbers ~ yXz; ,1, (fog):x -= f:(g:x) +:x - x=<y,z> & y,z are numbers---> y+z; ,1, (where y+0 = ),1, Construction fi ..... fn:x = <fi :x ..... fn:X> (Recall that since Transpose < .... _3 .... > = _1_ and all functions are _L-preserving, so trans:x -- x=<4, ..... 4'> >--" ;,/, is fi ..... fn-) X=<Xl, ... , Xn> --+ <yl, ... , fro>; _1_ where Condition ,liX<-~"~iX ... , Xim> and (p-+ f, g):x -- (p:x)=T---~ f:x; (p:x)=F--+ g:x; ± yj=<xtj ..... Xnj>, l_i__n, l_j_m. Conditional expressions (used outside of FP systems to And, or, not describe their functions) and the functional form condi- and:x ~ x=<T,T> >-- T; tion are both identified by "---~". They are quite different x=<T,F> V x=<F,T> V x=<F,F> >--- F; -3 although closely related, as shown in the above defini- etc. tions. But no confusion should arise, since the elements Append left; append right of a conditional expression all denote values, whereas apndl:x = x=<y,ep> ~ <y>; the elements of the functional form condition all denote functions, never values. When no ambiguity arises we X~-<.V,<Z1 .... , Zn>> ~ <y, Zl .... , Zn>; _3 omit right-associated parentheses; we write, for example, apndr:x =- x=<q,,z>--+ <z>; pl ---)f,;p2--*f2; g for (pl---> fi; (/02-'-~ f2; g)). X=<<yl ..... yn>,Z> "-'> <yl ..... yn,,Z>; "1" Right selectors; Right tail Constant (Here x is an object parameter.) ~c:y = y=/~ ±; x lr:x - x=<x,, ..., Xn> ---) Xn; -J- 2r:x -- x=<x~, ..., x,> & n_2 -+ x,-,; -3 Insert etc. /f:x -= x=<xl> ~ Xl; x=<xl, ..., xn > & n_>2 tlr:x-- x=<x~> --+ 6; -->f:<x,,/f:<x2 ..... Xn>>; ± x=<x, .... , x,> & n_>2 --+ <x, ..... Xn-,>; "1" If f has a unique right unit ur # ±, where Rotate left; rotate right f:<x,ur> E {x, }_3 for all objects x, then the above rotl:x = x=~ ~ ;~4 x=<xl> >--" <Xl>; definition is extended:/f:q~ = ur. Thus x=<x, ..... x.> & n_2 >--- <x2 .... , Xn,X,>; ± etc. /+:<4,5,6> = +:<4, +:<5,/+:<6>>> = +:<4, +:<5,6>> = 15 11.2.4 Functional forms, F. A functional form is an /+:~=0 expression denoting a function; that function depends on the functions or objects which are the parameters of the Apply to all expression. Thus, for example, iff and g are any func- af:x - x=ep ~ ;'4 tions, then fog is a functional form, the composition off X=<XI ..... Xn> ~ <f:x, ..... f:Xn>; ± 621 Communications August 1978 of Volume 12 the ACM Number 8 Binary to unary (x is an object parameter) and knows how to apply it. Iffis a functional form, then (bu f x) :y - f: <x,y> the description of the form tells how to compute f: x in terms of the parameters of the form, which can be done Thus by further use of these rules. Iff is defmed, Deff- r, as (bu + l):x = l+x in (3), then to fmdf:x one computes r:x, which can be done by further use of these rules. If none of these, then While f:x - ._1. Of course, the use of these rules may not (while p f): x ~ p: x= T *-- (while p f): (f: x); terminate for somefand some x, in which case we assign p:x=F---~ x; ± the value f: x --- ._1. The above functional forms provide an effective method for computing the values of the functions they 11.3 Examples of Functional Programs denote (if they terminate) provided one can effectively The following examples illustrate the functional pro- apply their function parameters. gramming style. Since this style is unfamiliar to most readers, it may cause confusion at first; the important 11.2.5 Definitions. A definition in an FP system is an point to remember is that no part of a function definition expression of the form is a result itself. Instead, each part is a function that must Def l -- r be applied to an argument to obtain a result. 11.3.1 Factorial. where the left side 1 is an unused function symbol and the right side r is a functional form (which may depend Def ! - eq0 ~ ; xoid, !osubl on/). It expresses the fact that the symbol I is to denote where the function given by r. Thus the definition Def last 1 - loreverse defines the function lastl that produces the Def eq0 -- eqoid, 0 last element of a sequence (or ±). Similarly, Def subl - -oid, Def last -- nullotl >-- l; lastotl Here are some of the intermediate expressions an FP system would obtain in evaluating !: 2: defines the function last, which is the same as last .1 Here in detail is how the definition would be used to compute !:2 ~ (eqO--~ ;1 ×oid, !osubl):2 last: <1,2>: xoid, !osubl:2 ×:<id:2, !osubl:2> ~ ×:<2, !:1> last:<l,2> = definition of last (nullotl ---, ;1 lastotl):<l,2> x:<2, x:<l, !:0>> action of the form (p--~fi g) lastotl:<l,2> x:<2, X:<I,I:0>> ~ x:<2, x:<l,l>> since nullotl:<l,2> = null:<2> x:<2,1> ~ 2. =F action of the form fog last:(tl:<l,2>) In Section 21 we shall see how theorems of the algebra definition of primitive tail last:<2> of FP programs can be used to prove that ! is the definition of last (nullotl ~-- l; lastotl):<2> factorial function. action of the form (p-*~ g) 1:<2> since nutlotl:<2> = null:oh = T 11.3.2 Inner product. We have seen earlier how this definition of selector 1 ~2 definition works. The above illustrates the simple rule: to apply a Def IP -~ (/+)o(ax)otrans defined symbol, replace it by the right side of its defini- tion. Of course, some definitions may define nontermi- 11.3.3 Matrix multiply. This matrix multiplication nating functions. A set D of definitions is well formed if program yields the product of any pair <re,n> of con- no two left sides are the same. formable matrices, where each matrix m is represented 11.2.6 Semantics. It can be seen from the above that as the sequence of its rows: an FP system is determined by choice of the following m = <ml, ... , mr> sets: (a) The set of atoms A (which determines the set of where mi = <mil ..... mis> for i = 1 ..... r. objects). (b) The set of primitive functions P. (c) The set Def MM = (aalp)o(adistl)odistro ,1 transo2 of functional forms F. (d) A well formed set of definitions D. To understand the semantics of such a system one The program MM has four steps, reading from right to needs to know how to compute f:x for any function f left; each is applied in turn, beginning with 1, transo2, and any object x of the system. There are exactly four to the result of its predecessor. If the argument is <m,n>, possibilities for f: then the first step yields <rn,n'> where n' = trans:n. The (l)fis a primitive function; second step yields <<ml,n'> .... , <mr,n'>>, where the (2)fis a functional form; mi are the rows of m. The third step, adistl, yields (3) there is one definition in D, Deff- r; and <distl:<ml,n'>, ..., distl:<mr,n'>> = <pl, ... ,pr> (4) none of the above. Iff is a primitive function, then one has its description where 622 Communications August 1978 of Volume 21 the ACM Number 8