A Tutorial on Action

DRAFT

1

Peter D Mosses

Computer Science Department

Aarhus University

Ny Munkegade Bldg

DK Aarhus C Denmark

Octob er

NB This draft is incomplete and unpolished

It is not to be copied without the written p ermission of the author

1

Internet p dmossesdaimiaaudk

Contents

Introduction

Motivation

Requirements

Features

Concepts

Syntax

Concrete Syntax

Abstract Syntax

ContextSensitive Syntax

Semantics

Semantic Functions

Semantic Entities

Pragmatics

An Illustrative Example

Abstract Syntax

Expressions

Statements

Declarations

Programs

Semantic Functions

Expressions

Statements

Declarations

Programs

Conclusion

A An Illustrative Example ctd

B Action Notation

C Data Notation i

Abstract

Formal semantics is a topic of ma jor imp ortance in the study of programming languages Its

applications include do cumenting language design establishing standards for implementations

reasoning ab out programs and generating compilers

This tutorial is ab out action semantics a recentlydeveloped framework for formal seman

tics The primary aim of action semantics is to allow useful semantic descriptions of realistic

programming languages

Action semantics combines formality with many go o d pragmatic features Regarding com

prehensibility and accessibility for instance action semantic descriptions comp ete with informal

language descriptions Action semantic descriptions scale up smo othly from small example lan

guages to fullblown practical languages The addition of new constructs to a describ ed language

do es not require reformulation of the alreadygiven description An action semantic description

of one language can make widespread reuse of that of another related language All these prag

matic features are highly desirable Action semantics is however the only semantic framework

that enjoys them

Action semantics is compositional like The main dierence b etween

action semantics and denotational semantics concerns the universe of semantic entities action

semantics uses entities called actions rather than the higherorder functions used with deno

tational semantics Actions are inherently more op erational than functions when performed

actions pro cess information gradually

Primitive actions and the various ways of combining actions corresp ond to fundamental

concepts of information pro cessing Action semantics provides a particular notation for express

ing actions The symbols of action notation are suggestive words rather than cryptic signs

which makes it p ossible to get a broad impression of an action semantic description from a

sup ercial reading even without previous exp erience of action semantics The action combina

tors a notable feature of action notation ob ey desirable algebraic laws that can b e used for

reasoning ab out semantic equivalence

This tutorial provides a quick halfday introduction to action semantics It should b e

accessible to senior undergraduates and to professional programmers No previous knowledge

of formal semantics is assumed For further study a full exp osition of the framework and an

extended example are provided in Mos

Chapter sketches the background for action semantics motivating the formal description of

programming languages by considering the requirements of various p otential users Chapter

recalls the notions of abstract syntax and comp ositional semantics and introduces the novel

concept of actions as used in action semantics Chapter takes a walk through an illustrative

description explaining all the notation that it uses Chapter assesses the pragmatic qualities of

action semantic descriptions and compares the framework to VDM and RAISE The App endices

provide a full algebraic sp ecication of the sp ecial notation used together with an informal summary of the standard notation

Chapter

Introduction

This chapter provides some background for the topic of this tutorial namely the action semantic

description of programming languages We start by identifying some imp ortant uses for descrip

tions of programming languages Although various uses require dierent features of descriptions

these requirements are not necessarily conicting Formality is a particularly imp ortant feature

Motivation

Programming languages are articial 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 sp ecial purp oses others are complex and generalpurp ose 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 languagesand hence motivate the study of

appropriate frameworks for such descriptions

First there is the programming language design pro cess Designers need to record decisions

ab out particular language constructs esp ecially when the design is a team eort This amounts

to giving a partial description of the language At a later stage the formulation of a complete

language description may b e useful for drawing attention to neglected details and for revealing

irregularities in the overall design

Once a language has b een designed it usually gets implemented although in practice design

and implementation are often interleaved and iterated A comprehensive description of the

language is needed to convey the intentions of the language designers to the implementors

unless the designer and the implementor are the same p erson of course It is also needed for

setting a denitive standard for implementations so that programs can b e transp orted b etween

dierent implementations that conform to the standard without mo dication

A programmer needs a description of any new language in order to relate it to previously

known ones and to understand it in terms of familiar concepts The programmer also needs a

description as a basis for reasoning ab out the correctness of particular programs in relation to

their sp ecications and for justifying program transformations

Finally theoreticians can obtain new insight into the general nature of programming lan

guages by developing descriptions of them This insight can then b e exploited in the design of

new and p erhaps more elegant programming languages

CHAPTER INTRODUCTION

So we see that there are plenty of applications for descriptions of programming languages

But not all kinds of description are suitable for all purp oses The various applications mentioned

ab ove require dierent prop erties of descriptions as we consider next

Requirements

Which prop erties might language designers require of language descriptions Well design is an

iterative pro cess so to start with designers need partial descriptions that can easily b e extended

and mo died They also need descriptions that provide clear and concise do cumentation of

individual language design decisions For economy of eort they might want to b e able to reuse

parts of descriptions of existing languages in the description of a new language Finally their

completed language description should provide an appropriate basis for conveying the design to

the implementors and for setting standards

The implementors of a language require a complete and unambiguous description of it

except that certain features such as the order of sub expression evaluation may have b een

delib erately left unsp ecied Explicit indication of implementation techniques in the description

may b e helpful but it might discourage alternative p erhaps more ecient implementations

Ideally the conformance of a purp orted implementation to a standard imp osed by a language

description should b e veriable

A longterm aim is to generate complete correct and ecient implementations automatically

from language descriptions in the same way that parsers can b e generated from grammars

There have already b een some encouraging exp eriments in this direction This application

requires that the language descriptions can b e directly related to machine op eration

What do programmers require A language description should b e easy to understand and

to relate to familiar programming concepts without a ma jor investment of eort in learning

ab out the description technique itself It should supp ort program verication And it shouldnt

take up to o much space on the shelf

Theoreticians may require clear and elegant foundations for the exploited description tech

nique to supp ort tractable reasoning ab out equivalence and other program features They may

take a prescriptive view of language description considering only a restricted class of program

ming languagesthose amenable to their favourite description techniquein the hop e that this

will prevent the design of big bad and ugly languages Or they may take a more lib eral

descriptive view requiring a universal description technique that can cop e with any conceiv

able programming language and hoping that p o or language design will b e evident from its

description

It seems highly unlikely that all the ab ove requirements can b e fully satised simultaneously

Certainly none of the previously available frameworks app ears to b e suitable for use in all the

ab ove applications This has led to the prop osal of socalled complementary language descrip

tions where several dierent techniques are used to give indep endent but hop efully relatable

descriptions of the same language

The topic of this tutorial action semantics avoids the need for complementary descriptions

by making a compromise b etween the ab ove requirements An action semantic description

is extremely mo dular providing the high degree of extensibility mo diability and reusability

required by language designers It is also strongly suggestive of an op erational understanding of the describ ed language and it has b een found to b e very well suited for generating compilers

FEATURES

and interpreters so implementors should b e content Programmers should nd action semantic

descriptions almost as easy to read as the usual reference manuals without much preparation

On the other hand although the foundations of action semantics are rm enough the theory

for reasoning ab out actions and hence ab out programs is still rather weak and needs further

development This situation is in marked contrast to that of denotational semantics Mos

1

where the theory is strong but severe pragmatic diculties hinder its application to realistic

programming languages

Some of these claims for the virtues of action semantic descriptions can b e supp orted by

lo oking at an example Let us p ostp one consideration of the extent to which action semantics

meets the stated requirements until Chapter after we have seen action semantics in action

Features

One esp ecially signicant feature of language descriptions is whether or not they are formal Let

us distinguish b etween formal and informal descriptions as follows Purely formal descriptions

are expressed in welldened established notation often b orrowed from mathematics Note that

this notation itself may have b een established either formally using some previouslyestablished

metanotation or informally but rigorously as in most mathematical texts Purely informal

descriptions are expressed in natural languages such as English

Currently the only comprehensive description of a programming language is usually its

reference manual which is mainly informal Unfortunately exp erience has shown that even

when carefully worded such reference manuals are usually incomplete or inconsistent or b oth

and op en to misinterpretation This is obviously undesirable esp ecially when such descriptions

are used to guide implementors and to set standards The existence of pro cedures for requesting

clarication of international standards which are generally based on reference manuals conrms

that misinterpretation is a problem Moreover informal descriptions can never provide a sound

basis for reasoning ab out program correctness or equivalence

To comp ensate for the vaguenesses of an informal language description a formal validation

suite of programs is sometimes used as the nal arbiter of implementation correctness By

itself however such a validation suite is not much use as a language description In any case

the correct pro cessing of a validation suite by an implementation cannot guarantee analogous

p erformance on other programs

It might b e imagined that informal descriptions should b e easy to read b ecause they are

written in a natural language but in fact the vain attempt to b e precise in a natural language

leads to a rather stilted literary style that is tedious to read on a large scale When wellwritten

however informal descriptions can provide an easilyaccessible guide to the fundamental concepts

underlying a programming language this seems to b e their only real strength

Formal descriptions have almost the opp osite qualities to informal ones They can b e com

plete and consistent and can b e given a precise interpretation appropriate for setting denitive

standards Questions ab out their consequences are answered by the theoretical foundations of

the formal notation used Formal descriptions can b e used as the basis for systematic develop

ment and automatic generation of implementations And it is one of their main strengths that

they can provide a basis for sound reasoning ab out program correctness and equivalence

1 at least for dealing with deterministic sequential programs

CHAPTER INTRODUCTION

On the other hand it is often dicult to relate a formal description of a programming

language to fundamental concepts and to grasp the implications of the description for the

implementation of programs Poor notation or excessively large and complex formulae can also

lead to obscurity Inferior formal descriptions can b e unintentionally ambiguous or incomplete

even inconsistent The mere use of formality do es not ensure success

One could consider the text of a compiler or of an interpreter as a formal denition of the

language that it implements The language used for writing it should already have a welldened

interpretation of course a socalled metacircular interpreter written using the language itself

b eing interpreted do esnt formally dene anything at all Unfortunately practical compilers for

realistic programming languages are somewhat unwieldy ob jects and demand familiarity with

particular target co des Interpreters are generally more accessible but still tend to have many

details that are incidental to the implemented language So much for the background of formal descriptions

Chapter

Concepts

This chapter explains the concepts underlying action semantic descriptions of programming

languages It considers the factorization of language descriptions into syntax and semantics

and discuss the pragmatic issue of setting standards for programming languages Readers who

are already familiar with other semantic description frameworks eg denotational semantics

may skip to Section

In programming as in the study of natural languages it is useful to distinguish

b etween syntax and semantics The syntax of a programming language is concerned only with

the form of programs which programs are legal what are the connections and relations

b etween the symbols and phrases that o ccur in them Semantics deals with the meaning of

legal programs

Ideally a comprehensive description of a programming language involves the sp ecication

of syntactic entities of semantic entities and of a semantic function that maps the former to

the latter The syntactic entities include the legal programs of the language and the semantic

entities include representations of the intended b ehaviours of these programs To facilitate

reasoning ab out parts of programs the semantic function should give semantics not only to entire

programs but also to their comp onent phrases and it should preferably b e compositional so that

the semantics of a comp ound phrase is determined purely by the semantics of its comp onents

indep endently of their other features

Most frameworks for language description unfortunately do not provide a clear separation

b etween syntactic and semantic entities nor do they exploit comp ositional semantic functions

A notable exception is denotational semantics from which action semantics was developed

The distinction b etween the syntax and the semantics of a language is dep endent on the

division into structure and b ehaviour At one extreme structure could b e trivialarbitrary

strings over an alphab et of symbolsand then the usual notion of program legality would have

to b e considered as a comp onent of b ehaviour At the other extreme b ehaviour could b e

incorp orated into a dynamic notion of structure For comprehensive language descriptions it

is b est to nd a compromise such that separate descriptions of syntax and semantics provide a

useful factorization of the entire description into parts with a simple interface

Syntax

The syntax of a programming language determines the set of its legal programs and the rela

tionship b etween the symbols and phrases o ccurring in them

CHAPTER CONCEPTS

We may divide syntax into concrete and abstract syntax Concrete syntax involves analysis

the recognition of legal programs from texts ie sequences of characters and their unambiguous

parsing into phrases Abstract syntax deals only with the comp ositional structure of phrases

