• AD is a medium-scale, high-level programming language. Syntactically, it is a sublanguage of ADA.

• The specified action semantics for AD constructs does not always correspond exactly to the semantics described in the ADA Reference Manual. For instance, parameter passing modes are left implementation-dependent in ADA, but not in AD.

• The action semantic description of AD given here collects and extends the fragmented illustrations given throughout Part III. It also provides the full algebraic specifications of all the semantic entities used in Part III.

• Some of the actions specified in Part III are respecified here with some extra subactions. For example, the action representing the execution of a block statement now synchronizes with locally-declared tasks before starting to execute the block body, and relinquishes locally-declared variables afterwards.

• The description of AD allows assessment of the pragmatic qualities of action semantics: readability, comprehensibility, modularity, modifiability, etc.

• To extend the description of AD to an accurate description of ADA would be a major project, the feasibility of which remains to be seen.

• The modular structure of the description is specified first, in the order in which the modules are presented, which is mostly bottom-up.

In this first part of the book we introduce a few categories as fundamental semantic frameworks and explore the formulation of general choice operators and iteration in arbitrary categories with finite coproducts.

• The specification of the algebraic properties of action notation in this Appendix is divided into modules as shown on the next page.

• The body of each module introduces symbols, highlights their principal properties, and lists their secondary properties.

• The properties specified are sufficient to reduce the full action notation to a kernel, whose abstract syntax and structural operational semantics are defined in Appendix C.

• The specified properties of the kernel action notation hold for the notion of action equivalence defined at the end of Appendix C. The algebraic theory of action notation is not yet fully developed, although it may already be adequate for verifying the semantic correctness of simple program optimizations.

• Action notation supports concurrency, but without introducing a combinator for it, so there are no algebraic properties concerning the sending and receipt of messages, or the fulfilment of contracts.

• The moduleFacetsdeserves special mention. It defines a moderately expressive notation for subsorts of actions, with reference to outcomes and incomes, and similarly for yielders. This notation is specified axiomatically; the expected correspondence with the operational semantics of action notation has not yet been proved. Nevertheless, the axiomatic specification of the subsort notation provides useful documentation of the sorts of yielders to be used in primitive actions, and of the various facets of the action combinators.

• Descriptions of programming languages have several important applications.

• Different applications require different features of descriptions.

• Informal descriptions are inadequate: formality is essential.

• Good pragmatic features are needed to make formal descriptions usefu.

• Comprehensive language descriptions involve both syntax and semantics.

• Standards relate syntax and semantics to implementations.

This chapter provides some background for the main topic of this book, namely the action semantic description of programming languages. We start by identifying some important uses for descriptions of programming languages. Although various uses require different features of descriptions, these requirements are not necessarily conflicting. Formality is a particularly important feature. We go on to consider the factorization of language descriptions into syntax and semantics, and discuss how they relate to the pragmatic issue of setting standards for programming languages.

Motivation

Programming languages are artificial languages. Programs written in them are used to control the execution of computers. There are many programming languages in existence. Some are simple, intended for special purposes; others are complex and general-purpose, for use in a wide variety of applications.

Even though programming languages lack many of the features of natural languages, such as vagueness, it is not at all easy to give accurate, comprehensive descriptions of them. Which applications require descriptions of programming languages—and hence motivate the study of appropriate frameworks for such descriptions?

First, there is the programming language design process.

• Task declarations initiate concurrent processes, which can synchronize using entry calls and accept statements. The select statement may now iterate until an entry call can be accepted.

• The semantics of task declarations illustrates the use of the communicative action notation introduced in Chapter 10.

• Semantic entities now include agents, and various signals sent in messages. They also include entities that represent open alternatives of selections.

Let us first consider the treatment of input and output in programming languages. By definition, the input of a program is the information that is supplied to it by the user; the output is the information that the user gets back. However, it is important to take into account not only what information is supplied, but also when the supply takes place. We may distinguish between so-called batch and interactive input-output.

