• 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.

• The algebraic specification of data notation given here is definitive. See Chapter 5 for an informal introduction to the various symbols. The occasional informal comment is inserted in the formal specification where appropriate.

• The specification is divided into nested modules. The order of presentation of the modules is such that earlier modules do not often refer to later ones. In fact the submodules could be presented in a strictly bottom-up manner, but this would make navigation more difficult.

• Reference to the module Data Notation/General includes all the specified modules except for the submodule Characters/ASCII, thus allowing specialization to alternative character sets. It also omits the Instant submodules, which are intended for use with the symbols translated to some specified sort.

Part III gives a progressive series of examples of action semantic descriptions. The programming constructs described all come from ADA. (NO previous familiarity with ADA is required, as the necessary concepts are all explained here.) The examples not only describe a substantial sublanguage of ADA, they also serve as paradigms for description of other programming languages. The description of constructs in the earlier examples remains unchanged in the later examples. This is in marked contrast to denotational semantics, where tedious reformulations of the earlier descriptions would be required when giving the later ones! Appendix A collects the examples together, for convenience of reference—and to show how a medium-scale action semantic description looks in its entirety. It also specifies the detailed specifications of semantic entities that are omitted in Part III.

Navigation

• If this is your first reading, proceed in parallel through Parts II and III: Chapter 4, Chapter 11, Chapter 5, Chapter 12, and so on. This way, you see an illustration of the use of each part of action notation immediately after its introduction.

• If you are already familiar with high-level programming languages, you could alternatively look at each chapter of Part III before the corresponding chapter of Part II. This way, the illustrations in Part III motivate the action notation introduced in Part II.

• If you are revising, and would like an uninterrupted presentation of examples of action semantic descriptions, proceed straight through Part III.

The founding paper [Pratt 1976] on dynamic logic begins as follows:

This book continues study of such mathematics with particular emphasis on semantic frameworks. We intend for these frameworks to be flexible, relying on no particular concept of state. Ultimately, extensions of the theory are to address at least program semantics, operating systems, concurrent processes and distributed networks; but the accomplishments of the foundational core herein are modest.

We shall be concerned with a category-theoretic foundation. One possible paradigm is that a morphism is the behaviour of a program. Composition of morphisms models program-chaining. An implementation of a programming language must provide a definite category in which to assign morphisms to programs. We shall also require that high-level specifications about programs map, as well, to true-false assertions about the corresponding interpreted programs.

Our semantic frameworks are categories satisfying certain axioms, that is, are models of the first-order theory of categories. Composition is the only primitive operation. Such models are strongly typed in that two morphisms cannot be composed unless the target of the first coincides exactly with the source of the second.

• The original motivation for the development of action semantics was dissatisfaction with pragmatic aspects of denotational semantics.

• Early work on abstract semantic algebras focused on the use of algebraic axioms to specify the intended interpretation of action notation.

• Although the concrete form of action notation has varied greatly, the underlying primitives and combinators have remained rather stable.

• The adoption of a meta-notation based on unified algebras simplified the algebraic specification of generic abstract data types, and allowed the use of operations on sorts in actions.

• The provision of a structural operational semantics for action notation emphasized the operational essence of action notation, and allowed the verification of algebraic laws.

• Recent enhancements of action semantics concern the grammars for specifying abstract syntax, action notation for communication and indirect bindings, and the notation for sorts of actions.

• Current and future projects involve: the action semantic description of various programming languages; the implementation of systems supporting the creation, editing, checking, and interpretation of descriptions; action semantics directed compiler generation; and the further investigation of the theory of action notation.

• The author welcomes comments on action semantics, and maintains a mailing list.

This concluding chapter explains the original motivation for the development of action semantics. It then gives what amounts to an annotated bibliography for action semantics and for its precursor, a framework called abstract semantic algebras. Finally, it describes current work, and invites you to participate in the future development of action semantics.

Part IV concludes by briefly relating action semantics to other frameworks, and by sketching its development. It cites the main sources for action semantics and the related frameworks, and mentions some current projects.

• Action notation includes a communicative action notation for specifying information processing by distributed systems of agents.

• Communicative actions are concerned with permanent information.

• Chapter 17 illustrates the use of communicative action notation in the semantic description of tasks and entry calls.

So fax, we have dealt with sequential performance of actions by a single agent in isolation. Let us now consider concurrent performance by a distributed system of agents, where each agent can communicate with the other agents, sending and receiving messages and offering contracts. Even when only one agent is active, this generalizes action performance sufficiently to allow the representation of interactive input-output behaviour, where nonterminating information processing is especially significant.

An agent represents the identity of a single process, embedded in a universal communication medium, or ‘ether’. Implementations of processes may run them on physically separate processors, linked by buses or networks, or on a single processor using time-sharing. Of course each processor itself may consist of a number of connected parts, such as CPU, memory modules, video cards, etc. Agents may correspond to the behaviours of such special-purpose subprocessors, as well as to processes specified directly in high-level programming languages.

Communication between agents is asynchronous: to send a message, an agent emits the message into the medium, with another agent specified as the receiver, and then carries on performing, not waiting until the message has been delivered to the other agent.

Part I introduces the concepts and formalism used in action semantics. First it motivates formal descriptions of programming languages, and discusses their main features. It then explains the particular kinds of formal specification used in action semantic descriptions of programming languages, giving a simple illustrative example. Finally it presents an unorthodox framework for algebraic specifications, and sketches the algebraic foundations of action semantics.

Navigation

• Have you read the Preface? If not, please do so now—it explains how this book is organized.