of programs ignoring how that structure might have b een determined In general it is easier

to dene the semantics of programs on the basis of their abstract syntax rather than on their

concrete syntax

For comprehensive language descriptions b oth kinds of syntax are neededtogether with an

indication of how they are related Here we are mainly concerned with semantic descriptions

so we emphasize abstract syntax giving only a cursory explanation of concrete syntax and its

relation to abstract syntax

Concrete Syntax

Conventionally concrete syntax is separated into lexical analysis and phrasestructure analysis

The task of lexical analysis is to group the characters of a program text into a sequence of legal

symbols or lexemes That of phrasestructure analysis is to group these symbols into phrases

thereby constructing a parse tree or derivation tree with the symbols as leaves

The parse tree pro duced by phrasestructure analysis of a program represents the recognized

comp onent relation b etween its phrases It may also represent how the phrases have b een

classied

Both lexical and phrasestructure analysis are required to b e unambiguous a sequence of

characters making up a legal program must determine a unique sequence of symbols which in

turn must determine a unique parse tree In the case of ambiguity the programmer is left in

doubt ab out the recognized structure of the program

Abstract Syntax

Abstract syntax provides an appropriate interface b etween concrete syntax and semantics It is

usually obtained simply by ignoring those details of parse tree structure which have no seman

tic signicanceleaving abstract syntax trees that represent just the essential comp ositional

structure of programs

For instance in concrete syntax one usually subclassies comp ound arithmetic expressions

into terms and factors in order to avoid ambiguous parsing of sequences such as abc Factors

are more restricted than terms in that any additions that o ccur in factors have to b e enclosed in

grouping parentheses whereas the parentheses are optional when additions o ccur in terms The

term ab is not classied as a factor so the only p ossible parsing for abc is the one where bc

is group ed together But the only semantically relevant features of an arithmetic expression are

its sub expressions and its op erator so for abstract syntax we can ignore whether the expression

is classied as a term or as a factor

The symbols used for lab eling the no des in an abstract syntax tree may b e the same as the

lexical symbols of the corresp onding concrete syntax This is not essential though as the sym

b ols are needed only to distinguish no des for dierent constructs For instance whilestatements

and ifthenstatements usually b oth have two comp onents a condition and a statement extra

symbols are required to lab el them distinctly but these can b e chosen arbitrarily Similarly

when every statement is terminated by a semicolon in concrete syntax the semicolons may b e

omitted in the corresp onding abstract syntax as they have no distinguishing eect On the

SYNTAX

other hand the lexical symbols from the concrete syntax do have considerable suggestive and

mnemonic value By retaining them as lab els in abstract syntax treesin the same order that

they o ccur in the corresp onding parse treesmuch of the relation b etween concrete and abstract

syntax can b e made selfevident

Another way of abstracting details of parse tree structure is to ignore the order of comp o

nents when this is semantically insignicant For instance the order in which the cases of a

casestatement are written in the program text may b e irrelevant then one could take a set

of cases rather than an ordered list Similarly one might let declarations b e nite maps on

identiers instead of lists of pairsthereby reecting also that an identier is not to b e declared

twice in the same sequence of declarations This seems app ealing but on closer investigation

turns out to have gone too far in abstraction at least from a pragmatic p oint of view as it com

plicates the denition of semantic functions on abstract syntax In general however ignoring

semantically irrelevant details of parse tree structure tends to simplify the denition of semantic

functions

It can happ en that the comp ositional structure of programs derived from a given concrete

syntax has a nesting that is inconvenient for a comp ositional semantics We may then use an

abstract syntax that corresp onds to a rearrangement of the original structure provided that we

are prepared to sp ecify the map from parse trees to abstract syntax trees But when this map

is complicated the comprehensibility of the language description suers considerably

Some programming environments provide templates for constructing and editing abstract

syntax trees and for viewing them graphically thereby allowing the use of concrete syntax to

b e avoided Although this do es not justify ignoring concrete syntax altogether when giving

a comprehensive description of a programming language it do es underline the imp ortance of

abstract syntax and further motivates that semantics should b e dened on the basis of abstract

rather than concrete syntax

ContextSensitive Syntax

Contextfree syntax deals with those asp ects of structure that can b e describ ed by contextfree

grammars such as those written in the p opular BNF formalism Asp ects which fall outside

contextfree syntax are called contextsensitive and include declaration of identiers b efore

use and welltypedness of expressions Characteristic for them is that they involve a kind

of matching b etween distant parts of programs that is inherently more complex than mere

parenthesismatching

The description of contextsensitive syntax can in principle b e accomplished by use of so

called attribute grammars Unfortunately these are not always as p erspicuous as contextfree

grammars Moreover contextsensitive abstract syntax makes a more complicated interface

b etween concrete syntax and semantics than contextfree abstract syntax do es Of course

this is to b e exp ected b ecause the former generally captures more information than the lat

ter Attribute grammars cannot cop e straightforwardly with socalled dynamic scope rules for

declarations in programs

An alternative way of dening contextsensitive syntax is by giving inference rules for

wellformed phrases Wellformedness is usually dened as a binary relation b etween context

dep endent information and phrases and the wellformedness of a comp ound phrase may dep end

on the wellformedness of its subphrases with mo died contextdependent information As with attribute grammars this technique is not applicable when scop e rules are dynamic

CHAPTER CONCEPTS

Here let us keep abstract syntax contextfree and describ e contextsensitive asp ects sepa

rately This amounts to treating contextsensitive syntax as a kind of semantics called static

semantics b ecause it dep ends only on the program structure and do es not involve program

input The inputdep endent b ehaviour of a program is referred to as its dynamic semanticsor

simply as its semantics when this do esnt lead to confusion Note that static semantics is just

as essential an ingredient in a comprehensive language description as dynamic semantics and

that there are signicant problems with program p ortability due to inconsistent implementation

of static semantics by compiler frontends In this tutorial however we are primarily concerned

with dynamic semantics

Semantics

Consider an entire program in some programming language What is the nature of its semantics

Let us restrict our attention to programs in highlevel programming languages which gen

erally deny the program direct control over the details of physical b ehaviour The appropriate

semantics of these programs is implementationindependent consisting of just those features of

program execution that are common to all implementations This usually includes termination

prop erties but ignores eciency considerations

Thus the semantics of a program is an abstract entity that mo dels the programs implementation

indep endent b ehaviour The semantics of a programming language consists of the semantics of

all its programs

Semantic Functions

The semantics of a programming language can b e captured by a semantic function that maps the

abstract syntax of each program to the semantic entity representing its b ehaviour How ab out

the semantics of parts of programs ie of phrases such as statements declarations expressions

etc

Well one could say that the semantics of a phrase is already implicit in the semantics

of all the programs in which it o ccurs Thus two phrases have the same semantics if they

are interchangeable in any program context ie when replacing the one phrase by the other

never aects the b ehaviour of the whole program For example two pro cedures that implement

dierent algorithms for sorting have the same semantics provided that program b ehaviour do es

not take account of eciency Any comp ositional semantics for phrases that has this prop erty

is called ful ly abstract

For reasoning ab out phrasestheir semantic equivalence for instanceit is undesirable to

have to consider all p ossible programs containing them so we insist on explicit denition of

semantics for all phrases When the semantics of a comp ound phrase dep ends only on the

semantics of its subphrases not on other features such as their structure the semantics is

called compositional This guarantees that whenever two phrases have the same semantics they

are indeed interchangeable But when they have dierent semantics they may or may not b e

interchangeable a comp ositional semantics is not necessarily fully abstract

Action semantics following denotational semantics insists on comp ositionality with the

semantic function mapping not only entire programs but also all their comp onent phrases to

semantic entities The semantics of a phrase thus entirely represents the contribution of the phrase to program semantics

SEMANTICS

The semantic entities providing the semantics of parts of programs are usually more complex

than those representing the b ehaviour of entire programs For example the semantics of a

statement not only has to represent its direct contribution to observable program semantics

such as the relation b etween input and output but also its indirect contribution by means of

assignments to variables etc

Unfortunately full abstractness is often dicult to obtain at least when semantics is dened

explicitly In fact it has b een shown impossible to give fully abstract denotational semantics for

some rather simple programming languages Plo Sto In any case a lessthanfully abstract

semantics can b e much simpler to sp ecify and the semantic equivalence that it provides b etween

phrases may b e adequate for most purp oses For instance a semantics that is not fully abstract

sets exactly the same standard for implementations as one that is fully abstract provided the

semantics of entire programs is the same since requirements on implementations do not directly

involve the semantics of phrases such as statements and expressions So let us not demand full

abstractness at all

Semantic Entities

Semantic entities are used to represent the implementationindependent b ehaviour of programs

as well as the contributions that parts of programs make to overall b ehaviour There are three

kinds of semantic entity used in action semantics actions data and yielders The main kind

is of course actions data and yielders are subsidiary The notation used in action semantics for

sp ecifying actions and the subsidiary semantic entities is called unsurprisingly action notation

Actions are essentially dynamic computational entities The performance of an action

directly represents information pro cessing b ehaviour and reects the gradual stepwise nature

of computation Items of data are in contrast essentially static mathematical entities repre

senting pieces of information eg particular numbers Of course actions are mathematical to o

in the sense that they are abstract formallydened entities analogous to abstract machines

as dened in automata theory A yielder represents an unevaluated item of data whose value

dep ends on the current information ie the previouslycomputed and input values that are

available to the p erformance of the action in which the yielder o ccurs For example a yielder

might always evaluate to the datum currently stored in a particular cell which could change

during the p erformance of an action

Actions

A p erformance of an action which may b e part of an enclosing action either

completes corresp onding to normal termination the p erformance of the enclosing action

pro ceeds normally or

escapes corresp onding to exceptional termination parts of the enclosing action are skipp ed

until the escap e is trapp ed or

fails corresp onding to abandoning the p erformance of an action the enclosing action

p erforms an alternative action if there is one otherwise it fails to o or

diverges corresp onding to nontermination the enclosing action also diverges

CHAPTER CONCEPTS

Actions can b e used to represent the semantics of programs action p erformances corresp ond

to p ossible program b ehaviours Furthermore actions can represent the p erhaps indirect

contribution that parts of programs such as statements and expressions make to the semantics

of entire programs

An action may b e nondeterministic having dierent p ossible p erformances for the same ini

tial information Nondeterminism represents implementationdependence where the b ehaviour

of a program or the contribution of a part of it may vary b etween dierent implementationsor

even b etween dierent instants of time on the same implementation Note that nondeterminism

do es not imply actual randomness each implementation of a nondeterministic b ehaviour may

b e absolutely deterministic

The information pro cessed by action p erformance may b e classied according to how far it

tends to b e propagated as follows

transient tuples of data corresp onding to intermediate results

scoped bindings of tokens to data corresp onding to symbol tables

stable data stored in cells corresp onding to the values assigned to variables

permanent data communicated b etween distributed actions

Transient information is made available to an action for immediate use Scop ed information

in contrast may generally b e referred to throughout an entire action although it may also b e

hidden temp orarily Stable information can b e changed but not hidden in the action and

it p ersists until explicitly destroyed Permanent information cannot even b e changed merely

augmented

When an action is p erformed transient information is given only on completion or escap e

and scop ed information is pro duced only on completion In contrast changes to stable infor

mation and extensions to p ermanent information are made during action p erformance and are

unaected by subsequent divergence failure or escap e

The dierent kinds of information give rise to socalled facets of actions fo cusing on the

pro cessing of at most one kind of information at a time

the basic facet pro cessing indep endently of information control ows

the functional facet pro cessing transient information actions are given and give data

the declarative facet pro cessing scop ed information actions receive and produce bindings

the imperative facet pro cessing stable information actions reserve and unreserve cells of

storage and change the data stored in cells and

the communicative facet pro cessing p ermanent information actions send messages receive

messages in buers and oer contracts to agents

These facets of actions are indep endent For instance changing the data stored in a cellor even

unreserving the celldo es not aect any bindings There are however some directive actions

which pro cess a mixture of scop ed and stable information so as to provide nite representations

of selfreferential bindings There are also some hybrid primitive actions and combinators which

involve more than one kind of information at once such as an action that b oth reserves a cell of storage and gives it as transient data

PRAGMATICS

The standard notation for sp ecifying actions consists of action primitives which may involve

yielders and action combinators which op erate on one or two subactions

Data

The information pro cessed by actions consists of items of data organized in structures that give