With batch input, all the input to the program is supplied at the start of the program. The input may then be regarded as stored, in a file. Batch output is likewise accumulated in a file, and only given to the user when (if ever) the program terminates. On the other hand, interactive input is provided gradually, as a stream of data, while the program is running; the program may have to wait for further input data to be provided before it can proceed. Similarly, interactive output is provided to the user while the program is running, as soon as it has been determined.

• Action notation includes a data notation for general use.

• Standard data consists of tuples, truth-values, numbers, characters, strings, lists, trees, sets, and maps.

• Some of the operations of data notation are intended for use mainly on proper sorts, rather than on mere individuals.

• Appendix E gives the full algebraic specification of data notation.

Consider an implementation of a high-level programming language. When a program is run, the information processed by it is represented entirely by sequences of bits: O's and 1's. The programmer, however, does not usually have to deal with this representation directly. The program can be regarded as processing abstract entities, such as numbers, arrays, and sets. Indeed, standards for high-level programming languages generally leave the binary representation of information unspecified. Recall from Chapter 1 that the semantics of a program is an entity which represents the implementation-independent aspects of its information processing behaviour, and that the semantics of a phrase is an entity which represents its contribution to overall behaviour. In action semantics, these entities are generally actions. The information processed by programs is represented by items of data, which correspond directly to abstract entities such as numbers rather than to bit sequences.

Various sorts of data are needed for the semantics of general-purpose high-level programming languages, not only ‘mathematical’ values such as numbers and lists, but also abstract entities of computational origins such as variables, procedures, packages, and so on.

• Action notation includes a declarative action notation for specifying scopes of bindings.

• Declarative actions are concerned with scoped information.

• Chapter H illustrates the use of declarative action notation in the semantic description of declarations, expressions, and statements.

Declarative actions axe concerned with processing scoped information, which generally gets propagated further than transient information. The scoped information current at the start of an action is often current throughout the action—although it may get temporarily hidden by other scoped information within the action. It disappears at the end of its scope.

Scoped information represents the associations, called bindings, which declarations in programs establish between identifiers and entities such as constants, variables, procedures, etc. Implementations usually represent bindings by some form of symbol table.

Programming languages are often characterized as having static or dynamic scopes for bindings. The difference concerns whether or not it is possible to determine from the program text, before running the program with its input, which declarations establish the bindings of which identifiers. For efficiency, compilers extract the required information from the symbol table during compilation, so that it isn't needed when the compiled code is run.

The possibility of dynamic bindings only arises when the programming language contains procedures, or similar constructs, where the body of the procedure can be called from various parts of the program: the bindings current at each call might be different.

• Subprograms are classified as procedures or functions.

• Procedures are parameterized statements. They may be declared, and then called with various actual parameters. Formal parameter declarations resemble incomplete constant and variable declarations.

• Functions are essentially parameterized expressions.

• The semantics of subprogram declarations and calls illustrates the use of the reflective action notation introduced in Chapter 9, as well as the declarative action notation introduced in Chapter 7.

• Semantic entities now include subprogram entities, which are formed from abstractions, and data that are used to distinguish subprogram returns from other reasons for abnormal termination of statement execution.

A procedure is a construct that incorporates a statement, which is known as the body of the procedure. A procedure declaration binds an identifier to a procedure. A procedure call statement causes the body of the identified procedure to be executed. In a few languages, procedures are provided as expressions; then a procedure declaration may be written just like an ordinary constant declaration.

A function is like a procedure, but a function body is essentially an expression, rather than a statement: it has to return a result. A function call is a kind of expression. In practice, most conventional programming languages allow impure functions, where the body is a mixture of statements and an expression.

• The systematic informal description of action notation summarizes Part II, and gives further details. It is intended for reference

• To make it self-contained, it starts by repeating most of the introduction to the concepts of actions, data, and yielders given in Section 1.5.2.

• The symbols of action notation are explained below in the same order as they are introduced in Part II and Appendix B, as indicated below. See the start of Appendix B for a more detailed overview of the modular structure of action notation.