One stimulus for writing this article was a talk entitled ``Programming languages of the year 2000'' that I considered insufficiently ambitious.
It has long been said that programming languages need more of the features of natural language, but it has not been clear what the desirable features are, and there have been few significant conceptual advances in the last 20 years. It is rather clear that the surface syntax of natural language doesn't offer much; COBOL did not turn out to be an advance.
This article proposes several new features for programming languages more or less taken from natural language. We also propose new kinds of specifications that make it easier to be confident that the specifications express what is wanted of the program. As a vehicle we propose Elephant 2000, a language that would embody them. Some features are not yet well enough defined to be included in the program examples.
For example, when a program ``promises'' someone to do something, it needn't believe (as Searle (1969) suggests it should) that fulfillment of the promise will do its recipient some good. Indeed many programs that promise won't have any beliefs at all. We expect to be able to generate the intrinsic correctness sentences automatically from the text of the program. Thus the text of the program that designates certain outputs as answers to questions, determines a logical sentence asserting that the answers are truthful.
In the customary philosophical terminology, some of the outputs of Elephant programs are performative sentences, commonly referred to just as performatives. Indeed Elephant 2000 started with the idea of making programs use performatives. However, as the ideas developed, it seemed useful to deviate from the notions of speech act discussed by J. L. Austin (1962) and John Searle (1969). Thinking about speech acts from the design standpoint of Daniel Dennett (1971) leads to a view of them different from the conventional one. We now refer to abstract performatives which include purely internal actions such as commitments not necessarily expressed in output, but on whose fulfillment the correctness of the program depends. Taking the design stance in the concrete way needed to allow programs to use speech acts tends to new views on the philosophical problems that speech acts pose.
Notice that it isn't necessary for most purposes to apply moral terms like honest, obedient or faithful to the program, and we won't in this paper. However, we can incorporate whatever abstract analogs of these notions we find useful. The philosophical investigations have resulted in ideas useful for our purposes. This is partly because programs belonging to one organization that interact with those belonging to other organizations will have to perform what amounts to speech acts, and the specifications of these programs that have to be verified often correspond to what Austin calls the happy performance of the speech acts.
(McCarthy 1979a) discusses conditions under which computer programs may be ascribed beliefs, desires, intentions and other mental qualities. It turns out that some specifications require ascription of beliefs, etc. for their proper statement, and others do not.
Allowing direct reference to the past may also permit easier modification, because the program can refer to past events, e.g. inputs and outputs, directly rather than via data structures whose design has to be studied and understood. Since referring directly to past events is characteristic of natural languages, we expect it to prove useful in programming languages.
Procedures for human execution often specify perlocutionary acts. For example, a teacher might be told, ``Have your students take the test on Wednesday''. However, including perlocutionary acts in programs is appropriate only if the program has good enough resources for accomplishing goals to make it reasonable to put the goal in the program rather than actions that the programmer believes will achieve it. One would therefore expect perlocutionary statements mainly in programs exhibiting intentionality, e.g. having beliefs, and involving some level of artificial intelligence.
Even without putting perlocutionary acts in the program itself, it is worthwhile to consider both input-output and accomplishment specifications and for programs. These correspond to illocutionary and perlocutionary speech acts respectively. For example, an air traffic control program may be specified in terms of the relations between its inputs and its outputs. This is an input-output specification. Its verification involves only the semantics of the programming language. However, our ultimate goal is to specify and verify that the program prevents airplanes from colliding, and this is an accomplishment specification. Proving that a program meets accomplishment specifications must be based on assumptions about the world, the information it makes available to the program and the effects of the program's actions as well on facts about the program itself. These specifications are external in contrast to the intrinsic specifications of the happy performance of speech acts.
It will often be worthwhile to formulate both input-output and accomplishment specifications for the same program and to relate them. Thus an argument based on an axiomatic theory of the relevant aspects of the world may be used to show that a program meeting certain input-output specifications will also meet certain accomplishment specifications. Apparently the dependence of program specifications on facts about the physical world makes some people nervous. However, the problem of justifying such axiomatic theories is no worse than that of justifying other formalized theories of the physical world in applied mathematics. We are always trusting our lives to the physical theories used in the design of airplane wings.
This article is exploratory, and we are not yet prepared to argue that every up-to-date programming language of the year 2000 will include abstract performatives. We hope that programs using performatives will be easier to write, understand, debug, modify and (above all) verify. Having a standard vocabulary of requests, commitments, etc. will help.