access to the individual items Data can include various familiar mathematical entities such as

truthvalues numbers characters strings lists sets and maps It can also include entities such

as tokens cells and agents used for accessing other items and some comp ound entities with

data comp onents such as messages and contracts Actions themselves are not data but they

can b e incorp orated in socalled abstractions which are data and subsequently enacted back

into actions Abstraction and enaction are a sp ecial case of socalled reication and reection

New kinds of data can b e introduced ad hoc for representing sp ecial pieces of information

Yielders

Yielders are entities that can b e evaluated to yield data during action p erformance The data

yielded may dep end on the current information ie the given transients the received bindings

and the current state of the storage and buer In fact action notation provides primitive

yielders that evaluate to comp ound data tuples maps lists representing entire slices of the

current information such as the current state of storage Evaluation cannot aect the current

information

Comp ound yielders can b e formed by the application of data op erations to yielders The

data yielded by evaluating a comp ound yielder are the result of applying the op eration to the

data yielded by evaluating the op erands For instance one can form the sum of two number

yielders Items of data are a sp ecial case of data yielders and always yields themselves when

evaluated

Pragmatics

Let us conclude this chapter by considering the use of comprehensive language descriptions for

setting standards for implementations

The syntax of a programming language denes the set of legal programs and the seman

tics of each program gives a representation of its implementationindependent b ehaviour A

standard for a programming language relates its syntax and semantics to prop erties of physical

implementations dening the class of conforming implementations Thus it is concerned with

the pragmatics of the language

With syntax a standard may for instance require implementations to reject with an infor

mative error message illegal programs and p erhaps allow them also to reject legal programs

whose pro cessing exceeds the available resources It may allow national or typographical varia

tions in the characters used to write programs

It is imp ortant to realize in connection with semantics that the actual b ehaviour of a par

ticular program may b e allowed to vary b etween implementationseven b etween dierent runs

on the same implementation This variation may b e represented in the semantics by lo osely

sp ecied entities ie parameters or by a nondeterministic relation b etween input and output

A standard may require certain parameters to b e implementationdened the remaining ones

CHAPTER CONCEPTS

are left undened and an implementation is free to choose In Ada for instance the value of

INT is implementationdened whereas the order of expression evaluation is generally left MAX

undened

Finally note that although it may b e feasible for a standard to dene a class of implemen

tations on the basis of syntactic and semantic descriptions one may still not b e able to verify

that a particular implementation b elongs to that class In practice it is feasible to verify only

those implementations that have b een developed systematically from language descriptions A

validation suite for a language is a particular set of programs that an implementation must

pro cess correctly so as to b e regarded as valid The use of validation suites to test conformance to standards is a rather weak approximation to verication

Chapter

An Illustrative Example

Now that we have considered the main concepts underlying action semantics let us take a

walk through an illustrative description explaining all the notation that it uses as we go along

Summaries of the standard action notation and data notation used in the description are given

in the App endices

The language used here to illustrate action semantic descriptions is a mediumscale ideal

programming language Syntactically it is a sublanguage of Ada However the sp ecied action

semantics for the constructs do es not always corresp ond exactly to the semantics describ ed in

the Ada Reference Manual For instance parameter passing mo des are left implementation

dep endent in Ada but not here

The language is a cutdown version of that describ ed in Mos App endix A The main

constructs omitted here for simplicity are comp ound values variables and types p ointers

accesses in Ada terminology packages named actual parameters separate subprogram b o dy

denitions entry selection statements and function denitions

The mo dular structure of our illustrative action semantic description is formally sp ecied as

follows

Abstract Syntax

Expressions

Statements needs Expressions Declarations

Declarations needs Expressions Statements

Programs needs Expressions Declarations

Semantic Functions needs Abstract Syntax Semantic Entities

Expressions

Statements needs Expressions Declarations

Declarations needs Expressions Statements

Programs needs Expressions Declarations

Semantic Entities

An action semantic description consists of three main parts concerned with sp ecifying abstract

syntax semantic functions and semantic entities We sp ecify these parts as separate modules

CHAPTER AN ILLUSTRATIVE EXAMPLE

which may themselves b e divided into submodules just as we normally divide technical rep orts

and textb o oks into sections and subsections

Let us adopt the following discipline in our mo dular sp ecications each mo dule has to have

a title and it has to b e selfcontained in the sense that all the notation used in a mo dule must

b e sp ecied there to o Of course when some mo dule M uses notation that is already sp ecied

0 0

in another mo dule M there is no p oint in rep eating all of M literally in M it is sucient to

0

refer to M from M using its title Similarly when the submo dules M of a mo dule M use some

i

common notation we may as well sp ecify that notation just once at the level of M letting it b e

inherited by each M A reference to a mo dule M thus provides not only the notation sp ecied

i

directly in M and its submo dules but also that which is sp ecied in mo dules referenced by M

and in sup ermo dules enclosing M

We write titles of mo dules using initially capitalized words in This Bold Font The sp ec

ication ab ove has three mo dules with the obvious titles We could give a title to the whole

sp ecication if we wished here let us simply inherit the title of the present chapter The

abstract syntax mo dule and the semantic entities mo dule are selfcontained and could b e used

indep endently On the other hand the semantic functions mo dule needs the notation intro

duced by b oth the other mo dules so its use implies their use to o Our notation for indicating

mo dular structure is intended to b e unobtrusive and most of the time we shall disregard the

mo dularization and fo cus on what is sp ecied in the b o dies of the mo dules

We allow mo dules to b e mutual ly dep endent and the order in which we present mo dules is

immaterial In abstract syntax for instance the sp ecication of pro cedure declarations involves

statements and that of blo ck statements involves declarations so the corresp onding mo dules

have to b e mutually dep endent similarly for the corresp onding parts of the semantic equa

tions Most previous frameworks for mo dules insist on a strict hierarchy thus forbidding mutual

dep endence

A related p oint is that we are free to present mo dules in whatever order is most convenient

for the reader In semantic descriptions it is preferable to present the sp ecication of abstract

syntax rst followed by the semantic functions leaving the semantic entities to the end This is

assuming that the notation for semantic entities is well chosen and its intended interpretation

strongly suggested by the symbols used When semantic entities are presented b efore the seman

tic functions it can b e dicult to appreciate them indep endently of their usage However there

is no need for us to b e dogmatic ab out such matters b ecause the order in which mo dules are

written has no eect at all on what they sp ecify

Finally we use various devices to indicate that mo dules are submo dules of other mo dules For

small sp ecications such as that of the overall mo dular structure ab ove indentation formally

equivalent to putting grouping parentheses around the indented part is adequate for showing

nesting structure For larger sp ecications we use numbered titles m m M as in ordinary

1 n

technical do cuments

Abstract Syntax

Now let us consider how to sp ecify abstract syntax Reference manuals for programming lan

guages generally use formal contextfree grammars augmented by some form of regular expres

sions to sp ecify concrete syntax A formal grammar consists of a set of productions involving

terminal symbols which may b e characters or strings as well as auxiliary nonterminal symbols

ABSTRACT SYNTAX

Formal grammars have excellent pragmatic prop erties such as readability and mo diability let

us adapt them for sp ecifying abstract syntax

The grammarlike sp ecication given b elow consists mainly of a set of numbered equations

Ignoring the double brackets equations have the same form as productions in a particular

variant of BNF grammarone that is commonly used for sp ecifying concrete syntax in reference

manuals such as the ISO standard for Pascal diering a little from the variant used in the

Ada reference manual Terminal symbols are written as quoted strings of characters such

as and or The use of ordinary lexical symbols as terminal symbols in the grammar

sp ecifying abstract syntax makes it rather easy to imagine a corresp onding concrete syntax up

to disambiguation of grouping at least

Nonterminal symbols are written as unquoted words such as Expression and we adopt the

convention that they generally start with a capital letter to avoid confusing them with symbols

for semantic functions and entities which we write using lower case letters Such conventions

have no formal signicance and may b e varied as desired The alternatives for each nonterminal

and terminated by a p erio d symbol are started by separated by

grammar

closed

There is a precise formal interpretation of a grammar as an algebraic specication of sorts of

trees interested readers may consult Mos Here it is enough to know that o ccurrences of

indicate the construction of no des of trees In denotational semantics such brackets merely

separate abstract syntax from semantic notation and cannot b e nested We make a distinction

b etween a character such as and the string consisting of just that character following

most programming languages Actually strings are simply no des whose branches are all single

characters We write grammar to ensure this interpretation of the subsequent equations We

also write closed in a grammar mo dule when all the pro ductions are b eing given in full

Expressions

*

(1) Identier letter letter digit

+ + +

(2) Literal digit digit digit

The standard nonterminals digit and letter are always implicitly available in our grammars for

convenience when sp ecifying the lexical syntax of identiers and numerals The terminal symbols

that they generate are single characters rather than strings of characters

The equations ab ove involve socalled regular expressions In our notation a regular expres

sion is either a single symbol or it consists of a sequence hR R i a group ed set of alternatives

1 n

? *

R R an optional part R an optional repeatable part R or an obligatory repeatable

1 n

+

part R We do not use the rather inelegant notation for optional and rep etitive parts provided

by socalled Extended BNF EBNF despite its familiarity from reference manuals b ecause

we have a b etter use for the brackets it uses for optional parts R and its fR g is hardly sugges

tive of ordered rep etition Moreover EBNF requires R fR g to express that R is an obligatory

+

rep eatable part whereas our R avoids writing R twice

Identier Expression (3) Expression Literal

UnaryOperator Expression

Expression BinaryOperator Expression

Expression ControlOp erator Expression

CHAPTER AN ILLUSTRATIVE EXAMPLE

Note that literals and identiers are special cases of expressions rather than merely o ccurring

as comp onents of expressions

We make no attempt to distinguish syntactically b etween expressions according to the sort of

entity to which they evaluate truthvalues or numbers Such distinctions b etween expressions

would not simplify the semantic description at all and they would in any case b e context

dep endent

*

(4) Expressions h Expression h Expression i i

As we do not consider function calls or array comp onent selections expression lists are only

used in pro cedure calls and could b e just as well sp ecied in the mo dule for statements

abs not (5) UnaryOperator

(6) BinaryOperator mo d rem

and or xor

h or else i (7) ControlOp erator h and then i

The distinction b etween control op erators and binary op erators is semantically relevant since

the intended order of evaluation of their op erands is dierent

Statements

(1) Statement null Identier Expression

+ + ?

if Expression then Statement h else Statement i end if

? +

h while Expression i lo op Statement end lo op

exit

+ ? +

h declare Declaration i b egin Statement end

?

Identier h Expressions i

return

Identier Identier

+ ?

accept Identier h do Statement end i

One could save some eort by regarding an ifthen statement as a formal abbreviation for an

ifthenelse statement with a null else part similarly a lo op statement could abbreviate a while

statement with an alwaystrue expression part

* +

(2) Blo ck h Declaration b egin Statement end i

A blo ck is essentially a statement with some lo cal declarations Following Ada blo cks can o ccur

directly in ordinary statement sequences whereas in Pascal for example they can only o ccur

in subprogram declarations

Declarations

?

(1) Declaration Identier constant Identier Expression

?

Identier Identier h Expression i

?

procedure Identier h Formals i is Blo ck

+

task Identier is Entry end

task b o dy Identier is Blo ck

SEMANTIC FUNCTIONS

(2) Entry entry Identier

Task heads are supp osed to b e declared b efore the corresp onding b o dies although we dont

b other to insist on this in our grammar ab ove We retain the entries of a task head only for the

sake of familiarity as they are irrelevant to our dynamic semantics

?

(3) Formal Identier Mo de Identier

*

(4) Formals h Formal h Formal i i

h in out i out (5) Mo de in

Following Ada parameterless pro cedures omit the parentheses as well as the formals and a

missing formal parameter mo de is equivalent to the mo de in

Programs

+

(1) Program Declaration Identier

In legal Ada programs the toplevel declarations are compilation units which are essentially just

packages subprograms and tasks Here we do not b other to exclude other sorts of declaration

such as constant and variable declarations Let us assume that the identier of a program

indicates a main pro cedure without parameters to b e called when the program is run

That concludes the illustration of how to sp ecify abstract syntax for use in action semantic

descriptions

Semantic Functions

In action semantics we sp ecify semantic functions by semantic equations Each equation denes

the semantics of a particular sort of phrase in terms of the semantics of its comp onents if any

using constants and op erations for constructing semantic entities The required comp ositionality

of semantic functions is generally apparent from the semantic equations

Mathematically a set of semantic equations is simply an inductive denition of maps from

syntax to semantics Those familiar with algebraic semantics may understand the equations as

a presentation of a target algebra then the unique homomorphism to the target algebra from

the initial algebra of abstract syntax corresp onds to the semantic functions Programmers may

prefer to regard semantic equations as a denition of mutuallyrecursive functions by cases as

allowed for instance in the functional programming language Haskell

It is also p ossible to view a set of semantic equations as merely sp ecifying a translation

from programming language syntax to notation for semantic entities But it is the semantic

entities themselves that count not the notation in which they are expressed two phrases may

get translated dierently yet still have the same semantics

A semantic function always takes a single syntactic argument and gives a semantic entity

as result The symbols used to denote semantic functions may b e chosen freely generally the

author tries to maximize their suggestiveness at the exp ense of conciseness but this is not

and the placeholder obligatory Each symbol may consist of several words eg the value of

indicates where the argument go es

It is usual to sp ecify the functionality of each semantic function For instance

evaluate Expression action giving a value

CHAPTER AN ILLUSTRATIVE EXAMPLE

asserts that for every abstract syntax tree E for an expression the semantic entity evaluate E

is an action which when p erformed gives a value The actual denition of evaluate E by the

semantic equations is then required to b e consistent with this

Each semantic function must b e dened consistently and completely on the sort of abstract

syntax tree for which it is required Thus any tree of that sort must match the pattern in the

left hand side of precisely one semantic equation for that function When the right hand sides of

equations involve applications of semantic functions only to branches of the tree matching the

left hand side welldenedness is ensured otherwise one has to check that no direct circularities

are involved

The right hand sides of the semantic equations involve the standard notation for actions and

data provided by action semantics It must b e emphasized that the notation is absolutely formal

The fact that it is p ossible to read it informallyand reasonably uentlydoes not preclude

reading it formally as well The grouping of the symbols might not b e completely obvious to

those who have not seen action notation b efore but it is in fact unambiguous The following

hints ab out the general form of action notation may b e helpful

Action notation consists mainly of action primitives and combinators Each primitive is

concerned with one particular kind of information pro cessing and makes no contribution to the

other kinds Each combinator on the other hand expresses a particular mixture of control ow

and how the various kinds of information ow Action notation was designed with sucient

primitives and combinators for expressing most common patterns of information pro cessing

straightforwardly ie not simulating one kind of information pro cessing by another

Action notation also incorp orates a basic notation for data including truthvalues rational

numbers lists and nite maps

The standard symbols used in action notation are ordinary English words In fact action

notation mimics natural language terms standing for actions form imp erative verb phrases

involving conjunctions and adverbs eg check it and then escap e whereas terms standing for

data and yielders form noun phrases eg the items of the given list Denite and indenite

articles can b e exploited appropriately eg cho ose a cell then reserve the given cell This

feature of action notation is reminiscent of Apples HyperCard scripting language HyperTalk

Go o and of Cobol

These simple principles for choice of symbols provide a surprisingly grammatical fragment

of English allowing sp ecications of actions to b e made uently readablewithout sacricing

formality at all To sp ecify grouping unambiguously we may use parentheses but for large

scale grouping it is less obtrusive to use indentation which we emphasize by vertical rules as

illustrated in the semantic equations for statements given earlier

Compared to other formalisms such as the socalled notation action notation may app ear

to lack conciseness each symbol generally consists of several letters rather than a single sign

But the comparison should also take into account that each action combinator usually corre

sp onds to a complex pattern of applications and abstractions in notation For instance under

the simplifying assumption of determinism the action term A then A might corresp ond to

1 2

something like A A In any case the increased length of each symbol

1 1 1 2 2 2

seems to b e far outweighed by its increased p erspicuity It would also b e rather misleading

to use familiar mathematical signs to express actions whose essence is unashamedly computa

tional For some applications however such as formal reasoning ab out program equivalence on

the basis of their action semantics optimal conciseness may b e highly desirable and it would

SEMANTIC FUNCTIONS

b e appropriate to use abbreviations for our verbose symbols The choice of abbreviations is

left to the discretion of the user Such changes of symbols do not aect the essence of action

notation which lies in the standard primitives and combinators rather than in the standard

verbose symbols

The informal app earance and suggestive words of action notation should encourage pro

grammers to read it at rst rather casually in the same way that they might read reference

manuals Having thus gained a broad impression of the intended actions they may go on to

read the sp ecication more carefully paying attention to the details A more cryptic notation

might discourage programmers from reading it altogether

The intended interpretation of the standard notation for actions is sp ecied op erationally

once and for all in Mos App endix C All that one has to do b efore using action notation is to

sp ecify the information that is to b e pro cessed by actions which may vary signicantly according

to the programming language b eing describ ed This may involve extending data notation with

further sorts of data and specializing standard sorts using sort equations Furthermore it

may b e convenient to introduce formal abbreviations for commonlyo ccurring conceptually

signicant patterns of notation Extensions sp ecializations and abbreviations are all sp ecied

algebraically as illustrated in Section A

Now let us b egin to dene the semantic functions for our illustrative language We declare

the symbols used for the semantic functions at the start of each main mo dule

Expressions

the value of evaluate introduces the token of

the unaryoperationresult of the binaryoperationresult of

mo derate

Identiers

the token of Identier token

Tokens have a standard usage in action notation they get b ound to data The sort token is

sp ecied in Section A to b e a subsort of strings

(1) the token of I Identier upp ercase I

Following Ada let us canonicalize identiers by converting all letters to one case For languages

would simply b e where case dierences are taken seriously the semantic function the token of

the identity function on identiers and then we could omit it altogether

Literals

the value of Literal numb er

The sort numb er is sp ecied in Section A to b e a sort including b oth integer and approximate

real numbers

+

(1) the value of d digit integernumb er of decimal d

CHAPTER AN ILLUSTRATIVE EXAMPLE

+ +

(2) the value of d digit d digit

1 2

realnumb er of the sum of decimal d

1

the product of decimal d

2

the exp onent of decimal the negation of the count of d

2

The op eration decimal is a standard data op eration on strings similarly count is the standard

data op eration that returns the number of comp onents in any sort of tuple We could dene these

op erations as semantic functions but it wouldnt b e very exciting so we take this shortcut

Formally we are regarding a digit sequence as its own semantics ie a string No abstractness

is lost though b ecause leading zeros in digit sequences are signicant in the fractional parts of

real numbers

The use of in the right hand sides of the semantic equations ab ove is atypical It is

needed b ecause decimal exp ects its argument to b e a string not a tuple of characters

Evaluating Expressions

Expression action evaluate

giving a value

using current bindings current storage

Let us b e content here with an informal reading of such indications of the sorts of actions as

a thorough explanation involves considering op erations that can b e applied to entire sorts But

note that failure is always an implicit p ossibility

(1) evaluate LLiteral give the value of L

The primitive action give Y completes giving the data yielded by evaluating the yielder Y

(2) evaluate I Identier

give the entity b ound to the token of I then

give the given value or

give the value assigned to the given variable

The functional action combination A then A represents ordinary functional comp osition of A

1 2 1

and A the transients given to the whole action are propagated only to A the transients given

2 1

by A on completion are given only to A and only the transients given by A are given by the

1 2 2

whole action Regarding control ow A then A sp ecies normal lefttoright sequencing

1 2

The primitive action give Y fails when Y yields nothing The yielder the entity b ound to T

refers to the current binding for the particular token T provided that there is one otherwise it

yields nothing causing the giving action to fail

The yielder given Y yields all the data given to its evaluation provided that this is of the

data sort Y For instance the given value where the is optional yields a single individual

of sort value if such is given Otherwise it yields nothing and give the given value fails This

causes the alternative currently b eing p erformed to b e abandoned and if p ossible some other

alternative to b e p erformed instead ie backtracking

The action A or A represents implementationdependent choice b etween alternative actions

1 2

although here A A are such that one or the other of them is always b ound to fail so the

1 2

choice is deterministic The yielder the value assigned to Y refers to the current storage for the

particular variable yielded by Y analogously to the entity b ound to T If I is currently b ound to

an entity that is neither a value nor a variable eg a pro cedure b oth alternatives fail causing

their combination to fail as well

(3) evaluate E Expression evaluate E

SEMANTIC FUNCTIONS

(4) evaluate O UnaryOperator E Expression

evaluate E then give the unaryoperationresult of O

(5) evaluate E Expression O BinaryOperator E Expression

1 2

evaluate E and evaluate E

1 2

then give the binaryoperationresult of O

The action A and A represents implementationdependent order of p erformance of the indi

1 2

visible subactions of A A When these subactions cannot interfere with each other as here

1 2

it indicates that their order of p erformance is simply irrelevant Lefttoright order of evalua

tion can b e sp ecied by using the combinator A and then A instead of A and A ab ove In

1 2 1 2

b oth cases the values given by the subactions get tupled and subsequently passed on by the

combinator A then A

1 2

The evaluation of an expression may give any individual of sort value We leave it to the

semantics of op erators sp ecied b elow to insist on individuals of particular sortsnumbers

for instance For simplicity we do not b other with precise error messages in case the given

op erands are not of the right sort for a particular op erator we merely let the application of the

corresp onding op eration yield nothing so that the action which gives it must fail In any case

errors arising due to wrong sorts of op erands are statically detectable in most languages and

should therefore b e the concern of a static semantic description not of the dynamic semantics

that we are developing here

(6) evaluate E Expression or else E Expression

1 2

evaluate E then

1

check the given truthvalue then give true

or

check not the given truthvalue then evaluate E

2

(7) evaluate E Expression and then E Expression

1 2

evaluate E then

1

check the given truthvalue then evaluate E

2

or

check not the given truthvalue then give false

The action check Y requires Y to yield a truthvalue it completes when the value is true

otherwise it fails It is used for guarding alternatives For instance check Y then A or check

1

not Y then A expresses a deterministic choice b etween A and A dep ending on the condition

2 1 2

Y

Op erating Unary Op erators

UnaryOperator yielder the unaryoperationresult of

of value using given value

Assuming that applications of op erators to op erands should never diverge or escap e we may

represent the semantics of an op erator as a yielder Otherwise we could use actions here to o

But note that we cannot let the semantics of an op erator b e simply an algebraic op eration since

our metanotation is rstorder

(1) the unaryoperationresult of the given numb er

(2) the unaryoperationresult of the negation of the given numb er

(3) the unaryoperationresult of abs the absolute of the given numb er

CHAPTER AN ILLUSTRATIVE EXAMPLE

(4) the unaryoperationresult of not not the given truthvalue

Numerical op erations such as negation and absolute are sp ecied lo osely in Section A The

truthvalues are the standard ones from data notation equipp ed with the usual logical op era

tions such as not

Op erating Binary Op erators

the binaryoperationresult of BinaryOperator yielder

of value using given valuevalue

(1) the binaryoperationresult of

the sum of the given numb er the given numb er

The yielder given Y n yields the n th individual comp onent of a given tuple for n provided

that this comp onent is of sort Y

(2) the binaryoperationresult of

the dierence of the given numb er the given numb er

(3) the binaryoperationresult of

the concatenation of the given array the given array

(4) the binaryoperationresult of

the product of the given numb er the given numb er

(5) the binaryoperationresult of

the quotient of the given numb er the given numb er

(6) the binaryoperationresult of mo d

the mo dulo of the given numb er the given numb er

(7) the binaryoperationresult of rem

the remainder of the given numb er the given numb er

(8) the binaryoperationresult of

the given value is the given value

(9) the binaryoperationresult of

not the given value is the given value

(10) the binaryoperationresult of

the given numb er is less than the given numb er

(11) the binaryoperationresult of

not the given numb er is greater than the given numb er

(12) the binaryoperationresult of

the given numb er is greater than the given numb er

(13) the binaryoperationresult of

not the given numb er is less than the given numb er

(14) the binaryoperationresult of and

b oth of the given truthvalue the given truthvalue

(15) the binaryoperationresult of or

either of the given truthvalue the given truthvalue

(16) the binaryoperationresult of xor

not the given truthvalue is the given truthvalue

SEMANTIC FUNCTIONS

Mo derating Expressions

Expressions action mo derate

+

storing giving argument

+

using given mo de current bindings current storage

The evaluation of actual parameter expressions in pro cedure calls is dep endent on the mo des

of the corresp onding formals in pro cedure declarations The semantic entities corresp onding to

syntactic mo des are sp ecied in Section A

(1) mo derate I Identier

+

give the rst of the given mo de then

check either it is the referencemo de it is the copymode then

give the variable b ound to the token of I

or

check it is the constantmo de then evaluate I

The tuple selector op eration rst is standard in data notation as is rest b elow The yielder it

formally abbreviates the given datum here we could also write the given mo de

(2) E Identier nothing

mo derate E Expression

+

give the rst of the given mo de then

check it is the constantmo de then evaluate E

Here we collapse the uniform semantic equations for the remaining Expression constructs into a

single conditional equation whose condition holds when E is abstract syntax not of sort Identier

(3) mo derate h E Expression E Expressions i

1 2

mo derate E and

1

+

give the rest of the given mo de then mo derate E

2

Whereas the data ow in A then A is analogous to that in ordinary function comp osition

1 2

g f at least when the functions are strict the data ow in A and A is analogous to socalled

1 2

targettupling of functions sometimes written f g and dened by f g x f x g x That

is b oth A and A are given the same transient data as the combination Note that the tupling

1 2

of the data given by A and A is asso ciative

1 2

Statements

introduces execute

Executing Statements

+

Statement action execute

completing escaping with an escap ereason diverging storing communicating

current storage current buer using current bindings

+

(1) execute h S Statement S Statement i execute S and then execute S

1 2 1 2

The basic action combination A and then A combines the actions A A into a comp ound

1 2 1 2

action that represents their normal lefttoright sequencing p erforming A only when A com

2 1

pletes

Note that the semantics of a statement is welldened b ecause the ab ove semantic equation

can only match a statement sequence in one way

CHAPTER AN ILLUSTRATIVE EXAMPLE

(2) execute null complete

The primitive action complete is the unit for A and then A

1 2

(3) execute I Identier E Expression

give the variable b ound to the token of I and evaluate E

then assign the given value to the given variable

The action assign Y to Y is sp ecied in Section A

1 2

+

(4) execute if E Expression then S Statement end if

evaluate E then

check the given truthvalue and then execute S

or

check not the given truthvalue

Since check D do esnt give any data and execute S do esnt refer to given data it do esnt make

any dierence whether we use A and then A or A then A to combine them ab ove

1 2 1 2

It is imp ortant not to omit or check not the given truthvalue ab ove for then the execution

of an ifthen statement with a false condition would fail rather than simply completing

+ +

(5) execute if E Expression then S Statement else S Statement end if

1 2

evaluate E then

check the given truthvalue and then execute S

1

or

check not the given truthvalue and then execute S

2

+

(6) execute lo op S Statement end lo op

unfolding

execute S and then unfold

trap

check there is given an exit

or

check there is given a procedurereturn and then escap e with it

The action combination unfolding A p erforms A but whenever it reaches the dummy action

unfold it p erforms A instead It is mostly used in the semantics of iterative constructs with

unfold o ccurring exactly once in A but it can also b e used with several o ccurrences of unfold

The action A trap A sets A as the trap action to b e p erformed when A escap es Once

1 2 2 1

an escap e has b een trapp ed normal sequencing is resumed

The primitive action escap e with Y terminates abnormally giving the data yielded by Y to

the action that traps the escap e if any An exit is simply a data item as is a procedurereturn

The data op eration there is d results in true when d is a data item other than nothing

+

(7) execute while E Expression lo op S Statement end lo op

unfolding

evaluate E then

check the given truthvalue and then execute S and then unfold

or

check not the given truthvalue

trap

check there is given an exit

or

check there is given a procedurereturn and then escap e

SEMANTIC FUNCTIONS

(8) execute exit escap e with an exit

+

(9) execute b egin S Statement end execute S

+ +

(10) execute declare B h Declaration b egin Statement end i

execute B

A declare statement is a blo ck Some languages Pascal for instance dont allow such anony

mous blo cks to o ccur in the middle of a statement sequence only directly in other declarations

but the extra generality here do esnt complicate the semantic description noticeably

(11) execute I Identier

enact the procedureabstraction of

the parameterless procedure b ound to the token of I

The action enact Y p erforms the action incorp orated in the abstraction yielded by Y The

p erformance of the incorp orated action is not given any transient data nor do es it receive

any bindings However transients andor bindings may have already b een supplied to the

incorp orated action using the notation for yielders explained later

The notation for constructing pro cedure entities from abstractions is sp ecied in Section A

(12) execute I Identier E Expressions

give the procedure b ound to the token of I then

give the procedureabstraction of the given procedure and

give the formalmodes of the given parameterized procedure then

mo derate E

then enact the application of the given abstraction

+

to the argument yielded by the rest of the given data

Supp ose that Y yields abstraction of A and that Y yields data d Then the yielder application

1 2

Y to Y evaluates to abstraction of give d then A

1 2

(13) execute return escap e with a procedurereturn

(14) execute I Identier I Identier

1 2

give the taskagent b ound to the token of I then

1

send a message to the given taskagent containing entry of the token of I

2

and then

receive a message from the given taskagent containing the donesignal

The primitive action send Y where Y yields a sort of message initiates the transmission of

a message The usual form of Y is a message to Y containing Y where Y and Y are

1 2 1 2

individuals The sort yielded by Y is implicitly restricted to messages from the p erforming

agent with the next lo cal serial number and this should determine an individual message

The action receive Y waits indenitely for a message of the sort sp ecied by Y to arrive

removes it from the buer and gives it

The notation for entries and signals that are contained in the messages is sp ecied in Sec

tion A

(15) execute accept I Identier end

receive a message from any taskagent containing entry of the token of I then

send a message to the sender of the given message containing the donesignal

+

(16) execute accept I Identier do S Statement end

receive a message from any taskagent containing entry of the token of I then

execute S and then

send a message to the sender of the given message containing the donesignal

CHAPTER AN ILLUSTRATIVE EXAMPLE

Executing Blo cks

Blo ck action execute

diverging storing communicating escaping with an escap ereason

using current bindings current storage current buer

+

(1) execute h b egin S Statement end i execute S

+ +

(2) execute h D Declaration b egin S Statement end i

furthermore elab orate D hence

synchronize D and then execute S and then relinquish D

trap

relinquish D and then escap e with the given escap ereason

The action furthermore A pro duces the same bindings as A together with any received bindings

that A do esnt override In other words it overlays the received bindings with those pro duced

by A

The combination A hence A lets the bindings pro duced by A b e received by A which

1 2 1 2

limits their scop eunless they get repro duced by A It is analogous to functional comp osition

2

The comp ound combination furthermore A hence A recall that prexes have higher precedence

1 2

than inxes corresp onds to ordinary blo ck structure with A b eing the blo ck head and A

1 2

the blo ck b o dy nonlo cal bindings received by the combination are also received by A unless

2

they are overridden by the lo cal bindings pro duced by A

1

The use of synchronize D here is concerned with task initialization considered later

Whereas bindings pro duced by declarations automatically disapp ear at the end of their

scop e lo callydeclared variables are not thereby automatically relinquished it has to b e sp ecied

explicitly Notice that the trap is needed to ensure that exits and pro cedure returns do not evade

relinquish D

Declarations

relinquish synchronize introduces elab orate

the mo de of the mo des of actualize

Elab orating Declarations

*

Declaration action elab orate

binding diverging storing communicating

current storage current buer using current bindings

+

(1) elab orate h D Declaration D Declaration i elab orate D b efore elab orate D

1 2 1 2

The action A b efore A represents sequencing of declarations Like furthermore A hence A

1 2 1 2

it lets A receive bindings from A together with any bindings received by the whole action

2 1

that are not thereby overridden The combination pro duces all the bindings pro duced by A

2

as well as any pro duced by A that are not overridden by A Thus A may rebind a token

1 2 2

that was b ound or hidden by A Note that the bindings received by the combination are not

1

repro duced at all unless one of A A explicitly repro duces them

1 2

The use of the combinator A b efore A in the semantics of declaration sequences allows

1 2

later declarations to refer to the bindings pro duced by earlier declarationsbut not the other

way round Mutuallyrecursive declarations are not considered here

(2) elab orate h i complete

SEMANTIC FUNCTIONS

?

(3) elab orate I Identier constant I Identier E Expression

1 2

evaluate E then bind the token of I to the given value

1

The declarative action bind T to Y pro duces the binding of the token T to the bindable data

yielded by Y It do es not repro duce any of the received bindings

Somewhat contrary to the explanation of Ada constants in the Reference Manual we let

constants b e b ound directly to values rather than to sp ecial variables that cannot b e assigned

new values Thus our constants resemble named numbers in Ada

(4) elab orate I Identier I Identier

1 2

allo cate a variable for the type b ound to the token of I

2

then bind the token of I to the given variable

1

The action allo cate d for Y is ad hoc sp ecied in Section A As we only deal with simple

variables in this tutorial allo cate a variable for Y merely chooses reserves and gives a single

storage cell

(5) elab orate I Identier I Identier E Expression

1 2

allo cate a variable for the type b ound to the token of I

2

and evaluate E

then

bind the token of I to the given variable and

1

assign the given value to the given variable

The basic and functional combinators such as A and A all pass the received bindings to their

1 2

subactions without further adoanalogously to the way A and A passes all the given data to

1 2

b oth A and A They are similarly unbiased when it comes to combining the bindings pro duced

1 2

by their subactions they pro duce the disjoint union of the bindings providing this is dened

otherwise they simply fail

(6) elab orate procedure I Identier is B Blo ck

bind the token of I to

parameterless procedure of the closure of abstraction of

execute B

trap check there is given a procedurereturn

When current bindings evaluates to b closure Y yields abstraction of produce b hence A

1

The use of closure ab ove ensures static bindings the execution of the blo ck B when the

function is called receives the same bindings as the declaration These bindings however do

not include that for I itself so selfreferential or recursive calls of the function are not p ossible

In fact it is easy to allow selfreference just change bind to recursively bind in the semantics

equations for elab orate D But it is not quite so straightforward to allow mutual reference

Mos App endix A shows how this can b e done using indirect bindings directly

Notice that an enaction of an abstraction b ound to a pro cedure identier can only complete

when the execution of the blo ck escap es giving a return If the execution of the blo ck escap es

for any other reason or completes the enaction fails

(7) elab orate procedure I Identier F Formals is B Blo ck

bind the token of I to

parameterized mo dalized the mo des of F

procedure of the closure of abstraction of

furthermore actualize F thence

execute B

trap check there is given a procedurereturn

and then copyback the given map token to variable

CHAPTER AN ILLUSTRATIVE EXAMPLE

The p erformance of actualize F ab ove not only produces bindings for the formal parameters it

also gives a map corresp onding to the bindings for copymode parameters This map is exploited

to copy back the nal values of the lo cal formal parameter variables to the actual parameter

variables The action copyback Y is ad hoc sp ecied in Section A The combination A

1

thence A passes transients as wel l as bindings from A to A

2 1 2

The op eration mo dalized m p attaches the mo des m to a pro cedure p so that formal

mo des of p can obtain them when pro cedure call statements are executed This is sp ecied in

Section A

+

(8) elab orate task I Identier is E Entry end

oer a contract to any taskagent containing abstraction of the initial taskaction

and then

receive a message containing a taskagent then

bind the token of I to the task yielded by the contents of the given message

The primitive action oer Y where Y yields a sort of contract initiates the arrangement of a

contract with another p erhaps only partially sp ecied agent The usual form of Y is a contract

to an agent containing abstraction of A where A is the action to b e p erformed according to

the contract

The action initial taskaction is dened in Section A

(9) elab orate task b o dy I Identier is B Blo ck

send a message to the taskagent b ound to the token of I

containing task of the closure of abstraction of execute B

Executions of task blo cks receive all the bindings that were current where their b o dy was

declared These may include bindings to other tasks a system of communicating tasks can

b e set up by rst declaring all the heads then all the b o dies They may also include bindings to

variables but attempts to assign to these variables or to insp ect their values always fail b ecause

the cells referred to are not lo cal to the agent p erforming the action It is a bit complicated to

describ e the action semantics of distributed tasks that have access to shared variablesthe task

that declares a variable has to act as a server for assignments and insp ectionsso we let our

illustrative language deviate from Ada in this resp ect

Relinquishing Variable Declarations

+

relinquish Declaration action

storing completing

current storage using current bindings

Whereas bindings pro duced by declarations automatically disapp ear at the end of their scop e

lo callydeclared variables are not thereby automatically relinquished Here we introduce an extra

semantic function on declarations for this purp ose

+

(1) relinquish h D Declaration D Declaration i relinquish D and relinquish D

1 2 1 2

?

(2) relinquish I Identier I Identier X h Expression i

disp ose of the variable b ound to the token of I

SEMANTIC FUNCTIONS

?

(3) D Identier constant Identier Expression

+

task Identier is Entry end

?

function Identier h Formals i return Identier is Blo ck

?

procedure Identier h Formals i is Blo ck

task b o dy Identier is Blo ck

relinquish D complete

Synchronizing Task Declarations

+

Declaration action synchronize

completing diverging communicating

using current bindings current buer

The action synchronize D is used to delay the execution of the statements of a blo ck until all

the tasks declared in the blo ck have b een started

+

(1) synchronize h D Declaration D Declaration i

1 2

synchronize D and synchronize D

1 2

(2) synchronize task b o dy I Identier is B Blo ck

receive a message from the taskagent b ound to the token of I

containing the b eginsignal

?

(3) D Identier constant Identier Expression

?

Identier Identier h Expression i

+

task Identier is Entry end

?

function Identier h Formals i return Identier is Blo ck

?

procedure Identier h Formals i is Blo ck

synchronize D complete

Mo des

?

the mo de of Mo de mo de

(1) the mo de of h i the constantmo de

(2) the mo de of in the constantmo de

(3) the mo de of h in out i the copymode

(4) the mo de of out the referencemo de

Mo des of Formal Parameters

+

Formals mo de the mo des of

?

(1) the mo des of I Identier M Mo de I Identier the mo de of M

1 2

(2) the mo des of h F Formal F Formals i the mo des of F the mo des of F

1 2 1 2

CHAPTER AN ILLUSTRATIVE EXAMPLE

Actualizing Formal Parameters

Formals action actualize

giving a map token to variable storing binding

+

using given argument current bindings current storage

The map of tokens to variables given by actualization is used for copyingback the values of

copymode parameters on pro cedure return Maps together with op erations for creating and

combining them are provided by the standard data notation used in action semantics

?

(1) actualize I identier M in I Identier

1 2

+

bind the token of I to the value yielded by the rst of the given argument

1

and give the emptymap

(2) actualize I identier out I Identier

1 2

+

bind the token of I to the variable yielded by the rst of the given argument

1

and give the emptymap

(3) actualize I identier in out I Identier

1 2

+

give the variable yielded by the rst of the given argument

and allo cate a variable for the type b ound to the token of I

2

then

bind the token of I to the given variable and

1

give map of the token of I to the given variable and

1

assign the value assigned to the given variable to the given variable

(4) actualize h F Formal F Formals i

1 2

actualize F and

1

+

give the rest of the given argument then actualize F

2

then give the disjointunion of the given map the given map

Programs

introduces run

run Program action

diverging storing communicating completing

current buer using current storage

+

(1) run D Declaration I Identier

produce requiredbindings hence

furthermore elab orate D hence

synchronize D and then

give the procedure b ound to the token of I then

enact the procedureabstraction of the given parameterless procedure

and then send a message to the useragent containing the terminatedsignal

The primitive action produce Y pro duces a binding for each token mapp ed to a bindable value

by the map yielded by Y See the end of Section A for the denition of the bindings of

required identiers in our illustrative language The analogous denition for full Ada would b e

substantially larger

The termination message sent ab ove insists that the user should b e able to notice when the

program has terminated this might b e useful when the user runs the program on a remote agent

SEMANTIC FUNCTIONS

To complete our semantic description of the illustrative language we have to sp ecify the

notation that is used in the semantic equations for expressing semantic entities This is done in

Section A which also refers to the standard action notation and data notation used in action semantics summarized informally in App endix B and App endix C resp ectively

Chapter

Conclusion

Here the pragmatic qualities of action semantic descriptions will b e assessed and compared

with those of other frameworks such as VDM and RAISE

App endix A

An Illustrative Example ctd

The mo dular structure of this App endix is as follows

Semantic Entities

Sorts needs Values Variables Subprograms Tasks Escap es

Values needs Numbers

Variables needs Values Types

Types

Numbers

Subprograms

Mo des

Arguments needs Values Variables

Pro cedures needs Mo des Arguments

Tasks

Escap es

Required Bindings needs Types Numbers

A Semantic Entities

Most of the notation used here for sp ecifying semantic entities has a fairly obvious interpretation so few comments

are provided

includes Mos Action Notation

A Sorts

introduces entity

 entity value variable type procedure task disjoint

escap ereason mo de message entry 2  datum entity

*

 token string of upp ercase letter upp ercase letter digit

 bindable entity

 storable value

task entry signal 2  sendable agent

We use the same symbol for sort union as we used for combining alternatives in grammars Thinking of sorts

of data as sets which isnt quite right but close enough for now we may regard as ordinary set union it is

1

asso ciative commutative and idemp otent Although sort equations lo ok a bit like the socalled domain equations

used in denotational semantics their formal interpretation is quite dierent The use of 2 ab ove formally expresses

an inclusion as it leaves op en what other sorts might b e included in datum and sendable

1

Idemp otency of means X X X

APPENDIX A AN ILLUSTRATIVE EXAMPLE CTD

A Values

introduces value

is includes Mos Data NotationInstantDistinction value for s

 value truthvalue numb er disjoint

A Variables

introduces variable

to the assigned to allo cate for disp ose of assign

 assign to yielder of value yielder of variable ! action storing

 the assigned to value yielder of variable ! yielder of value

for variable yielder of type ! action giving a variable storing  allo cate

 disp ose of yielder of variable ! action storing

(1) variable cell

(2) assign Y yielder of value to Y yielder of variable

1 2

store the storable yielded by Y in the cell yielded by Y

1 2

(3) the v value assigned to Y yielder of variable

the v storable stored in the cell yielded by Y

(4) allo cate v variable for Y yielder of type

allo cate a cell

(5) disp ose of Y yielder of variable

unreserve the cell yielded by Y

For simplicity here we do not b other to distinguish b etween cells for storing dierent sorts of values so the type

entities are quite redundant In a more realistic example the sp ecication of variable allo cation and assignment

can b ecome quite complex

The standard action store Y in Y changes the data stored in the cell yielded by Y to the storable data

1 2 2

yielded by Y The cell concerned must have b een previously reserved using reserve Y otherwise the storing

1

action fails Here Y has to yield a particular individual cell

allo cate a cell abbreviates the following hybrid action

indivisibly

cho ose a cell not in the mapp edset of the current storage then

reserve the given cell and give it

Reserved cells are made available for reuse by unreserve Y where Y yields an individual cell

A Types

introduces type b o oleantype

integertype realtype

 type b o oleantype integertype realtype individual

A Numbers

introduces numb er integernumb er realnumb er mininteger maxinteger

realnumb er of negation absolute integernumb er of

sum dierence product quotient mo dulo remainder

 numb er integernumb er realnumb er

 mininteger maxinteger integer

integer ! integernumb er partial  integernumb er of

rational ! realnumb er partial  realnumb er of

absolute numb er ! numb er partial  negation

 sum dierence product quotient

2

numb er ! numb er partial

A SEMANTIC ENTITIES

2

remainder integernumb er ! integernumb er partial  mo dulo

 is is less than is greater than

integernumb er integernumb er ! truthvalue total

realnumb er realnumb er ! truthvalue total

(1) i integer min mininteger max maxinteger ) integernumb er of i integernumb er

(2) i integer min successor maxinteger ) integernumb er of i nothing

(3) i integer max predecessor mininteger ) integernumb er of i nothing

(4) realnumb er of r approximation realnumb er

(5) realnumb er of r interval approximation realnumb er of approximately r

(6) integernumb er of i integernumb er )

(1) negation integernumb er of i integernumb er of negation i

(2) absolute integernumb er of i integernumb er of absolute i

(7) integernumb er of i integernumb er integernumb er of i integernumb er )

1 2

(1) sum integernumb er of i integernumb er of i integernumb er of sum i i

1 2 1 2

(2) dierence integernumb er of i integernumb er of i integernumb er of dierence i i

1 2 1 2

(3) product integernumb er of i integernumb er of i integernumb er of product i i

1 2 1 2

(4) quotient integernumb er of i integernumb er of i

1 2

integernumb er of integerquotient i i

1 2

(5) mo dulo integernumb er of i integernumb er of i

1 2

integernumb er of integermo dulo i i

1 2

(6) remainder integernumb er of i integernumb er of i

1 2

integernumb er of integerremainder i i

1 2

(8) realnumb er of r realnumb er )

(1) negation realnumb er of r realnumb er of negation r

(2) absolute realnumb er of r realnumb er of absolute r

(9) realnumb er of r realnumb er realnumb er of r realnumb er )

1 2

(1) sum realnumb er of r realnumb er of r realnumb er of sum r r

1 2 1 2

(2) dierence realnumb er of r realnumb er of r realnumb er of dierence r r

1 2 1 2

(3) product realnumb er of r realnumb er of r realnumb er of product r r

1 2 1 2

(4) quotient realnumb er of r realnumb er of r realnumb er of quotient r r

1 2 1 2

(10) integernumb er of i integernumb er integernumb er of i integernumb er )

1 2

(1) integernumb er of i is integernumb er of i i is i

1 2 1 2

(2) integernumb er of i is less than integernumb er of i i is less than i

1 2 1 2

(3) integernumb er of i is greater than integernumb er of i i is greater than i

1 2 1 2

(11) realnumb er of r realnumb er realnumb er of r realnumb er )

1 2

(1) realnumb er of r is realnumb er of r r is r

1 2 1 2

(2) realnumb er of r is less than realnumb er of r r is less than r

1 2 1 2

(3) realnumb er of r is greater than realnumb er of r r is greater than r

1 2 1 2

The sp ecication of real arithmetic uses a lo oselysp ecied sort of rational approximations and intervals to avoid

insisting that implementations should b e exact Similarly there are lo oselysp ecied b ounds on integers

A Subprograms

A Mo des

introduces mo de constantmo de referencemo de copymode

 mo de constantmo de copymode referencemo de individual

includes Data NotationInstantDistinction mo de for s is

(1) distinct constantmo de referencemo de copymode true

APPENDIX A AN ILLUSTRATIVE EXAMPLE CTD

A Arguments

introduces argument copyback

variable  argument value

map token to variable ! action completing storing  copyback

privately introduces copyback from

(1) copyback Y yielder of map token to variable

copyback Y from the elements of the mapp edset of Y

*

(2) copyback Y yielder of map token to variable from Y yielder of token

1 2

check Y is or

2

assign the value assigned to the variable b ound to the rst of Y

2

to the variable yielded by Y at the rst of Y and then

1 2

disp ose of the variable yielded by Y at the rst of Y and then

1 2

copyback Y from the rest of Y

1 2

A Pro cedures

introduces procedure procedure of procedureabstraction

parameterless parameterized mo dalized

formalmodes

 procedure of abstraction ! procedure partial

procedure ! abstraction total  procedureabstraction

 parameterless parameterized procedure ! procedure partial

mo des procedure ! procedure partial  mo dalized

 formalmodes procedure ! mo des partial

diverging storing communicating (1) a action completing

using given arguments current storage current buer )

procedure of abstraction of a procedure

(2) p procedure of a ) the procedureabstraction of p procedure a

(3) p procedure of a )

parameterless p procedure procedure parameterized p procedure procedure

(4) p parameterless procedure of a ) the procedureabstraction of p procedure a

(5) p parameterized procedure of a ) the procedureabstraction of p procedure a

(6) p parameterized mo dalized m mo des procedure of a )

(1) the procedureabstraction of p procedure a

(2) the formalmodes of p procedure m

A Tasks

introduces taskagent task task of taskabstraction initial taskaction

signal b eginsignal donesignal terminatedsignal

is entered in entry entry of

 taskagent  agent

 task of abstraction ! task total

 taskabstraction task ! abstraction total

donesignal terminatedsignal individual  signal b eginsignal

 initial taskaction action

token ! entry total  entry of

 is entered in entry buer ! truthvalue total

(1) t task of a ) taskabstraction t task a

A SEMANTIC ENTITIES

(2) initial taskaction

send a message to the contractingagent containing the p erformingagent and then

receive a message from the contractingagent containing a task

then

send a message to the contractingagent containing the b eginsignal and then

enact the taskabstraction of the task yielded by the contents of the given message

(3) entry of k token is entry of k token k is k

1 2 1 2

(4) e entry is entered in emptylist false

(5) e entry is entered in list of m message containing an entry e is the contents of m

agent task false (6) e entry is entered in list of m message containing a signal

(7) e entry is entered in concatenation b buer b buer

1 2

either e is entered in b e is entered in b

1 2

A Escap es

introduces escap ereason exit procedurereturn

 escap ereason exit procedurereturn individual

A Required Bindings

introduces requiredbindings

type  requiredbindings map token to value

(1) requiredbindings disjointunion of map of TRUE to true

map of FALSE to false

map of BOOLEAN to b o oleantype

map of MININT to integernumb er mininteger

map of MAXINT to integernumb er maxinteger

map of INTEGER to integertype map of REAL to realtype

App endix B

Action Notation

The systematic informal description of almost all of action notation summarizes the explana

tions given in Chapter and gives further details It is intended for reference The usage of the

notation is illustrated in the semantic description in Chapter

The symbols of action notation are explained in the order indicated b elow See Section

for the general concept of actions

Action Notation

Basic

Functional

Declarative

Imp erative

Reective

Communicative

Hybrid

Facets

Outcomes

Incomes

Actions

Yielders

B Basic Action Notation

Basic action notation is primarily concerned with sp ecifying ow of control in p erformances of actions It includes

basic notation for data as well see App endix C

B Actions

 Al l primitive basic actions

Give no transients except for escap e

Pro duce no bindings

Make no changes to storage

Do not communicate

 Al l basic action combinators are

Functionally conducting see the basic action A and A except for A trap A which is functionally

1 2 1 2

comp osing see the functional action A then A in Section B

1 2

B BASIC ACTION NOTATION

Declaratively conducting see the basic action A and A

1 2

 complete a primitive basic action Represents normal termination Unit for A and A as well as for A

1 2 1

and then A

2

Indivisible Always completes

 escap e a primitive basic action Represents abnormal termination Unit for A trap A

1 2

Indivisible Always escap es

Gives any given transients

 fail a primitive basic action Represents ab ortion of the current alternative Unit for

A or A

1 2

Indivisible Always fails

 commit a primitive basic action Represents commitment to the current alternative cutting away other

current alternatives

Indivisible Always commits and completes

 unfold a dummy action standing for the innermost enclosing unfolding

 unfolding A Represents the in general innite action formed by continually substituting A for unfold

To avoid singularities in pathological cases substitute complete and then A rather than just A

Performs A but whenever the dummy action unfold is reached A is p erformed in place of unfold

 indivisibly A a basic combination of action A Represents that the steps of p erforming A are not interleaved

with those of other actions p erformed by the same agent Also ensures that the p erformance of A cannot

b e interrupted by an escap e or failure o ccurring outside A For use only when A cannot diverge

Indivisible A is p erformed as a single step

 A or A a basic combination of actions A A Represents implementationdependent choice sp ecializes

1 2 1 2

to deterministic choice when one or the other of A A must fail

1 2

Performs either A or A When the p erformed alternative fails without committing it is ignored

1 2

and the other alternative is p erformed instead

All the transients given to the combination of A A are given to the p erformed alternative On

1 2

normal or abnormal termination all the transients given by the p erformed alternative are given by

the combined action

All the bindings received by the combination of A A are received by the p erformed alternative

1 2

On normal termination all the bindings pro duced by the p erformed alternative are pro duced by the

combined action

 A and A a basic combination of actions A A Represents implementationdependent order of p er

1 2 1 2

formance of indivisible subactions sp ecializing to indep endent p erformance when there is no interference

b etween A and A

1 2

Basically interleaving Performs b oth A A with arbitrary interleaving of their indivisible steps

1 2

An escap e or a failure causes any remaining parts of the subactions to b e skipp ed

Functionally conducting The transients given to the combination of A A is given to b oth A A

1 2 1 2

On normal termination all the transients given by A A is collected and given by the combined

1 2

actionif b oth give one or more items of transients these are tupled in the given order On escap e

only the transients given by the escap e is given by the combined action

Declaratively conducting The bindings received by the combination of A A are received by b oth

1 2

A A On normal termination all the bindings pro duced by A A are collected and pro duced by

1 2 1 2

the combined actionprovided that the bindings are all for distinct tokens otherwise the combined

action fails

 A and then A a basic combination of actions A A Represents dep endency on normal termination

1 2 1 2

APPENDIX B ACTION NOTATION

Basically normal sequencing Performs A rst If A completes p erforms A

1 1 2

 A trap A a basic action combination Represents recovery from abnormal termination

1 2

Performs A rst If A escap es p erforms A

1 1 2

Functionally comp osing see the functional action A then A in Section B

1 2

 action the sort of all actions See Section B for notation for subsorts of action

B Yielders

 the d yielded by Y a yielder where d is a sort of data and Y is a yielder When Y yields an individual

it yields that individual provided that the individual is included in the sort otherwise it yields nothing

 Every dataoperation ie op eration sp ecied for arguments included in data is extended to arguments of

sort yielder The application of a data op eration to yielders yields whatever is yielded by applying the data

op eration to the data yielded by the arguments For instance sum Y Y yields the numerical sum of

1 2

whatever Y and Y yield

1 2

 yielder the sort of all yielders See Section B for notation for subsorts of yielder

B Data

 datum a sort Its individuals represent items of data Left op en as it dep ends on the variety of information

pro cessed by the programs of a programming language Includes generallyuseful sorts from data notation

see App endix C except for tuples Similarly for distinctdatum the sort of datum whose individuals are

is distinguished by the op eration

 data a sort Its individuals represent tuples ie ordered collections of individuals of sort datum which

may also b e pro cessed as transient information see Section B

 a d the same data as d Only used to improve the readability of the notation Similarly for an d the d

of d and some d Thus an application of an op eration op to arguments x can b e written as op x op of x

and the op of x Note that the words the and of are obligatory parts of some other op eration symbols

Compare the Hyp erCard scripting language Hyp erTalk Go o

B Functional Action Notation

Functional action notation is primarily concerned with sp ecifying the pro cessing of transient information data

B Actions

 Al l primitive functional actions

Do not commit

Pro duce no bindings

Make no changes to storage

Do not communicate

 Al l functional action combinators are

Declaratively conducting see the basic action A and A in Section B

1 2

 give Y a primitive functional action where Y is a data yielder Represents creating a piece of transient

information

Indivisible Completes when Y yields data Fails when Y yields nothing

Gives the data yielded by Y

B DECLARATIVE ACTION NOTATION

 escap e with Y a primitive functional action where Y is a data yielder Represents escaping with a piece

of transient information which may b e used to distinguish dierent reasons for escap e

Indivisible Escap es when Y yields data Fails when Y yields nothing

Gives the data yielded by Y

 regive a primitive functional action Represents propagation of transient information ie data Unit for

A then A

1 2

Indivisible Always completes

Gives any given data

 cho ose Y a functional action where Y is a data yielder Represents implementationdependent choice

b etween a p ossibly innite collection of individual items of data

Indivisible Completes when Y yields a sort including a data individual Fails when Y yields nothing

Gives any individual data of the sort yielded by Y

 check Y a functional action where Y is a truthvalue yielder Represents a guard checking that a condition

is true

Indivisible Completes when Y yields true Fails when Y yields false or nothing

Gives no data

 A then A a functional combination of actions A A Represents passing on transient information

1 2 1 2

normally

Basically sequencing see the basic action A and then A in Section B

1 2

Functionally composing The transients given to the combination of A A are given to A Only

1 2 1

the transients given by A are given to A provided that A is p erformed Only the transients

1 2 2

given by A are given by the combined action

2

B Yielders

 given d a data yielder where d is a sort of data Yields the transient data given to its evaluation provided

that the data is of sort d

 given d p a datum yielder where d is a sort of datum and p is a p ositive integer Yields the p th

comp onent of the transient data given to its evaluation provided that the datum is of sort d

 it a datum yielder Yields the single datum given to its evaluation as a transient

 them a data yielder Yields all the data given to its evaluation as transients

B Data

 data a sort Its individuals represent ordered collections ie tuples of individuals of sort datum pro cessed

as transient information

B Declarative Action Notation

Declarative action notation is primarily concerned with sp ecifying the pro cessing of scop ed information bindings

B Actions

 Al l primitive declarative actions

Do not commit

Give no transients

APPENDIX B ACTION NOTATION

Make no changes to storage

Do not communicate

 Al l declarative action combinators are

Functionally conducting see the basic action A and A in Section B

1 2

 bind T to Y a primitive declarative action where T is a token and Y is a yielder of bindable data

Represents creating a piece of scop ed information

Indivisible Completes when Y yields data of sort bindable Fails otherwise

Pro duces the binding of the token T to the bindable data

 unbind T a primitive declarative action where T is a token Represents hiding a piece of scop ed informa

tion making a hole in its scop e

Indivisible Completes

Pro duces the binding of the token T to the datum unknown

 rebind a primitive declarative action Represents propagation of scop ed information Unit for the declar

ative action A hence A

1 2

Indivisible Always completes

Pro duces all received bindings

 produce Y a primitive declarative action Represents pro duction of reied scop ed information

Indivisible Completes when Y yields a datum of sort bindings

Pro duces the bindings yielded by Y

 furthermore A a declarative combination of the action A Represents propagating the received bindings

but letting bindings pro duced by A take precedence when there is a conict

Basically as A

Functionally as A

Declaratively as rebind moreover A

 A moreover A a declarative combination of actions A A Like A and A but gives priority to bindings

1 2 1 2 1 2

pro duced by A

2

Basically interleaving see the basic action A and A in Section B

1 2

Declaratively overlaying The bindings received by the combination of A A are received by b oth

1 2

A A On normal termination the bindings pro duced by A overlaid with those pro duced by A

1 2 1 2

are pro duced by the combined action

 A hence A a declarative combination of actions A A Represents passing on scop ed information

1 2 1 2

restricting the bindings received by A

2

Basically sequencing see the basic action A and then A in Section B

1 2

Declaratively composing The bindings received by the combination of A A are received by A

1 2 1

Only the bindings pro duced by A are received by A provided that it is p erformed Only the

1 2

bindings pro duced by A are pro duced by the combined action

2

 A b efore A a declarative combination of actions A A Represents accumulating scop ed information

1 2 1 2

Basically sequencing see the basic action A and then A in Section B

1 2

Declaratively accumulating The bindings received by the combination of A A are received by

1 2

A The bindings received by the combined action overlaid with the bindings pro duced by A are

1 1

received by A provided that it is p erformed On normal termination the bindings pro duced by

2

A overlaid with those pro duced by A are pro duced by the combined action

1 2

B IMPERATIVE ACTION NOTATION

B Yielders

 current bindings a yielder of bindings maps Yields the collection of bindings received by its evaluation

 the d b ound to T a yielder of bindable data where d is a sort of data and T is a token Yields the data

of sort d to which T is b ound by the received bindings if any

B Data

 bindings a subsort of map Its individuals represent collections of asso ciations b etween tokens and bindable

or unknown individuals

 token a subsort of distinctdatum Left unsp ecied as it dep ends on the variety of identiers of a program

ming language Usually it is a subsort of string

 bindable a subsort of data Left op en as it dep ends on the variety of scop ed information pro cessed by the

programs of a programming language

B Imp erative Action Notation

Imp erative action notation is primarily concerned with sp ecifying the pro cessing of stable information storage

B Actions

 Al l primitive imperative actions

Give no transients

Pro duce no bindings

Do not communicate

 There are no special imperative action combinators

 store Y in Y a primitive imp erative action where Y is a yielder of storable data and Y is a yielder of

1 2 1 2

cells Represents changing an atomic piece of stable information

Indivisible Commits and completes when Y yields a reserved cell and Y yields storable data Fails

2 1

otherwise

Stores the storable yielded by Y in the cell yielded by Y

1 2

 reserve Y a primitive imp erative action where Y is a yielder of cells Represents extending stable

information with an extra uninitialized piece

Indivisible Commits and completes when Y yields an unreserved cell Fails otherwise

Reserves the cell yielded by Y and stores the datum uninitialized in it

 unreserve Y a primitive imp erative action where Y is a cell yielder Represents destroying stable infor

mation

Indivisible Commits and completes when Y yields a reserved cell Fails otherwise

Unreserves the cell yielded by Y

B Yielders

 current storage a yielder of storage maps Yields the state of storage

 the d stored in Y a yielder of storable data where d is a sort of data and Y is a yielder of cells Yields

the data of sort d stored in the cell yielded by Y according to the current storage provided that the cell is currently reserved

APPENDIX B ACTION NOTATION

B Data

 storage a subsort of map Its individuals represents states of stable information asso ciating cells with

storable or uninitialized individuals

 cell a subsort of distinctdatum Its individuals represent the lo cations of pieces of stable information Left

lo oselysp ecied as the details are implementationdependent

 storable a subsort of data Left unsp ecied as it dep ends on the variety of stable information pro cessed

by the programs of a programming language

B Reective Action Notation

Reective action notation is concerned with sp ecifying the reication of actions and information as abstractions

and with the reection of abstractions as actions

B Actions

 enact Y a reective action where Y is a yielder of abstractions Represents p erforming an action in a

context dierent from that of its o ccurrence

Performs the action incorp orated in the abstraction yielded by evaluating Y

The p erformance of the incorp orated action is given no data But see the abstraction yielder

application d to d

1 2

The p erformance of the incorp orated action receives no bindings But see the abstraction yielder

closure d

B Yielders

 application d to d an abstraction when d is an abstraction and d is data Incorp orates the same action

1 2 1 2

as d except that the incorp orated action is given d as transients whenever the abstraction is enacted

1 2

Represents supplying transients to an abstraction precluding the supply of further transients

This op eration extends to yielders Y Y in the usual way it is evaluated by applying the ab ove op eration

1 2

to the data yielded by evaluating Y Y

1 2

 closure d an abstraction yielder where d is an abstraction Yields an abstraction which incorp orates the

same action as d except that the incorp orated action receives particular bindings whenever the abstraction

is enacted The bindings are those current for the evaluation of closure d

This op eration extends to yielders Y in the usual way it is evaluated by applying the ab ove op eration to

the datum yielded by evaluating Y

The yielder closure abstraction of A represents reication of an action as an abstraction with static bindings

The action enact the closure of a given abstraction represents reection of an abstraction with dynamic

bindings unless static bindings were already supplied to it The action enact a given abstraction represents

reection of an abstraction with no bindings unless static bindings were already supplied to it

B Data

 abstraction the sort of datum that incorp orates ie reies an action The incorp orated action is p er

formed when the abstraction is enacted ie reected

 abstraction of A an abstraction where A is an action Incorp orates A Represents a p ointer to the co de

implementing A Yielders o ccurring in A do not get evaluated when the abstraction is evaluated they are

left for evaluation during the p erformance of the incorp orated action

B Communicative Action Notation

Communicative action notation is primarily concerned with sp ecifying the pro cessing of p ermanent information communications

B COMMUNICATIVE ACTION NOTATION

B Actions

 Al l primitive communicative actions

Give no transients

Pro duce no bindings

Make no changes to storage

 There is only a unary communicative action combinator

 send Y a primitive communicative action where Y yields a sort of message Represents initiating the

transmission of a message The usual form of Y is a message to Y containing Y where Y and Y

1 2 1 2

yield individuals

Indivisible Commits and completes when the sort of message yielded by Y includes a message from

the current p erformer with the next serial number Fails otherwise

Emits a message of the sort yielded by Y The serial number of the message is the successor of

that of the previous message sent or contract oered by the p erforming agent Message transmis

sion is reliable but each message takes an implementationdependent time to arrive so message

transmission b etween two particular agents is not necessarily orderpreserving

 remove Y a primitive communicative action where Y is a yielder of individual messages Represents that

a particular message in the buer has b een pro cessed and is to b e discarded

Indivisible Commits and completes when the message yielded by Y is in the buer Fails otherwise

Removes the message yielded by Y from the buer

 oer Y a primitive communicative action where Y yields sort of contract Represents initiating the

arrangement of a contract with another p erhaps only partially sp ecied agent The usual form of Y is a

contract to an agent containing abstraction of A where A is the action to b e p erformed according to the

contract

Indivisible Commits and completes when the sort of contract yielded by Y includes an individual

contract from the p erformer Fails otherwise

Gives no data

Requests the arrangement of a contract of the sort yielded by Y Oered contracts are distinguished

by serial numbers as with sent messages The arrangement of a contract takes an implementation

dep endent time which must b e nite when there is a continually uncontracted agent of the sp ecied

sort

 patiently A a communicative action where A is an action Represents busy waiting while A fails Only

useful when A refers to information that may change due to some other action for instance the messages

in the buer

Performs A indivisibly but not indivisible itself If the p erformance fails it tries again Thus it

diverges when A always fails

Functionally as A

Declaratively as A

B Yielders

 current buer a yielder of buers Yields the list of messages that have app eared in the buer but which

have not yet b een removed The messages are listed in the order of their arrival in the buer

 p erformingagent a yielder of agents Yields the identity of the agent that is p erforming the enclosing

action

 contractingagent a yielder of agents Yields the identity of the agent that oered the contract to the p erformer

APPENDIX B ACTION NOTATION

B Data

 agent a sort of datum An agent identies a p otential pro cess of p erforming an action representing a piece

of distributed pro cessing It is lo oselysp ecied as the maximum number and distribution of pro cesses is

usually implementationdependent

Each agent has its own buer and storage It is inactive until it accepts a contract to p erform an action

whereafter it remains active for ever even after the termination of the contracted action

 useragent a distinguished agent It corresp onds to the environment of a program providing input and

accepting output The user agent is initially the only agent with a contract

 buer a sort of datum A buer is a list of messages sent to the same agent in the order of their arrival

 communication a sort of datum Individual communications represent information that can b e transmitted

by agents Communications have comp onents indicating their sender receiver and contents Moreover

each communication is distinguished by a serial number determined by the sender

 message a subsort of communication Messages can b e sent directly from one agent to another

 sendable a sort of data The data that can b e the contents of messages sent b etween agents Left op en as

it dep ends on the variety of p ermanent information pro cessed by the programs of a programming language

Sp ecied to include abstraction and agent to allow prop er use of sub ordinate Y

 contract a subsort of communication Contracts can b e oered by one agent to another sort of agent

The contents of a contract is the abstraction to b e enacted by an agent accepting the contract

 contents d data where d is a communication The data contained in d

 sender d a datum where d is a communication The agent that sends d

 receiver d a datum where d is a communication The agent that receives d

 serial d a datum where d is a communication The serial number of d determined lo cally when it is

emitted

 d containing d a subsort of communication where d is a sort of data and d is a sort of communication

1 1

It includes only those communications in d whose contents is of sort d

1

 d from d a subsort of communication where d is a sort of agent and d is a sort of communication

1 1

It includes only those communications in d whose sender is of sort d

1

 d to d a subsort of communication where d is a sort of agent and d is a sort of communication It

1 1

includes only those communications in d whose receiver is of sort d

1

 d at d a subsort of communication where d is a sort of natural number and d is a sort of communi

1 1

cation It includes only those communications in d whose serial number is of sort d

1

B Hybrid Action Notation

Hybrid action notation consists of some useful abbreviations for comp ound actions involving more than one kind

of information together with some hybrid combinators that mix various facets of the other combinators There

are also some hybrid data op erations

B Actions

 allo cate d an imp erative and functional action where d is a sort of cell Represents implementation

dep endent choice and reservation of a cell of sort d

Indivisible Commits and completes when there is an unreserved cell of sort d Fails otherwise

Reserves some cell of sort d

Gives the reserved cell

 receive Y a communicative and functional action where Y yields a sort of message Represents waiting

for a message to arrive in the buer The usual form of Y is a restriction such as a message from Y

1

containing Y where Y Y may yield sorts or individuals

2 1 2

B FACETS

Patiently waits for a message of the sort yielded Y to arrive then commits and completes Otherwise

diverges

Cho oses and gives any received message of the sort yielded by Y

Removes the chosen message from the buer

 A thence A a declarative and functional hybrid combination of actions A A Like

1 2 1 2

A then A for control and transients and like A hence A for bindings

1 2 1 2

B Yielders

 There are no hybrid yielders

B Data

 owner d an agent where d is a cell or an indirection The agent where it is lo cated

 d on d a subsort of cell where d is a sort of agent and d is a sort of cell It includes only those cells

1 1

in d whose owner is of sort d Similarly when d is a sort of indirection

1

B Facets

The facets of actions and yielders are obtained by fo cusing on particular kinds of information The notation

summarized b elow is used for expressing sorts of actions and yielders

B Outcomes

O combines  outcome a sort of auxiliary entities used for sp ecifying sorts of actions Sort union O

2 1

outcomes The various outcomes b elow are disjoint so there is no use for sp ecifying their intersections

 giving d allows normal termination that always gives transients included in the data sort d completing

abbreviates giving where is the empty tuple of data

 escaping with d allows abnormal termination that always gives transients included in the data sort d

escaping abbreviates escaping with data

 binding allows normal termination that optionally pro duces some bindings The union outcome giving

binding allows normal termination that always gives transients of sort d and optionally pro duces some d

bindings The use of binding alone implies completing

 failing ignored Most comp ound actions that use information fail when that information is not made

available to their p erformance

 committing allows commitment indep endently of termination Included in storing and communicating

which are analogous

 diverging allows nontermination Actions without this sort of outcome are guaranteed to terminate

whereas those with this outcome might or might not terminate Actions that contain any o ccurrence of

unfolding or enact Y have this sort of outcome unless they are equivalent to other actions that do not have

it

B Incomes

 income a sort of auxiliary entities used for sp ecifying sorts of actions and yielders Sort union I I

1 2

combines incomes The various incomes b elow are disjoint so there is no use for sp ecifying their intersec

tions

 given d allows use of given transients of the data sort d More sp ecically the income given d p sp ecies

p ossible use of the p th comp onent of the given transients this b eing of datum sort d

 current bindings allows use of received bindings

APPENDIX B ACTION NOTATION

 current storage allows use of storage

 current buer allows use of the message buer

B Actions

 action the sort of all actions Its subsort primitiveaction includes not only the actions describ ed in this

App endix as primitive but also comp ound actions that are equivalent to them eg complete and then

escap e which is equivalent to escap e

 A O a sort of action where A is a sort of action and O is a sort of outcome Restricts A to those

actions which whenever p erformed either fail or have an outcome whose termination prop erties and kind

of information pro cessing are included in O Note that A O A O is generally a prop er subsort of A

1 2

O whereas A O A O is the same sort as A O O which can also b e written as A O O

2 1 2 1 2 1 1

O

2

 A using I a sort of action where I is a sort of income Restricts A to those actions which whenever

p erformed p erhaps evaluate yielders that refer to the current information indicated by I Compare Y

using I where Y is a sort of yielder b elow

B Yielders

 yielder the sort of all yielders

 Y d a sort of yielder where Y is a sort of action and d is a sort of data Restricts Y to those yielders

which whenever evaluated yield data included in d Note that the union sort Y d Y d is generally

1 2

a prop er subsort of Y d d whereas Y d Y d is the same sort as Y d d which can also

1 2 1 2 1 2

b e written as Y d d

1 2

 Y of d equivalent to Y d but a yielder of an integer reads a bit more naturally than yielder integer

 Y using I a sort of yielder where I is a sort of income Restricts Y to those yielders which whenever

evaluated refer at most to the current information indicated by I

App endix C

Data Notation

This App endix will provide an informal summary of the data notation used in the example

Bibliography

Go o Danny Go o dman The Complete HyperCard Handbook Bantam

Mos Peter D Mosses Denotational semantics In J van Leeuwen A Meyer M Nivat

M Paterson and D Perrin editors Handbook of Theoretical Computer Science vol

ume B chapter Elsevier Science Publishers Amsterdam and MIT Press

Mos Peter D Mosses Action Semantics Number in Cambridge Tracts in Theoretical

Computer Science Cambridge University Press

Plo Gordon D Plotkin LCF considered as a programming language Theoretical Computer

Science

Sto Allen Stoughton Fully Abstract Models of Programming Languages Pitman John

Wiley