The Vienna development method: the Meta-langauge

Lecture Notes in Computer Science Edited by G. Goos and J. Hartmanis

61 I

I

The Vienna Development Method: The Meta-Language

Edited by D. Bjerner and C. B. Jones I

IIIII III

Springer-Verlag Berlin Heidelberg NewYork 1978

Editorial Board P. Brinch Hansen D. Gries C. Moler G. SeegmL~ller J. Stoer N. Wirth Editors Dines Bjerner Department of Computer Science Building 343 and 344 Technical University of Denmark DK-2800 Lyngby

Cliff B. Jones IBM International Education Centre Chaussee de Bruxelles 135 B-1310 La Hutpe

Library of Congress Cataloging in Publication D a t a

Main entry under title: The Vienna development method. (Lecture notes in computer science ; 61) Bibliography: p. Includes index. 1. Programming languages (Electronic computers)-Addresses, essays, lectures. I. BJ~rner, Dines. II. Jones, Cliff B.~ 1944Ill. Title: Matalanguage. IV. Series. QA76.7.V53 001.6'424 78-7232

AMS Subject Classifications (1970): 68-02, 68A05, 68A30 CR Subject Classifications (1974): ISBN 3-540-08766-4 Springer-Verlag Berlin Heidelberg NewYork ISBN 0-387-08766-4 Springer-Verlag New York Heidelberg Berlin This work is subject to copyright. All rights are reserved, whether the whole or part of the material is concerned, specifically those of translation, reprinting, re-use of illustrations, broadcasting, reproduction by photocopying machine or similar means, and storage in data banks. Under § 54 of the German Copyright Law where copies are made for other than private use, a fee is payable to the publisher, the amount of the fee to be determined by agreement with the publisher. © by Springer-Verlag Berlin Heidelberg 1978 Printed in Germany Printing and binding: Beltz Offsetdruck, Hemsbach/Bergstr. 2145/3140-5432

CONTENTS

V

Introduction

XVII

Acknowledgements Addresses

XIX

of All A u t h o r s

ON THE F O R M A L I Z A T I O N

OF P R O G R A M M I N G

LANGUAGES:

EARLY HISTORY AND MAIN APPROACHES

Peter Luca8 PROGRAMMING

IN THE M E T A - L A N G U A G E :

A TUTORIAL

24

Dines Bj~rner THE M E T A - L A N G U A G E :

A REFERENCE

218

MANUAL

Cliff B.Jones DENOTATIONAL

SEMANTICS

A N D ITS R E L A T I O N

OF GOTO:

AN EXIT F O R M U L A T I O N 278

TO C O N T I N U A T I O N S

Cliff B.Jones A FORMAL

DEFINITION

IN THE

OF A L G O L

1975 M O D I F I E D

60 AS D E S C R I B E D 305

REPORT

Wolfgang Henhapl & Cliff B.Jone8 SOFTWARE

ABSTRACTION

-- T u t o r i a l Command

Examples Language

On-Condition

PRINCIPLES: of: A n O p e r a t i n g Specification,

Language

System

and a P L / I - l i k e

Definition

337

Dines BjCrner References

& Bibliography

All papers lists their CONTENTS at their very beginning.

375

INTRODUCTION The purpose of this v o l u m e is to provide a summary of a body of w o r k w h i c h has reached a r e l a t i v e i y stable state. The w o r k is, however, from complete

far

(in the sense - even - that the authors w h o s e w o r k is

presented here feel that they h a v e s a t i s f a c t o r y solutions tO the prob~ lems they set out to solve.) N o t w i t h s t a n d i n g

their own r e c o g n i t i o n of

d i f f i c u l t i e s and shortcomings in the current presentation,

the authors

hope that w h a t has been achieved may be of use to others. Furthermore, a summary of the results of any significant effort may be hoped to stimulate the work of researchworkers.

The purpose of this i n t r o d u c t i o n is, of course,

to i n t r o d u c e the vo-

lume. Firstly an o u t l i n e is p r o v i d e d of the so-called

"Vienna Develop-

ment Method" and some m o t i v a t i o n offered of the m e t a - l a n g u a g e w h i c h is the part of the method of c o n c e r n in this volume. F o l l o w i n g this a review is provided of other work done in the V i e n n a Laboratory,

in order

to put w h a t is presented h e r e in context.

Vienna D e v e l o p m e n t Method

Before entering into the d e s c r i p t i o n itself,

it is perhaps w o r t h spend-

ing a few m o m e n t s on the name itself in the hope to avoid a m i s u n d e r standing w h i c h could arise. The earlier w o r k of the V i e n n a l a b o r a t o r y d e v e l o p e d a m e t a - l a n g u a g e for d e f i n i t i o n s w h i c h b e c a m e k n o w n as the ~'Vienna D e f i n i t i o n Language" p r e s e n t e d in this v o l u m e

(VDL). The r e l a t i o n s h i p b e t w e e n the w o r k

and the VDL is d i s c u s s e d below. Of course,

the earlier m e t a - l a n g u a g e had a large influence on the later one. But even here there is a sharp d i f f e r e n c e between the two

(technically,

VDL was d e s i g n e d for w r i t i n g o p e r a t i o n a l d e f i n i t i o n s w h i l s t

the meta-

language used in V D M is intended for the p r e s e n t a t i o n of d e n o t a t i o n a l d e f i n i t i o n s ) . Moreover, Method

as the name suggests,

(abbreviated to V D M in this volume)

the V i e n n a D e v e l o p m e n t

is m u c h more than just a

me~a-language.

Turning now to the content of VDM. The "method"

is m e a n t to b e a sy-

stematic a p p r o a c h to the d e v e l o p m e n t of large computer s o f t w a r e systems. Strictly,

there is nothing w h i c h restricts the a p p l i c a t i o n to software

but no attempts have b e e n made to use the a p p r o a c h on h a r d w a r e design. The key p r o p o s a l s are simple and by no means u n i q u e to VDM. As indicated in f~g.

I, the first objective in getting any c o m p l e x s y s t e m

VI

i EQUIREMENTS I

Intuitive

FORMAL DEFINITION

I

DEVELOPMENT

I

i

i

THE VIENNA DEVELOPMENT METHOD

under control is the construction quired function.

of a formal definition of the re-

This specification

sequent development. of development

is a reference point for the sub-

For a large system there will follow a sequence

steps. The downward pointing arrows are suggestive

a time sequence. design process, relationships

Stepwise Refinement and Decomposition

STEPS 1,2, .... n I

FIG. l:

Architectural Model

I) i

Step

Because it is often necessary to 'think ahead'

of

in a

it is more accurate to view the arrows as showing the

between the final stages of the documentation.

reader may understand

Thus, a

the design of a system in a strictly top-down

way although this is an idealization

of the actual

(iterative)

design

process. The backward links in f i g . each stage of development

I relate

to another key point of V D M .

a justification

is provided.

overall process begins with a specification,

At

Just as the

each intermediate develop-

ment step can be viewed as presenting a solution to a specification (all that distinguishes

the last ' i m p l e m e n t a t i o n '

phase is that instead

of generating new specifications,

all of the required units are avail-

able). The aim of a justification

is to document why the proposed

lution, is believed

to fulfil its specification.

can be presented at different

so-

Such justifications

levels of formality.

But without enter-

ing here into a discussion of what level might be chosen in various cir-

VII

cumstances,

it should be clear that justifications d o c u m e n t e d d u r i n g

the d e v e l o p m e n t process are likely to be both much more intuitive and of m o r e use in early d e t e c t i o n of d e s i g n errors than any a t t e m p t to c o n s t r u c t a proof for a c o m p l e t e system after construction.

D e c o m p o s i t i o n and c o r r e c t n e s s arguments are two key points: the use of a b s t r a c t i o n to handle complexity.

a third is

In the papers in this vo-

lume it will be m a d e clear how a s p e c i f i c a t i o n can be viewed as an abstract model of the system to be specified. Such an a b s t r a c t model will m a k e extensive use of abstract data objects

(see Bj~rner 78b):

it

is the choice of a p p r o p r i a t e abstractions w h i c h can make a short and readable formal specification.

The use of a b s t r a c t objects during the

d e v e l o p m e n t process and their r e f i n e m e n t to objects w h i c h are representable in the eventual r e a l i z a t i o n is d i s c u s s e d in Bj~rner 77a, Jones 77a.

W h i l s t V D M was first envisaged for languages and the d e v e l o p m e n t of their processors,

the d e f i n i t i o n m e t h o d s have s u b s e q u e n t l y b e e n applied

to other "systems" - see Hansal 76, Nilsson 76, Madsen 77.

~he M e t a - L a n g u a g e

Having e m p l o y e d an internal name

("Vienna Development Method")

first part of the title of this volume,

for the

the anonymous sub-title may

cause some surprise. In fact there is an internal name

("Meta-IV")

for

the m e t a - l a n g u a g e used in Z D M so its o m i s s i o n can be guessed to h a v e strong grounds. The point is that in d e f i n i n g and d e v e l o p i n g systems a number of concepts h a v e been used;

it has of course been n e c e s s a r y to

use a n o t a t i o n to m a n i p u l a t e the concepts.

It is, however,

the concepts

w h i c h are important not the particular c o n c r e t e syntax used for expressions r e a l i z i n g these concepts.

It was felt by the authors that m a k i n g

w i d e u s e of a name for the m e t a - l a n g u a g e might focus a t t e n t i o n on the w r o n g issues and so it has been avoided. Furthermore,

it should be

m a d e clear that the m e t a - l a n g u a g e is not "closed" in that

(well defined)

extensions can be m a d e w i t h o u t fear of a 'standards committee'

The need for a m e t a - l a n g u a g e should be clear. D e c o m p o s i t i o n has b e e n shown to be a part of VDM and this only makes sence if something is written about each stage of development. m u s t use some language.

If s o m e t h i n g is to be w r i t t e n it

In view of the s y s t e m a t i c a p p r o a c h b e i n g t a k e n

Vtlt

to d e v e l o p m e n t and,

in particular,

the use of justifications,

it should

be obvious that a formal n o t a t i o n is required. Given that abstract objects are required,

choosing established n o t a t i o n

appear to be wise. Surprisingly,

(e.g. for sets) would

the d e c i s i o n to use

'standard' mathe-

matical notation for standard things has actually caused some people to object: The clue is a concern, which is unfounded,

that the use of

notation from a branch of m a t h e m a t i c s implies that a d e e p k n o w l e d g e thereof is required.

A n o t h e r influence on the m e t a - l a n g u a g e has been p r o g r a m m i n g languages. Just as choosing u n d e r s t o o d m a t h e m a t i c a l objects can aid the reader, the use of sequencing constructs

from p r o g r a m m i n g languages

(e.g. ~_~

then else) can enhance the r e a d a b i l i t y of a definition. Of course, all such constructs employed must themselves be p r e c i s e l y d e f i n e d - this is tackled in Jones ?Sa.

The major inpetus towards d e n o t a t i o n a l semantics has come from Oxford University. There is, however,

a striking d i f f e r e n c e in the a p p e a r a n c e

of d e f i n i t i o n s created by Oxford or Vienna. This subject is returned to later in the volume but it is important to r e m e m b e r the o b j e c t i v e s of the d i f f e r e n t groups in order to avoid

(erroneously)

seeking a "cor-

rect" choice. The Oxford group have been interested in the foundations of their m e t a - l a n g u a g e and its use on examples small enough to facilitate complete proofs;

the V i e n n a group was forced to take a more engi-

neering approach when faced with languages like PL/I.

Several things have b e e n d e l i b e r a t e l y excluded from this volume. Firstly the subject of c o n c r e t e syntax is w e l l - d o c u m e n t e d Uzgalis 79 ignored.

elsewhere

(e.g.

and thus, w h i l s t an important part of a system d e f i n i t i o n , i t is

Secondly,

there is no formal d e s c r i p t i o n of methods for de-

fining parallelism. Thirdly the r e l a t i o n s h i p to other methods is only d i s c u s s e d by P. Lucas: of, for example,

this is not a c o m m e n t on the other authors' views

axiomatic definitions.

IX

Relation

to E a r l i e r V i e n n a Work

The purpose of this s e c t i o n the work p r e s e n t e d

is to i d e n t i f y

in this volume

and that d o n e

Laboratory.

For this o b j e c t i v e

necessarily

long and is not attempted.

into the introduction, rial will

in the V i e n n a

fits,

is u n f a m i l i a r

to first read both

names

be un-

logically,

w i t h the m a t e -

the m o r e general of the cur-

78a.)

for the two phases

"FDL" and "FDM" will be used.

pared,

(This s e c t i o n

785 or Jones

between

view w o u l d

78 - and one of the d e s c r i p t i o n s

- Bj~rner

to have p r e c i s e

earlier

historical

but the r e a d e r w h o

review - Lucas

rent m e t a - l a n g u a g e

In order

a complete

find it more b e n e f i c i a l

historical

the main d i f f e r e n c e s

that are to be com-

"Vienna D e f i n i t i o n

Language"

(VDL) was a term coined and used most w i d e l y in N o r t h A m e r i c a and identifies

the language

na L a b o r a t o r y

during

has b e e n d e s c r i b e d in some i n p o r t a n t tivations

definition

the 1960's.

above.

respects:

reviewing

to the earlier work.

60 and following

the papers McCarthy TC2 c o n f e r e n c e

was

647 L a n d i n

(see Steel

steps"

towards

(ULD) are recorded

objective

as d e s c r i b e d

implementation

a style

in Bandat

statements

in 1966.

an internal

volving

This

and s u b s e q u e n t the s t r u c t u r e

a formal de-

64 and the Baden

McCarthy

66). The

Language

It is w o r t h

quoting

for language d e s i g n

about

It should the o b j e c t

of the PL/I d e f i n i t i o n

plete and b e c a m e language.

65, Elgot

and as a useful b a c k g r o u n d

programmers ....

langu a g e w h e n p r i n t e d

for

b a s i s of this w o r k was

for "Universal 65.

relating

a compiler

Desthe

by P. Lucas:

groups,

and p r o v e

The first v e r s i o n

review

and their mo-

to u n d e r t a k e

66 - especially

"The r e s u l t may serve as a vehicle

and s o p h i s t i c a t e d

asked

The a c k n o w l e d g e d

63a, L a n d i n

of 1964

"tentative

version

these d i f f e r e n c e s

group had c o n s t r u c t e d

this work

language.

cription"

mulate

(VDM)

Method

to the earlier work but differs

some of the i m p o r t a n t d o c u m e n t s

The V i e n n a

f i n i t i o n of the PL/I

first

and used in the Vien-

The V i e n n a D e v e l o p m e n t

It owes much

technical

developed

are the subject here.

We begin by b r i e f l y

ALGOL

notation

evolution

for educated

be p o s s i b l e language."

2 was

and r e f e r e n c e

essentially

tool

led to the r e q u i r e m e n t

(extensive)

to for-

did n o t c o v e r the c o m p l e t e

The 1968 v e r s i o n control

groups,

revisions.

of this third version:

com-

for the efor a third

It is i n t e r e s t i n g

to

Compile

Time F a c i l i t i e s

Fleck 69

Concrete Syntax

Urschler 69a

T r a n s l a t i o n C o n c r e t e to A b s t r a c t

Urschler 69b

A b s t r a c t Syntax and Interpreter

Walk 69

Informal Introduction

Alber 69

The VDL notation is a means of describing a b s t r a c t interpreters Lucas 78 for d e f i n i t i o n of this approach.) taken of objects and their m a n i p u l a t i o n

(see

A very general v i e w was

(cf. the "~" function)

and the

control c o m p o n e n t was m a d e part of the state of the interpreter. This m e a n t that extremely "flexible" interpreters could be c o n s t r u c t e d w h i c h may have been one of the reasons why VDL was quickly adopted by a number of groups both in and outside IBM. To give just a few references: Lauer 68, Z i m m e r m a n n

69, Lee 72, Moser 70a

(this is one of several at-

tempts to use the m e t a - l a n g u a g e for the d e s c r i p t i o n s of "systems").

The best o v e r v i e w of the VDL w o r k is probably still Luoas 69 along with Bekic 70b on the subject of storage models. Other reviews are a v a i l a b l e in Wegner 72 and Ollengren 75.

(Although this section is not a full his-

torical survey it would be remiss not to m e n t i o n the g u i d a n c e provided by H. Zemanek - see, for example,

Zemanek 66).

Rather than listing the users of VDL it will be m o r e germane to consider how such d e f i n i t i o n s w e r e used in the j u s t i f i c a t i o n of implementations of d e f i n e d languages. Just as w i t h the work on p r o g r a m development, the initial w o r k concentrated on proofs: once this basis was laid, attention was turned to systematic d e v e l o p m e n t methods. R e a l i z i n g his earlier

(quoted) hopes P. Lucas was able to d e m o n s t r a t e the u s e of a

VDL d e f i n i t i o n in proving an i m p l e m e n t a t i o n correct in Lueas

68. A con-

s i d e r a b l e amount of work in this d i r e c t i o n was then u n d e r t a k e n and is reviewed in Jones 71. Much of this w o r k was m a d e m o r e d i f f i c u l t than one felt was n e c e s s a r y by the "flexibility" of the abstract interpreters which could be w r i t t e n u s i n g VDL. In p a r t i c u l a r the ability to e x p l i c i t l y change the control meant that inductive proofs over the structure of

(abstract)

programs w e r e not,

in general, valid;

and the

inclusion of objects like the environment in a "Grand State" c o m p l i c a t ed proofs. A l t h o u g h the proofs in Jones 71 avoided the former problem, the latter led to some of the longest proofs in the paper. The attempts to use VDL definitions as a basis for systematic d e v e l o p m e n t of implem e n t a t i o n s was,

then, providing indications that a change of d e f i n i t i o n

style might be worthwhile.

XJ

Other important q u e s t i o n s w e r e being raised on the style of definition. Of great importance w e r e the observations in Beki~ 70a that a more "Mathematical"

style could avoid much u n n e c e s s a r y detail. One of the

problems w h i c h had caused the use of the control in VDL was p r o v i d i n g a model for goto statements. An a l t e r n a t i v e "exit approach" had been d e s c r i b e d in Henhapl 70a. A "functional" d e f i n i t i o n of A L G O L 60 used this a p p r o a c h in Allen 72. Furthermore, "small state"

this d e f i n i t i o n had used a

in that the e n v i r o n m e n t was made a s e p a r a t e argument to

the d e f i n i n g functions. This d e f i n i t i o n is not, however, ("denotational")

"mathematical"

and is u n n e c e s s a r i l y c o m p l i c a t e d by the a v o i d a n c e of

combinators for frequently r e c u r r i n g patterns.

(Other w o r k on the ques-

tion of "style" had, of course, b e e n pursued - see, for example, Lauer 71, Hoare 69, Hoare 74).

The "denotational" a p p r o a c h is c h a r a c t e r i z e d in Lucas 78. The work of the Oxford group is well d o c u m e n t e d in Scott 71~ Mosses 74, Stoy 74 (the most r e a d a b l e account)

and Milne 76.

Towards the end of 1972 the Vienna group again turned their a t t e n t i o n to the p r o b l e m of s y s t e m a t i c a l l y d e v e l o p i n g a compiler from a language definition.

The overall approach adopted has been termed the "Vienna

D e v e l o p m e n t Method". Based on the above comments it should be no surprise that a "denotational" approach was adopted for the d e f i n i t i o n itself.

(Using, however,

the exit approach rather than "continuations"

see Jones 78b). This change was, thors choose to suggest.

in fact,

-

less drastic than some au-

It is p o s s i b l e to read a d e n o t a t i o n a l defini-

tion as an abstract interpreter. However,

there is a d e n o t a t i o n a l

"rule" w h i c h requires that the d e n o t a t i o n s of c o m p o u n d objects should depend only on the d e n o t a t i o n s of their components:

this rule leads

one to the c o n s t r u c t i o n of d e f i n i t i o n s w h i c h are much clearer and easier to r e a s o n about.

In fact the change from o p e r a t i o n a l to d e n o t a t i o n a l

style was further m a s k e d by a p r e s e r v a t i o n of an overall Vienna

"flay-

our". This flavour comes from the choice of a p p r o p r i a t e a b s t r a c t i o n s for source and semantic objects and a w r i t i n g style which aims at readability rather than conciseness.

The m e t a - l a n g u a g e a c t u a l l y adopted portions of PL/I

("Meta-IV")

is used to define major

(as given in ECMA 74 - i n t e r e s t i n g l y a "formal" stand-

ards d o c u m e n t w r i t t e n as an a b s t r a c t interpreter)

in Beki{ 74. The pro-

ject w e n t on to c o n s i d e r how this d e f i n i t i o n would be used to c o n s t r u c t a compiler. An i n d i c a t i o n of the interface p r o b l e m w h i c h results from

XII

using a typical "product oriented"

front-end,

is shown in W e i s s e n b S c k

75. A concern is often expressed as to how one can check that a formal d e f i n i t i o n captures one's intuitive notion of a language. latter is inherently informal,

Since the

the short answer is that one can not

so do. But certain c o n s i s t e n c y conditions can be established and this is the subject of Izbicki 75. A l t h o u g h the project was not pursued to the stage of a running compiler,

the overall m e t h o d used is described

in Jones 76a.

Again the m e t a - l a n g u a g e d e v e l o p e d for the FDM phase has b e e n used by a number of other groups. The only s i g n i f i c a n t IBM p u b l i c a t i o n is Hansal 76 which is interesting b e c a u s e it addresses the p r o b l e m of relational data bases. Externally,

Nilsson 76 and m a n y w o r k i n g d o c u m e n t s of the

Technical U n i v e r s i t y of Denmark have used "Meta-IV"

(see also BjCrner

775).

There are still a number of open issues. The p r o b l e m of d e f i n i n g arbitrary m e r g i n g and/or p a r a l l e l i s m was tackled in Bekic 74 but the technique used has not yet b e e n d e f i n e d in a s a t i s f a c t o r i l y

"Mathematical"

way - see Bekic 71 and Milner 73. A n o t h e r area of future r e s e a r c h is o u t l i n e d in Mosses 77. In the general view of m a k i n g d e f i n i t i o n s m o r e abstract,

the rSle of the e n v i r o n m e n t is questioned

in Jones 70.

On the D e f i n i t i o n of PL/I

Beki{ 74 contains a d e f i n i t i o n of most of the non-I/O parts of PL/I as described in ECMA 74.

(Some of the input-output statements w e r e

d e f i n e d by W. Pachl, but the w o r k is not published). The A L G O L 60 definition in this v o l u m e

(Henhapl 78) has b e n e f i t e d

from that work and

exhibits m a n y of the f o r m u l a t i o n s u s e d earlier. There are, unfortunately, minor notational d i f f e r e n c e s

to be faced in reading the earlier

work. The significant differences,

however, d e r i v e from the extra

"richness" of PL/I and the main aspects of the r e l e v a n t formulations are reviewed here.

(Again, this section should be skipped at first

reading).

As m e n t i o n e d above, some attempt was m a d e in Beki6 74 to cover the p r o b l e m of arbitrary order.

In p a r t i c u l a r the order of access to vari-

ables a n y w h e r e w i t h i n expressions is not constrained. tor was introduced to tackle

this problem.

The "," combina-

Xlll

Because PL/I offers a larger set of ways of b u i l d i n g aggregates than is a v a i l a b l e in A L G O L 60, a m o r e i m p l i c i t m o d e l of storage is used. Furthermore,

the normal way of g o v e r n i n g the lifetime of v a r i a b l e s in

A L G O L 60 becomes one of four ways a v a i l a b l e in PL/I: is called AUTOMATIC~ ly to STATIC;

this normal way

the "own" variables of A L G O L 60 c o r r e s p o n d rough-

in addition PL/I offers BASED and DEFINED storage classes.

With BASED variables explicit a l l o c a t i o n statements m u s t be executed and there is no automatic freeing. There are a number of e x p r e s s i o n s involved such as references to pointer variables and the m a i n interest is in showing when, tions

(see below)

in w h a t environment and w i t h w h a t e x c e p t i o n condi-

these various expressions are evaluated.

As well as p a r a m e t e r s of type ENTRY

(i.e. procedure)

permits v a r i a b l e s of t h e s e types. Furthermore, cally constrained,

and LABEL,

PL/I

their use is not stati-

as is the case in A L G O L 68, to p r e v e n t a t t e m p t e d

access to entities local to a block after the lifetime of that block. Therefore,

the p r o b l e m of c h e c k i n g for "past activations" had to be

tackled in the PL/I definition.

Perhaps the most i n t e r e s t i n g e x t e n s i o n is the use of "ON conditions" and "condition

built-in-functions/pseudo-variables".

ca be m o d e l l e d as a s s i g n m e n t s to ENTRY variables namically,

not lexicographically,

ing a c o n d i t i o n

(whether SIGNALled

ON statements

(notice they are dy-

inherited). The effect of encounteror i m p l i c i t l y raised)

can be model-

led by a call of the p r o c e d u r e w h i c h is c u r r e n t l y a s s i g n e d to the app r o p r i a t e variable. The p s e u d o - v a r i a b l e s used for i n v e s t i g a t i n g and returning values from these p r o c e d u r e s b e h a v e like global variables.

For further d e t a i l s on the PL/I model, "annotation"

the reader is r e f e r r e d to the

section of Beki6 74.

The S t r u c t u r e of this Volume The papers of this volume can be grouped in four cateHories. (I) The first paper:

On the F o r m a l i z a t i o n of P r o g r a m m i n g Languages: Main Approaches

Early History

&

XIV

by Peter Lucas sets the stage. It discusses the main approaches to language definition, the intrinsic aspects of the problem area and their origins. As such the paper provides a frame for the remainder of the volume.

(II) The next two papers:

Programming in the Meta-Language: A Tutorial

by Dines Bj~rner, and:

The Meta-Language: A Reference Manual

by Cliff B. Jones give complementary descriptions of the meta-language. The tutorial is a partly informal introduction to, partly comprehensive primer for, the meta-language. The reference manual gives precise semantics definitions of the more important meta-language constructs. The tutorial is primarily aimed at persons new to formal definitions, but with some background in (ALGOL-like) programming. The reference manual, in contrast, is primarily aimed at people, familiar with the basic ideas of denotational semantics, who wishes to understand the meta-language. Comprehension of the tutorial is otherwise a sufficient prerequisite for any other paper of this volume. The tutorial describes constructs not formally covered by the reference manual. Any such construct can, however, be simply reduced to simple combinations of constructs formally covered by the reference manual. It is in this sense we say that the language described in the tutorial is 'larger' than that defined by the reference manual.

(III) The fourth paper:

Denotational Semantics of Goto: An Exit Formulation and its Relation to Continuations by Cliff B. Jones, brings focus on a major factor distinguishing the Oxford, Scott-Strachey, School of expressing Denotational Semantics, from the current Vienna School. As such the paper contributes to a deeper understanding of the VDM meta-language by analyzing one of its combinators, the exit construct.

XV

(IV) The last group of papers exhibits actual abstractions:

A Formal Definition of ALGOL 60 as Described in the 1975 Modified Report by Wolfgang Henhapl & Cliff B. Jones presents the latest in a number of ALGOL 60 definitions.

Over its only 32 pages of text and formulae

it demonstrates, we believe,

the power of the abstractional techniques

used, and the meta-language tool described earlier, by giving a very readable and neat denotational semantics definition. The last paper of the volume: Software Abstraction Principles:

Tutorial Examples of an Operating

System Command Language Specification and a PL/l-like On-Condition Language Definition. by Dines Bj~rner summarizes a number of complementing & contrasting abstract modeling techniques. The first example is chosen to indicate the applicability of the software abstraction ideas to other than conventional programming languages; t h e second

in order to illustrate

various state modeling techniques & also the unusual On-Condition Lan= guage construct. The volume ends with a unified bibliography recording the referred to in the various papers.

literature

ACKNOWLEDGH~ENTS The editors of this volume gratefully acknowledge the Computer Science Department of The Technical University of Denmark and the European Systems Research Institute of the IBM Corporation for their kind support, enabling us to prepare this volume. The editors are especially happy to thank the co-authors: Wolfgang Hanhapl & Peter Lucas,

for their much appreciated contributions.

These latter actually stretches back over the many years the authors were members of the IBM Vienna Laboratory. To all of our colleagues, some of them still there, goes our most sincerely felt appreciation for the seemingly never-ending source of inspiration they represent. Very special, deep

and fond thanks goes to Prof. Heinz Zemanek for

having created such unique working environments;

and to Dr. Hans Beki~

for his unwavering high standards which kept us straight. Finally all co-authors

join the editors in expressing their indebtness

for the expert and untiring assistance of Mrs. Annie Rasmussen and Mrs. Jytte S#llested.

Dines Bj#rner

&

Cliff B. Jones

Montpellier, January,

France 1978

ON THE FORMALIZATION OF PROGRAMMING LANGUAGES: EARLY HISTORY AND MAIN APPROACHES

Peter

Luca8

Abstract: The paper discusses the nature of the subject, and summarizes its origins. interrelationships

The main approaches and their

are discussed.

The author's view

on the long and short range objectives is presented.

CONTENTS

1.

On the Significance of the Area

2.

Historical Background

3.

Basic Methodological Approaches

I0

3.1

Abstract Syntax

i0

3.2

Mathematical Semantics

Ii

3.3

Operational Semantics

15

3.4

Axiomatic Approach

18

4.

Challenges

21-23

1. ON THE S I G N I F I C A N C E OF THE A R E A

C o m p u t e r systems can be viewed as m a c h i n e s capable of i n t e r p r e t i n g languages;

they accept and u n d e r s t a n d d e c l a r a t i v e sentences,

p e r a t i v e sentences and answer questions,

obey im-

all w i t h i n the f r a m e w o r k of

t h o s e languages for w h i c h the systems w e r e built. A computer system a c c o m p l i s h e s its tasks on the basis of a p r e s c r i p t i o n of these tasks, i.e. o n the basis of a p r o g r a m e x p r e s s e d in some p r o g r a m m i n g language.

There is no i n h e r e n t d i s p a r i t y b e t w e e n h u m a n languages

(including na-

tural l a n g u a g e and the a r t i f i c i a l languages of science)

and languages

used to talk to computers. Thus there is no need to a p o l o g i z e for "ant h r o p o m o r p h i s m s " i n the above point of view;

in fact our only way to

talk s c i e n t i f i c a l l y about the r e l a t i o n of humans guages is in terms of c o m p u t e r notions

to

their natural lan-

(or so it seems to me).

By v i e w i n g c o m p u t e r s as l a n g u a g e i n t e r p r e t i n g m a c h i n e s it becomes quite a p p a r e n t that the analysis of p r o g r a m m i n g

(and human)

languages is

bound to be a central theme of C o m p u t e r Science.

Part of the f a s c i n a t i o n

of the subject is of course related

timate c o n n e c t i o n to h u m a n language,

to its in-

i.e. the m e c h a n i s m s we study mirror

in some way at least part of our own internal m e c h a n i s m s .

A l t h o u g h there is no i n h e r e n t d i s p a r i t y b e t w e e n h u m a n language and computer language,

there is at p r e s e n t a h u g e gap b e t w e e n w h a t we c a n

a c h i e v e by h u m a n c o n v e r s a t i o n and our c o m m u n i c a t i o n w i t h m a c h i n e s . A little further a n a l y s i s [ w i l l

i n d i c a t e the nature of the gap.

F i r s t we c o n s i d e r the s t r u c t u r a l aspect of language, are c o m p o s e d of w o r d s and sentences called

i.eo how phrases

~ r e b u i l t f r o m phrases,

commmonly

"syntax". T h e r e are e f f i c i e n t and p r e c i s e m e t h o d s Go define the

syntax of a l a n g u a g e and a l g o r i t h m s £o compose and d e c o m p o s e sentences a c c o r d i n g to such d e f i n i t i o n s . The p r o b l e m is m o r e or less solved. Yes, computer

l a n g u a g e u s u a l l y h a v e a simpler and more regular syntax than

natural languages

(as even some s c i e n t i f i c notations)

t e c h n i c a l p r o b l e m s yet to be solved. Yet,

and there are

it seems to me, there is not

m u c h of a gap.

Second,

there is the a s p e c t of meaning, or ,semantics" as it is u s u a l l y

called. Now we get into m o r e subtle problems. Let me r e s t r i c t the d i s cussion,

for the time being,

to the objects we can talk about in the

v a r i o u s l a n g u a g e s ( r a ~ h e r than c o n s i d e r i n g w h a t we can say about them). P r o g r a m m i n g languages in the strict sense talk i n v a r i a b l y about rather a b s t r a c t objects such as numbers, truth-values, the like. Certainly,

the major p r o g r a m m i n g languages in use do not let

us talk a b o u t tables, chairs or people, sions of numbers such as: hours, guages

do not

scientific

c h a r a c t e r strings and

not even about p h y s i c a l d i m e n -

pounds or feet. The c o m m e r c i a l lan-

know about the d i s t i n c t i o n of dollars and francs,

languages

and

do n o t know about time and space. There have been

some attempts to include those notions or a d e v i c e that makes it possible to d e f i n e these notions w i t h i n a language,

e.g. the class con-

cept in SIMULA and PASCAL and the i n v e s t i g a t i o n s around a b s t r a c t data types. If we extend the n o t i o n of p r o g r a m m i n g l a n g u a g e to include query languages and d a t a b a s e languages we may o b s e r v e a t e n d e n c y in the ind i c a t e d direction.

Yet, there is a gap. A r t i f i c i a l I n t e l l i g e n c e has

e x p e r i m e n t e d for some time w i t h languages that can be used to talk about objects other than numbers etc.; we should p r o b a b l y look a lot more freq u e n t l y accross the fence.

D e f i n i t i o n methods c o n c e r n i n g semantic, and even m o r e so, m e c h a n i c a l ways to u s e semantic d e f i n i t i o n s

are m u c h less u n d e r s t o o d than in the case

of the syntactic aspect.

Thirdly,

there is the aspect of l a n g u a g e understanding;

call this "pragmatics" since the latter term

I h e s i t a t e to

has b e e n used for too

m a n y things. S u p p o s e I ride on a train w i t h a friend. The friend observes:

"The

windows are wet "l) . The s t a t e m e n t is p r e s u m a b l y s t r u c t u r e d a c c o r d i n g to the english grammar and has a certain meaning. However,

I would

p r o b a b l y not just analyze the s e n t e n c e and d e t e r m i n e its meaning,

and

leave it at that. M o s t likely I w o u l d react by looking at a window,

ob-

serve that there are d r o p s , C o n c l u d e that it is raining, p r e p a r e my umbrella so that I d o n ' t get wet and ruin my

coat

w h e n I get off the

train, etc.,. To d r a w all these c o n c l u s i o n s and act a c c o r d i n g l y I need

(i) It w o u l d not m a k e any d i f f e r e n c e to the f o l l o w i n g a r g u m e n t if my learned friend had used M E T A - I V a n d p a s s e d a note saying: "wet (windows)". T h a t is to say, I do not discuss the d i s t i n c t i o n between natural language and standard (forma~ n o t a t i o n but the dist i n c t i o n of the h u m a n and c o m p u t e r use of the statement irrespective of the form.

to use a lot of k n o w l e d g e my specific

environment.

about the physical world

in general

It is in this area of l a n g u a g e

and about

understanding,

where I see the bigger gap b e t w e e n our interaction with the computer as opposed

to humans.

What is lacking in the machine are models of the

external world and general mechanisms actions.

Again A r t i f i c i a l

to draw conclusions

Intelligence

have been concerned with the problem. tical influence on e.g. commercial

and natural Yet,

and trigger

language research

this has not had any prac-

applications.

With the increase

in computer power it m i g h t very well be worth looking over the fence.

With the p r e c e d i n g paragraphs

I w a n t e d to put the present subject into

a much larger context than is usual. gramming

languages

than procedures,

Thank God, there is more to proassignment

The rest of the paper is a lot less ambitious within the traditional my subjective

tives.

(or no gotos).

and remains more or less languages.

It presents

perception of the various origins of the methods

mantic definitions. rized.

concepts of programming

and goto's

Each of the three m a i n approaches

The paper concludes

by outlining

of se-

are then summa-

some more short range objec-

2. H I S T O R I C A L B A C K G R O U N D

The theory of p r o g r a m m i n g languages, techniques in particular, other d i s c i p l i n e s

the related formal d e f i n i t i o n

has roots in - and is related to - several

such as linguistics,

matical disciplines.

In fact,

formal logic and certain mathe-

the terms "syntax" and "semantics" and

with these terms the d i s t i n c t i o n b e t w e e n the r e s p e c t i v e aspects of language, have b e e n introduced by the a m e r i c a n p h i l o s o p h e r ris [ Morris

Charles Mor-

38~ Zemanek 66 ]. He d e v e l o p e d a science of signs w h i c h

he called semiotics.

Semiotics,

to three d i s t i n c t fields: book on Signs, Language,

a c c o r d i n g to Morris,

syntax,

semantics,

and B e h a v i o r

"pragmatics - deals with the origin,

is subdivided in-

and pragmatics.

In his

[Morris 55] Morris defines:

uses and effects of signs w i t h i n

the b e h a v i o r in w h i c h they occur;

semantics - d e a l s with the s i g n i f i c a t i o n of signs in all modes of signifying;

syntax - deals w i t h the c o m b i n a t i o n of signs w i t h o u t regard for their specific s i g n i f i c a t i o n s or their r e l a t i o n to the b e h a v i e u r in w h i c h they occur."

The clear d i s t i n c i t o n b e t w e e n syntax and semantics,

first applied to

a p r o g r a m m i n g language in the A L G O L 60 report [Naur 63], has turned out to be t r e m e n d o u s l y useful. There have been several not so successful attempts to carry the notion of p r a g m a t i c s g r a m m i n g languages

into the theory of pro-

(see e.g. San Dimas C o n f e r e n c e [ACM 65]). We may

start the h i s t o r y of formal d e f i n i t i o n methods

for p r o g r a m m i n g languages

w i t h the year 1959 w h e n J. Backus p r o p o s e d a scheme for the syntactic d e f i n i t i o n of ALGOL 60 [Backus 59]. This scheme was then a c t u a l l y u s e d in the ALGOL 60 report; known as BNF

(a g e n e r a t i v e grammar) the related n o t a t i o n is

(for Backus N o r m a l F o r m or Backus Naur Form). BNF, or

v a r i a t i o n s thereof, h a v e b e e n used in m a n y instances;

it has stimulated

theoretical r e s e a r c h as well as p r a c t i c a l schemes for c o m p i l e r production

(both automatic and non-automatic).

Roughly speaking,

BNF grammars

c o i n c i d e w i t h the class of context free grammars of C h o m s k y [Chomsky 59]; it is w o r t h m e n t i o n i n g that C h o m s k y divides his g r a m m a t i c a l formalisms in an attempt to obtain a basis for the syntax of the E n g l i s h language. M u c h r e s e a r c h has b e e n devoted to the study of subtypes and extended sire

to

defined;

types capture

of BNF grammars; more syntactic

the former,

i.e.

the

the

latter in support

properties

of

the de-

of the language to be

study of subtypes is u s u a l l y m o t i v a t e d

by the wish to guarantee properties which permit fast syntax recognition and analysis algorithms.

The subject of formal syntax definition,

and the related computational problems and methods, way into textbooks and computer science curricula;

have found their in fact, the larger

part of compiler writing courses is usually spent on syntax problems. At least since the ALGOL 60 report,

the lack of rigorous definition

methods for the semantics of programming languages was widely recognized; furthermore,

the success of formal syntax definitions invited si-

milar attempts for the semantic aspects of programming languages, yet, the problem turned out to be of an obstinate nature. To date, there is no satisfactory solution,

at least none that enjoys the consensus of

the computing community.

The instructions of machine languages are defined by the behaviour of the respective machine upon execution of these instructions. ciated manuals usually describe first what constitutes the specific machine

The asso-

the state of

(e.g. content of main storage, content of regis-

ters, etc.) and then for each instruction and any given state the successor state after execution of the instruction to be defined. Hence, for a programmer,

the most direct way to define a programming language

is in terms of an interpreting machine; only that, for higher level languages, we must abstract from particularities of hardware machines and inplementation details and use a suitable hypothetical machine instead. E.W. Dijkstra formulated the situation in 1962 follows:

"A machine defines

(by its very structure)

its input language; conversely,

[Dijkstra 62] as

a language, viz.

the semantic definition of a !angauge

specifies a machine that understands it "l) .

The classic paper that has triggered a large volume of follow-on work is by McCarthy of computation;

[McCarthy 63]. The paper outlines a basis for a theory more important for our subject, it establishes the main

goals and motivation: methods to achieve correctness of programs in general and of compilers

in particular;

rigorous language definitions

constitute a subgoal. The schema for language definitions proposed by McCarthy contains a number of novel subjects. Firstly,

a complete se-

(1)it would be unfair to include this quotation and not say that Prof. E.W. Dijkstra would probably no longer defend this position, and rather tend to be a proponent of the direction described under "Axiomatic Approach" in this paper.

paration of notational issues, i.e~ the representation of phrases by linear character strings,

from the definition of the essential syntac-

tic structure of a language. The latter definition is called Abstract Syntax. It is, at least for complicated languages, much more concise than the concrete syntax. Thus, a semantic definition on the basis of an abstract syntax becomes independent of notational details and is also more concise. Secondly,

state vectors are introduced as the bases of

the semantic definitions proper,

i.e. the meaning of an instruction or

sta£ement is defined as a state transition.

The paper shows in princi-

ple the task of proving compilers correct. The basic scheme of language definitions has been elaborated in many instances during the past decade, e.g. by the earlier work of the Vienna Laboratory on PL/I [Lucas 69] and the proposed ECMA-ANSI standard

[ECMA 74].

Another successful direction of research was initiated by P. Landin [Landin 64~65], using the lambda-calculus [Church 41] as the fundamental basis. He revealed that certain concepts of ALGOL 60 (and similar languages)

can be viewed as syntactic variations

lambda-calculus.

(syntactic sugar) of the

The inherently imperative concepts,

assignment and

transfer of control, were captured by introducing new primitives the lambda-calculus; SECD machine,

into

the extended base is defined by the so-called

a hypothetical machine whose state consists of 4 compo-

nents: Storage, Environment,

Control and Dump. The machine state has

more structure than the state vectors of McCarthy, because the machine had to reflect more complicated concepts

(blocks, local names)

than

McCarthy's original simple example was intended to. In 1964

[Strachey 66]

C. Strachey argued that, with the introduction

of a few basic concepts,

it was possible to describe even the impera-

tive parts of a programming language in terms of the lambda-calculus. With the referenced paper, C. Strachey initiated a development that led to an explication of programming languages known as mathematical or denotational

semantics.

The fundamental mathematical basis for the lat-

ter development was contributed by D. Scott in 1970 [Scott 70]. The joint paper, by D. Scott and C. Strachey

[Scott 71] offers a descrip-

tion method and its application to essential language concepts based upon the indicated research. Research on axiom systems and proof theory suitable as a base for correctness proofs of programs was initiated by R. Floyd a simple flow diagram language. C.A.R. Hoare

[Floyd 67], with

[Hoare 69,71], extended

and refined the results to apply to constructs of higher level languages.

The area has been £he most actively pursued,

including expreriments

in

automatic program verification. There are several pioneering research efforts, which do not so evidently fall into the categories

introduced above. Among the very early re-

sults on semantics published is A. van Wijngaarden's [van Wijngaarden 62].De Bakker

"Generalized ALGOL"

[de Bakker 69] discovered that the schema

proposed by A. van Wijngaarden can be viewed as a generalized Markov Algorithm. A. Carraciolo

Forin6

66] also used Markov Algorithms

as the starting point for the formalization of programming language semantics.

For anyone familiar with syntax directed compilers

it is tempting to

apply similar ideas to the definition of semantics. A definition method on this basis is due to D. Knuth: Semantics of Context Free Languages

[Knuth 68]. In some way or another, a formal definition of the

semantics of a language invariably specifies a relation between any phrase of the language and some mathematical

object called the deno-

tation of the phrase. D. Knuth provides a convenient scheme that allows the specification of functions over the phrases of a language assuming that the phrase structure of the language is given by a production system.

Most research so far has been devoted to the definition and analysis of existing languages

(or concepts found in existing languages).

Yet,

formal semantics could be a most valuable intellectual tool for the design of novel programming concepts ming language constructs). of formal semantics

(e.g.

(or synonymously:

novel program-

There are rare instances of such applications [Dennis 75, Henderson 75]).

10

~- BASIC M E T H O D O L O G I C A L A P P R O A C H E S 3.1 A b s t r a c t ~

The notion of abtract syntax is of c o n s i d e r a b l e value for p r a c t i c a l d e f i n i t i o n s of n o t a t i o n a l l y c o m p l i c a t e d languages. T h e r e exist several m e t h o d o l o g i c a l variations, w h i c h all achieve the same objective:

to

a b s t r a c t from s e m a n t i c a l l y i r r e l e v a n t n o t a t i o n a l detail and reduce the syntax to d e f i n e the essence of the linguistic forms only.

For i l l u s t r a t i o n consider the f o l l o w i n g examples.

Let v be the catego-

ry of v a r i a b l e s and e be the c a t e g o r y of expressions.

Several notatio-

nal v a r i a n t s are in use to d e n o t e a s s i g n m e n t statements e.g.:

U = e V :=

e

e ~ V The s e m a n t i c a l l y essential structure common to these notations T h a t there is a syntactic c a t e g o r y called a s s i g n m e n t statement, that an a s s i g n m e n t s t a t e m e n t has two components,

is: and

a v a r i a b l e and an ex-

pression.

A n a b s t r a c t syntax may d e f i n e an e x p r e s s i o n to be either an e l e m e n t a r y expression

(variable, constant,

ing of an operator,

etc.,)

a first operand,

or a b i n a r y o p e r a t i o n consist-

and a second operand

(the defini-

tion of e x p r e s s i o n s may have several other alternatives);

operands are

again expressions.

As a c o n c r e t e syntax, m e a n t to d e f i n e c h a r a c t e r strings, nition w o u l d be h o p e l e s s l y i n s u f f i c i e n t and ambiguous, not know w h e t h e r to parse

x+y~z

into:

+

/\ y

or: / z

x

%~z

y

such a defi-

e.g. we w o u l d

11

Thus the concrete

syntax has to introduce p u n c t u a t i o n marks

such as

parentheses,

in the example of expressions,

rules of

operators

and,

to avoid ambiguities.

However,

the d e f i n i t i o n

given above is p e r f e c t l y usable as an abstract It can be regarded as a d e f i n i t i o n ty p r o b l e m is c o m p l e t e l y

avoided.

are suppressed

of expressions

syntax definition.

of parsing trees,

hence the ambigui-

Thus there are advantages

even in the case where only one language nal details

precedence

is considered:

gained

representatio-

and each phrase is given a kind of normal

form.

For practical cases,

such as PL/I,

the number of rules necessary

to de-

fine an abstract syntax is much smaller than for the c o r r e s p o n d i n g concrete

syntax;

hence we have obtained

semantic definition. formalization

a more concise basis

The price we pay is an additional

of a language, which establishes

for the

part for the

the relation b e t w e e n

the concrete and the a b s t r a c t syntax.

3.2 M a t h e m a t i c a l

The semantics

Semantics

of a given language

able m a t h e m a t i c a l language;

object

is formalized by associating

(set, function,

etc.) w i t h each p h r a s e of the

the phrase is said to denote the associated

ject is called the d e n o t a t i o n view w h i c h is r e f e r e n t i a l l y denotations

the d e n o t a t i o n s

transparent,

semantics

objects,

object;

Furthermore,

the ob-

to gain a

of the language to be defined,

shall be defined solely in terms of

of the subphrases.

the m a t h e m a t i c a l mathematical

of the phrase.

of composite phrases

a suit-

The major p r o b l e m in establishing

for a given language

is to find suitable

that can serve as the denotations.

Using the notation introduced by D. Scott and C. Strachey we will write I[p] for the d e n o t a t i o n ses to be discussed, notation,

e.g.

of a phrase pl). To indicate

the various phra-

we will use an ALGOL like and otherwise obvious

I[x:=x-l] is the d e n o t a t i o n of the assignment statement

x:=x-1.

(i) for small better to For larger here would

examples, like those introduced in this paper, it is abstain from using abstract syntax and M E T A - I V functions. examples (e.g. PL/I), the notational conventions used lead to c o n s i d e r a b l e difficulties.

12

The further gramming

elaboration

language

first a simple (e) w i t h o u t

side effects,

we wo u l d c e r t a i n l y we do not wish

a fixed

introduce

a state v e c t o r

(usually)

partial

ways

of pro-

Take

expressions

and c o m p o u n d interpreter,

(~ i~ McCarthy).

Although

the effect of exe-

to c h a r a c t e r i z e

we i n t r o d u c e

the

state v e c t o r s

names ID into

from v a r i a b l e

VAL, w h i c h a v a r i a b l e may assume,

the set of values,

(id),

(id:=e)

to compute

Therefore

functions

a series

a definitional

we still have

e f f e c t of this execution.

a, w h i c h are

statements

to c o n s t r u c t

and their parts,

go through

order of complexity.

set of v a r i a b l e s

assignments

If we w e r e

to specify p a r t i c u l a r

cuting programs overall

in i n c r e a s i n g

l a n g u a g e with

(81;82).

statements

of the subject will

concepts

i.e.

a: ID ~ VAL. L e t ~ be the set of all p o s s i b l e occur

in the e x a m p l e

l[e] : ~ ~ I[st] i.e.

language

that

signment

and c o m p o u n d semantics

I[id:=e](e)

statements

statement

:

=

from states

are functions

elsewhere,

according

into val-

from states

the d e f i n i t i o n

to the p h i l o s o p h y

to states.

of as-

of m a t h e -

assign{s,id, I[e](a))

of i m m e d i a t e counter.

... functional

of c o m p o s i t e subphrases

phrases

are given

composition

in terms of deno-

and that w e have a v o i d e d

For each a d d i t i o n a l

to revise

the d e f i n i t i o n

of states,

notations

or even d e s i g n

new k i n d s

As a first c o m p l i c a t i o n

for x=id a'(x) = r ~val <~(x) for x~id

assign(~,id, val) = ~',

l[s~].l[sl]

that d e n o t a t i o n s

a statement

while

that

read:

where:

I[81;s2]

are functions

I[e] has b e e n d e f i n e d

Assuming

tations

of d e n o t a t i o n s

: Z ~ Z

the d e n o t a t i o n s of e x p r e s s i o n s

matical

The kinds

VA5

ues and the d e n o t a t i o n s o f

Note

states.

can now be c h o s e n as follows:

language

introduce

new ways

of m a t h e m a t i c a l

we i n t r o d u c e

to c o m p o s e

de-

objects.

a loop s t a t e m e n t

e do s, say. We assume that e returns

introducing

feature we m a y have

of the form:

a truth v a l u e

and intui-

13

tively expect that the d e n o t a t i o n of the loop s t a t e m e n t can be d e f i n e d as:

I[while

e do s](~))

=

g~

~IEwhile

--

s](I[~](~))

[o

the d e f i n i t i o n is of the form f=F(f),

Evidently,

if

I[e](~)

if~

I[e](~)

with f=I[while

e do s],

i.e. f is d e f i n e d as the fixed point of F. Before this d e f i n i t i o n can be a c c e p t e d as m e a n i n g f u l ,

one has to ask w h e t h e r such a fixed point

always exists and w h e t h e r

it is unique: The e x i s t e n c e can be a s s e r t e d

under a p p r o p r i a t e m a t h e m a t i c a l r e s t r i c t i o n s m o n o t o n i c i t y and continuity);

(introducing c o n c e p t s of

there will in general be m o r e than one

fixed point s a t i s f y i n g the equation.

Thus an a d d i t i o n a l rule has to be

i n t r o d u c e d w h i c h makes the defined o b j e c t unique

(the "smallest"

point under a s u i t a b l y d e f i n e d o r d e r i n g relation).

fixed

This is not the

place to e l a b o r a t e the issue at length and the reader m u s t be r e f e r r e d to the r e s p e c t i v e literature.

However,

it should by now be e v i d e n t that we are led into d e e p m a t h e m a -

tical issues,

and this at a stage where,

from a p r o g r a m m i n g language

p o i n t of view, we have only i n t r o d u c e d the m o s t p r i m i t i v e l a n g u a g e constructs. At this point,

it seems that we have to c o n t e m p l a t e the poten-

tial uses of a semantic definition.

The author suggests to d i s t i n g u i s h

b e t w e e n the f o u n d a t i o n of the s u b j e c t m a t t e r and m o r e p r a c t i c a l problems like the d e s c r i p t i o n of r e a l - l i f e p r o g r a m m i n g languages for comp i l e r writers.

L i k e the f o u n d a t i o n s of m a t h e m a t i c s on the one hand and

applied m a t h e m a t i c s on the other, but are distinct.

these two fields are not u n r e l a t e d

If we accept the p r o g r a m of m a t h e m a t i c a l

semantics,

the steps we have tried to i n d i c a t e follow, and the d i f f i c u l t i e s observed above are inevitable. On the other hand,

it seems u n r e a l i s t i c

and in fact u n n e c e s s a r y to r e q u i r e that each c o m p i l e r w r i t e r be fluent in m o d e r n algebra. Rather,

one w o u l d expec~ that the f o u n d a t i o n s are

used to justify, once and for all, u s e f u l p r a c t i c a l m e t h o d s w h i c h in turn can be a p p l i e d d i r e c t l y by the p r a c t i t i o n e r

(not e v e r y b o d y who

a p p l i e s F o u r i e r A n a l y s i s need to be a s p e c i a l i s t in the foundations of mathematics).

Next we i n t r o d u c e e x p r e s s i o n s w i t h side effect,

i.e. e v a l u a t i o n of an

e x p r e s s i o n r e t u r n s a v a l u e and changes the state. C o n s e q u e n t l y , we change the type of o b j e c t an e x p r e s s i o n denotes to:

I[e]

:

~

~ Z

VAL

14

The d e f i n i t i o n A further

of a s s i g n m e n t

important

local names,

i.e.

concept

and

loops are to be c h a n g e d

in m o s t p r o g r a m m i n g

names w h i c h are d e c l a r e d

scope of a program.

The s y n t a c t i c

category

Since the same name may now be used we have to i n t r o d u c e

ables us to d i s t i n g u i s h troduces

an a u x i l i a r y

tion from names locations;

is that of textual

is c a l l e d b l o c k

some d e v i c e

o b j e c t called

(variable

names

the state then maps

and takes

locations;

to i n t e r p r e t

ment which

enin-

env, w h i c h

into values.

is a func-

to so c a l l e d

Thus a state ~ is

w h e r e LOC is a set of p r i m i t i v e

the a u x i l i a r y

the names

types

which

One u s u a l l y

example)

env is of type env:ID~LOC.

object

m

a g i v e n p h r a s e we always have

associahes

The m a t h e m a t i c a l

for d i f f e r e n t

in the d e f i n i t i o n

environment,

location

of type o: LOC ~ V A L ,

blocks

uses of a name.

in the p r e s e n t

now a f u n c t i o n called

in d i f f e r e n t

the d i f f e r e n t

objects

In order

languages

for a specific

begin dal id; st en_~d.

the form:

purpo s e s

accordingly.

occurring

to have an e n v i r o n -

in the p h r a s e w i t h

of the d e n o t a t i o n s

locations.

h a v e to be revised:

N

I[e] i.e. forms

:

ENV ~ (~ ~ Z VAL)

I[e] w h e n applied

to an e n v i r o n m e n t

a state and returns

I[begin dcl id;s end]

The d e n o t a t i o n

a function which

: ENV ~ (~ ~ Z) of the other

of blocks,

constructs

the new construct,

I[begin dcl id;s end.](env)(~) = I[s](env')(~')

where

= ~loa

~ i~ x=loc s'(x) = [o(xY o t h e r w i s e

where:

The l a s t f e a t u r e s

loc is some

passing.

semantics

ENV ~ ((A1

is d e f i n e d

sir as:

I restrict to dom of ~

if x=id otherwise

loc6LOC not in dom of

should

it is of type:

are p r o c e d u r e

the d e n o t a t i o n

be? A c c o r d i n g

... Ah) ~ (~ -~ 2))

are d e s i g n e d

[env(x)

in this s e c t i o n

What

(in the s e n s e of A L G O L or PL/I) thematical

env'(x)

to be d i s c u s s e d

tions and p a r a m e t e r

trans-

a value.

The types of the d e n o t a t i o n s milarly.

yields

declara-

of a p r o c e d u r e

to the p h i l o s o p h y

of ma-

15

i.e. given arguments tifiers o c c u r r i n g state t r a n s i t i o n mit procedures

al,a~,...~an,

and env to interpret

in the procedure, function.

the procedure

Some higher

is usually considered

distinct

range to avoid the w e l l - k n o w n

for procedures

is

a

languages

a procedure

can

and value

The e s t a b l i s h m e n t the appropriate

major achievement

per-

the type of a function

from its range of arguments paradoxes.

free theory of functions which provides tations

in p a r t i c u l a r

In contrast,

iden

is simply a state to

level p r o g r a m m i n g

to be passed as arguments

be passed as an a r g u m e n t to itself.

the global

of a type

domain of deno-

of D. Scott

[Scott 70].

Apart from those language constructs which none of the methods has so far addressed, solution

there are several problems w h i c h have as yet no known

in the framework of m a t h e m a t i c a l

rallel and q u a s i - p a r a l l e l

execution

cution).

Condition h a n d l i n g

mulated,

however,

in PL/I;

in particular

unspecified

With parallel

processing,

to the intuitive

it seems referen-

cannot be achieved as long as denotations

of stage-

ments m e r e l y reflect the initial state / result state relation. are two sizable tion of ALGOL of PL/I

There

language d e f i n i t i o n s 60 [Mosses

pa-

order of exe-

labels and goto's have been for-

the models do not closely correspond

concept of the construct. tial t r a n s p a r e n c y

semantics;

(tasking,

in this style. Firstly,

74]. Secondly a recent d e f i n i t i o n

There

a definiof a subset

[Beki6 74].

is an exellent tutorial on the subject by J. Stoy

3.3 O p e r a t i o n a l

[Stoy 74].

Semantics

The semantics of a p r o g r a m m i n g

language can be defined via a hypothe-

tical machine which interprets

the programs

thods have been called term is, however,

"operational",

misleading,

or "constructive".

because the s p e c i f i c a t i o n

cal machines may contain n o n - c o n s t r u c t i v e implicit definitions terpreter"

and infinite objects.

elements,

such me-

The latter of hypotheti-

such as quantifiers,

The term "definitional

in-

is sometimes used instead of "hypothetical machine".

By machine we u n d e r s t a n d subsets

of that language;

thereof:

a structure consisting

of a set of states,

the initial states and the end states,

tion function and a function which maps programs into initial states;

a state transi-

and their input data

also usually not given explicitly,

be a function which takes end states as a r g e n t s

two

there should

and yields

that part of

16

T0"'[1-'' " ""

input

data

2"" " "'Tn

~

........

TO

... initial state

step

... state t r a n s i t i o n f u n c t i o n

Tn

... end state

• O,°..~T n ... c o m p u t a t i o n

an end state which is the result of the program.

Since m o s t higher

level languages are such that the p r o g r a m remains constant, not modified,

i.e. is

during its interpretation, one could s!so k e e p the pro-

g r a m s e p a r a t e and only include a s t a t e m e n t counter to the c u r r e n t l y e x e c u t e d s t a t e m e n t w i t h i n the state itself. The d e f i n i t i o n of the step function,

if p r o p e r l y done, will reflect the syntactic s t r u c t u r e of

the language, computation, computation, text means.

such that we cannot only relate an entire p r o g r a m to a but also subphrases of the p r o g r a m to sections of the i.e. we m a y ask w h a t a specific s u b p h r a s e in a given con-

In languages,

like e.g. PL/I, w h e r e the order of o p e r a t i o n s

is not e n t i r e l y fixed, the d e f i n i n g h y p o t h e t i c a l m a c h i n e is n o n - d e t e r i.e. the step

ministic,

function will,

in general, yield a set of pos-

sible s u c c e s s o r states and a p r o g r a m will thus be related to a set of computations.

To illustrate the d i f f e r e n c e s

(and similarities)

between mathematical

semantics and o p e r a t i o n a l methods c o n s i d e r the following example:

intermed values

J"""'0

states of hyp~ m a c h i n e

envl,~ I

<...,[envl],el>

env2,G 2

[~nv~l <...,LenVlJ,a2>

beyin dc I x;

@

Ix:=1; ""

@ .@

"~3

<...j

-"-

~3 >

<...J

_Jr_

,04>

end

@

env1,c 4

<...,[envl],O4 >

17

The example p r o g r a m p a r t is a b l o c k w i t h one d e c l a r a t i o n and a c o m p o u n d s t a t e m e n t as the e x e c u t a b l e part.

In order to e l a b o r a t e this p r o g r a m

part, given a m a t h e m a t i c a l definition, we w o u l d have to compute the i n t e r m e d i a t e states and e n v i r o n m e n t s

shown in column one of the above

table. The s e q u e n c e of i n t e r m e d i a t e values a l m o s t r e p r e s e n t s the comp u t a i o n of a h y p o t h e t i c a l machine. of a m a c h i n e requires

The p r e v i o u s l y i n t r o d u c e d c o n c e p t

that each state of a c o m p u t a t i o n only depends

upon its immediate p r e d e c e s s o r state. Consequently, the e n v i r o n m e n t a v a i l a b l e at point remembered,

in order to have

(5) of the c o m p u t a t i o n it has to be

i.e. c o n t a i n e d in the states

(2),

(3) and

(4). This is ac-

c o m p l i s h e d by an e n v i r o n m e n t stack as shown in the second column of the above table;

the stack is p a r t of the state of the h y p o t h e t i c a l

machine.

The example shows that the state has to be e x t e n d e d in order to get f r o m the m a t h e m a t i c a l semantics

to a c o r r e s p o n d i n g h y p o t h e t i c a l machine;

w e h a v e to c o n s t r u c t a "grand state" as it is sometimes called. At the same time the d i s c u s s e d step indicates how one could get from a l a n g u a g e definition,

in a s y s t e m a t i c fashion to the r e l a t e d implementation. More

precisely, w h a t remains to be done is to find a finite r e p r e s e n t a t i o n of the grand states in terms of data and storage s t r u c t u r e of the target m a c h i n e and the m a c h i n e code w h i c h simulates the given t r a n s f o r m a tion on the grand state.

In the r e l e v a n t l i t e r a t u r e there exist various examples r e l a t i n g language d e f i n i t i o n to i m p l e m e n t a i o n s

(e.g.

[McCarthy 67]). A c o m p r e h e n -

sive e l a b o r a t i o n of this subject would be of great tutorial and practical v a l u e and w o u l d in fact c o m p l e m e n t the e x i s t i n g m a t e r i a l on the subject of syntax d e f i n i t i o n and parsing, which, understood.

in contrast,

is w e l l

(Books on c o m p i l e r w r i t i n g have u s u a l l y a lot to say on

the s y n t a c t i c p a r t of the q u e s t i o n and very little on semantics, ject time o r g a n i z a t i o n and code generation.)

ob-

The step from the syntax

d e f i n i t i o n to the r e s p e c t i v e parser can be automatic. W e are far from that stage on the semantic side of the problem.

The m e t h o d has b e e n a p p l i e d to several large languages; p r o p o s e d E C M A / A N S I PL/I s t a n d a r d an o p e r a t i o n a l d e f i n i t i o n .

in fact the

[ECMA 74] has been f o r m u l a t e d u s i n g

The m e t h o d is the only one p r e s e n t l y known,

w h i c h is c a p a b l e of c o v e r i n g the c u r r e n t l y e x i s t i n g language constructs.

There is a tutorial on the s u b j e c t by A. O l l o n g r e n several summaries,

[Ollongren 75], and

e.g. an in d e p t h e v a l u a t i o n by J.C. R e y n o l d s

[Reynolds 72]

18

3.4 A x i o m a t i c A p p r o a c h

The e s s e n t i a l semantics of a p r o g r a m m i n g language is d e f i n e d by a collection of axioms and rules of inference, w h i c h permits the proof of p r o p e r t i e s of programs,

in p a r t i c u l a r that a given p r o g r a m is correct,

i.e. realizes a s p e c i f i e d i n p u t / o u t p u t relation. Of course, one can prove assertions about p r o g r a m s u s i n g either a m a t h e m a t i c a l or operational d e f i n i t i o n and o r d i n a r y m a t h e m a t i c a l reasoning.

In fact, the

axioms and rules of inference can be r e g a r d e d as theorems w i t h i n the framework of m a t h e m a t i c a l semantics.

However,

the o b j e c t i v e of the axiomatic m e t h o d is a fomal system w h i c h

permits to e s t a b l i s h proofs u s i n g the u n i n t e r p r e t e d p r o g r a m text only, i.e. w i t h o u t r e f e r r i n g to d e n o t a t i o n s of the p r o g r a m or p r o g r a m parts. W h e n e v e r we talk about d e n o t a t i o n s in this section,

then this is for

e x p l a n a t o r y p u r p o s e s and is not p a r t of the axiomatic system.

The p r o b l e m of c o r r e c t n e s s proofs of programs two subproblems;

is u s u a l l y split into

the first is c o n d i t i o n a l correctness,

i.e. c o r r e c t -

ness u n d e r the a s s u m p t i o n that the e x e c u t i o n of the p r o g r a m terminates, and secondly,

the t e r m i n a t i o n of the program.

Until further notice this

section deals w i t h c o n d i t i o n a l correctness.

To illustrate the a p p r o a c h we will refer to the s i m p l e s t language level of section 3.2, i.e. a fixed set of variables, c o m p o u n d statement.

a s s i g n m e n t s t a t e m e n t and

The n o t a t i o n and p a r t i c u l a r axioms of the example

are due to C.A.R. Hoare. The b a s i c new piece of n o t a t i o n are p r o p o s i tions of the form:

p1{~t}p2 w h e r e p7 and p2 are p r o p o s i t i o n s r e f e r r i n g to v a r i a b l e s of the program, and st is a statement. The intuitive m e a n i n g of the new form is: if pl is true b e f o r e the e x e c u t i o n of st and the e x e c u t i o n of st terminates, dition,

then p2 is true after the e x e c u t i o n of st.

p; is called precon-

p2 is the s o - c a l l e d p o s t c o n d i t i o n or consequence.

As e x a m p l e for axioms and rules of inference we take the a s s i g n m e n t

19

s t a t e m e n t and the c o m p o u n d statement. The a x i o m a x i o m schema)

for the a s s i g n m e n t s t a t e m e n t reads:

X

X

Pe{X:=e}p X

In fact,

(more p r e c i s e l y the

w h e r e Pe means: r e p l a c e all o c c u r e n c e s of x in p by ~.

,

Pe is the w e a k e s t p o s s i b l e p r e c o n d i t i o n given p and vice verX

sa g i v e n p~ as the p r e c o n d i t i o n p is the s t r o n g e s t p o s s i b l e consequence;

i.e. the schema captures all there is to k n o w about the assign-

m e n t statement. A s p e c i f i c instance of the schema w o u l d e.g. be:

O<x+1 {x:=x+l} O<x Note that in order to use the schema it is not n e c e s s a r y to refer to the d e n o t a t i o n of

"x:=x+l". The d e f i n i t i o n of the c o m p o u n d s t a t e m e n t

takes the form of a rule of i n f e r e n c e and reads:

IF P1{stl}p2 AND P2{st2}p3 THEN P1{stl;st2}P3 For a full language d e f i n i t i o n there w i l l in general be an a x i o m per p r i m i t i v e s t a t e m e n t and a rule of inference per c o m p o s i t e statement; in addition,

there are some g e n e r a l rules w h i c h have not been exem-

plified in this section.

The s t r u c t u r e of the proofs r e f l e c t s the s y n t a c t i c s t r u c t u r e of the p r o g r a m text, as one w o u l d hope.

There is a simple r e l a t i o n b e t w e e n the d i s c u s s e d a x i o m a t i c a p p r o a c h and a c o r r e s p o n d i n g d e f i n i t i o n ~ i~ m a t h e m a t i c a l semantics. As already m e n t i o n e d the axioms and rules of i n f e r e n c e can be interpreted as theorems w i t h i n m a t h e m a t i c a l semantics. p r o p o s i t i o n a l form,

In p a r t i c u l a r we i n t e r p r e t the new

p1{st}p2 as follows. A s s u m e for the m o m e n t that pl

and p2 are e x p r e s s i o n s that are also valid e x p r e s s i o n s m i n g language,

p1{st}p2

in the p r o g r a m -

d e n o t i n g truth values.

=

I[pl](a)

D I[p2](I[st](a))

for all ~ for w h i c h

I[8t] is defined, i.e. st terminates.

The v a r i o u s axioms and rules of i n f e r e n c e may now be r e w r i t t e n a c c o r d i n g to the above i n t e r p r e t a t i o n and p r o v e n w i t h r e s p e c t to the d e f i n i t i o n s of m a t h e m a t i c a l s e m a n t i c s

(see [Manna 72]).

20

Neither the generation of the proof nor solving the termination problem can be completely mechanical, able. However,

since both are in general undecid-

there is hope that for frequently occurring program

structures the problems can be solved effectively by algorithms.

Pro-

posals to solve the termination problem frequently rely on an indirect proof,

in particular on finding a quantity which decreases as the com-

putation proceeds,

but cannot decrease indefinitely.

The subject of axiomatic definitions and program verification has stimulated widespread research activities due to the intellectually pleasing content but also because of its potential economic value. The belief in the latter is based on the vision that, ultimately,

the extreme-

ly cost-intensive program testing and so-called program maintenance can be replaced by systematic program design and verification, possibly to some extent automated. There are many examples of correctness proofs of specific programs (see [London ~0]~ and several automated verification aids

(e.g.

[King

?5]). The existing examples are mostly small programs for more or less complicated mathematical problems.

Some of the algorithms published in

the respective section of the C A C M are certified by proofs. An attempt to axiomatize a full language, and Wirth

PASCAL, has been undertaken by Hoare

[Hoare 75] resulting in the definition of at least a large

subset. Intimately connected to axiom systems for programming languages is the issue of programming style and development methodology.

The essence

of structured programming is, in the light of the presented research, the recommendation to use only language constructs which have simple axioms

(this excludes e.g. the general form of gotos, although restrict-

ed forms may well lead to simple correctness arguments). As it turns out, the process of developing a program is intimately connected to the generation of the corresponding correctness proof. Thus we may expect guidance how to develop programs rather than merely learn how to prove ready made programs correct. Yet, there is an enormous gap between current programming practice and the complexity of the software being produced on the one hand, and the vision and capabilities of the systematic techniques described.

The

proper discussion of the dilemma needs a larger context than has been given in this section and will therefore be deferred to the next section.

21

4. CHALLENGES

In accordance with the intent of the entire paper, section excludes

topics considered

tion. With this r e s t r i c t i o n finition of p r o g r a m m i n g consequently,

in mind we may certainly

language

the d i s c u s s i o n

velopment

semantics

say that the de-

is not an end in itself;

of future directions

from the intended app{ications definition

the scope of this

to belong to the theory of computa-

cannot be isolated

of semantic definitions,

of real life languages,

i.e. precise

compiler development,

p r o g r a m de-

and language design.

There are two topics we want to clearly separate to avoid a frequent confusion:

Firstly,

isting p r o g r a m m i n g language

the semantic languages;

analysis

secondly,

and formal definition

the design of novel,

of ex-

useful

constructs.

Current programming

languages

provide the most c o m f o r t a b l e and the aim to c o n s t r u c t with k n o w n compiler

are a compromise

between the desire to

and elegant language for the human user

efficient implementations

technology.

Furthermore,

on given systems

the more intensely used

languages undergo an evolution over the years to support new system functions.

These

languages were not designed with the aim to make

formal correctness fortably

proofs easy nor were they designed

into the framework

w o u l d be a mistake

of m a t h e m a t i c a l

to fit most com-

semantics.

However,

it

to conclude that these languages are no longer

worth the attention of computer

science.

In view of the heavy invest-

ment by users as well as m a n u f a c t u r e r s it is not likely that the current programming

languages will change radically

the carriers of new programming current

languages.

definition semantic

uable

The initial m o t i v a t i o n

to achieve portability,

analysis

A comparative

of COBOL

in the near future.

of formal semantics,

is still valid;

[Strachey

75]. Finally, implementation

language).

level would be quite val-

there is no c o m p r e h e n s i v e techniques

precise

there is as yet no

(the most widely used programming

language study on the semantics

of the existing

Thus

style will be, at least for some time,

representation

related to formalized

seman-

tic concepts. Whereas

BNF, or slight variations

means to define a concrete syntax, sensus

thereof,

are widely accepted as a

there is no such w i d e s p r e a d

for any of the semantic d e s c r i p t i o n

schemes.

con-

22

Next I w i s h to offer a top d o w n a r g u m e n t to justify the m a j o r long range goals of the present subject.

Firstly, we can observe that over

the past two decades the speed and storage c a p a c i t y of computers have b e e n increased e x p o n e n t i a l l y roughly

at a rate of about 40 p e r c e n t a

year. This trend has been b a l a n c e d by a similar d e c r e a s e of cost per o p e r a t i o n and per storage unit of s y s t e m c o d e

(i.e. bit or byte).

(operating system, compilers,

n e n t i a l l y as well. However,

S i m i l a r l y the size

etc.) has i n c r e a s e d expo-

in this case no b a l a n c i n g trend of d e c r e a s -

ing cost per line of code can be observed.

Furthermore, we will not

only h a v e to m a s t e r greater q u a n t i t y but larger c o m p l e x i t y as well. We c o n c l u d e that software p r o d u c t i o n is or soon w i l l be the b o t t l e n e c k for the use of computers.

There are three general r e s e a r c h d i r e c t i o n s p r o m i s i n g to improve the situation:

i. A d v a n c e A u t o m a t i c P r o g r a m m i n g 2. Remove T e s t i n g in favor of ~ o r r e c t n e s s Proofs 3. A d v a n c e M o d u l a r P r o g r a m m i n g

By the first r e s e a r c h area we m e a n to e x t r a p o l a t e the d e v e l o p m e n t of h i g h e r level languages by i n t r o d u c i n g m o r e a b s t r a c t datatypes e.g. sets) and their a s s o c i a t e d operations,

(such as

relax r e s t r i c t i o n s

in cur-

rent languages and introduce m o r e p o w e r f u l control structures;

the in-

tent is, of course, short,

to a u t o m a t e part of the p r o d u c t i o n process;

in

follow the trends s u g g e s t e d under the term "very high level

language".

Topics one and two are i n t i m a t e l y connected. As J. Schwartz

[Schwartz 75] observes,

it is m u c h easier to prove the c o r r e c t n e s s on

an a b s t r a c t level rather than on the level of d e t a i l e d r e p r e s e n t a t i o n s . If the a b s t r a c t p r o g r a m can be compiled, completed,

the task of the p r o g r a m m e r is

p r o v i d e d the c o m p i l e r has b e e n p r o v e n as well. "Thus the step

from the a b s t r a c t a l g o r i t h m to its u l t i m a t e r e p r e s e n t a t i o n in m a c h i n e form is proven once and for all by a c o m p i l e r proof. The author believes that r e s e a r c h in c o r r e c t n e s s proof must t h e r e f o r e be i n v e s t i g a t e d h a n d in hand w i t h the d e v e l o p m e n t of v e r y high level languages. the a s s u m p t i o n that the level of p r o g r a m m i n g

Even under

languages can be raised,

c o r r e c t n e s s proofs w i l l r e m a i n s u f f i c i e n t l y c o m p l i c a t e d to w a r r a n t machine a s s i s t a n c e in the form of proof g e n e r a t o r s and checkers. A l t h o u g h the latter subject has b e e n c o n s i d e r a b l y a d v a n c e d over the last decade, it has not yet reached the stage of a p p l i c a b i l i t y in p r a c t i c a l p r o g r a m ming. Various subgoals m a y be envisaged,

e.g. c o n v e r s a t i o n a l systems

23

like EFFIGY

[King 75] w h i c h offer a c o m b i n a t i o n of g e n e r a l i z e d testing

hy symbolic e x e c u t i o n and some a s s i s t a n c e for g e n e r a t i n g proofs. A notorious p r o b l e m in d e s i g n i n g large pieces of software is m o d u l a r i ty. It is r a r e l y the case that e x i s t i n g m o d u l e s can be used to build new systems w i t h o u t m a j o r trimming, observes,

if at all. As J. Dennis

[Dennis 75]

the success of m o d u l a r p r o g r a m m i n g not only depends on how

m o d u l e s are written,

but also on the c h a r a c t e r i s t i c s of the linguistic

level at w h i c h these modules are expressed. This c o n j e c t u r e is supported by a d e t a i l e d analysis of some high level languages

in [Dennis 75].

Modules are u s u a l l y e x p r e s s e d by procedures,

subroutines or p r o g r a m s

(depending on the s p e c i f i c languages used).

In short, we have to look

for c o n s t r u c t s other than p r o c e d u r e s ways to compose p r o c e d u r e s

(etc.) and the r e l a t e d traditional

into larger units,

in order to achieve the

desired modularity.

After this detour we now r e t u r n to the subject proper and ask w h a t the r e l e v a n c e of formal semantics w i t h these issues is. Firstly,

axiomatic

semantics p r o v i d e s the proof theory for p r o g r a m c o r r e c t n e s s proofs, and thus is also the basis for the m e c h a n i c a l aids in this area.

It is

rather d i f f i c u l t to p r o p o s e useful axioms and rules of inference w i t h out h a v i n g an i n t e r p r e t e d s y s t e m first,

such as p r o v i d e d by a m a t h e m a -

tical or o p e r a t i o n a l system. However,

this is a c o n t r o v e r s i a l issue.

In search for new language c o n s t r u c t s

(such as a useful notion of mo-

dule),

formal semantics ought to p r o v i d e the framework for f o r m u l a t i n g

the p r o b l e m and for

stating

and j u s t i f y i n g solutions

[Straehey 73].

So far m o s t r e s e a r c h in formal semantics has b e e n c o n c e r n e d w i t h constructs as found in t r a d i t i o n a l

languages. Here is a piece of language,

w h a t does it mean, was the q u e s t i o n in the light of the d i s c u s s e d softw a r e problems.

We should start from the other end,

i.e. c o n s t r u c t novel

d e n o t a t i o n s and a s s o c i a t e a name after we are s a t i s f i e d w i t h their properties.

PROGRAMMING IN THE META-LANGUAGE: A TUTORIAL

Dines

Bj@rner

Abstract: This paper provides an informal introduction to the "art" of abstractly specifying software architectures using the VDM meta-language ~. A formal treatment of the semantics,

as well as a BNF-like concrete syntax,

of a large subset of the meta-language is given in [Jones 78a] following this paper.

colloquially known as: M E T A - I V

CONTENTS

Part I: Prelude

31

0. Introduction

32

Example 0

34

1. Overview of Meta-Language

43

i.i Abstract Data Types

43

1.2 Combinators:

44

Statements and Structured Expressions

1.3 Abstract Syntax

46

1.4 Logic

46

-- Quantified

Expressions

1.5 Descriptor Expressions

47 47

1.6 Undefined & Erroneous Situations

47

1.7 User-Defined Identifiers

48

1.8 Structure of Tutorial

50

Part II: Domains,

Objects & Operations

2. SETs

51 52

Example 1

52

2.1 Defining Domains of SET Objects

54

Example 2-3

54

2.2 Representing Instances of SET Objects 2.2.1 Explicit Enumeration The Empty Set

55 55 55

2.2.2 Implicit Enumeration

55

Examples

4-5-6

56

2.3 SET Operations

56

Example 7

58

2.4 S E T - o r i e n t e d

Combinators

Example 8 2.5 Further Examples

59 60

(9~10)

61,63

28

65

3. T U P L E s

Example ll

65

3.1 Defining Domains of T U P L E Objects

67

Example 12 3.2 Representing Instances of 2 U P L E Objects

67 68

3.2.1 Explicit Enumeration

68

The Empty Tuple

69

3.2.2 Implicit Enumeration -- Pt.l

69

Example 13

69

3.2.3 Element Ordering

70

3°2.4 Implicit Enumeration -- Pt.2

71

Examples

72

lh-15

3.3 T U P L E Operations Examples 16-17 3.4 T U P L E - o r i e n t e d Combinators Example 18

73 74 75 76 77

4. MAPs

Example 19

77

4.1 Defining Domains of M A P Objects

81

Example 20

81

Defining M A P Domains -- Cont'd.

82

Example 21

82

Defining M A P Domains -- Cont'd.

82

Example 22

83

Defining M A P Domains -- Term'd.

83

Example 23

83

4.2 Representing Instances of M A P Objects 4.2.1 Explicit Enumeration

84 84

The Empty Map

85

Example 24

85

4.2.2 Implicit Enumeration Example 25

86 87

4.2.3 A Note on Scopes

88

Example 26

88

4.3 M A P Operations

9O

Example 27

91

4.4 MAP-oriented Combinators Example 28

93 93

27

93

4.5 Further Examples Introductory Example Cont'd -- 29

93

Another Example -- 30

96

A Last Example -- 31

99 102

5. T R E E S

Examples

102

32-33

5.1 Defining Domains of T R E E Objects

104

Example 3h

105

5.1.1 Tree Constructor Axioms

105

Examples

106

35-36

5.2 Representing Instances of T R E E Objects

I08

5.3 T R E E Operations:

109

Selector Functions

Explicitly Defined Selector Function Names

109

Implicitly Defined Selector Function Names

ll0

Example

ii0

37

Non-Unique Selector Function Name Convention

!I0

Example 38

Iii 113

6. FUNCTIONs Examples

114

39-40

6.1 Defining Domains of F u n C T i o n

Objects

115 115

Example 41 6.2 Representing Instances of FunCtion Objects

116

Functional Abstraction

117

k-Expressions

ll8

Free- & Bound Variables -- Scope

121

Application

122

Definition vs. Application

123

The ¥ Operator

123 125

6.3 FunCTion Operations

125

Example 42

128

7. ABSTRACT SYNTAX Example 43

128

7.1 Domains of Abstract Objects

129

Syntactic & Semantic Domains

130

Domain Definitions

131

& Compositions

132

Definitions/Rules Compositions/Domain

Expressions

132

Domain Operators The Scope Delimiting

132

(...) Operator

134

Infix Operator Commutativity & Associativity

134

Examples

134

44-45-46

Semantics of the

I Operator

Constructing Disjoint Domains

135 136

28

7.2 A b s t r a c t Syntaxes & Rules

137 137,139

Context Constraint is-Function

137

Example ~T

138

S e m a n t i c s of A b s t r a c t S y n t a x e s

139

Example h8

140

7.3 A b s t r a c t S y n t a x - o r i e n t e d C o m b i n a t o r s The M c C a r t h y C o n d i t i o n a l Clause

141

The Cases C o n d i t i o n a l Clause

141 141

Example ~9

144

Part III C o m b i n a t o r s

145

8. V a r i a b l e s Example

141

145

50

8.1 D e c l a r a t i o n s & The State Example

148

8.2 V a r i a b l e R e f e r e n c e s

148

Prelude

149

8.3 A s s i g n m e n t Example

146 147

51

149

52

152

8.4 D e r i v e d R e f e r e n c e s S u b - R e f e r e n c e s to TUPLE E l e m e n t s

153

S u b - R e f e r e n c e s to MAP Range E l e m e n t s

153

S u b - R e f e r e n c e s to Sub-"TREE"s

154

Discussion

154 155

9. S t r u c t u r e d Clauses

155

9.1 O v e r v i e w C o n d i t i o n a l Clauses

155

Iterative Clauses

156 156

Examples -- 53 9.2 D e t a i l e d Syntax & S e m a n t i c s 9.2.1 If-then-else

Conditional

Schema

157 157 157

Meaning

157

P r o g r a m m i n g Notes

157

9.2.2 M c C a r t h y C o n d i t i o n a l

158

Schema

158

Meaning

159

P r o g r a m m i n g Note

159

9.2.3 The Cases Conditional

160

Schema

160

Programming Note

160

Meaning

161

Name Binding & Scope

161

Example

5h

163

Abstract Syntax

163

Semantic Functions 9.2.4 The Ordered,

164

Iterative For-To-Do Statement

165

Schema

165

Programming Note

165

The Controlled Variable

165

Name Binding & Scope

165

Meaning

165

Example

55

166

Further Examples 9.2.5 The Unordered,

56-57

168

For-All & Parallel Statements

The For-All Statement

169 169

Schema

169

The Controlled Variable

169

Name Binding & Scope

169

Meaning

170

The Parallel Statement Schema Meaning Examples

170 170 170

58-59

170

9.2.6 The While-Do Statement

171

Schema

171

Programming Note

172

Meaning

172

Examples:

172-173

Example 60

172

Example 61

173

i0. Blocks

174

Reference to Block Examples

174

The Block Concept

175

10.1 let Constructs The Syntactic The Semantic

176 let Construct

let Construct

176 176

let Construct Variants

176

Composite Object let Decompositions

177

Simultaneous & Recursive Notational Conventions

let Definitions

178 179

30

10.2 Pure & Impure E x p r e s s i o n s

181

10.4 C o m p o u n d S t a t e m e n t s & S t a t e m e n t Sequences

182

10.5 S t a t e m e n t - & E x p r e s s i o n Blocks

182

10.6 Return

183 184

ii. EXITs

184

Example 62 ii.i The EXIT M e c h a n i s m s

187

11.2 P r a g m a t i c s & S e m a n t i c s of the EXIT M e c h a n i s m

189

Scope Rules

190

Some E q u i v a l e n c e T r a n s f o r m a t i o n s

191

11.3 Examples:

Part IV:

180

10.3 The ";" C o m b i n a t o r

No. 63

192

No. 64

194

Abstract Models

12. F u n c t i o n D e f i n i t i o n s & A b s t r a c t Models

197

198

Example

198

12.1 The Syntax of F u n c t i o n D e f i n i t i o n s

198

Example 65

199

Example 66

200

SchSnfinckeling/Currying Formal Examples Formal P a r a m e t e r Syntactic T r a n s f o r m a t i o n s

201 201 202

12.2 The Semantics of F u n c t i o n D e f i n i t i o n s

Part V:

- & Abstract Models

203

Scope & Binding

203

General

203

Examples

203

A Note on I n p u t / O u t p u t

204

204

Miscellaneae Data Types

205

13.1 Rational NUMbers

206

13. E L E M e n t a r y

P r o g r a m m i n g Note: Numbers & N u m e r a l s 13.2 B 0 0 L e a n s

& Logic E x p r e s s i o n s

207 207

Predicate Expressions

207

Examples

208

Comments

208

31

13.3 QUOTations

209

Example 67

209

13.4 TOKENs

210

Example 68 P a r t VI:

211

Postlude

212

A n n o t a t e d Index to E x a m p l e s

PART

213-217

I: PRELUDE

Section 0 frames the subjectr

and gives an e x t e n s i v e l y a n n o t a t e d exam=

ple. This example illustrates m a n y of the i m p o r t a n t aspects of the me= ta-language.

The p a r t i c u l a r a b s t r a c t i o n choices made are, however,

c o m m e n t e d upon,

not

nor e x p l i c i t l y singled out.

S e c t i o n 1 forms an o v e r v i e w of the various m e t a - l a n g u a g e constructs. A l t h o u g h this p r i m e r is a l m o s t 200 pages it transpires

from section i, is not

(long), the m e t a - l a n g u a g e ,

tions are c o n s i d e r e d so common, or simple, b e y o n d section i. We think here,

as

'big'~ C e r t a i n m e t a - l a n g u a g e no= that they are not treated

in p a r t i c u l a r on sections 1 . 5 - 1.7.

32

0. I N T R O D U C T I O N This tutorial teaches you the meta-language.

The primary aim is to ren-

der you fluent in the notation and its meaning, as a writer.

both as a reader and

That is: both as a user of software architectures

ly specified by other people,

self. The secondary aim is to make you use the m e t a - l a n g u a g e intentions, suitable plete,

abstract-

and as a producer of such documents

as per its

i.e. in good style. We wish that you be able to produce

software abstractions.

Thus we emphasize giving a rather com-

yet informal coverage of the syntax & semantics of the meta-lan-

guage. We refrain

however,

from presenting

tion to the kind of abstraction principles language

is especially designed

contains an extensive

a comprehensive

to facilitate

set of examples.

introduc-

and techniques which the metaand express.

The tutorial

A careful study of these is in-

tended to give you a rather complete o v e r v i e w of the fundamentals abstract modeling

-- as we see this activity.

The meta-language, lume,

one-

as already m e n t i o n e d

denotational

[Hansal 76, Nilsson

formal definitions

76],components

m a n d & (job) control applications

languages

oriented

plexes of software,

of relational

of operating

with many,

free-standing

according

systems

to

data base systems

These all exemplify, and intricate

will, however,

or imply,

facilities.

large com-

Individual

also illustrate

applications

functions .

cept); versus examples illustrating

in addition to

been applied

systems and their com-

The examples of this tutorial can be grouped according criteria:

se-

[Bj~rner 78a, Madsen 77], as well as more

software.

examples of this tutorial, to basic algorithmic

of other languages,

to this vo-

denotational

[Beki6 7h]. It has subsequently,

semantics definitions

similarly abstracted,

a readable,

of

[Bj~rner 78c].

in the introduction

evolved in the course of documenting

mantics of a PL/I subset

See also

examples

(illustrating

an isolated

strung together over several

software).

to the kind of systems

The latter can

to either of two software con-

sections

(furthermore)

software being abstracted.

(usually be grouped The follow-

ing is a reference guide to these: ~ Programming Language Constructs: Examples:

30-34,

36-38,

40, 42-43,

47,

49-62,

64-68.

(Most of these examples are mere transcriptions and annotations parts of the m i n i - l a n g u a g e

definition of appendix

III

.....................................................................................

s e e p a g e s 2 1 3 - 2 1 7 for a complete, a n n o t a t e d i n d e x to all examples.

of

[Jones 78a].)

33

File System Concepts Examples:

3-8, 12-13,

17-18,

(Operating or File System) Examples:

19, 29,

20-25,

27-28,

35.

Catalogues/Directories

63.

Usually major sections will start with a large example illustrating all the main notions introduced by the section. The examples interspersed in the text outlining the individual language constructs are usually far simpler than the more encompassing introductory example. Finally, many sections are trailed by yet additional, find difficulties

larger examples.

If you

in comprehending the introductory examples you may

wish to skip these intially.

If you find difficulty in understanding

the interspersed examples this tutorial will have failed:

(We mention,

in passing,

system architectures: cater for this

that no examples will be given of concurrent

the subject meta-language was not designed to

[sadly neglected]

of a rather formal,

area.) Finally some examples will be

or schematized nature;

notions, but paraphrasing principal,

not illustrating

or 'theoretical',

'practical'

aspects of the

meta-!anguage. We stress here, as was stressed in the introduction to this volume, the meta-language (on a computer),

that

is to be used, not for solving algorithmic problems but for specifying,

way, the architecture

(or models)

in an implementation-independent

of software.

Instead of using inform-

mal English mixed with technical jargon, we offer you a very-high-level 'programming'

language. We do not offer an interpreter or compiler for

this meta-language.

And we have absolutely no intention of ever wasting

our time trying to mechanize

this meta-language.

We wish, as we have

done in the past, and as we intend to continue doing in the future,

to

further develop the notation and to express notions in ways for which no mechanical interpreter system can ever be provided.

Given a terse

and readable abstract model of some software item, and as e.g. expressed in this meta-language,

we see it as the foremost and almost solely dis-

tinguishing task of programming to carefully turn the abstraction, stages of, at most semi-automated, lization.

development,

in

into an efficient rea-

Once such an implementation has been reached we let the entire,

possibly annotated,

documentation:

intermediate development stages,

the abstract model,

as well as all

serve as the only documentation of the

realized software. To give you a flavor of the meta-language,

but not really the kind of

software we primarily intend it aimed at, we now give you a rather comprehensive example.

34

We will p r e s e n t this example c o m p l e t e l y formally: model,

then the annotations.

first the a b s t r a c t

Other than these annotations, w h i c h repre-

sent a m e r e reading of the formulae, we do not here explain the formulae. Thus the example is b r o u g h t to give you,

from the v e r y start, a

capsule v i e w of core aspects of the m e t a - l a n g u a g e ; about w h a t a model is: its parts,

as well as an idea

their p u r p o s e and interrelations.

S e m a n t i c Domains

1

GROCER

::

SHELVES

2

SHELVES

=

Wno ~ N 1

3

STORE

=

Wno ~ N 1

4

CASH

=

NO

5

CATALOGUE

=

Who

6

Description

::

Price

7

Price

=

NI

8

Minimum

=

N1

9

Maximum

=

N1

10

Size

=

N1

STORE

CASH

CATALOGUE

~ Description Minimum

Maximum

Size

-- annotations:

The m o d e l is c o n c e r n e d w i t h rather s e l f - c o n t a i n e d fragments of a grocery: its inventory,

cash and c a t a l o g u e subsystem. The model d e s c r i b e s a

d o m a i n of such groceries and exemplifies a few of the m a n i p u l a t i o n s g r o c e r i e s are subject to: c u s t o m e r purchases,

that

and i n v e n t o r y / c a s h control.

The reader is, t h r o u g h o u t this primer, w e l l - a d v i c e d in reading the annotations w i t h a finger following the formulae and trying, otherwise,

to

e s t a b l i s h the connection~ A g r o c e r y is here s e l e c t i v e l y a b s t r a c t e d by a b s t r a c t i o n s of its shelves and store,

i.e. inventory,

its cash register,

and its

catalogue. The shelves display a finite, non-zero number of items of a finite v a r i e t y of merchandise. stracted by ware number codes.

M e r c h a n d i s e p r e s e n t l y being ab-

$5

In the s t o r e - r o o m is s i m i l a r l y kept a finite,

n o n - z e r o number

of b o x e d q u a n t i t i e s of items of a finite s e l e c t i o n of wares. The cash r e g i s t e r is simply a b s t r a c t e d by the c a s h it contains. The grocers'

c a t a l o g u e lists a d e s c r i p t i o n of each sort of m e r -

chandise. Such a d e s c r i p t i o n here consists of the unit the m i n i m u m and m a x i m u m

(lower- & upper-bound)

of the d e s c r i b e d m e r c h a n d i s e , p l a c e d on the shelves;

(item)

sales price;

numbers of items,

w h i c h ought, r e s p e c t i v e l y may be

and finally the size of a stored box,

m e a s u r e d in terms of the number of m e r c h a n d i s e Prices are m e a s u r e d in integer

items it contains°

(positive number)

units of cur-

rency. etc..

Comments

The a b o v e d e s c r i p t i o n formulae,

'read' the formulae as d e s c r i b i n g a grocery. The

in fact, defines a whole domain

The f o r m u l a e

(1-10), and

(abstract syntaxes).

(12-15) below,

Each line

(i, 2,

(i.e. class)

of such.

c o n s t i t u t e an a b s t r a c t syntax

..., i0) is an a b s t r a c t syntax

rule. The rules all have their l e f t - h a n d sides being identifiers.

The

r i g h t - h a n d sides are s o - c a l l e d d o m a i n - e x p r e s s i o n s .

The d e s c r i b e d d o m a i n s are said to c o n s t i t u t e the semantic domains.

Se-

m a n t i c domains are "whst the whole thing is about". S y n t a c t i c domains, d e s c r i b e d b e l o w in f o r m u l a e 12-14, are m a n i p u l a t i o n s of semantic objects.

(just the) objects w h i c h denote

36

Well-Formedness

Constraints

ii. 0 is-w f - G R O C E R (Ink-GROCER (she lves , store,

(dom store c dom shelves

.I .2

cash, c a t a l o g u e ) ) =

c domcatalogue)

^(Vwno 6 d o m c a t a l o g u e )

.3

(let m k - D e s c r i p t i o n ( p r i c e , m i n , max, s i z e ) =

.4

(0 < size < m a x - m ~ n )

inn

^((WHO 6 dom shelves)

.5

~(let items = shelves(who)

.6

((wno 6 dom store)

.7

-- a n n o t a t i o n s

~

< max),

items < max)))

:

The d o m a i n d e s c r i p t i o n s groceries,

in

~ (min < items

T

.8

captured

but the d e f i n e d

w h i c h do not satisfy

ii.0

catalogue(wno)

For a g r o c e r y register,

the essence

domains

natural

contain

of h o w we a b s t r a c t l y

objects,

i.e.

view

groceries,

constraints:

(which c o n s i s t s

and a catalogue)

of shelves,

a store room,

to be w e l l - f o r m e d ,

the cash

the f o l l o w i n g

con-

straints m u s t be satisfied: ll.l

There

cannot be m e r c h a n d i s e

displayed

on the shelves;

m u s t be d e s c r i b e d i1.2 11.3

look-up

the price,

minimum

for that w a r e

the box update ting If,

size.

& maximum

in the catalogue,

shelf-,

and box size quan-

than or equal

(in that order)

of shelves w i t h

in addition,

on the shelves

in the catalogue: to the minimum,

m u s t be lower

(This is a p r a g m a t i c

(min, max)

is not also

Furthermore:

described

N o w the m a x i m u m m u s t be h i g h e r their d i f f e r e n c e

11.5

and any m e r c h a n d i s e

in the catalogue.

For each type of m e r c h a n d i s e

tities i1.4

in the store room w h i c h

constraint.

the full c o n t e n t s

and

hhan or equal It p e r m i t s

of boxes,

to

the

without

viola-

constraints.) the ware

is also,

actually

displayed

on a shelf,

then: 11.6

Let us call the n u m b e r

of items of that ware

on the shelves

for

items. Now:

ii.

If the ware the

additionally

is further

stored

in the back room,

number of items on the shelves m u s t a c t u a l l y

fall b e t w e e n

then the

37

minimum, 11.8

lower and maximum,

there can be no m o r e

u p p e r bounds;

items on the shelves

otherwise than is m a x i m a l l y

per-

mitted.

Comment:

The i s - w f -

function

is d e f i n e d

class of all G R O C E R i e s .

the class of those objects any m a n i p u l a t i o n , shall

i.e.

Thus

tions

-- w h e t h e r

Syntactic

which

we shall u n d e r s t a n d

satisfy

grocery

the p r e d i c a t e

p a r t of the i n v a r i a n t

to some named domain,

the p r e d i c a t e

any t r a n s f o r m a t i o n

leave us a(nother)

constraint.

relative

In the f 6 1 1 o w i n g

according

also

(ii)

satisfying

on,

'program'

or c o n c r e t e

In fact, a grocery,

the w e l l - f o r m e d n e s s

is also seen as forming

to w h i c h we

on the abstract,

(ii).

of, or process

here the by G R O C E R

a major

our m a n i p u l a -

level.

Domains

12

Transaction

=

Purchase

13

Purchase

::

WhO +

14

Control

::

Wno-set

15

...

I Control

I

-- annotations:

The g r o c e r

sees a c u s t o m e r

b i l i t y of c e r t a i n wares, the grocery.

12

Syntactically

A transaction something

13

groups 14

a customer

A store c l e r k (for w h i c h

on

purchase,

a c l e r k control,

or

at the c h e c k - o u t

distinct

wares.

consists

inventory

counter

In this

of the same kind need not o c c u r

control

their

are o p e r a t i o n s

undefined:

is p r e s e n t e d

of not n e c e s s a r i l y

of items

These

speaking:

is either

purchase

his own d a i l y c h e c k on the availa-

as t r a n s a c t i o n s .

else - p r e s e n t l y

A customer sequence

purchase,

etc.,

together.

of a set of d i s t i n c t

amounts

are asked).

as a

sequence

ware

types

38

Comment:

Observe

that only

notions.

That

is: we have t o t a l l y

those of their

Dynamic

16.0

the last p a r e n t h e s i z e d

phrase

separated

above

syntactic

descriptions

from

Constraints

is-well-formed-purchase(purchase,

grocery)

=

(let mk-Purchase(wl)

= purchase

mk-GROCER(shelves,

2

, , )

= grocery

let m i n i - s h e l f = make-shelf(wl)([])

3

semantic

semantics.

Consistency

1

invoked

in

in

(dom m i n i - s h e l f c d o m s h e l v e s )

4

^(Vwno 6 d o m m i n i - s h e l f )

5

(mini-shelf(wno)

6

~ shelves(wno))

-- a n n o t a t i o n s :

The c u s t o m e r quantities

16.0

can select m e r c h a n d i s e

bounded

by w h a t

For the combination: we m u s t t h e r e f o r e

16.1 16.2

16.3

the ware

a purchase

require

list of w h i c h

the shelves

(from w h i c h given

codes

as do

and numbers

we

shelves, of

chase and c o m p u t e s

selected

The f u n c t i o n

let us c o m p u t e of times

satisfy

for each w a r e

it o c c u r s

it mini-shelf. a functional

(shelves, which

definition

That

the

takes

type,

in the purchase. shelves,

to an

is: m i n i - s h e l f

association

mini-shelf)

this association,

N o w to the c o n s t r a i n t s 16.4

and

in the way we a b s t r a c t e d

call

f u n c t i o n make-shelf,

shelf.

is m a d e up,

the w a r e s w e r e

the n u m b e r

o b j e c t of SHELVES~

The

to be consistent,

in lines 16.4-16.6.

Since this corresponds,

displays,

and in

that

those c o n s t r a i n t s

in the purchase,

and a g r o c e r y

the p u r c h a s e

constraints To express

only from the shelves,

is displayed:

b e t w e e n ware

items of that ware.

the w a r e - l i s t

of the pur-

is a c t i v a t e d w i t h an e m p t y

is g i v e n b e l o w

(17).

themselves:

The kind of w a r e s p u r c h a s e d m u s t subset of the m e r c h a n d i s e

form a

displayed

(not n e c e s s a r i l y

on the shelves.

proper)

39

And : 16.5

For each ware p u r c h a s e d the number

16.6

number

of items p u r c h a s e d

of w a r e s

m u s t be less than or equal

to the

of that kind on the shelves.

Comment

The a b s t r a c t i o n have hoped. function

given

is not as e l e g a n t

and t r a n s p a r e n t

somewhat

of a resort

as we w o u l d

of the make-shelf

Thus we find the i n t r o d u c t i o n

to an o p e r a t i o n a l

description

auxiliary of the con-

straint.

Auxiliary

17

Function

make-shelf(wl)(shelf)= /Zwl

= <>

then shelf 3

else

(let WhO = h d w l

4

let shelf'

in

= ((WHO 6 dom shelf)

5

shelf+[wno~(shelf(wno)+1)],

.6

T~ shelfU [wno~l])

.7

make-shelf(tl wl) (shelf')) type:

Wno+ ~

-- a n n o t a t i o n s

The f u n c t i o n shelf

~HELVES

takes,

as arguments,

clause

expresses

is a s o - c a l l e d

domain

cf.

It p e r f o r m s

line 17.7.

the list,

(shelf') 17.1 17.2

expression.

list separately:

its front,

or head,

till a n o t h e r

then

17.3-17.6. leaving

as result,

and a a SHELVES

The form a f t e r the type

function

is r e c u r s i v e l y

by t r e a t i n g

That

is: by

treatment (17.7),

of w a r e s

each

'chopping'

of the rest,

passing

item

i.e.

colon

defined,

(wno)

the a c c u m u l a t e d

ware

list

is the null

in

off the list tail,

it the shelves

of

object

Thus:

(tail of the)

as the result.

The

(or list)

and yields,

this.

its f u n c t i o n

recursion

so far computed.

If the

a tuple

of SHELVES)

an o b j e c t

The type

the w a r e

~ SHELVES )

:

(really:

object.

from

in

tup!e,

shelf c o m p u t e d up till now is d e l i v e r e d

40

17.3

Otherwise:

Let us call the first item of the r e m a i n i n g

ware

list

for wno. 17.4

spection 17.5

(being "tallied'9

Otherwise,

this

has already

Seman t i c

18.0 .i

occurred

in the ware

in-

list, of

so far purchased. is a first o c c u r r e n c e

and the shelf is a u g m e n t e d count

If the item u n d e r

shelf has one added to the number of items,

then the u p d a t e d the same kind,

17.6

the shelf so far computed.

A n d then u p d a t e

of this p a r t i c u l a r

by the i n i t i a l i z a t i o n

ware,

of its tally

to I.

Functions

Elab-Purchase(mk-Purchase(wl),

grocer)=

! Z wl = <>

.2

then grocer

.3

else

(let mk-GROCER(shs, sto, cash, cat)

= grocer,

mk-Description(p,min, max, s i z e ) =

.4

wno

.5

cat(h_ddwl), = hd wl

.6

let cash' = cash+p,

.7

(shs',sto')

in

=

(let items = shs(wno),

.8

stored=

.9

((WHO 6 dom sto) ~ T

.i0

sto(wno),

~ O) in

i_~ ((items=min)^(stored>O))

.ii

then

.12 .13

(shs + [wno~items-l+size],

.14

((stored=l) T

.15

~ sto~{wno}, ~ sto+[wno~stored-1]))

else

.16

(((items=l)

.17

T

.18

sto))

.19

Elab-Purchase

.20

~ shs~{wno ~ shs+[wno~items-1]),

in

(mk-Purchase(tlwl), mk-GROCER(shs',sto',cash',cat)))

.21 N

type:

Purchase

GROCER

GROCER

-- annotations: To p u r c h a s e

a ware

is to take a g r o c e r y

store and d e l i v e r

another.

In

41

the r e s u l t i n g g r o c e r y store the shelf c o u n t for the p u r c h a s e d ware (wno) is d i m i n i s h e d by 1 (18.13 & 18.18),

and if the shelf d i s p l a y

goes u n d e r m i n i m u m and there are supplies stored is r e p l e n i s h e d by size items

the p u r c h a s e price of the ware

The Purchase

Elaboration,

(18.11)

then the shelf

(18.13). To the cash r e g i s t e r is added (18.6).

as did the above a u x i l i a r y function, works

by u p d a t i n g the g r o c e r y store, once c o m p l e t e l y for each item in the purchase

(18.3-18.19). T h a t is:

18.1

If the p u r c h a s e has been c o m p l e t e l y serviced,

18.2

then the result is the

18.17

If the shelf d i s p l a y of the p u r c h a s e d ware would go to zero,

~input' grocery.

c o g n i z a n c e of this ware is d e l e t e d from the shelf. Likewise: 18.14

If by r e p l e n i s h i n g the shelves from the store the supplies go to zero,

this w a r e is deleted from the store room.

18.20

The rest of the p u r c h a s e is elaborated.

18.21

w i t h the u p d a t e d grocery.

19.0

Elab-Control(mk-Control(wno),grocer)= Tabulate(wno,grocer)([]) type: Control

GROCER

~

(WhO ~ N O )

-- a n n o t a t i o n s :

To control the g r o c e r y for the q u a n t i t i e s a v a i l a b l e of each of a g i v e n set of w a r e c a t e g o r i e s is to tabulate these,

starting w i t h an empty

table.

The tabulate f u n c t i o n is auxiliary.

The r e s u l t i n g table a s s o c i a t e s to

each ware c a t e g o r y the p o s s i b l y zero q u a n t i t y on hand, as well as in the supply.

on the shelves

42

Auxiliary

Function

Tabulate(wnos,grocer)(table)=

20.0 .1

~wnos={}

.2

then

table

.3

else

(let m k - G R O C E R ( s h s , sto,

.4

WhO 6 wnos let items

.5

,cat)

=((wno

6 dom shs)

~ shs(wno),

£ dom sto)

~ sto(wno),

T

.6 stored=

.7

((WHO

~ 0),

T

.8 size

.9

= grocer,

in

~ 0),

= s-Size(cat(whO))

.10

let sum

.ii

Tabulate(wnos~{wno},grocer)(tableU[wno~sum] t~:

Who-set

-- a n n o t a t i o n s

are

GROCER

:

left to the reader!

= items

~

+

in

(stored~size)

((Who ~ N O )

~

in

(Who ~ NO))

43

1. OVERVIEW OF META-LANGUAGE

In this section we briefly survey the meta-language.The

overview

of

sections 1.1-1.3 emphasizes only syntactic aspects. The aim of sections 1.1-1.3 is to give you a rather comprehensive feeling for the composition and extent of the meta-language.

1.1 Abstract Data Types The elementary data types

(except for booleans)

of the meta-language

are not fixed. For a suggestion of suitable base types we refer to section 13.

The composite,

very-high level abstraction-facilitating, data types are:

Sets: Domains:

A-set

ConstructOrs

{.o.}

Operations

U, N, \, ~_, c, E, card,

power,

=,

,

Tuples: Domains:

A*,

A +

Constructors:

<..~>

Operations:

hd,

Domains:

A~B

Constructors:

[ ..... ]

Operations:

domj

tl,

len,

ind,

elems, ~,

[.3, cone,

Maps: m

rng,

Functions: Domains:

A-~B~ A~B

Constructors:

~..~@o,.

Operations:

(.)

(.),

U, +, ~,

j

----,

=,

,

44

Trees:

The

Domains: Constructors:

mk-Aj

mk,

Operations:

s-Bi,

=,

'domains'

A

::

B I B 2 ...

Bn,

(C I C 2 ...

C n)

(...) %

lines above exemplify the expression of domains of objects

of the subject type. A, B, B~ and C i are given constructors hint at the following

(or defined)

domains.

typical object construction

The

expres-

sions:

(a 1, a 2, • . ., a n ), , [a l~b 1, a 2 ~ b 2, • . . , a n ~ b n],

representing

respectively

denoting expressions.

explicit

{ F(d)

I P(d)

},

< F(i)

f P(i)

^ m
[ F(o)

~ G(o)

I P(o)]

& implicit

>

set, tuple and map object

Also: hid. c l a u s e

abstracts

the meta-language

function of id that c l a u s e

mk-A(bl,b2,...,bn),

expression or statement c l a u s e

into the

is. Finally:

m k ( C l , C 2 ..... c n)

and ( C l , C 2 ..... a n )

denote trees.

1.2 Combinators:

Statements

and Structured Expressions

Declaration:

dcl

Va~

Assignment:

Va~

:= expr,

Identity:

I

Contents

expressions:

Conditional

Clauses:

:= e x p r

type

D,

(null statement)

c Vat i~

expr

then

clause I else

(expr I ~ c l a u s e 1 , expr 2 ~ clause2, . * °

e x p r n ~ c l a u s e n)

is the classical

McCarthy conditional

clause, with:

clause 2

4S

cases

eXPro:

(expr I ~ clausel, expr 2 ~ clause2, o . o

expr n ~ clause n) being

a variant

while

of the H o a r e / W i r t h

cases

clause.

expr do stmt,

for all id 6 set d~o stmt,

and:

for i = m to n do strut are the

(conventional)

semicolon

operator:

Statement-

iteration

(stmtl;

& expression

statements.

Compound

statements

use the

stmt2;... ; stmt n) -- w h e r e stmt are statements.

blocks m a y o c c u r

anywhere

a statement,

respec-

t i v e l y expression, m a y occur:

(let def = expr in clause), and:

(let def : expr;

illustrate kind,

clause)

the two b l o c k

forms:

the f o r m e r b a s i c a l l y

the latter of the imperative

Function

definitions

of the a p p l i c a t i v e

kind.

are written:

fid(idl,id2,...,idn)= clause type:

-- or in some such form. imperative ted,

D

D I D 2 ... D n The

and a p p l i c a t i v e

un-labelled

language

variants

has no gotos,

of a

exit m e c h a n i s m ~

(tra P exit(id)

with

F(id) in clause)

and:

(tixe with:

[ G(o) ~ F(o)

I P(o)

but p r o v i d e s

~hrase-structured,

] in clause)

both

block-orien-

46

exit,

exit(expr)

being the exit causing constructs.

1'.3 Abstract Abstract

Syntax

syntaxes are used in defining named domains of objects:

I B2

l ...

union

A0

=

B1

A1

=

B-set

i Bn

sets

A2

=

B~

tuples

A3

=

B+

tuples maps

A4

=

B~C

A 5

=

B~C

functions

A6

=

B~C

partial

A 7

::

BI

B2

...

trees

Bn

are typical rules. Objects,

functions

o, in the domains defined by some such rule

satisfy:

i s - A • {~ . o . .

z

l" 4 Logic Only one elementary data type is assumed:

BOOL

consisting

true,

of the two truth valued objects:

fa!s ~

to which the following

At Vt

non-commutative

operations

(and, or, implication)

as well as: (negation,

identity).

apply:

47

Quantified ExDressions

Predicates (I)

asserting truth properties:

(Vo 6 setJ(P(o))

(2)

(30 6 set)(P(o))

(3)

(3" o £ setJ(P(o))

read as follows:

(i) for all objects

[in the set] the predicate

(2) there exists an object

(P) holds.

[in the set] for which the predicate

(3) there exists a unique object

(P) holds.

[in the set] for which the predicate

(P)

holds.

1.5 Descripto ~ Expression

This subsection will be the only place in which the descriptor expression is treated.

(1o)(P(o)), i (iota)

(Ao)(P(o)j

and A (delta) are offered as alternate forms of representing

the descriptor operator.

The forms above denote

the unique object satisfying the predicate

(and read): (P).

1.6 Undefined & Erroneous Situations The form:

undefined is offered as a notation expressing some further unspecified undefined object. Applying operations outside their domain is (likewise) yield undefined results. The form:

Brror

Similarly for descriptor expressions.

said to

48

is o f f e r e d as a n o t a t i o n for stating situations for w h i c h there are no clear definitions.

In this primer we c o n s i s t e n t l y use undefined state) objects,

to denote u n d e f i n e d

use error to denote u n d e f i n e d state transitions, i m p e r a t i v e contexts. Thus we c o n s i d e r undefined

error,

(non-

i.e. in b a s i c a l l y a p p l i c a t i v e contexts. We c o n s i s t e n t l y i.e. in b a s i c a l l y to be an expression;

a statement:

1.7 U s e r - D e f i n e d Identifiers

The m e t a - l a n g u a g e sets no spelling standard for identifiers naming objects

(defined functions, variables,

parameters,

etc.) or d o m a i n s

(as

in a b s t r a c t syntaxes).

The following o u t l i n e s the c o n v e n t i o n s b a s i c a l l y followed in this primer.

Identifiers are either single Greek letters or sequences of one or m o r e R o m a n letters and A r a b i c digits.

I d e n t i f i e r s m i g h t contain p r o p e r infix

hyphens,

and p o s s i b l y be d e c o r a t e d w i t h

letters)

and/or single, double,

(simple)

triple . . . . .

subscripts

(superscript)

(digits and primes.

The choice between Greek letters and other i d e n t i f i e r forms is b a s i c a l l y g o v e r n e d by these informal,

(So-called)

e n u m e r a t i v e rules:

State D o m a i n

~, or

Names:

~, r e s p e c t i v e l y

State Object Names: (So-called)

Environment Domain

Names:

env, or p

E n v i r o n m e n t Object Names: (So-called)

Continuation Domain

ENV

Names

C o n t i n u a t i o n O b j e c t Names:

C 0

The c r i t e r i u m on w h e n to use upper and lower case letters is b a s i c a l l y this: (So-called)

Semantic D o m a i n Names:

S e q u e n c e s of one or u s u a l l y more U P P E R CASE LETTERS, p o s s i b l y trailed by a digit.

49

(So-called)

Syntactic Domain Names:

UPPER case letter followed by one or more lower case letters, possibly trailed by a digit. Object Names: Lower case counterparts of corresponding domain names, usually amounting to prefixes of such, and quite often decorated. Assignable Variable Names: -- in this primer usually written in tildes. When variable is global,

script and underlined with

first letter is upper case;

otherwise lower-case. Other conventions are: Function Names: Elaboration functions primarily applicable to objects of domain

Xyz have names: elab-Xyz

(for imperatively stated)

E-Xyz

for

int-Xyz

(for imperatively stated)

I-Xyz

for

respectively:

(applicatively expressed)

elaboration functions~

respectively:

(applicatively expressed)

interpretation func-

tions;

ev~l-Xyz

(for imperatively stated) respectively:

V-Xyz

for

(applicatively expressed)

evaluation functions.

(Elaboration is a term comprising both interpretation and evaluation. Interpretation implies elaboration of constructs basically for the sake of their side-effects.

EValuation implies elaboration of constructs

basically for the sake of values explicitly yielded.) Other Function Names: Let A be some domain name,

then

is-A, s-A, mk-A, is-wf-A, are reserved names,

mk-A in i.i. i8-wf-A

is-A was explained in section 1.3. 8-A and is to be the name for any static context

50

c o n d i t i o n p r e d i c a t e function a p p l i c a b l e to all A objects and y i e l d i n g true only for those A objects one a c t u a l l y intends the d e f i n i t i o n of A to cover!

s-A and mk-A m a y not a c t u a l l y

be defined by some a b s t r a c t syntax. The above r e s e r v a t i o n then intends to p r e v e n t confusion.

1.8 S t r u c t u r e of T u t o r i a l

The s t r u c t u r e of this p r i m e r is as follows.

In part II we cover data types:

sets, tuples, maps,

trees,

functions

and the notion of a b s t r a c t syntax. R e s p e c t i v e l y sections 2,3,4,5,6 & 7. The l a n g u a g e features covered enable

us to express domains, o b j e c t s

and p r i m i t i v e o p e r a t i o n s on these -- in p a r t i c u l a r o p e r a t o r / o p e r a n d expressions. E x a m p l e s of earlier sections will n e c e s s a r i l y e m p l o y m e t a l a n g u a g e notions only f o r m a l l y i n t r o d u c e d in later sections. as this is the case we rely on your g o o d - w i l l and patience, on our behalf,

however,

to keep such uses to a r e a s o n a b l e minimum.

In p a r t III we cover language c o n s t r u c t s such as variables: ration, ments;

a s s i g n m e n t and contents access; blocks,

Insofar attempting,

their decla-

structure e x p r e s s i o n s and state-

and the exit mechanism. W i t h these m e t a - l a n g u a g e f e a t u r e s

we are now able to express c o m p o s i t e transformations, c o m p o u n d processes,

on objects,

r e s p e c t i v e l y state

r e s p e c t i v e l y state variables.

The examp-

les of this part take on a flavor d i s t i n c t from that of the examples of part II. There the e x a m p l e s were e x p l i c i t l y tied to the i n d i v i d u a l subjects being covered. E x p l i c i t e x a m p l e s using the c o n s t r u c t s f o r m a l l y i n t r o d u c e d in part III are g i v e n a l r e a d y in part II. instead the examples of part III tend to be r a t h e r more comprehensive,

i l l u s t r a t i n g several

aspects of a b s t r a c t m o d e l i n g simultaneously.

In part IV we w r a p up the story on f u n c t i o n d e f i n i t i o n s and a b s t r a c t models. This part is not comprehensive.

It relies on the subject being already,

albeit p a r t i a l l y c o v e r e d in parts II & I I I .

Part V ties up loose ends

c o n c e r n i n g e l e m e n t a r y data types.

In a d d i t i o n to the above contents survey we advise the reader to carefully study the c o n t e n t s listing in order to a s c e r t a i n the logical s t r u c t u r e of this primer.

51

PART II

DOMAINS,

OBJECTS & OPERATIONS

Function definitions describe transformations on data objects. As such the defined functions apply to a domain of objects and yield objects of the range. The specific transformation is expressed, forms

(constructors)

in terms of

denoting objects, operators and structured com-

binators denoting operations on objects. The above paragraph serves the purpose of delineating the three cornerstones of this part: domains of objects,

the story on meta-language means of defining

representing constructed objects and operations on

objects. Most sections will be structured accordingly. basically three subsections. mains are defined, type-

These will have

One will outline and exemplify how do-

i.e. represented by means of so-called logical

(or, as we shall prefer to call them, domain)

expressions.

Another will outline and exemplify how instances of objects of the domain are constructed. expressions

Finally a third will outline and exemplify

formed around operators denoting operations on objects.

This last is split into two subsections:

one on primitive operations,

the other on combinators.

Each section dealing with a composite abstract data type will be introduced by

examples

whose purpose is to capture the essence

of the objects under discussion,

thus

motivating you right

into the

rather formally structured parts. And each section will be concluded with larger examples. In bringing examples we intend to illustrate basic principles of abstract modeling using the meta-language.

The examples take care to use

the meta-language in "good style".

[In this way you will also be introduced to representationalrational abstraction; in a few places,

& ope-

to applicative- & imperative programming;

to configurational-

and,

& hierarchical abstraction.]

52

2 SETs

The s i t u a t i o n w h i c h we w i s h to a b s t r a c t l y d e f i n e is p e r h a p s r a t h e r 'childish'.

We are g i v e n a set of classes,

set of students. t i o n code.

Let s t u d e n t s be a b s t r a c t e d by their s c h o o l r e g i s t r a -

Let the d o m a i n of all such codes be Student.

Class

is an abstract

=

b e i n g a set of to a domain,

l e f t - h a n d side is an identifier,

side is a domain

(distinct)

expression.

students.

It d e s c r i b e s

and

a c l a s s as

The e q u a t i o n g i v e s the name Class

and this d o m a i n is defined,

m a i n of f i n i t e

Then:

Student-set

syntax rule w h o s e

whose right-hand

by Student-set,

to be the do-

s u b s e t s of Student.

Let s u i t a b l y d e c o r a t e d classes,

each class c o n s i s t i n g of a

s's and o's d e n o t e r e s p e c t i v e l y s t u d e n t s and

i.e.:

is-Student(s) is-Class(e)

Now:

{sl,s~,.~.,s n} is a set c o n s t r u c t o r

expression.

TO test w h e t h e r a g i v e n student,

It d e n o t e s a class.

s, a t t e n d s a g i v e n class,

c, we write:

s£a -- w h i c h we read:

s is a m e m b e r of c. If s is not a m e m b e r of c, then

the e x p r e s s i o n is f a l s e, o t h e r w i s e

true.

t e s t s c l a s s r e c o r d i n g s for is-in-class

is-in-class(s,a) is a f u n c t i o n

definition.

c I and c2, we write:

If we c a l l the f u n c t i o n that

then:

= s £ c TO c o m p u t e the s t u d e n t s a t t e n d i n g two classes,

53

01

-- w h i c h dents

we

n

c2

read:

common

the

intersection

of

to b o t h c I a n d c2.. If n o

cI

and

students

02,

i.e. : t h e

attend

both

eI

set

of

and

stu-

c2,

then:

cI

their both

n

intersection is d e n o t e d

eI

-- w h i c h

we

diminished

is

read:

which the

we

the

the

might

departure

where

~

entry

of

a student,

number

of

card

--

for

and

the

students

of

aI

and

of

a student,

following

either

c I or

e 2 or

complement

to your

To

liking

of --

record

that

8, w e w r i t e :

{8}

students

c

cardinality.

c 2 . To

record

8, w e

that

a class,

c,

is

write:

c - {s}

- interchangeably,

is p r e f e r r e d .

0 u

The

as:

be more ~

union

or

read

notation

The

c2

c~{s}

-- w h i c h

empty.

by:

U

by

{)

c2 =

in a class

is:

s with the

set

although a class,

respect

to

{8},

c subtracted not 0,

in t h i s

or

{s}.

-We

use

primer,

is a u g m e n t e d

by

the

54

2.1 D e f i n i n g

Domains

of SET Objects

Let A be the name of a class of objects class of objects

which

sets of A), we use the

The d o m a i n w h o s e sets of INTG,

are finite domain

objects

expression

are finite

is d e f i n a b l e

i.e.

a domain.

sets of A objects operator

To define

(i.e.

the

finite

sub-

-set: A-set.

sets of integers,

i.e.

finite

sub-

as:

INTO-set

Call

this d o m a i n

IS.

Then:

IS = I N T O - s e t

is an a b s t r a c t

syntax

main whose objects sets of integers

are finite

is d e f i n a b l e

IS-set,

Let B r e p r e s e n t a file

system,

s y s t e m are, then:

rule f o r m a l l y

or:

defining

sets of

this name.

(potentially

Then

the do-

overlapping)

finite

as:

(INTG-set)-set

the d o m a i n w h o s e o b j e c t s is o t h e r w i s e

thought

or can be, unordered,

are a b s t r a c t i o n s

of as records.

finite

of what,

in

If files of such a

collections

of d i s t i n c t

records,

55

R-set is an a b s t r a c t i o n infinite nite

class,

sets.

of the class

is also

infinite

form R-set

The

The file system

system has no n o t i o n

are,

such a system.

however,

contrived.

Note

all fi-

will,

That

is: you

that at this stage the

files or k e y e d

sections

if R is an

expression.

seem a bit

of s e q u e n t i a l

in s u b s e q u e n t

The d o m a i n R-6et,

-- its o b j e c t s

is a d o m a i n

thus m o d e l e d m a y

m a y never w i s h to d e s i g n

when expanded

of files.

records.

however,

The examples,

appear m o r e

'rea-

listic'

2.2

Representing

Instances

2.2.1 E x p l i c i t

Enumeration

Given d i s t i n c t

objects

of SET O b j e c t s

al, a2,

...,

a

which

are all A objects,

the

n

expression:

{al,a2,...,a n} is said object

to be an e x p l i c i t

enumeration

of a set, w h i c h denotes

an

of A-set.

-- is d e n o t e d

by:

{}

2.2.2

Implicit Enumeration

Given

a function

arbitrary

F: D ~ A, w h e r e

domain);

{F(d)

D denotes

and a p r e d i c a t e

i P(d)}

some logical

type

(i.e.

F: D ~ B00L, the expression:

an

56

is said to be an implicit set enumeration, of A-set.

and then denotes an object

Since A could be any logical type e x p r e s s i o n the above de-

scribes how a r b i t r a r y sets may be represented.

The implicit set con-

structor e x p r e s s i o n can be read as: The set of o b j e c t s F(d) the p r e d i c a t e P(d)

~ ! ~

holds. Thus we read

I as

such that

'such that:

~-~-~:

The c o n s t r u c t o r expression:

{{1,s,s, 7,9},{~,~,11,~s,1~} ..... {} .

denotes an o b j e c t in (INTG-set)-set

. . .

{~.I,8}}

w h o s e e l e m e n t sets,

in this example,

are not disjoint.

Let r 1, r 2, ..., r n denote d i s t i n c t objects of R, i.e. be a b s t r a c t i o n s of records, then:

{rl,r2,...,rn } is

(an a b s t r a c t i o n of) a file, i.e. an o b j e c t in R-set.

Let Fr be a total f u n c t i o n from records into records,

type:

Fr:

i.e.:

R ~ R, and let f denote a file, e.g. the above, then:

{ Fr(r)

I rEf }

denotes a file d e r i v e d from f having each of the records of f p r o c e s s e d by

Fa •

2._~3 SE__~TOperations: The following special SET o p e r a t i o n s are defined:

57

U

union

N

intersection complement, proper

difference,

subtraction

(two forms provided)

subset

subset

power p o w e r s e t £ membership card

cardinality

union d i s t r i b u t e d

E a c h of these will

It is a s s u m e d

union

n o w be i n d i v i d u a l l y

b e l o w that

set,

set1,

and quite

set2 d e n o t e

informally

explained.

sets and setsets a set

of sets.

setIUset2

denotes

8etl,

8etlNset2

the set of those o b j e c t s

or in set2,

denotes

which

are either

in

or in both.

in setl

the set of o b j e c t s

which

are both

the set of objects

which

are in setl

and

set2.

setl~set2

denotes

but not in

set2.

8etlcs~t2

denotes

(the B O O L e a n

of 8etl

are in set2

set2 not in setl,

setlcset2

truth value) and there

(the B O O L e a n

of set1

are in setS,

power set

denotes

the set of all finite

obj6set

denotes

(the B O O L e a n

card set

denotes

the

if all m e m b e r s

is at least one m e m b e r

of

false.

otherwise

denotes

n o t e d by obj

true

truth value)

true

if all m e m b e r s

o t h e r w i s e false.

subsets

of set.

truth value) true

is a m e m b e r

(Natural)

if the o b j e c t de-

of set , o t h e r w i s e false.

number

of m e m b e r s

of set . Read as

cardinality.

union 8etsets

denotes

the set c o n s i s t i n g

sets b e i n g

elements

of all the objects

of setsets.

of all the

58

The set operations applied to a n y t h i n g other that sets are undefined.

Let f denote a file,

i.e. be in R-set;

let r and r. denote records Z

(i.e. both be in R). The o p e r a t o r - o p e r a n d e x p r e s s i o n s and constructs:

(i)

f u {r}

(2)

f ~ {r}

(3)

r E f

(4)

card f

(5)

(f~{r}) u {Fr(r)}

(6)

le t r i E f let r. £ f be 8.t.P(r)

(7)

Z

express typical set m a n i p u l a t i o n s .

These pure e x p r e s s i o n s could be

used to provide a m o d e l of the f o l l o w i n g typical o p e r a t i o n s on files: (i) w r i t i n g a (most likely new) record to a file; cord -- m o s t likely, but necessarily, file;

(2) d e l e t i n g a re-

c o n t a i n e d in a file -- from that

(3) asking w h e t h e r a given record is in a file;

the number of records in a file; new record,

(4) asking for

(5) u p d a t i n g a record in a file to a

i.e. r e p l a c i n g it -- w i t h the p o s s i b i l i t y that it m i g h t

not already be in the file, in w h i c h case

(i~5);

(6) reading an arbitra-

ry record from a file assumed not to be empty; and most a r b i t r a r y record,

(7) reading an al-

namely one further satisfying the p r o p e r t y ex-

pressed by the p r e d i c a t e function P.

Let fl and f2 denote files,

(8)

fl n f~

(9)

fl = f2

(10) (ii)

fl = f~ fl = f2

(12)

fl ~ f2

i.e. both be in R-set,

then:

59

m i g h t be r e a s o n a b l e a b s t r a c t i o n s of the following, tical, o p e r a t i o n s among files: cords c o m m o n to two files;

(8) collecting,

slightly hypothe-

into a file,

the re-

(9) asking w h e t h e r all records of one file

are c o n t a i n e d in another file;

(i0) -- and, in a d d i t i o n to

(9) --

asking w h e t h e r some records of the latter are not in the former; a s k i n g w h e t h e r two files are identical;

or

(ii)

(12) different!

The expression:

fl U f2

(13)

is a g e n e r a l i z a t i o n of file,

(1), in that {r} there denotes a s i n g l e t o n

i.e. a file of e x a c t l y one record.

the m e r g e of the records of two files. by

(13) can be u n d e r s t o o d as

The type Of the object denoted

(13) is a file.

2.4 SET-oriented

Combinators

The following c o m b i n a t o r s are a p p l i c a b l e to SET objects:

let obj £ Set let obj E Set be s.t.

P(obj)

w h i c h you have already seen a p p l i c a t i o n s of, and:

for all obj £

set d__ooS(obj)

The let clauses occur in e x p r e s s i o n - or s t a t e m e n t blocks:

(let obj £ Set ..~ in C (obj)) w h e r e C r e p r e s e n t s e i t h e r an e x p r e s s i o n or a statement. clause is a statement,

The for all

and so m u s t S be.

For the general m e a n i n g of let clauses we refer to s e c t i o n 10.1. The specific trary,

let clauses shown above bind the i d e n t i f i e r

obj to an arbi-

etc., m e m b e r of the set, or domain, Set, a n y w h e r e in C w h e r e

obj occurs free.

60

Note that Set in let clauses may either be an e x p r e s s i o n d e n o t i n g a finite set; or a d o m a i n - e x p r e s s i o n , In the for-all

p o t e n t i a l l y denoting infinite sets.

statement set m u s t however be r e s t r i c t e d to denote a

finite set, in particular:

the expression:

set m u s t not be a d o m a i n

expression. The m e a n i n g of the ~or-all clause is given here, but more systematically repeated in section 9.2.5. Let set denote the

finite set whose

idl,id 2 .... ,idn, w h e r e no i~. is

n objects we may a r b i t r a r i l y name: free in S(id); t h e n :

I/{S (id I),S (id 2), ... ,S (id n) } is a sufficient t r a n s l i t e r a t i o n of the for-all

statement into a quasi-

S(id), arises from S(obj) by r e p l a c i n g all free o c c u r r e n c e s of obj in S(obj) by id.

parallel

'compound'

statement,

each of whose statements,

For the m e a n i n g of compound statements rely on your intuition, it up in section

or look

10.4. Since the set element naming was a r b i t r a r y one

can permute the above statements arbitrarily.

The c o n s t r u c t o r expression:

{ Fr(r) I r£f } is an a p p l i c a t i v e e x p r e s s i o n -- p r o v i d e d Fa does not rely on any state component. An imperative analogue can be achieved by means of the

for-all statement: dcl ~

:= ~} type R-set

(Lot all r 6 f d__oo := e_ ii~ ~

U

{Fr(r)};

81

The above can be seen to be a process-oriented of a file manipulation system architecture.

abstraction of parts

The global v a r i a b l e ~

is initialized to the empty file, {}, of no records; contain only finite sets of distinct records denotes a constant reference,

ref R-set; with ~ rence,

and fixed to

(t~pe R-set). File now

to an R-set object,

i.e. an object in

denoting the dynamic contents at that refe-

i.e. value of the file variable.

2.5 Further Examples

To sharpen your understanding of set manipulations we now bring further examples.

The problem which we wish to abstractly define is that of recording equivalence classes. A set (e.g. sas) consisting of disjoint sets (e.g. asl, a82 ..... ash) of

(e.g. A) objects is said to define

which is the same, to 'realize') call the member sets

an equivalence relation.

(or,

In fact we

(aslj...) for equivalence classes. The set of

equivalence classes thus is a partitioning of the union of all the

(A) objects of the equivalence classes. Given one partitioning and an (A) object,

supposed to be a member of an equivalence class, we

wish to inquire whether it is indeed in some equivalence class of that partitioning.

(We call the predicate which tests for this isRecorded.)

As another subproblem we wish, given a partitioning and two 'recorded' ~A-) objects,

(al,a2) to generate a new partitioning as follows: If

the two A objects are recorded in the same equivalence class,

then

the result partitioning is the same as the argument partitioning. the two A objects are recorded in distinct equivalence classes,

If

then

the result partitioning is as the argument partitioning except for the collapse

(union) into one memberset of the two sets of which al

and a2 are respective members. generator function for enter).

(We call the new equivalence class

E@

=

B-set

B

=

A-set

EQ

=

(A-set)-set

i.e.:

is-wf-EQ(sas)= .i

(Vasl,as26sas)(as1~a82

= aslNas2={}) isRecorded(a, sas)=

isReaorded(a, sas)= (a £ union 8as)

.i

where

we gave

two versions

as £ sas)(a £ as)

of isRecorded.

enter((al,a2),sas)= {as

°i

J as68as

U ~ aslUas2

.2

^ {al,a2}Nas={}}

[ (aslEsasJ^(aIEasl)^(as26sas)^(a26as2)}

equiv((al,a2),sas)= (3as6sas)(alEa8

.i type:

i8-wf-EQ:

^ a26as)

EQ

isRecorded:

~

A

BOOL

EQ

~

BOOL

enter:

(A A) EQ

~

EQ

equiv:

(A A) EQ

~

BOOL

-- a n n o t a t i o n s :

i. EQ n a m e s a d o m a i n of o b j e c t s . with

the

latter

being

finite

These

are

finite

sets of A objects

sets of B objects, -- h e n c e

a n EQ o b j e c t

is a s e t o f s e t s of A o b j e c t s .

2. F o r

s u c h a set to b e a p a r t i t i o n i n g ,

intentions

of defining

the domain

8a8) m a y h a v e a n y A o b j e c t s membersets

must

3. F o r a n A o b j e c t ,

to b e w e l l - f o r m e d

in c o m m o n ;

or, w h i c h

as p e r

members

is t h e

same,

(of all

be d i s j o i n t .

a, to b e r e c o r d e d ,

is in s o m e m e m b e r s e t , which

i.e.

EQ, n o two d i s t i n c t

i.e.

it is a n e l e m e n t .

(3.3)

shall mean

that

there

that

the object

is a m e m b e r s e t ,

(a)

as, o f

the

4~ The two lines

(4.1 & 4.2) express w h a t was s t i p u l a t e d above:

sult p a r t i t i o n i n g

is as the a r g u m e n t p a r t i t i o n i n g s

the re-

(4.1), except

(4.2) -- etc.

The t~pe

clauses of the functions d e f i n e the set of the input arguments,

to the left of the arrows,

and those of the results,

to the right of the

arrows. The arrows express that the d e f i n e d functions are sibly p a r t i a l

(indeed)

(pos-

(3)) functions -- from the a r g u m e n t domains into the re-

sult domains.

As in the p r e v i o u s example, we deal w i t h objects:

S =

(A-set)-set

-- but now not subject to any restrictions.

To check w h e t h e r an S objects

sas, is a p a r t i t i o n i n g we apply:

isDeeomposed(sas) = (Vasl,as26sas)(as1~as2~slnas2=~}) type:

S ~ BOOL

To d e c o m p o s e an S object, fewest elements,

sas,

into the coarsest,

p a r t i o n i n g of sas,

i.e.

smallest,

we apply d e c o m p o s e ( s a s ) .

A p o s s i b l y i n c o m p l e t e d e f i n i t i o n of a c o a r s e s t p a r t i t i o n i n g , set, sas, of p o t e n t i a l l y o v e r l a p p i n g sets, goes as follows: the result of d e c o m p o s e ( s a s ) . m e m b e r - s e t s of 8a8, only-if

for i 6 { l : n } ,

For all al and a2

{asl,a82,...,asn}

iff a2 is in all asi

(for i £ { l : n } ) ;

be

that are m e m b e r s of

of sas,

if-and-

al is in all asi,

and only such a's are

in m e m b e r - s e t s of 8a8' w h i c h are s i m i l a r l y in sas, u n i o n 8~8 t

given a

Let sas'

al and a2 are in the same m e m b e r - s e t of sas'

(iff) for any subset,

having

i.e.: u n i o n 8a8 =

64

Sometimes a picture is w o r t h quite a few words:

TO the left is some 8a8

8as':

({X,V,Z}),

to the right is its c o r r e s p o n d i n g

the digits I-7 index the c o r r e s p o n d i n g forms in the r i g h t - h a n d

side e x p r e s s i o n below:

decompose({X,V,Z}) = {X~(VUZ},V~(XUZ),Z~{VUX), (×nV)~Z,(VnZ)~X,(XnZ}~V,

XNVNZ} H e r e is a formal d e f i n i t i o n of the function:

decompose(sa8)= i_~ (3asl,as2£sas)((as1~as2)^((asINas2)*{})J then

(let asl,a82

E 8a8 be 8.t. aslNas2¢{};

decompose({asl~as2, as2~asl,aslNa~2}Usas~{asl,as2}) else 8a8 type:

S ~ S

65

3. T U P L E s

The p r o b l e m w i t h w h i c h we w i s h to illustrate, m o r e systematic coverage, TUPLEs,

before going into a

the m e t a - l a n g u a g e a b s t r a c t data type of

is p e r h a p s not a v e r y a b s t r a c t one. We are to compute the

first k rows of the P A S C A L triangle;

informally:

1 1 1 1 1

etc..

2 3

4 5

1 1 3 6

10

So we define two functions:

p u t t i n g the first k rows together.

1 4

10

1 5

1

one c o m p u t i n g the i'th row; another The second function invokes the

first.

row

type:

row:

+ N 1 ~ NI+ +

type:

tri:

NI ~ N1

takes a positive,

n o n - z e r o integer,

i.e. a natural number larger

then I, and p r o d u c e s a tuple of such numbers;

tri

takes a n o n - z e r o

natural number and p r o d u c e s a tuple of as m a n y tuples of natural numbers.

N1 + stands for the d o m a i n of tuples of natural numbers;

N1 ++

for tuples of tuples of these numbers. An i m p l i c i t way of s p e c i f y i n g row

and tri w o u l d e.g. define their p r e -

the c o n d i t i o n s that input

and p o s t - c o n d i t i o n s ,

(alone) m u s t satisfy,

ditions that input and o u t p u t

(together) m u s t satisfy:

type:

pre-row:

N 1 ~ BOOL

type:

post-row:

N 1NI

type:

pre-tri:

N 1 ~ BOOL

type:

post-tri:

N 1NI

+ ~ BOOL

++ ~ B O O L

i.e.

r e s p e c t i v e l y the con-

In particular:

pre-row(i)

= true

post-row(i,r)= cases

i:

(i

(r = ),

2

(r = ),

T

(let riml (It

= i)

= row(i-l)

in

^ (r[1]= I = r [ l r ] )

^

(vj £ {2:It-l}) (r[j]

pre-tri(k)

= riml[j-l]+riml[j])))

= true

post-tri(k, rr)= (1 rr = k) ^(Vi

6 {l:k})(rr[i]

= row(i))

In the n o t a t i o n of the m e t a - l a n g u a g e ,

tri(6)

w o u l d be p r e s e n t e d as:

<<1>,<1,1>,<1,2,1>.,<1,3,3,1>,<1,4,6,4,1>,<1,5,10,10,5,1>>

Giving the above implicit d e f i n i t i o n s of row and tri almost amounts to giving their e x p l i c i t counterpart. "read" the p r e -

The pre of r o w i=1

Instead of d o i n g this,

let us

and p o s t - ' s :

is always true

(for 5>0).

The p o s t

of row

says: if

then the r e s u l t i n g row r is just the tuple of length 1 whose only

m e m b e r is a I. If i=2 l's. In general,

then r is a 2-tuple both of w h o s e elements are

the length of r is i, its first and last e l e m e n t s

are both l's, and, for i>2, the elements of r, i.e. of row(i), r e l a t e d to e l e m e n t s of r o w ( i - l )

as follows:

are

let j be any index into

r e x c l u s i v e of the first and last, then the j ' t h e l e m e n t of r is the sum of the j - / ' s t and j ' t h e l e m e n t s of r o w ( i - l ) . The c o m p u t a t i o n s p e c i f i e d b e l o w computes

tri(k)

by imperative means:

67

(dc~,l lr~

:= <,>

type NI++ ,

Rowi := fo r i=~ t_~o k d2

(let riml

t~pe NI+;

: (c_Tr~)[i-1];

for j=2 t_~olen riml d_~o Row~ := (c Row~)~
[j]>;

Row~ := (cRow~)~<1>; T ~ := (o_TrZ)..<£~>); r e t u r n ( c Trig )

3.1 D e f i n i n g

of TUPLE

Domains

Objects

Let A be the name of a class of objects. all of w h o s e m e m b e r s jects we

use e i t h e r

A~

denotes whose

are finite

length

of the d o m a i n

the i n f i n i t e

elements

To d e f i n e

the class of objects

tuples w h o s e

expression

domain

of finite

are in A. The

elements

operators:

0-1ength

are A ob-

~ or +

length tuples all of tuple,

<>

, is in A ~

-- for any A!

A+

denotes

the i n f i n i t e

domain

LEs, all of w h o s e element8

Let G denote

a class of objects,

of a record,

w i t h records

ordered

fields,

i.e.

consisting

of finite

non-zero

are in A. Thus

a domain,

<> is not in A +.

abstracting

now of a finite

length TUP-

number

the fields of such

then:

G*

is a d o m a i n

expression

i.e.:

R

:

G~

abstracting

the class of records.

Call

this R,

68

Now let files be ordered,

finite length sequences of one or m o r e re-

cords. Then:

R + or

(G~) +

are e q u i v a l e n t domain expressions a b s t r a c t i n g the class of files. In the latter expression, you could,

the p a r e n t h e s e s are solely used for g r o u p i n g - -

of course,

omit p a r e n t h e s e s here:

G ~+.

If you so w i s h you

can likewise name the file domain:

Ft

= R+

In this example we did not retain the v i e w that files c o n s i s t e d of c o l l e c t i o n s of distinct,

FS

=

R-set

R

=

G•

FS

=

(G~)-set,

u n o r d e r e d records.

Had we done so:

or:

or: Fs

=

G~-set

w o u l d have been a p p l i c a b l e abstractions.

3.2 R e p r e s e n t i n g Instances o_~f TUPL____~EObjects

3.2. ! E x p l i c i t E n u m e r a t i o n

Given not n e c e s s a r i l y d i s t i n c t objects al,

a2,

...,

a n w h i c h are all

in A, the expression:


. . . ~an>

denotes an n-tuple,

i.e. an object of, or in: A * ,

A+

(for n > O ) .

-- is d e n o t e d by: <>

3.2.2.

Implici t E n u m e r a t i o n - Part 1

Given a f u n c t i o n F: INTG

< F(i)

I 1
~ D the expression:

>

denotes an n tuple -- as above~ So does:

< F(i)

I i£{1:n}

>,

< G(d)

I i£{m:m+n-1}

and

>,

etcetera,

w h e r e G: D ~ A. Thus we shall not be too p a r t i c u l a r about the form of the "type-building" p r e d i c a t e as long as it is clear, ders of your formulae, w h a t the size, be.

Since G(d)

G(d)

i.e. length, of your tuple will

is i n d e p e n d e n t of i the n tuple consists of identical

elements.

Let g1" cord,

to the rea-

g2"

"''"

gm"

and gij

for v a r y i n g i,j denote fields of a re-

i.e. all o b j e c t s in G, then :

< g l , g 2 , . . . , g m >, <,,.'',
~

are c o n s t r u c t o r e x p r e s s i o n s d e n o t i n g objects in G ~, r e s p e c t i v e l y R + That is: a b s t r a c t i o n s of

(instances of) records,

r e s p e c t i v e l y files!

70

Let F@,

Fr be total functions from fields to fields, r e s p e c t i v e l y

records to records,

i.e.:

type:

Fg:

G ~ G, type:

and let f,r denote a file, r e s p e c t i v e l y a record;

< Fg(r[i])

I l
< F&(f[j])

I l<j
F~:

R ~ R;

then:

r > >

denotes a record, r e s p e c t i v e l y a file, d e r i v e d from r, r e s p e c t i v e l y f, having all its fields, r e s p e c t i v e l y records, p r o c e s s e d -- in any order -- by Fg, r e s p e c t i v e l y

F&.Although to be dealt w i t h more

s y s t e m a t i c a l l y b e l o w r[i] denotes the i'th field of record r, w i t h Ir

d e n o t i n g the length,

in terms of not n e c e s s a r i l y distinct,

fields, of record r.

3.2.3 E l e m e n t O r d e r i n @

Sets are u n o r d e r e d c o l l e c t i o n s of objects.

Tuple elements are ordered.

In:


. ~an>

is the Ist element,

< F(i)

a 2 the 2nd,...,

the 2nd element is F ( m + 1 ) , . . . ,

is the k + l - s t element.

< G(d)

In:

I iE{m:m+n-1}>

all elements are alike, and are G(d)

By: < obj

In:

I i6{m:m+n-Z}>

the Ist element is F(m), for O
and a n the nth element.

I obj 6 set >

-- w i t h n of them~

and F(m+k)

71

we m e a n a card set

tuple of all d i s t i n c t m e m b e r s of the a s s u m e d

finite set set -- o c c u r r i n g in a r b i t r a r y order.

In g e n e r a l the form of an i m p l i c i t tuple b u i l d i n g c o n s t r u c t o r exp r e s s i o n is :

< F(i) where 0(i)

I 0(i) ^ P(i) >

is an o r d e r i n g p r e d i c a t e indicating,

mainly

through the

natural o r d e r i n g of integers i, the order of those elements

F(i), for/,

for w h i c h the m o r e general p r e d i c a t e P(i) holds:

3.2.4 I m p l i c i t E n u m e r a t i o n - Part 2:

Let P:

INTG ~ BOOL be a (total function)

p r e d i c a t e then the ex-

pression:

< F(i)

i£int~set

^ P(i) >

denotes an I tuple :

< F(il),F(i 2) .... ,F(i l) > where :

{il,i2,...,i l} c intgset ^ ^ ^

i1
In words:

The o r d e r i n g of the r e s u l t i n g tuple e l e m e n t s follow the

n a t u r a l o r d e r i n g of the INTeGers. the cardinality

The length of the tup!e will be

of that subset of the finite integer set, int~set,

for w h i c h P is satisfied.

72

Ex_am_~le 14-15: Although not illustrative

of abstraction

techniques,

as we intend them,

the following examples might help drive home the idea of implicit tuple constructions: (i) Let fib denote the so-called

fibonacci

function,

~ :

fib: N O ~ N I

where NO, N 1 denote the sets of natural numbers larger than or equal to 0, r e s p e c t i v e l y fib(i)

1. In particular

think of: fib(O)=1,

for i~1 being fib(i-2)+fib(i-1). < fib(i)

fib(I)=1,

with

Then:

J (re
>

denotes a tuple of those of the m'th, m+1'st,...,

up to, and including

the n'th fibonacci number provided these are not even numbers,

and m,n~O~

For m=3 and n=ll you would get: <3, 5, 13, 21,55, 89> i.e. the tuple of the 3rd,

4th,

6th,

The type of the above expressions (2) The following pure expression

7th, 9th and lO'th fibonacci number.

is : N 1 constructs

the pascal triangle between

rows 1 and k: < row(i)

I I < i < k

^ cases i (I

row(i)

= <•>,

2

row(i)

= <1,1>,

T

row(i)

= ~<

Crow(i-l)) [j]+ (row(i-l)) [j+l ] I l<j

..)

>

You are invited to compare this formulation with the impure expressionblock given as the last item of example

ii above.

78

3.3 TUPLE Operation s

The following

special TUPLE operations [pairwise]

h, hd t, tl l, len elems ind [i], (i)

head, tail,

are provided:

concatenation, 1 (two forms provided)

length, elements, indices, index,

selection,

distributive

oono +

(two forms provided)

concatenation

(of tupie of tuples),

replace.

Each of these operators will now be individually, mally explained.

and quite infor-

It is assumed below that tuple, tuplel, tuple2

denoted TUPLEs and tuplelist

tuple1~tuple2

a TUPLE of TUPLEs.

denotes

the TUPLE whose first ~tuplel

ments are those of tuplel order; whose last ~ t u p l e 2

ele-

in the given elements

of tuple2, and in that order;

are those

and whose length

is exactly the sum of the lengths of tuplel and tuple2.

tuple

denotes the Ist element of tuple. Taking the head of an empty tuple is undefined.

t tuple

denotes the tuple of all but the first element of tuple and otherwise

in the same order

as the elements of tuple. Taking the tail of an empty tuple is undefined.

I tuple

denotes the length of the tuple, ber of net necessarily

i.e. the Num-

distinct elements of

tuple. elems tupZe

denotes

tuple.

the SET of elements contained

in the

74

denotes the SET of Natural numbers w h i c h are

ind tuple

the indices of tuple. denotes the ith element of tuple p r o v i d e d i is

tuple[i]

a Natural number larger than 0 and less than or equal to the length of tuple. denotes the TUPLE of elements of the tuples

cone tuplelist

w h i c h are the immediate e l e m e n t s of tupleliet and in the order o t h e r w i s e given in the unrav e l l e d or de-bracketed,

element tuples.

denotes the tuple w h i c h is as tuple -- only

tuple+[i~o]

the ith o b j e c t is not tuple[i]

but o. If

1>i>~ tuple the e x p r e s s i o n is undefined. This last o p e r a t i o n is s i n g l e t o n map

(presently)

only defined for a right o p e r a n d

(in N1 m ~ OBJ).

The tuple o p e r a t i o n s applied to objects other than tuples are unde-

fined.

Ex_am_ples 16-17: Let VAL d e n o t e the class of v a l u e s o b t a i n e d during, of partial,

i.e. as a r e s u l t

e v a l u a t i o n s of e x p r e s s i o n s of some language,

and let

STACK be an a b s t r a c t i o n of stacks of these values. STACK

=

VAL ~

can then be c o n s i d e r e d a not too abstract, mentation-independent,

V£VAL (i)

yet s u f f i c i e n t l y imple-

model of the domain of stacks. Let stk£STAGK,

then:

-st

(2)

hst,

i4~t

(3)

k st,

t let

(4)

<>

75

are c o r r e s p o n d i n g l y operations

reasonable

abstractions

on or facts about stacks:

top" of, or into the stack; the resulting

of the following

typical

(i) pushing a new object

"on

(2) reading the top of the stack;

(3)

stack after a pop o p e r a t i o n

-- with

(4) not abstract-

ing any o p e r a t i o n but only brought here to exemplify

the empty,

un-

used stack .

Reverting

now to our examples

around file systems,

suitably decorated f, r and g denote files, tively,

i.e. objects

(5)

r~

(6)

h_f ,

(7)

f[i]

r[j]

(8 )

f l ~f2

r I ~r 2

(9 )

f+ [i~r ]

r+ [j~g ]

(i0)

conaf

(ii)

l f,

files cord

h_ddf

file file

[record];

[record]

3.4

even serial file

respectively

the i'th record

(9) updating

[records]

the i'th record

on

(5) writing a re-

[record];

(6) & (7)

[j'th field] of a together to form a [j'th field]

of a

(i0) chaining all the records of a file together to (~); and

(ii) inquiring

about the current size of a file

in terms of its number of records

TUPLE-oriented

The following

typical operations

(right column)]:

(8) chaining two files

[record];

form a record

len r

of the following

[and records

to a sequential,

[record];

hd r

l r,

abstractions

reading the first,

new file

h r,

fen f

(left column) [field]

records and fields respec-

in F, R and G, then the expressions:

f~

are reasonable

let possibly

[fields].

Combinators

combinator:

for i=m to n d__ooS(i) is provided

for the imperative

In particular,

handling

let t denote a tuple,

of p r i m a r i l y

then:

lists of objects.

76 for i=I to fen t do S(t[i]) is a typical statement. The integer valued bounds m and n m u s t be s t a t i c a l l y determined.

S is any statement.

See the d o u b l y nested

example of a use of the above iterative statement

given as the last

item of example !i.

The m e a n i n g is g i v e n by the transcription:

S(m); S(m+1);...; S(n) w h e r e S(j) arises from S(i) by s u b s t i t u t i n g all free o c c u r r e n c e s of i in S(i) by j. Since j is a c o n s t a n t no c o l l i s i o n w i t h other free v a r i a b l e s in S(i) will occur.

The c o n s t r u c t o r expression:

< Fa(f[i])

I 1

is an a p p l i c a t i v e e x p r e s s i o n -- p r o v i d e d Fr does not rely on any state component. An imperative analog can be a c h i e v e d by m e a n s of the for-to-do

dal

linearly iterative loop statement:

~:=

<> t~F ~ R~

([or i=1 to len f do

The above can be seen to be a p r o c e s s - o r i e n t e d a b s t r a c t i o n of parts of a file h a n d l i n g system specification.

The global v a r i a b l e / ~

is initialized to the null tuple, <> , of no records;

and fixed to

contain only finite length sequences of not n e c e s s a r i l y d i s t i n c t records

(type R~). ~

object,

i.e. an object of ref R~; w i t h c ~

now denotes a c o n s t a n t r e f e r e n c e to an R~

contents at that reference.

d e n o t i n g the dynamic

77

4 MAPs

As a p r e l u d e in this

to a s y s t e m a t i c

introductory

w h a t c o u l d be an o p e r a t i n g n e s t e d maps.

In this,

are p a r t i a l l y reflected

more

system

i.e.

ly i d e n t i f i e d card reader~

resources. a

hypothetical

operating

The o v e r a l l

-- and this

W i t h each user sequence

is e:g.

a file

is

is a s s o c i a t e d

of zero one or

system directory

of a finite

A resource

display terminal,

of

s y s t e m users

structured

of an o r d e r e d

consists

of m a p s w e are

the a b s t r a c t i o n

in terms of r e c u r s i v e l y

direetory

of the directory.

identifiers.

and a d i r e c t o r y

of the s u b j e c t

to i l l u s t r a t e

hierarchically

name c o n s i s t i n g

resource

rectory

going

perhaps

ordered,

in the d e s i g n

a qualified

treatment

example

non-empty either

is a di-

set of unique-

a line printer~

identifier

a

or it is a direc-

tory.

Abstractly

1

modeling

DIR

=

we write:

Rid

~ RES m

2

RES

=

The r e s o u r c e analyzed,

J CR

f DT

i Fid

and f i l e - i d e n t i f i e r s

e.g.

Rid

LP

=

elementary,

....

Fid

and d i s p l a y

LP

The above The

=

=

CR

two e q u a t i o n s

first d e f i n e s

identifiers domain

terminals

...,

(1,2)

the d o m a i n

to the right,

i.e.

to s p e c i f y w h a t

=

...,

line printers,

DT

are e x a m p l e s

=

un-

card

...

of a b s t r a c t

of f i n i t e d o m a i n m a p s it D I R ;

in the definiens.

or -- etc.

to be f u r t h e r

are:

to be the u n i o n

an o b j e c t of the d o m a i n R E S , printer),

are c o n s i d e r e d

,..

to resources, and names

of r e s o u r c e s

I

objects:

We also do not have here b o t h e r readers

I DIR

the latter d e f i n e s

(J) d o m a i n Thus

is e i t h e r

syntax

of the d o m a i n s

a particular

an o b j e c t

rules.

from r e s o u r c e

in L P

the listed

resource, (i.e.

i.e.

a line

78

If by suitably decorated

lower case letter sequences

analogous

to

the above domain names we mean to identify objects of respective classes,

then the following

denoting

an object in DIR,

is an expression of the m e t a - l a n g u a g e i.e. an abstract

"snapshot"

of a direc-

tory:

[rid 1 rid 2 rid 3

Ip I , fide, [rid 4 rid 5 rid 6

or 4, dt 5, [rid? ~ Ip?, rid 8 ~ [rid 9 ~ Crg], rid10 ~ fid10]],

rid11 ~ lid11, rid12 ~ [rid13 ~ dt13]] which we could informally picture:

/ Ipl

/

r' , d r'd12 fid2

/ id

cr4

ds~r id6

lid11 rii13

\

dt5

dt13

d r J8 ridlo

\

tp7

ri9 cr9

fid10

79

In the above h i e r a r c h i c a l

structure the labeling of edges

is u s u a l l y u n d e r s t o o d to v o i d any

(by rids)

'meaning' you m a y think that the

l e f t - t o - r i g h t o r d e r i n g of edges have.

O b s e r v e how, from the s y s t e m ~ d i r e c t o r y the q u a l i f i e d name

tories are:

designates

IPT. Q u a l i f i e d names d e s i g n a t i n g direc-

<>, , , , , and

these are the names a s s o c i a t e d w i t h users.

R e s o u r c e s a s s o c i a t e d w i t h e x i s t i n g users m a y be allocated or freed: Let sys-dir

stand for the system directory,

d e s i g n a t e a d i r e c o t r y in sys-dir,

qn for a name known to

and let rid and re8 denote respec-

tively the name by w h i c h the r e s o u r c e res is to be k n o w n in the dir e c t o r y d e s i g n a t e d by qn. The f o l l o w i n g function, w h e n invoked

by:

catalog(sys-dir, qn,rid, res) a c c o m p l i s h e s this: 3.0

.I

catalog(dir, q, id, r)= i_~ q=<>

.2

then dir U [id~r]

.3

else dir + [~q~catalog(dir(hq),~q, id, r)] type:

DIR Rid • Rid RES

~

DIR

The reader is e n c o u r a g e d to apply this function to the above example.

The line:

"dir U [id~r]" reads: ~'join, or merge, as a new entry, the

a s s o c i a t i o n of id to r, to the m a p dir". The last line reads: w h i c h is an Rid, d e s i g n a t e s a directory, Replace this directory,

"hq,

dir(~ q) , e m b e d d e d in dir.

dir(hqJ , with the one --

catalog(dir(hq),~q, id, r) -- o b t a i n e d by c a t a l o g i n g the resource r named id in the s u b d i r e c t o r y of dir(hq) d e s i g n a t e d by ~ q I" N o w it m a y be that the o r i g i n a l qn did not d e s i g n a t e a d i r e c t o r y in

sys-dir. Then the above f u n c t i o n w o u l d go awry. So here is an imp r o v e d version:

80

4.0

aatalog(dir, q, id, r)=

.i

i~ q=<>

.2

then i~ id 6 d o m d i r

.3

then error

.4

else dir U [id~r]

.5

else i_~ h q

N£ do___mmdir

.6

then error

.7

else

(let res = dir(hq)

.8

if ~is-DIR(res)

.9

then error else dir + [ h q ~ c a t a l o g ( r e s , ~ q ,

.i0

This

function

directory

also m a k e s

designated

the set of r e s o u r c e since

i_~n

a qualified

by q

sure that

identifiers

is is not already

dom dir

. Thus

u s e d in dir.

name m i g h t d e s i g n a t e

res, o t h e r than a directory,

denotes

i.e.

used

Observe

we test,

in the

the domain, finally

either n o n s e n s e

a DIR,

id, r)])

i.e. that

or a resource,

Is-DIR,

that res

is indeed a directory.

Further

experiments

section

4.5.

w i t h the above a b s t r a c t i o n

will

be e x h i b i t e d

in

81

4.1 D e f i n i n g Domains of MAP Objects

Let A, B, A. and B. (for i = 1,2,...,n and j = 1,2 ..... l) be class J names. To define the class of objects w h i c h are finite d o m a i n maps from

(subsets of) A, r e s p e c t i v e l y Ai, into B, r e s p e c t i v e l y Bj, we

use the d o m a i n e x p r e s s i o n o p e r a t o r ~: m

A ~ B,

Ai ~ B j

Let our file system now come of age~ Let the file system consist of a set of u n i q u e l y named files; u n i q u e l y keyed records,

and let each file consist of a set of

i.e. the file may have its records r a n d o m l y

a c c e s s e d by key. Let file names, keys and records p r e s e n t l y be further unspecified.

Then:

Key ~ REC is a domain e x p r e s s i o n suitably

a b s t r a c t i n g our notion of files,

p r o v i d e d Key & REC denote the d o m a i n s of keys and records. w i s h to name this file domain,

FILE

=

by e.g. FILE,

If you

then:

Key ~ REC

is an example of an a b s t r a c t syntax rule w h i c h lets FILE denote w h a t

Key ~ REC denotes! Now: Fid ~ FILE m

or e q u a l l y well:

Fid ~ (Key ~ REC) are d o m a i n e x p r e s s i o n s both suitable a b s t r a c t i n g our ideas about the file system and files, names.

again p r o v i d e d Fid d e n o t e s the domain of file

82

4. I.i D e f i n i n g

MAP Domains -- C o n t i n u e d

T h e n the logical type expression:

(ALIA21... IA n) ~ (BIlB21''' IB l)

l>n

d e n o t e s t h e class of objects w h o s e members are finite domain maps from

(subset of) the u n i o n class of A1, A2,

the u n i o n class of B 1, B 2,

...I and A n objects into

..°, and B l objects.

Ex_am_ple 21:

N o w define keys and records to be either i n t e g e r s or c h a r a c t e r s t r i n g s , r e s p e c t i v e l y finite, n o n - z e r o length sequences of either integers or c h a r a c t e r s t r ~ n g s -- p r e s e n t l y w i t h no constraints.

Then,

if INTG and

QUOT + are suitable a b s t r a c t i o n s of integers and c h a r a c t e r s t r i n g s respectively, we have that:

(INTGIQ UOT+) ~ (INTG+IQ UOT++) is a d o m a i n e x p r e s s i o n w h i c h defines any one file to c o n t a i n both integers and c h a r a c t e r s t r i n g s in its domain,

i.e. as its keys; and

sequences of b o t h of these in its c o - d o m a i n or range,

i.e. as its

records. Thus e.g. a given file may map 3 into ,

<2,4,9,11>,

5 into <3,5,?>,

4.1.2 D e f i n i n g

and

into

into .

MAP Domains -- C o n t i n u e d

The logical type expression:

(At M Sl) U_ (A~ M S~) k

..... U_ (A~ M B k)

denotes the class of objects whose m e m b e r s are finite d o m a i n m a p s as above but w i t h the r e s t r i c t i o n that A I objects, i.e. in the domain,

if at all mapped,

are m a p p e d into B I objects, A 2 objects

into B 2 objects,

(...)

.... and A k o b j e c t s into B k objects. We read the U MAP d o m a i n o p e r a t o r as a 'merge'-, rather than (as we did for I)

an 'either'-, union operation.

83

If we w i s h

cords,

to c o n s t r a i n

integer

and c h a r a c t e r s t r i n g

racte r s t r i n g s ,

U

m

The

expression

MAP Domains

Defining

logical

maps

whose

field

fields

re-

are cha-

(QUOT + ~ QUOT ++)

of the r i g h t kind

for s p e c i f y i n g

the above:

-- T e r m i n a t e d

I

(A2 ~ B e )

a class of objects

from A 1 into B1,

member

into records

into integer

type expression:

(A I ~ B1) denotes

keys

to m a p

then:

(INTG ~ I N T G O

is a d o m a i n

keys

is either

I

...

I

whose members

(Ak ~ B k)

are finite

domain,

partial

or A 2 into B2,... , or A k into B k. Thus

an A 1 ~ B 1 object,

a given

or an A 2 ~ B 2 object, .... or an

A k ~ B k object.

If f i n a l l y

any one

in its key d o m a i n

file should not m i x i n t e g e r s or r e c o r d

(INTG

~ INTG +) m (QUOT + ~ QUOT ++) m

is a d o m a i n

expression

co-domain,

and c h a r a c t e r s t r i n g s

then:

I (INTG

~ QUOT++) I m I (QUOT + ~ INTG +)

guaranteeing

this:

Note

that the d o m a i n

ex-

pression:

(INTG]QUOT+)

permits

~

any one r e c o r d

being c h a r a c t e r s t r i n g s .

(INTGIQUOT+)+

to have

some fields being

If that is your

a w a y in w h i c h you can so express

it!

integers,

others

ideas a b o u t records,

this

is

84

Note:

A map or a f u n c t i o n from subsets of A into B is said to be a partial map,

r e s p e c t i v e l y partial

function.

It is quite common to deal with

partial maps.

Prg~r _a~nin~

Note:

D e f i n i n g a class of functions using the ~ o p e r a t o r shall express that such objects have their graph, c o m p u t e d w h e n defined.

i.e. a r g u m e n t - v a l u e associations,

This is in c o n t r a s t to using the ~ and ~ ope-

rators whose use in d e f i n i n g total and partial functions shall express that the objects are i m p l i c i t l y d e f i n e d through some l-expressions-like device,

about w h i c h it can be said that the g r a p h of the

d e n o t e d function is not c o m p u t e d w h e n defined -- in fact: c o m p u t e d -- and where, infinite.

4.2

in addition,

the function domain(s)

For the story on such functions see section

is never may be

5.

R e p r e s e n t i n g Instances of MAP Objects

4.2.1 E x p l i c i t E n u m e r a t i o n Let al, a 2,

..., a d be d i s t i n c t A objects, ai!, ai2, ..., aid be distinct A i objects, b 1, b 2, ..., b d be not n e c e s s a r i l y d i s t i n c t B objects, and bjl , bj2, ..., bjd be not n e c e s s a r i l y d i s t i n c t Bj objects, then the c o n s t r u c t o r expressions:

[al~bl,a2~b2,...,ad~bd ]

and:

[ail~bjl,ai2~bj2 ..... aid~bjd ] denote maps from

(subsets of) A into B, r e s p e c t i v e l y

(subsets of) A i

into Bj, i.e. in: A m ~ B, r e s p e c t i v e l y A i ~ Bj. The c o n s t r u c t o r expression:

85

[a11~b11,a12~b12,~'°Jalm2~blml , a21~b21,a22~b22,''',a2m2~b2m2 , akl~bkl,ak~bk2,''',akmk~bkmk ] denotes a m a p in:

(At M BI)

_U (A 2 M S~)

a s s u m i n g of course that ing index,

_U ...

_U (A k M S k)

aij6Ai, bijEB i that is: that first A i r e s p e c t i v e l y B i. And:

subscript-

i, binds to domain

[ax1~byl,ax2~by2,...,axm~bym ] denotes a map in:

(ALIA21 .... A n ) ~

(BIlB21'''IBl)

provided:

axi6(AlIA21... IAn)

and

byj£(B lIB21.,. IBl).

-- is d e n o t e d by:

[]

Let

lid1, lid2,°.. , lid I let kij etc.

file names;

denote,

i.e. be a b s t r a c t i o n s of, d i s t i n c t

denote,

i.e. be a b s t r a c t i o n s of keys d i s t i n c t

for f i x e d i's; and let r.. etc. denote, n e c e s s a r i l y d i s t i n c t records.

Then:

i.e. be a b s t r a c t i o n s of not

88

[fid 1 -' [kl 1"~r11" k12"*r12" " ~ " " klnl~rln I ~" fid8

-~ [k21-~r21 , k22"~r22 , • . ., k2n2-~rsn2 ],

. . ,

lid I

[kl1~rll

is a s c h e m a t i z e d

(...)

p r o v i d e d fidi£Fid, If Key

kl2"~rl2 , . . . ,klnm~rlnl

snapshot of an object in Fid ~

kij£Key

(Key ~ REC),

and rij6REC.

= INTG and REC = QUOT ++ then:

[~ ~ <, <~, C>, <X,O_,W,E>>, 5 -~ < < V > > ,

7 ~ < < E , U , G , 2 , S_>,<S>>] r e p r e s e n t s a file of three records, w i t h keys 3,5 and ?; etc. Whereas keys of any one file need be distinct,

records or any two keys

of r e s p e c t i v e l y d i s t i n c t l y names files need not be distinct:

[fid e -~ [2-'<3, 4, 5>, 3"<3, 4, 5>], lid B -~ [3-~<3,4,5>,2-~<3,4,5>]]; in fact, as the above example of a snapshot of a small file system shows, d i s t i n c t l y named files need themselves not be distinct.

4.2.2 Implicit E n u m e r a t i o n

Let F: Dd~A

and G: D r ~B denote partial functions,

[ F(d) ~ @(r)

I P(d,r)

]

is a m a p c o n s t r u c t o r e x p r e s s i o n d e n o t i n g a map in sumed to be a predicate:

P:

Dd Dr

then :

~

B00L.

A

-* B. m

P is as-

87

Let

Fi, FTn, Gj, GIZ denote p a r t i a l functions: Fi:

FTn: G,: J G11: for

Dd Dd D r Dr

~ A i, -~ (AIIA2~... JAn), ~B. j -~ (BIIB21...IB l)

i=1,2, .... n and j=1,2,..o,l.

and :

The expressions:

[FiCd)

~ Gj(r)

!

P(d,r)],

[Fin

~ G1l(r)

I

P(d,r)]

d e n o t e m a p s from

and:

(subsets of) r e s p e c t i v e l y

A i into Bj~ and

(ALIA21... IAn) into (BIlB21... IB1). The expression:

where

[F1(d) ~ G1(r) U[F2(d) ~ G2(r)

P I (d, r) ] P2 (d, r) ]

U[Fk(d) ~ Gk(r)

Pk (d, r) ]

Pi are predicates, as above, denotes a map in: ~A I M S I)

~!~ Let

_U ~A 2 M B~)

k

"-

_U

CA~ M S~) .

~: Fr, Ff d e n o t e total (for simplicity: pure, applicative) func-

tions from records into records,

r e s p e c t i v e l y files into files. Let

s denote a file system, f some file, r some record; the next s u b s e c t i o n

(2.3.3) on operations,

note the set of filenames,

let

and, foregoing

dom s and domf

de-

r e s p e c t i v e l y the set of keys, of the f i l e

system -- r e s p e c t i v e l y of a file. Then:

[ lid ~ Ff(s(fid))

I fid 6 dom s]

[ k

I k

~ F~(f(k))

E dom f]

and :

[ fid ~ [ k ~ Fr((s(fid))(k))

1 kEdom s(fid)]

I fid 6dom s ]

88

denotes a file system,

a filer and a file system.

system is derived from a given file system, of its files; dually.

the latter by transforming

sing' programs. or 'accessing'

abstractions

Observe how randomness

f, by transforming

of various

records

(k,

file

of record and file

is p r e s e r v e d by the unorderedness

respectively

each

indivi-

Thus the above three implicit map constructor

expressions m a y be reasonable

(lid)

each of its records

The file is derived from a given file,

each of its records.

The former file

8, by transforming

of

'proces'positions'

'fetching'

files

f(k) ..... ), for transformation.

4.2.3 A Note on Scopes We have now seen three distinct m e t a - l a n g u a g e

constructs

for impli-

cit object constructions:

{ Fr(r)

I

r6f

< Fr(f[i]) 1 [ k ~ FrCf(k))

} 1
I

l f

>

k £ domf

]

In all three,F r and f were quantities sions;

and r, i and k respectively,

defined outside these expres-

were bound variables,

fined and bound to the right of the builder combinator: a scope extending respectively

[ & ]. The scope of these bound variables

i.e. nested expressions,

constructor

I, and with

to the closest embracing pair of { & }, < & >,

analog to those in ordinary programming to inner,

being de-

expressions

languages:

including

-- unless redefined

follow rules

thus they extend

{ }, < > and

[ ] based

in such inner forms,

practice which certainly can and should be avoidedl

a

The last file

system building expression of the previous example section illustrates the doubly nested use of bound variables.

Let: A ~

(B ~ C)

(A B)

"+ C m

So does:

89

be domain e x p r e s s i o n s w h e r e we do not p r e s e n t l y bother about A, B and C. Then: a£A,

for s u i t a b l y decorated,

and o c c a s i o n a l l y distinct,

b6B and c6C:

[ al

~

[bll

~

all,biB

~

a2 ~

[b21

~ c~I,b22

c12],

~ c22~b23

~ c23]

]

and

[ (al,b11)

~ ell, (a1,b12)

~ c12,

(a2, b21)

~ c21, (a2, b22)

~ c22, (a2, b23)

are examples of s o m e h o w

'equivalently'

~ c23]

d e n o t i n g e x p r e s s i o n s in that

functions can be d e f i n e d w h i c h c o n v e r t s b e t w e e n their objects.

Let,

for ease of reference,

the first d o m a i n be named X, the second

Y:

x

=

AM~MC)

Y

=

(A B) ~ C m

then:

c o n v x y (x )= [(a,b)~c

I aEdomx

A bEdom(x(a))

^ c=(z(a))(b)

]

eonvyx(y)= [ a~[b~c

I (a',b)6dom y ^ a'=a

^ c=y(a,b)]

where:

type:

convxy:

X ~ Y

type:

convyx:

Y ~ X

In fact the two f u n c t i o n s are e a c h others'

inverses.

I (a,

)6dom y

]

90

4.3 MAP O p e r a t i o n s

The following special MAP o p e r a t i o n s are provided:

U

merge,

+

override,

(...)

apply, restrict with,

l

r e s t r i c t to,

dom

domain,

rn~

range, composition

Each of these o p e r a t o r s will now be individually,

and quite infor-

mally explained:

maplUmap2

denotes a MAP p r o v i d e d the domains of mapl and map2 are disjoint,

o t h e r w i s e undefine d . The d e n o t e d map

maps d o m a i n e l e m e n t s of mapl m e n t s as does map1,

into the same range ele-

and d o m a i n e l e m e n t s of map2 into

the same range e l e m e n t s as does map2,

and m a p s nothing

else.

mapl+map2

denotes the MAP w h i c h maps d o m a i n elements of map2 into the same range e l e m e n t s as does map2,

and m a p s

those domain elements of map1 w h i c h are not in the domain of map2 into the same range e l e m e n t s as does

mapl, and maps nothing else. map(a)

denotes the range OBJect into w h i c h map m a p s a. If a is not in the d o m a i n of map the o p e r a t i o n is undefined

map~wset

denotes the MAP w h i c h m a p s those d o m a i n elements of

map w h i c h are not in the set wset into the same range elements as does map, and maps nothing else.

91

mapltset

denotes the MAP w h i c h m a p those d o m a i n elements of

map w h i c h are also in tset into the same range elem e n t s as does map, and maps nothing else.

dom map

d e n o t e s the set of objects w h i c h are d o m a i n elements of map.

d e n o t e s the SET of OBJects w h i c h are the range ele-

rng map

m e n t s of map.

map I "map 2

denotes a MAP p r o v i d e d the range of map2 is included, (~) in the d o m a i n of map1, o t h e r w i s e

i.e. c o n t a i n e d

the o p e r a t i o n is undefined.

The d e n o t e d m a p m a p s into

those range e l e m e n t s of mapl w h i c h are m a p p e d to by the d o m a i n e l e m e n t s of map1, m a p p e d into, as range elements of map2 from d o m a i n e l e m e n t s of map2. M o r e formally, and in this case c e r t a i n l y m o r e concisely:

(mapl"map2)(d) = i~ dEdommap2 then if map2(d) E dommapl then mapl(map2(d)) else undefined else undefined

Let s, id, f, r and k stand for a b s t r a c t i o n s of file systems, names,

(1)

files, records and keys,

8 U [idol]

f

then:

U [k-~r]

(2) (3) (4) (5)

id E dora8

k 6 domf

(6)

f 6 rn g 8

r 6 rng f

s + [id-~f]

f + [k-~r]

s'.{id}

f'.~k}

s(id)

f(k)

file

may be reasonable on file systems

abstractions

of the following

(left column)

an entirely new file sense of its name

[record]

[and files

typical operations

(right column)]:

into the file system

[key] not hitherto being one of a file

the system

[file];

(2) updating

the system

[a file];

an entire file

(3) deleting an entire file

[record]

[a file];

[a record];

a file of a given name

a given key] given file

is in the system

(i.e. its

is in the system

'value',

[record]

[a single record]

[keyed with k] from the system (5) asking whether

(i) writing

[a file] -- in the

named id

(4) reading an entire

[a file];

and

not name)

[record

in of

file

[a record with

(6) inquiring whether a ('value',

not key)]

[a file].

Let suitably decorated

id's and k's denote file names,

respectively

keys. Then:

(7)

s l { i d l , i d 2 ..... id n}

seems to be an acceptable

f ] { k l , k 2 ..... k m}

abstraction

for the operation of restricting

the files of a system to those of the indicated names -- i.e. deleting all other!

[respectively

are different from k.

deleting

all those file records whose keys

(l
Combining

the above operations:

(i')

8 + [ id "~ s(id)

U [k-~r] ]

+ [ id -~ s(id)

+ [k-~r] ]

(2') (3')

s + [ id-~

(s(id)'-{r}

]

(4')

(s(id) ) (k)

(5')

k 6 dom(s(id))

(6')

r £ rn~(s (id))

(7')

s + [ id -* ( ( s ( i d ) ) l { k l , k 2 ..... kn})

we get the right column equivalents,

]

on a file system.

93

4.4 MAP-oriented C o m b i n a t o r s

The same combinator:

the for-all-do statement,

as was d e f i n e d for

p r o c e s s i n g sets, is a v a i l a b l e for p r o c e s s e s on maps,

e.g.:

for all d 6 dommap do S(map(d))

We give the imperative v a r i a n t of the last of the three implicit, a p p l i c a t i v e map c o n s t r u c t i o n s shown in the example

25.

dal system := [] t,~<e (Fid ~ (Key ~ REC)), file := [] t _ ~ (Key ~ REC); (for all fid 6 doms

Ci/~

:=

d_~o

[] ;

for all k £ doms(fid) d_~o := ( c ~ )

:= ( c _ ~ )

U [ k ~ Fr ((s(fid))(k)) ] ;

u [ lid ~ Col!{ ~) ]))

4.5 F u r t h e r E x a m p l e s

Examp!~ ~ :

The i n t r o d u c t o r y example of this section is now continued.

We are

now i n t e r e s t e d in d e f i n i n g a number of a u x i l i a r y functions applicable to the o p e r a t i n g system directory. A f u n c t i o n for c a t a l o g u e i n g new entries,

i.e. new resources,

f u n c t i o n of u n c a t a l o g u e i n g e.g.

has

a l r e a d y been shown. The dual

takes a d i r e c t o r y and a non-null

r e s o u r c e name and deletes the d e s i g n a t e d resource -- i.e. returns a d i r e c t o r y in w h i c h the r e s o u r c e name is no longer a valid name:

94

1.0

u n c a t a l c g ( d i r , q)=

.I

cases

.2

q:

(

.3

T

~ dir

t_~:

Provided

~ dir~{id} +

[ hq

DIE R i d +

~

~ uncatalog(dir(hq),~q)

] )

DIR

q indeed does d e s i g n a t e

some r e s o u r c e

in dir~

q, id, r) ,q~)

= dir

When

such is

the case we can show that:

uncatalog(catalog(dir,

A function

for testing w h e t h e r

deed d e s i g n a t e

a non-null

something m e a n i n g f u l l

resource

name,

in a directory,

q, does

dir,

in-

is e.g.

the following:

i s u a l i d r n ( d i r , q) = q 6 r e s n m s ( d i r ) type:

D I R R i d + ~ BOOL

where:

3.0

resnms(dir)= [ ~rn

.i

I rid £ domdir ^ (is-DIR(dir(rid))

.2

T

.3 type:

another

4.0

DIR

~ rn6resnms(dir(rid)), ~ rn = <>)

}

~ Rid+-set

f u n c t i o n w o u l d be:

isrnok(dir,q)=

.i

(hq

.2

^(cases

6 dom dir) t q:

.3

(<>

~

trues

.4

T

~

isrnok(dir(~

type:

DIR

Rid +

~

q ) , ~ q)))

BOOL

w h e r e we rely on the n o n - c o m m u t a t i v e n e s s ,

in the m e t a - l a n g u a g e ,

the b o o l e a n

for r e t r i e v i n g

given

^ and v operators.

its name could

e.g.

A function

be expressed:

of

a resource

g5

5.0

.i .2

retrieve(dir, q)= cases q: ( ~ dir(id)~

.3

T type:

~ retrieve(dir(~q),~q)) DIR Rid +

The d o m a i n e x p r e s s i o n

~

Rid m RES

RES also defines the void map,

from no r e s o u r c e i d e n t i f i e r s to no resources,

[],

as part of its domain.

In some of the above f u n c t i o n d e f i n i t i o n s we have tacitly assumed that no

(embedded)

d i r e c t o r y was empty. A p r e d i c a t e function for

testing this w e l l - f o r m e d n e s s c r i t e r i a not e x p r e s s e d by the domain e x p r e s s i o n s m i g h t e.g.

6.0

.i .2 .3

look like:

is-wf-DIRo(dir)= (dir~[]) A(Vrid 6 dom dir) (ia-DIR(dir(rid)) type:

D is-wf-DIR ° (dir(rid)))

DIR ~ BOOL

File i d e n t i f i e r s are part of the directory.

If we e.g.

impose that

no two d i s t i n c t r e s o u r c e names, via d e s i g n a t e d file identifiers, "point" to identical files,

then the above is-wf-DIR ° m u s t be aug-

mented:

7.0 .i .2 .3 .4 .5

is-wf-DIR(dir)= i8-wf-DIRo(ir) A(Vrnl,rn 2 6 resnms(dir)) ((rnl~rn 2 ) ~(((is-Fid(retrieve(dir, rnl))Ais-Fid(r~trleve(dir, rn2) ~(retrieve(dir, rn 1) # retrieve(dir, rn2))))

96

ExamR! ~, 30:

Another

In this example we shall m o t i v a t e the m o d e l i n g of the s c o p e - b i n d i n g and variable concepts of block- & p r o c e d u r e - o r i e n t e d p r o g r a m m i n g languages by means of so-called environments, In s u b s e q u e n t examples,

r e s p e c t i v e l y abstract

(31,40,42,61), we shall then illustrate the se-

m a n t i c s m o d e l i n g of p r o c e d u r e s and blocks of such languages. duction,

stores.

into our realm of a b s t r a c t m o d e l i n g concepts,

and stores will now be argued in a few, short,

The intro-

of e n v i r o n m e n t s

illustrative,

but not

really c o m p l e t e steps. The n o t a t i o n used in the f o l l o w i n g for some arbitrary,

r e a l i s t i c source languages notions of b e g i n - e n d blocks and

v a r i a b l e d e c l a r a t i o n s and use has been d e l i b e r a t e l y c h o s e n to c o i n c i d e w i t h the m e t a - l a n g u a g e s however,

n o t a t i o n for the same constructs.

These will,

not be formally introduced till section i0.

The form:

(dcl v := e x p r type D;

C(..,)) is taken to r e p r e s e n t some source languages block c o n s t r u c t e q u a l l i n g begin,

and ")" the end).

In the semantics of this source lan-

guage v, w h i c h itself is an identifier, In fact:

in this source-,

tion of identifiers

iS

is to denote something constant.

as well as in our meta-,

c o n s t a n t over their scope,

The c o n s t a n t d e n o t a t i o n of v over the above block, scope,

is, rather c o n c r e t e l y speaking,

address)

(with "("

language,

the denota-

i.e. does not change! i.e. its d e f i n i n g

taken to be the location

(or:

of the storage cell in w h i c h are to be held values, ~v, of the

v a r i a b l e v. Thus, locations,

if by LOC, we denote the a b s t r a c t d o m a i n of storage

and by OBJ,

the values w h i c h can be held in those locations,

then the domain of storages can be a b s t r a c t e d as:

L O C ~ OBJ m We choose ~ since there will, at any point of e x e c u t i o n of our source m p r o g r a m % only be a finite number of active variables, i.e. of a l l o c a t e d storage cells. Thus we a b s t r a c t storages as u n i q u e associations, m a p s from locations to their values. To keep track of the location that v a r i a b l e identifiers denote we introduce,

speaking concrete again,

a table, h e n c e f o r t h called an environment,

in w h i c h is r e c o r d e d the a s s o c i a t i o n s of v a r i a b l e names to their locations.

97

Id ~ LOG m

where e.g. v £ Id. A g a i n the a s s o c i a t i o n is functional,

and again the

f u n c t i o n a l recordings are finite. Before a r g u e i n g why we do not directly m o d e l storages as:

Id

~.

m

OBJ

let us first see that we do indeed need the full use of the m e t a - l a n guage M A P concept, plify

'snapshots'

i.e. of the MAP operations. of environments,

of one simple block,

S i m u l t a n e o u s l y we exem-

p, and stores,

d. The example is that

c o n t a i n i n g the d e c l a r a t i o n of the v a r i a b l e named i,

nested in an outer block,

also c o n t a i n i n g the d e c l a r a t i o n of a identi-

cally named variable.

++~ + ÷ ÷ e + ÷ ÷ + + + + ÷ + ÷ + ÷ ÷ ÷ ÷ ÷ + + ÷ ÷ + + + + ÷ + + ÷ + ÷ + (p 0" ~ 0 ) ( dcl.., i := . . . ; t ÷ ÷ + + + ÷ + + + ÷ ÷ ÷ + + ÷ + ÷ + + ÷ ÷ ( P l , O l )

~+~+÷÷÷÷+÷++÷÷~÷÷+ .......... ÷÷÷C~i, ( del

i

:: ...;

oi')

... A~

L ÷ + + + + + ÷ + ÷ ÷ + ÷ ÷ ÷ + ( p ~" ~ 2 )

...

•

"

,.,

•

"

"

•

"

"

. , .

"

$~+÷+++++++++÷÷++÷÷÷÷+÷÷+÷+ ( P 2" ~ 2 ') )

[ + + + + + + + + ÷ + + + ÷ ÷ ÷ ÷ ÷ ÷ + ÷ ÷ ÷ ÷ ( P 1" °1 ") [ ÷ + ÷ + + + + + + + + + + + + ÷ ÷ ÷ ÷ + + ÷ ÷ ÷ ÷ ÷ ÷ ÷ ÷ + ( Pl ' ~1 "' ) )

[ + + + + + + + ÷ + ÷ + ÷ + ÷ ÷ + + ÷ + + + ÷ + ÷ + + + + (P O" ~ 0 ')

The e n v i r o n m e n t i m m e d i a t e l y prior to outer block e l a b o r a t i o n is P0 and the state is d 0. These are not detailed. O b e y i n g the results in the e l a b o r a t o r c l a i m i n g a new, us call its l o c a t i o n li I . Thus:

sl

=

~0 u [li I ~ 01 ]

Pl

=

PO + [i -~ li I]

with:

'first' d e c l a r a t i o n

fresh storage cell for i, let

98

Thus we use U as an a b s t r a c t i o n U since

of the storage

of the e n v i r o n m e n t

n a m e l y be a l r e a d y

in P0" O b s e r v e

"falling

the

recorded

through"

~1' where

=

this,

' on ~0 shall

~2

=

a I' U ['li2 -~ 02 ]

the storage

claimed

the storage

for the inner blocks'

e.g.

PI' r e m a i n

=

SO"

00'

=

01'~{Ii1}

i.e.:

i to e.g.

of storage

-- w h i c h

example.

a recursively of n e s t e d

are the semantics

31 and onwards

for d e c l a r e d

variables

follow

is: ~.

for the use of b o t h e n v i r o n m e n t s

j would permit modeling

[part of]

in the outer block.

as p a r t of the b l o c k epilogue.

of nested b l o c k s

convincing

not

~0"

justification

not solve the p r o b l e m

example

=

deallocation

The above e x a m p l e

fresh,

]

is p e r f o r m e d

abstracting

~ is also

aO" U ['liI ~ 01"]

U [li I ~ 0 1 "

or d e a l l o c a t i o n

(o1')! And:

i.

constant

01"

=

this b l o c k m a y

gO' U [li I -~ Ol',li 2 -~ o 2 ]

~2'~{li2}

is not a s u f f i c i e n t l y

In

=

=

any b l o c k was

to P0

PO + [i -. li 2]

01"

We n o w turn to a brief

locations

=

aO" U [li I ~ 01",li 2 ~ 02']

structure,

outside

i m a y have been u p d a t e d

=

and stores.

-- i m a y

Similarly:

a 2'

The MAP o p e r a t o r

action

that we do "fall back"

block.

for the outer blocks'

how environments,

freeing,

would

'update'

that v a r i a b l e s

Also

Pl + [i -* li 2]

with

inner

indicate

updated.

=

clash i n g

the b l o c k

the outer,

P2

That is:

Thus

--

~0' U [li I -* o1']

have had their v a l u e s

Observe

operation

li I is new, i.e. not in the d o m a i n of 00: li I .~6 dom ~0 ~ But

we use + as an a b s t r a c t i o n

when

allocation

redefining

Static

stores

defined

renaming

variable of e.g.

names the

as Id ~ OBJ. If, however, m p r o c e d u r e static r e n a m i n g

activations'

we n o r m a l l y

i denoting

distinct

expect!

we use ENV and s o m e t i m e s

X as follows:

99

ENV

= =

Finally,

Id ~ LOC m LOG ~ OBJ m

as a last example, we show the m o d e l i n g of v a r i a b l e referencing,

value access and of assignment.

'state'

For the e l a b o r a t o r modeled

(p,a) e l a b o r a t i o n of some V £ d o m p

is

(a) as:

v

i

p(v)

A c c e s s i n g the contents of a v a r i a b l e v:

c v

~(O(v))

i

and a s s i g n i n g the o b j e c t

v

o

:=

•

(value) o to v a r i a b l e v changes the state d to:

~

+

[p(v)

~

o].

The v a r i a b l e s of some source l a n g u a g e are either of scalar or array type w i t h all array objects being scalars. V a r i a b l e references, are to scalars only,

The £ £ ~ S ~ ! S

~2~!~

however,

i.e. not to arrays or a r r a y - s l i c e s thereof.

of v a r i a b l e d e c l a r a t i o n s of a block can be m o d e l e d

as a m a p from v a r i a b l e name i d e n t i f i e r s to their type:

1

Block

::

(Id ~ T y p e )

...

Stmt

Type

::

Scalar-type

[ E x p r +]

with :

2

i.e. w i t h types having an o p t i o n a l

[...] array u p p e r bounds e x p r e s s i o n

list, E x p r +. If the o p t i o n a l part is absent,

i.e. nil,

the v a r i a b l e is

a scalar.

The c o r r e s p o n d i n g

£eman~i~ ~2~5!~ of storages can be m o d e l e d as a map

from scalar l o c a t i o n s to scalar values.

100

3

STG

=

(Bool-loc

~ Bool) m

4

Bool

=

BOOL

I undefined

5

Intg

=

INTG

I undefined

U (Int-loc ~ Intg) -m

where:

E n v i r o n m e n t s keep track of v a r i a b l e name associations:

6

ENV

=

Id ~ L O C m

with :

7

LOC

= Scalar-Lot

i Array-Loc

8

Array-Loa

= (Nl++÷m I n t - L o c )

9

Scalar-Loc

= Int-Loc

U (Nl+÷÷m B o o l - L o c )

I Bool-Loc

with the c o n s t r a i n t that the integer index lists of any g i v e n array l o c a t i o n forms a 'rectangle':

i0.0

(Vl 6 A r r a y - L o c )

.i

(3il E N l + ) ( d o m I = r e c t a n g l e ( i l ) )

w h e r e we i n f o r m a l l y e x p l a i n rectangle:

ii.0

rectangle() =

.1

{

The il

'picked'

is

array-dimension,

(to be)

I i k E { l : u b k} ^ l
the tuple, whose length c o r r e s p o n d s to the

and whose k'th e l e m e n t

for the k'th dimension,

dcl STG

(here) as a global m e t a - v a r i a b ! e ,

ST G:

:= [] type STG

In the block p r o l o g u e are

(ub k) is the upper-bound index

all of w h o s e lower-bounds are 1!

A p a r t i c u l a r storage is m o d e l e d

12

}.

(automatically)

(.1-.2)

allocated,

in the block epilogue:

locations of b l o c k d e c l a r e d v a r i a b l e s and these are likewise freed

(.4-.8)

101

int-Block(mk-Block(dclsj...,stl))(p)=

13

.!

(let P' : P + [id ~ get-loc(dcls(id))(p)

.2

iid

£ domdcls

.3

int-Stmt-list(stl)(p');

.4

let loc8

.5

let 81oc8 = { l I ((l£1ocs)

= { p'(id)

.6

Iid

] ;

E domdcl8

} i_~n

^ is-Scalar-Lot(l))

v((1 6 rng al) ^ (al E lots) ^

.7

is-Array-Loc(al))}

.8

:= e S l G

STG

~

~n

sloes)

with:

get-loc(mk-Type(sctp,

14.0 .i

if bdl=nil

.2

then

bdl))

(p)=

(let 1 6 Scalar-Loc

.3

.4 .5

ST~ := ~ S T G

.6

return(1))

be s.t. (Z~£ domcST__.~G)^

1-tp-match(sctp, 1)) U [l~undefined];

else

.7

(let ebdl

.8

: < eval-Expr(bdl[i])(p)

I 1 < i < lenbdl>;

if {3i £ {l:len ebdl})(ebdl[i]<1)

.9 .I0

then error

.ii

else (let 1 £ Array-Lot

.12

be 8.t.

((sol £ rn~ 1)~ 1-tp-match(sctp, sol))

.13 .14

A(dom 1 = rectangle(ebdl))

.15

A(Crng I N d o m c STy) = {});

.16

ST G := ~ S T G

.17

return(l)))

U

[ sol-undefined

I scl £ r n ~ l ] ;

and

15.0

1-tp-match(tp, 1) = ((tp=BOOL) (tp=~NT)

.1

Assuming

16

(i.e.

that the state,

Z

=

~ is-Bool-Loc(1), ~ is-Int-Loc(1))

Z, is d e s c r i b a b l e

as:

S[G ~ STG

Z is a o n e - p o i n t

m

(ST G) map),

the type of the above

functions

are:

102

type:

5.

int-Block:

Block ~ (E~V ~ (Z ~ Z))

get-Loc:

Type

~ (ENV ~ (~ ~(X LOC)))

rectangle:

NI+

~ (N1+)-set

TREEs

Ex_amples

32-33:

Blocks of some source language consists of three d i s t i n c t parts: an u n o r d e r e d set of variable ly named procedures

(Var-set

declarations,

an u n o r d e r e d set of d i s t i n c t -

and an ordered sequence of one or m o r e statements.

Id ~ Proc m

Stmt +)

The above is a domain expressions. If Var denotes the d o m a i n of v a r i a b l e identifiers,

Id that of p r o c e d u r e identifiers, Proc the domain of pro-

cedures and Stmt

the domain of statements;

then the above domain ex-

p r e s s i o n abstracts a nameless d o m a i n of blocks.

These are trees, whose

first s u b c o m p o n e n t s are sets of v a r i a b l e names,

second s u b c o m p o n e n t s

are maps from

identifiers to procedures,

and whose last subcompo-

nents are tuples of statements.

If suitably d e c o r a t e d v's,

id's, p's and s's stand for variables,

p r o c e d u r e names, procedures,

•

and statements,

then:

•

mk( {V l,V 2, . . ,v v} , [id1~Pl , td2~p 2 , . . . ,idp~pp], <s 1,s 2,.. . ,s

>)

and:

({V I,v2,o..,vv }" [idl~p1"id2~p2"" °''idp~Pp]'<Sl"S2"'"

"'e8>)

(the latter c o n s t r u c t o r e x p r e s s i o n having dropped the nameless constructor function, mk) objects.

r e p r e s e n t the way we write down such c o m p o s i t e

If b is a block, or more precisely,

d o m a i n s p e c i f i e d above,

let mk(vs,pm, sl) = b; let

if b is an object in the

then the following m e t a - l a n g u a g e combinators:

(re,pro, s1) = b;

103

provide

means

modelling

of d e c o m p o s i n g

blocks,

variables,

vs;

the s t a t e m e n t

The d o m a i n

into their p r o p e r

the m a p list,

tree

structured

constituents

from p r o c e d u r e

names

objects,

-- here

here

the set of

to procedures,

pm;

and

sl.

expression:

(s-Vars:Var-set

(with inner

(,)'s,

miter)

defines

three

selector

s-stmtl.

nameless

s-procm:(Id

around

Id m Proc,

the same d o m a i n functions,

s - s t m t l : Stmt +)

~ Proc)

m

used o n l y as s y n t a c t i c

as above,

but in a d d i t i o n

here a r b i t r a r i l y

named:

s-vars,

deli-

defines s-procm~

NOW:

let vs = s - v a r s ( b ) , pm = s - p r o c m ( b ) , sl = s - s t m t l ( b ) ;

has

the s~ne e f f e c t

other w o r d s ,

if

vs

as the p r e v i o u s

£ Var-set,

s - v a r s ( m k ( v s , p m , sl))

=

vs,

s - p r o c m ( m k ( v s , p m , sl) ) =

pm,

s-stmtl(mk(vs,pm,

sl.

We can give

sl))

=

sl

a name to the above block domain,

Block

-- note

decomposition

pm 6 I d ~ P r o c , m

::

the d r o p p i n g

Vat-set

of

(,)'s!

Id

With

~ m

combinators.

£ S t m t +,

e.g.

In

then:

Block:

Stmt +

Proc

vs, pm

and sl as before:

m k - B l o c k (vs, pm, 81)

would

~2~ have

to be our way of w r i t i n g

The trees d e n o t e d introduce

by B l o c k

selectors:

are now named

down

instances

(Block).

of blocks.

Also here we could

104

Block

::

(where the limiters).

s-vars:Var-set

s-proem: (Id ~ Proc) m

(,)'s, around Id ~ Proc, m And again:

s-stmtl:Stmt +

again are used as syntactic

s-vars(mk-Block(vs,...,...))

= vs

etc.. A benefit derived from naming the class of constructed objects,

here Block,

de-

tree

is that any object can be tested for member-

ship of the named domain:

is-Block(b)

is true provided

b is the result of some m k - B l o c k ( v s , p m , sl) -- for

any applicable vs, pm and 81.

5.1

D efinin~ Domains o_~f TRE___~EObjects

Two means of defining domains of tree objects exist in the metalanguage: (i)

Named:

Using the abstract

syntax rule d e f i n i t i o n

:: to separate definiens

D

(2)

AnonymOu§:

::

D I D 2 ... D n

Using the domain expressions

operator

(D 1 D 2 ... D n)

The former defines named or root labelled

(i)

{ m k - D ( d l , d 2, ..°, d n)

trees:

I i s - D .(d.) for all i }

The latter defines unnamed trees: (2)

{ mk(dl,d2,...,dn)

or, dropping

the mk:

symbol

from definiendum:

I i s - D i ( d i) for all i }

(...),

105

{ (dl,d 2 .... ,d n)

{ i s - D i ( d i) ~ o r all i }.

Exam~!~ 34: Statements while-do

Observe

of a source

statements

Stmt

=

Asgn

Asgn

::

Id E x p r

While

::

E x p r Stmt

IfThen

::

E x p r Stmt

are e i t h e r

assignment

statements,

statements:

J While

I IfThen

h o w the two last domains:

{ mk-While(e,s)

I is-Expr(e)

^ i8-Stmt(s)

}

{ mk-IfThen(e,8)

i is-Expr(e)

^ i8-Stmt(s)

}

are d i s j o i n t tions,

language

or if-then

-- simply b e c a u s e

mk-While

5.1.I

and m k - I f T h e n ,

Tree C o n s t r u c t o r

For any two D' and D" structing

abstract

the n a m e s of their o b j e c t m a k e

Axioms

identifiers

syntax

rules:

D'

::

A 1 A 2 ... A m

D"

::

B 1 B 2 ...

Bn

objects:

m k - D ' (al, a2, . . ., am), m k - D " ( b 1, b 2, • . ., b n) are i d e n t i c a l

if and only

func

are distinct:

if

(iff) :

being definienses

of tree con-

108

D' is the same i d e n t i f i e r

as D";

~ ~ n; ai

= bi

for i.e.

that is,

all

i,

if A. is the same

iff the two rules

For any two i m p l i c i t

above

identifier

as B.

are the same.

tree d o m a i n d e n o t i n g

expressions:

(A 1 A 2 ... A m) (B 1 B 2 ... B n) objects:

mk(al,a2,...,am) m k ( b l , b 2 , . . . , b n) or, w h i c h

is the

same:

(al,a2,...,a m) (bl,b 2 .... ,b n) are identical

iff:

m = n, a.=b. Ai

Example

is

the

and

same identifier

as

Bi

for

all

i.

35-36:

The a b s t r a c t

syntax

CTLG

=

Define

::

are i n t e n d e d

CaTaLoGues,

rules:

Fid ~ (Ktp Dtp) m Fid (Kip Dtp)

to define

the s~mantic

respectively

domain

thesyntactic

of file d e s c r i p t i o n

domain

of file d e f i n i t i o n

107

commands.

To each file,

in the catalogue,

i d e n t i f i e d by its name

is associated,

its d e s c r i p t i o n -- namely a 'pair' c o n s i s t i n g of a

Key type-, and a D a t a type-

indication,

A file d e f i n i t i o n c o m m a n d names,

(fid 6 Fid),

(in Fid)

say lid,

and gives the Key type-,

an object likewise in (Ktp Dtp).

i.e. an o b j e c t in (Xtp Dtp). the file to be defined

and Data type

indication,

In p a r t i c u l a r a catalog,

i.e.

ctl~, m a y

look like:

[ fid I ~ mk(ktPl,dtPl) , fid n ~ mk(ktPn, dtPn)

],

w i t h a define c o m m a n d looking like:

mk-Define(fid, mk(ktp, dtp)). D r o p p i n g the s o m e w h a t superfluous m e n t i o n i n g of the o t h e r w i s e nameless mk

define

(prefixing command,

(...)), we get that ctl~,

upon e x e c u t i o n of the

is a u g m e n t e d to:

ctlg U [fid ~ (ktp, dtp)] provided,

of course lid ~ 6 dom ctlg]

As a n o t h e r example of n a m e l e s s tree c o n s t r u c t i o n s

let us a b s t r a c t

the syntactic d o m a i n of p n o c e d u r e s of some source language

Proc

::

:

(Id Tp) ~ Block

(Id Tp) ~ could be w r i t t e n Parm a , i.e.:

The form

Proc

::

Parm ~ Block

::

Id Tp

provided:

Parm

In the former case the p a r a m e t e r

list is a b s t r a c t e d as a p o s s i b l y

108

z e r o - l e n g t h tuple of parameters, trees,

themselves being

their Types

these being a b s t r a c t e d as n a m e l e s s

'pairs' of formal p a r a m e t e r I d e n t i f i e r s and

(not being further specified).

p a r a m e t e r s are a b s t r a c t e d as named d e c o r a t e d id's, spectively,

(Parm)

In the latter case these trees. Given that s u i t a b l y

tp's and b's denote objects in Id, Tp and Block,

we get,

in the two cases,

re-

that:

mk-Proc ( <( idl, tP l ) , (id2, tP 2) .... , (idn, tPn ) >, b) respectively:

m k - P r o c ( <mk-Parm (id 1, tP l) , . . . , m k - P a r m (idn, tPn)>, b) display instances of p r o c e d u r e s a c c o r d i n g to either abstraction.

Thus

observe that the (,)'s in (Id Tp) ~ serve the double f u n c t i o n of constructing a domain of a n o n y m o u s trees, as well as i n d i c a t i n g the scope of the tuple d o m a i n b u i l d i n g

~ operator.

5.2 R e p r e s e n t i n g Instances o_~f TRE___EEObjects

G i v e n objects oi, e.g.: DI,

D2,

02,

...,

Dn,

(oi,o2,...,On), denote

(identical)

...,

o n of not n e c e s s a r i l y d i s t i n c t domains,

the c o n s t r u c t o r expressions:

m k ( O l , O 2 , . . . o n)

tree objects of domain:

(D I D 2 ... D n) i.e. an anonymous tree. Given that there exists an a b s t r a c t syntax rule of the form:

D

::

D I D 2 ... D n

the c o n s t r u c t o r expression:

m k - D ( O l , O 2 , . . . , o n) denotes a tree object of domain D, i.e. a root labelled tree.

409

5.3

TREE

Operations:

Selector Functions

The only special o p e r a t i o n d e f i n e d on T R E E s

is the selector function.

Names of s e l e c t o r f u n c t i o n s are either explicitly,

or implicitly,

de-

finable.

E x p l i c i t l y D e f i n e d S e l e c t o r F u n c t i o n Names

In the named tree c o n s t r u c t i n g a b s t r a c t syntax rule:

D

::

s - n m 1 : D 1 s - n m 2 : D 2 ...

s-nml:D l

as well as in the a n o n y m o u s tree c o n s t r u c t i n g d o m a i n expression:

(s-nm1:D 1 s-nm2:D 2 .~

s - n m l : D l)

the i d e n t i f i e r s :

8-nml,

8 - n m 2,

...,

s-nm l

denote selector functions obeying:

s-nml(mk-D(Ol,O2,°

~.,ol))

8-nm2(mk-D(Ol,O2,...~Ol))

=

e1

=

02

=

ol

. . .

s-nml(mk-D(Ol,O2,...~Ol)) respectively

8-nm1((Ol,O2,...,o 8-nm2((oi,o2,.

l)

=

o1

• .,o l)

=

02

• .,o l)

=

ol

. ° .

s-nml((ol,o2,. for all Ol,

0 2 ....

, oI .

In the above, explicit,

selector f u n c t i o n name d e f i n i n g forms,

assumed that all i d e n t i f i e r s

s - n m i and 8 - n m j

w i s h to omit any subset of these, past.

are distinct.

it is

You may

including all, as we have done in the

110

!~!i~!~!Y

Defined Selector F u n c t i o n Names

A s s u m i n g uniqueness of D.

D

::

, for some or all i in {l:l} in:

D 1 D 2 .,.

Dl

respectively:

c~

o~),

D2 . . .

and in particular,

a s s u m i n g that D° is an identifier,

the above two tree

d o m a i n c o n s t r u c t i n g forms define the selector function:

s-D i .

In the source language S t a t e m e n t

8-Id

Stmt

=

Asgn

Asgn

::

Id Expr

While

::

Expr

applies to A s g n

to A s g n

and While

plies to While size:

I While

Stmt

objects and yields ~he Id component;

objects and yield the E x p r component;

objects and yield the p r o p e r Stmt

'proper component'

syntax rule,

syntax rules:

since any While

is itself a Stmt

s-Expr

applies

and 8 - S t m t

component.

ap-

We empha-

object, by the first a b s t r a c t

object.

N 2 n z U n i ~ u e Selector F u n c t i o n Name C o n v e n t i o n

For the common case w h e r e two or m o r e identifiers,

D

::

D 1 D 2 ...

D1

or:

(D I D 2 ...

are the same,

o l)

the following c o n v e n t i o n is adopted:

D i and Dj,

of either:

1It

In

the form D 1 D 2 ...

the same

identifier,

s-C-I,

s-C-2,

are the s e l e c t o r respectively

In the source

For

object

...

For

::

Id E x p r

If

::

Expr

function

components

and s - S t m t - i

::

~ For

select

C component

of

the Ist,

the 2nd,...,

-- from left-to-right.

syntax rules:

I If

Expr

Stmt

Expr

Stmt ~

Stmt

s-Expr-lj as w o u l d

s-Expr-2 s-init,

Id s - i n i t : E x p r

and 8 - S t m t - 2

and s - e l s e

If

which

Statement

=

For

s-then

functions

the kth p r o p e r

language

occurrences

. . ~j s-C-k

Stmt

the s e l e c t o r

D l let there be k d i s t i n c t

say C, then:

selects

and s - E x p r - 3

s-step

select

and 8 - l i m i t

s-step:Expr

in:

s-~imit:Expr

the same I f o b j e c t

the same

Stmt*;

components

as w o u l d

in:

::

Expr

s-then:Stmt

s-else:Stmt.

leaves

unexplained

the names of the i m p l i c i t l y

E~og~_a.~_!n~ N o t e s The m e t a - l a n g u a g e fined s e l e c t o r

and:

functions

Block

::

For

::

Id-set

(Id~Prc) Stmt ~ m s-cv:Id (s-i:Expr s-b:Expr

In the

latter

form there are only

tions,

namely

the two s e l e c t i n g

objects

de-

in such forms as:

s-t:Expr) + Stmt*

two i m p l i c i t l y

the

(Expr

Expr

defined

selector

func-

Expr) + and Stmt ~ tuple

of For objects.

The r e a s o n

for i n t r o d u c i n g

pragmatic.

That

is:

there

explicit is,

selector

in m o s t cases,

function

names

no t e c h n i c a l

is m o s t l y

need

for in-

112

venting

names.

tor functions

To see "this,

recall

is to select p r o p e r

that the t e c h n i c a l

of selec.

of trees.

But this

use of the m k

function!

Let e.g.

t into its n subcomponents.

So w o u l d :

could as well be done by a

(sub-)components

purpose

'reverse'

t be an o b j e c t of

(D I D 2

then:

the

...

let

clause:

let

(oi,o2,

so-to-speak

Dn) ,

.... o n ) =

decomposes

let

01

=

o2 =

t

S-Dl(t), 8-O2(t)

,

o.°

o

=

s-D

n

provided,

of course,

for D objects

D

leading

all D i were

distinct

t, where:

::

DI D2

...

Dn

to:

let

etc..

(t) n

mk-D(Ol,O2,...,o

n)

=

t

(and)

identifiers!

Similar

1t3

6 FUNCTIONs By a function, we shall -- in a s o m e w h a t c i r c u l a r fashion -- understand an o ~ e { a ~

which, w h e n ~ ! ~

call its ar~_um_en~ ~ ! ~

to something, w h i c h we shall

a c e r t a i n thing as the v a l u e of the f u n c t i o n

for that argument.

The object to w h i c h the function is applicable, g u a r a n t e e d to yield a v a l u e

(defined result),

i.e. for w h i c h it is

c o n s t i t u t e s the d o m a i n

of the function. The y i e l d e d values c o n s t i t u t e the ~an~e domain)

(or: co-

of the function.

Two functions are i d e n t i c a l iff they the same range, and

(i) have the same domain,

(2)

(3) for each a r g u m e n t in the d o m a i n the same va-

lue. FunCTion e q u a l i t y is, however,

not a d e f i n e d operation.

To denote the value of a f u n c t i o n for a given a r g u m e n t we write a name of the function, a; the latter,

say f, f o l l o w e d by a name of the argument,

say

the former or b o t h p o s s i b l y e n c l o s e d b e t w e e n paren-

theses:

fa, f(a),

(f)(a)~ (fa), (f}a

M a n y functions can m o r e easily be d e s c r i b e d algorithmically,

i.e. by

a recipe for how to compute the result value g i v e n an a r g u m e n t value, than by e x p l i c i t or i m p l i c i t enumeration. Moreover, such,

functions, w h i c h we w i s h to m a n i p u l a t e

some,

if not m o s t

(create, pass and apply) f

have an infinite d o m a i n -- and by the p r a g m a t i c s of MAPs could not be c o n s t r u c t e d as such. Finally: m a n y functions can best be d e s c r i b e d in an implicit,

or even recursive,

the image, or thought, finitions.

way, w h i c h c e r t a i n l y does not conjure

of its graph being c o m p u t e d at the time of de-

(By the g r a p h of a f u n c t i o n we u n d e r s t a n d the set of all

a r g u m e n t result

'pairs'.)

For m a p s this g r a p h is indeed being c o m p u t e d at "time" of definition, w h e r e a s we m a y think of this g r a p h never b e i n g c o m p u t e d in c o n n e c t i o n w i t h the k i n d of f u n c t i o n d e f i n i t i o n s we are i n t e r e s t e d in in this section.

114

Ex_am_ples 39-40:

The following

is a b l o c k - e x p r e s s i o n

is that of the d e n o t a t i o n

of the m e t a - l a n g u a g e ;

of f, w h i c h

is the factorial

(le.~ f(n) = if n=O then I else nxf(n-1)

its v a l u e

function:

in

f)

Let,

as another

cedure

example,

the p r o c e d u r e

name -- and p r o c e d u r e

stract s y n t a c t i c a l l y

Prc

::

body,

describable

of some

The m e a n i n g

- name),

language

of p r o c e d u r e

be ab-

definienses

Id of the d o m a i n of formal p a r a m e t e r statement

of a procedure,

according

source

of pro-

Id ~ Block

Block of blocks -- as e.g.

may,

-- e x c l u s i v e

as:

Here Prc is the name of the d o m a i n der + body,

header

i.e.

to the school

a function

from a r g u m e n t

denotation

of these

and

blocks.

the d e n o t a t i o n

of m a t h e m a t i c a l

of a p r o c e d u r e

semantics,

lists to the d e n o t a t i o n

latter

(hea-

names,

are functions

Of blocks.

from states

name,

be taken as If the

(Z) to states

then:

Prc: ARG ~ ~ (Z ~ Z) a Pro object,

Given give

prc,

the f u n c t i o n w h i c h

i.e. itself

one of the form mk-Prc(idl, bl), we now yields

a last preparation,

procedure

rather

environment.

than c a l l i n g

the d e n o t a t i o n

denotations

of prc. Let,

be f u n c t i o n s

V-prc(mk-Prc(idl, bl))(O)(~) = (Set fct(al)(~) = (let p' = [ idl[i]~al[i]

J 1
I-Blk(bl)(o+p')(~))

fct) Observe place nored,

the following:

in a d e f i n i n g

evaluation

environment,

of a P r o c e d u r e p, and state,

and need thus not have been

shown.

as

of the d e f i n i n g

denotation

o. The state

takes is ig-

The r e s u l t of P r o c e d u r e

115

e v a l u a t i o n is a function, f c t . in the t h r e e - l i n e as follows:

let

This f u n c t i o n is c o m p l e t e l y d e s c r i b e d

clause. The d e f i n i t i o n g i v e n there can be read

is that f u n c t i o n w h i c h w h e n a p p l i e d to some a r g u m e n t

fct

list, al, and in some state,

~, will y i e l d a new state. This new state

results from I n t e r p r e t i n g the B l o c k ('slightly') fiers,

in the d e f i n i n g e n v i r o n m e n t

e x t e n d e d -- by the b i n d i n g s of formal p a r a m e t e r identito actual,

idl[i],

c a l l i n g state, function,

b~

call time, arguments,

al[i] -- and in the

~. We do not here d i s p l a y the I - B l o c k

elaboration

but see section 6.3.

6~! ' D e f i n i n ~ Domains of F u n C T i o n

Let A and B denote Domains.

Objects

To d e f i n e the class of i m p l i c i t l y l-de-

fined objects w h i c h are partial,

r e s p e c t i v e l y total functions

from

A into B, we use the d o m a i n e x p r e s s i o n o p e r a t o r s ~, r e s p e c t i v e l y ~: N

A -~B,

A -~B

A p p l y i n g the a b i l i t y to d e s c r i b e f u n c t i o n spaces to the b u i l t - i n o p e r a t i o n s of the m e t a - l a n g u a g e itself, we can now list the logical type of these: Sets:

type:

U:

SET

SET

~

SET

N:

SET

SET

~

SET

~:

SET

SET

~

SET

c:

SET

SET

~

B00L

c:

SET

SET

~

B00L

SET

~

SET

power: union: £ a,ard

OBJ

SET

~

SET

SET

~

BOOL

SET

~

NO

116

Tuples:

type:

~:

TUPLE

type:

~ TUPLE

h,

hd:

TUPLE

~ OBJ

t,

tl:

TUPLE

~ TUPLE

~,

fen:

[.]:

Maps:

TUPLE

TUPLE

TUPLE

~ NO

N1

~ OBJ

elems:

TUPLE

~ SET

ind:

TUPLE

~ N1-set

cone:

TUPLE

~ TUPLE

+:

TUPLE

MAP

~ TUPLE

~:

TUPLE

Nl-set

~ TUPLE

U:

MAP

MAP

~ MAP

+:

MAP

MAP

~ MAP

~:

MAP

SET

~ MAP

I:

MAP

SET

~ MAP

(.):

MAP

OBJ

~ OBJ

MAP

~ SET

dom: rn~: ":

MAP

MAP

~ SET

MAP

~ MAP

The reason why certain of these o p e r a t i o n s are partial functions will now be explained. just expresses: whereby:

SET-set SET-set. type:

The u n i o n o p e r a t i o n applies to sets of sets, S E T

sets of objects. We could get around this by w r i t i n g type:

union:

hd and tl applies

hd:

O B J + ~ OBJ,

SET-set

t kl:

OBJ + ~ O B J *

[i], m u s t have i lie in the i n d e x fined, type: MAP

conc cone:

~ SET,

i.e. u n i o n

to n o n - z e r o length tuples,

T U P L E ~ ~ TUPLE.

-- note totality.

set of the tuple,

is to tuples w h a t u n i o n

is to sets,

Updating

is total over

i.e.: Indexing,

otherwise unde-

i.e.

(+) tuple elements m u s t have

in (N I ~ OBJ) w i t h domain e l e m e n t s be in i n d e x set of tuple. So

not even:

type:

+:

TUPLE

(N 1 ~ OBJ)

~

TUPLE would make

+ total

over d e f i n e d domain.

6.2 R e p r e s e n t i n g Instances o f F u n C T i o n Objects This section is somewhat d i f f e r e n t l y o r g a n i z e d than were o t h e r w i s e c o m p a r a b l e earlier sections

(i.2 for i=2,3,4,5).

In a number of subsec

tions we recount basic aspects of so-called h-expressions.

117

We shall

shortly,

understanding

in a s e q u e n c e

of f u n c t i o n a l

forms w h i c h d e n o t e expressions

covered

gument-value

association

of de f i n i t i o n ,

and w h o s e

4. A n o t h e r

are used

is k n o w n

steps,

at an

to w r i t e

of forms were

the m a p

such form is that of X-

to define

(i.e. b e i n g

domain-range

arrive

The idea b e i n g

One such class

in section

Map e x p r e s s i o n s

small

abstraction.

functions.

9 ~ q ~ "

of eight

functions

fixed)

whose

ar-

at the instance

sets are i n d i v i d u a l l y

known

and finite.

Functional

Abstraction

(0)

There

are § ! ~ ! ~

(1)

Simple

names are either

thing,

or their d e n o t a t i o n

Composite

and

~2~2~

names express

of the w a y in w h i c h

proper

arbitrarily

names.

assigned

has b e e n a s s i g n e d

through

to denote

some-

an a r b i t r a r y

their s t r u c t u r e

name.

some a n a l y s i s

they denote.

(2)

A constant

is a p r o p e r

name having

(3)

A variable

is a p r o p e r

name w h o s e

a fixed,

denotation

or single denotation.

m a y range over a

set of values.

(4)

An e x p r e § s ! o n

is a name c o n t a i n i n g

o t h e r names

as proper

consti-

tuents.

Composite

(5)

names

A form is either more proper

(6)

are e x p r e s s i o n s .

In o r d e r

names

a variable

have been r e p l a c e d

to s p e a k a b o u t

form is we a b s t r a c t three

symbols:

or an e x p r e s s i o n

the

in w h i c h

one or

by variables.

function of a free v a r i a b l e

the form by p r e f i x i n g

that a

it w i t h a s e q u e n c e

of

a ~, the free variable and a dot.

ly.3+y is the f u n c t i o n of y that 3+y is; i.e. w h i c h increments any number by thr£e.

(7)

The p a s s a g e functional

from a fo_r_m to an a s s o c i a t e d abstraction.

function

is c a l l e d

118

Functionally

abstracting

ly.3+y,~x, hy.x+y r e s p e c t i v e l y by-3

function,

the a d d i t i o n (say)

lx. ly.x results

(of two numbers)

function

from

booleans

(y) to that integer x.

integers

a rather

detailed

names,

use of the concepts:

le

shall

imply the i n c l u s i o n

(identifier)s.

Forms

expressions

are h e n c e f o r t h

and the

functions

restricted

of simple

in the i n c r e m e n t function

(x) to c o n s t a n t

In the above we have e m p l o y e d

expression

3+y, x+y and hy.x into e.g.

the forms:

from

(say)

and not c o m p l e t e l y and forms.

constants

The term

and variab-

expressions.

~expressions

Any c l a u s e

(expression

or statement),

can be f u n c t i o n a l l y

abstracted,

not

variables,

(for f r e e / b o u n d

Functional

abstraction

clause,

whether

of the m e t a - l a n g u a g e

containing

free v a r i a b l e s

or

see below).

in zero v a r i a b l e s

is written:

~ () .c lause Writing,

in the m e t a - l a n g u a g e ,

the definition:

let f = h().clause or :

let f() = clause -- w h i c h

is e q u i v a l e n t

tion of no v a r i a b l e s

-- thus

scope of the definition, without

() shall

occurrence

i.e.

then denote

If the v a l u a t i o n then r e p e a t e d

f as a name

is. A n y s u b s e q u e n t

use in c o n t r a s t the function,

in the scope of the d e f i n i t i o n

the e l a b o r a t i o n

may r e s u l t

identifies

that clause

for the func-

occurrence

to definition,

whereas

in the

of f

any s u b s e q u e n t

of f of f()

shall denote

of clause.

of clause

occurrences

in d i s t i n c t

is d e p e n d e n t of f(),

f(),

i.e.

on a state

elaborated

clause,

-- not shown --

in d i f f e r e n t

'values'.

states,

T h e s e remarks

119

also apply

to functions

Functional

abstraction

lid I

of several v a r i a b l e s

in two or m o r e v a r i a b l e s

lid 2

.~

hid n

is w r i t t e n

either:

o clause

or :

l ( i d l , i d 2 .... , i d n )"

where n ~ 2 , traneous of

all i d ' s

and

to the m e t a - l a n g u a g e .

(for suitable

below)

distinct

substitutions

(D 2 ~

(...

...

Dn ~ D

... is a s h o r t e n i n g

Let i d .

range

of actual

over D, then the d e n o t e d

D1 ~

clause

~

for formal

function

(D n ~ D)

ellipsis

ex-

over D. and the values parameters,

see

is in the space:

...))

respectively:

D1 D2

The

former

form c o r r e s p o n d s

finckeling" permits ments,

of the m o r e

the a p p l i c a t i o n namely

Dk+ I ~

where

k+1

D' ~ D",

m-ary

~

of

the f i r s t

Such an a p p l i c a t i o n

n.

(strictly)

"currying" form.

less

a function

(Dk+ 2 ~

~

for m > O ,

(...

(D n

say)

also yield

= clause

~ ( i d l ~ i d 2 . . . . . i d m)

(k
a functional

will

or :

le t f =

k

n arguarguments.

in the space:

can be identified:

f(idl,id2~o.o,idm)

as here,

form also

D) ... ))

if D is a itself of n a r g u m e n t s

or "sch~n-

The former

than,

(from left-to-right,

[Of course,

let

latter,

then denotes

then a p p l i c a t i o n

functions,

to a s o - c a l l e d

familiar,

clause

space,

say

a function.]

120

where

no two id. and id. are the same.

in clause point

then the d e n o t e d

solution

to the

function

(recursive)

If f occurs

free

(see below)

is the s o - c a l l e d m i n i m a l

fix-

equation:

f(idl,id 2 ..... id m) = clause etc.

The m i n i m a l

subsequently. instead

fix-point

We could have

defining

finding

operation,

indicated

¥, will be e x p l a i n e d

any such i n t e n d e d

recursion

by

f by:

letrec f(idl,id2,...,id m) = clause respectively:

let f = ylg. h(idl,id2,...,idm) where

clause'

in clause

arises

from clause

. clause'

by s u b s t i t u t i n g

[Using g instead

of f on the r i g h t - h a n d

since -- u n d e r

the

side

letrec v e r s u s

is s t r i c t l y

We shall,

however,

recursion

when using

we choose

to o m i t the rec

sion maker.

tion

always

the only

style

(inside a c o n v e n t i o n a l

5) is by m e a n s

of a let d e f i n i t i o n

a name w h o s e

meta-language

function

denotation

b l o c ~ in w h i c h

the

f's.]

identifier

suffix on let's

and never

which

in clause.

let occurred.

Hence

can be re-

definition,

also gives name

is k n o wn w i t h i n

to m e a n

to use the ¥ recur-

in w h i c h a f u n c t i o n function

not

-- the

the user of the m e t a - l a n g u a g e

the d e f i n e d

Consequently

defined

force

speaking

let c o n v e n t i o n

left hand f is not b o u n d to any of the r i g h t - h a n d

function,

free o c c u r r e n c e s

of f by g.

necessary,

cursively

all

see secto the

the scope of the

This

is in c o n t r a s t

to

the f o r m :

¥hf.h(idlJid2,...,id m) • clause which otherwise tify it~

defines

the same function,

but does not further

iden-

121

Free and B o u n d Variables,

Scope

For the purpose of the d e f i n i t i o n of the concepts of fr§e and b0und v a r i a b l e s we c o n s i d e r the m e t a - l a n g u a g e p r o g r a m s tions)

(or: f u n c t i o n defini-

as m a d e up from the f o l l o w i n g three e x p r e s s i o n constructs:

(i) V a r i a b l e s (2) F u n c t i o n A p p l i c a t i o n s (3) F u n c t i o n A b s t r a c t i o n s

(i)

x is free in x.

(2)

x is ~ e e

in f(a)

(3)

x is ~ e e

in ly.clause

if it is ~r£e in either f, or a, or both.

if x~y

tinct from y) and x is ~ £ £

(4)

Since the n o n - r e c u r s i v e

(i.e. if x is an identifier disin clause.

let d e f i n i t i o n block:

(le_~t y = expr

i__~n

se) w h e r e se is either a m e t a - l a n g u a g e s t a t e m e n t or £xpression,

can

be u n d e r s t o o d to be a syntactic sugaring of:

(~y.se)(expr) p r o v i d e d ~@llzb~lvalue

is used, we see that fre§ness of X in a

let d e f i n i t i o n block follows the rules for ~r~§ness of x in an application.

(5)

Similar for s t a t e m e n t composition:

(stmtl; stmt2) only m a k e s sense if s t m t l

and stmt2 both denote functions from

states, ~, to states, ~P,

(stores to stores),

(stmt!; stmt2)~ is really to be u n d e r s t o o d as:

hence:

122

(let ~

= Stmt1(~)

in

stmt2(a')) w h i c h then reduces to:

(la '. (strut2 (a '))) (strut1 (a) ) A v a r i a b l e is bedrid in some e x p r e s s i o n if it occurs in the e x p r e s s i o n but is not free.

It follows then that the formal p a r a m e t e r v a r i a b l e s

(identifiers)

all of the free o c c u r r e n c e s of such identifiers in the ~2~Y,

bind

i.e. clause,

of a l-expression:

l(idl,id2,...,idm).Clause The id.'s

are called bound v a r i a b l e s .

The ~ 2 ~

of a bound v a r i a b l e is the entire b o d y - p a r t of the l-expres-

sion to w h i c h it belongs, with the specific e x c e p t i o n of each p r o p e r l y c o n t a i n e d l - e x p r e s s i o n of the b o d y - p a r t having that same bound v a r i a b l e identifier.

Application

A p p l y i n g a l-defined function:

Ivar.clause to an argument,

arg: (Ivar.clause)(arg)

then means to e v a l u a t e the e x p r e s s i o n clause' by ~ ! ~ ! ~

all free o c c u r r e n c e s of

tifier vat in c~ause

by the

(semantic)

Hence the m e t a - l a n g u a g e only has

w h i c h arises from clause

(the syntactic object)

the iden-

object denoted by arg.

S~!!zDXzYe!~-

The above a p p l i c a t i o n rule extends to functions of several arguments.

123

D e f i n i t i o n versus A p p l i c a t i o n

To write:

(let f(a)

= clause

in

C(f)) means:

let f denote the f u n c t i o n w h i c h satisfies the above e q u a t i o n and

e v a l u a t e or i n t e r p r e t C(f) in such an e n v i r o n m e n t where f is bound to that function.

It does, e.g., not mean:

e v a l u a t e clause before proce-

ding to e l a b o r a t i o n of C(f). clause is e v a l u a t e d iff f is applied and then the suitable s u b s t i t u t e d clause'

is e v a l u a t e d everytime,

afresh,

w h e n e v e r f is so applied!

The ~ O p e r a t o r

For the benefit of those who are not familiar w i t h the y operator of the l-Calculus we now p r e s e n t a d e v e l o p m e n t leading up to this o p e r a t o r and its purpose.

Let :

(let f(x) .,.)

define f r e c u r s i v e l y -- i.e.:

= F(x,f)

in

the r i g h t - h a n d side occurrence(s)

of f

in F(...) denotes the same as does the left-hand side f.

Since,

in the l-Calculus:

G = (Ix.G)(x) p r o v i d e d x does not occur

(free)

is the same as let f = Ix.F(x,f)

in G, and since let f(x) we get:

(let f = (Ig. lx. FCx, g))(f)

where g does not occur Ig.lx.F(x,g),

(free)

i.e. if we let:

= F(x,f)

in F(x,f).

in

If we ascribe the name F to

124

F = Xg. Xx.F(x,g)

then the p r e v i o u s can be written:

(let f = F(f)

Now: F is a function,

in

in fact it is a functional. And objects,

say w,

satisfying:

W = HW w h e r e H is any function,

are said to be ~ ! ~ Z ~ i ~

looking for, i.e. d e f i n i n g by the let clause,

of H. The f we are

thus is a f i x e d - p o i n t of

F. It turns out that there m a y be m a n y fixed-points of any given functional -- so, following good practice, way unique;

we select one w h i c h is in some

in particular, we choose to let such f's denote the so-

called m i n i m a l fixed-point.

This means:

tion) whose @[a~h is included

that solution, f,

(E) in any other solution.

(to the equaIt then turns

out that, under suitable and always r e a s o n a b l e c o n s t r a i n t s ty, etc.),

there exists a functional,

plied to objects,

(monotonici-

let us name it ¥, which w h e n ap-

like F, produce their m i n i m a l fixed-point!

This is the ¥ we are referring to. It is the so-called m i n i m a l fixed~2!~

~!~!~

2 ~ "

Observe the sequence,

let

f(x)

= F(x,f)

let

f

= hx.F(x,f)

let

f

= (lg. hx.F(x,g))(f)

let let

f f

= F(f) = yF

~et

f

= ¥~g.~x.F(x,g)

let

f

= ylf.~x.F(x,f)

I where : F = lg. lx.F(x,g)

That is: w r i t i n g lg.hx.F(x,g) cal meanings,

r e p e a t e d from above:

or w r i t i n g lf. hx.F(x,f)

p r o d u c e s identi-

since the h's shield the r i g h t - h a n d side f from the left-

hand side f -- they are now, formally speaking, they denote the same object:

not the same, a l t h o u g h

125

6.3 F u n C T i o n

Operations

There is only d e f i n e d one o p e r a t i o n on F u n C T i o n

(...)

objects:

apply.

In the i n t r o d u c t o r y example we i l l u s t r a t e d the 'concoction' dure denotations.

of proce-

In the following example we show their application.

Let:

1

Block

::

be an a b s t r a c t syntax

Var-set

(::-)

(Id ~ Pro)

rule.

B l o c k a b s t r a c t s the d o m a i n of the

blocks of some g o t o - f r e e source language. Variable

declarations,

Stmt ~

u n i q u e l y named

T h e y consist of three parts:

(Id) P r o c e d u r e s ,

and a S t a t e m e n t

list. Their semantics is:

type:

I-Block:

Block ~

(ENV ~ (E ~ E))

where:

2

~

=

L O C -~ VAL

3

ENV

=

Id ~ D E N

4

DEN

:

LOC

m m

i

(ARG ~ ~

(~ ~ E))

and :

5.0

I - B l o c k ( m k - B l o c k ( v a r s , procm, s t l ) ) ( p ) ( ~ ) =

.I

(let

.2

(~t,map)

= allocate(vars)(~)

let p' = P + map

.3

+

.4

[id ~ V - P r c ( p r o c m ( i d ) ) ( p ' ) ( s ' ) I id £ d o m p r o c m

.5

let o" = I - S t m t - l i s t ( s t l ) ( p ' ) ( ~ ' )

.6

~ " ~ r n g map)

Lines

in

]

.1-.4 c o n s t i t u t e the block a c t i v a t i o n prologue,

ing epilogue.

in in

line

.6 the match-

The f u n c t i o n a l l o c a t e is given v a r i a b l e names and states

and p r o d u c e s a new state in w h i c h is a l l o c a t e d all the cells c o r r e s p o n d ing to the variables,

their cell locations is r e c o r d e d in map w h i c h

126

binds v a r i a b l e

6.0

names

to these

locations:

allocate(vars)(o)=

.i

i f rare={}

.2

then [~,[])

.3

else

(let id £ vats

in

.4

let (o',map) = a l l o c a t e ( v a r e ~ { i d } ) ( s )

in

.5

let I 6 LOG be s.t.

in

.6

(s' U [l~undefined],ma p U [idol])) type: allocate: ......

1 ~6 d o m e '

Vat-set ~ (£ ~ (£ (Vat ~ LOG))) m

and:

tHpe:

[-Stmt-list:

Stmt ~ ~ (ENV ~ (X ~ ~)).

Now a statement

could be a call of a procedure:

7

Stmt

=

Call

8

Call

::

Id Expr ~

I

...

and with:

9.0

1-Stmt-list (stl) (p) (0)=

.i

i_~ stl=<>

•2

then o

.3

else

(let o' = ~ - S t m t ( h s t l ) ( p ) ( o )

.4

we end up h a v i n g

i0.0

.i

to explain:

I-Stmt(stmt)(p)(o)= casee stmt:

.2

(mk-Call(id, el)

.3

(let argl = < V-Arg(el[i])(O)(o)

.4

fct

.5

fct(argl) ) ,

where

in

~-Stmt-list(t 8tl) (p) (o') )

it is a s s u m e d

type:

= p(id)

that:

V-Arg:

Expr ~ (ENV ~ (~ ~ ARG))

i £ ind el >, in

127

in other words,

that evaluation of the amgument list does not create

side-effects by changing the state

(0).

Observe now, how the procedure denotation,

(ARG* ~ (Z ~ Z)), "time",

which is a FunCTion,

"packed" in the environment

is retrieved (10.4)

and applied

(10.5)

p' set up at prologue at "calling" time.

We have completed our task of showing the construction of FunCTion objects, the second of the introductory examples of this section; and the

~!!Se~!2~

of such objects to their arguments.

Observe that the apply operator of line .4 above, retrieving fct from the MAP object p, is a MAP operation;

whereas the apply operator of

line .5 above, applying the FunCTion object, fct, is the FunCTion operation of apply.

to its a~gument list,

128

7. A B S T R A C T

SYNTAX

Program

=

Stmt

=

Stmt Block

t If

Assign

The

above

I Goto

I

I NULL

::

(Id ~ Type) Prod-set Named-Stmt ~

Type

::

Scalar-type

Prod

::

Id Parm ~ Stmt

[(Expr

I ~)+]

Parm

::

Id (Type

Named-Stmt

::

[Id] Stmt

If

::

Expr Stmt Stmt

For

::

Id Expr Expr Expr Stmt

Call

::

Id (Var-ref

Goto

::

Id

Assign

::

Var-ref Expr

In

::

Var-ref

Out

::

Expr

Expr

=

Infix-expr

is a n e x a m p l e

to d e f i n e

guage.

Before

operators:

render

I Call

I Out

Block

tended

annotate

I For

I In

commenting

the above

itself more

IId) ~

I Rhs-ref

of a n i n c o m p l e t e ( d )

fragments

l, ~,~,

I PROC)

-set

of the

syntax open

abstract

syntactic

domains

o n its u s e of = a n d and

[...],

l e t us,

I Con-var-ref

in the w a y w e b e l i e v e

to i n s p e c t i o n

syntax.

by casual

I t is in-

of some source

:: r u l e s ;

for t h e

I Const

lan-

and of domain

sake of

instruction,

a formal model

should

readers:

-- a n n o t a t i o n

A program

is a s t a t e m e n t

A statement

is e i t h e r

or an assign,

A block uniquely

a block,

o r a n in,

has a variable associates

.

o r a n if,

o r a for,

o r a n out,

or a null.

declaration

part which

the t y p e o f t h e v a l u e s

variable,

a set of procedures,

block has

three

parts.

And

to v a r i a b l e

some,

o r all,

or a goto,

identifiers

that can be stored

a n d a l i s t of n a m e d

either,

o r a call,

statements.

of these may

in the Thus

a

be void.

129

A variable

type is e i t h e r

scalar type 'absent',

is m o d e l e d

nil. An

i.e.

a scalar or an array

whenever

same scalar

type.

(Expr I ~)+

A procedure

has an i d e n t i f y i n g

is of the

of the a rr a y is g i v e n by the l e n g t h of

name,

a parameter

specification

list,

is a statement.

specification

type description.

fier,

object being

the

list.

an a r g u m e n t

A named

[(ExprI~) +]

the o p t i o n a l

The d i m e n s i o n

A parameter

a scalar-,

In this m o d e l

a r r a y type has all a r r a y e l e m e n t s

the p r e s e n t

and a body w h i c h

type.

an array-

statement

or,

has an i d e n t i f y i n g The

formal p a r a m e t e r

type of an a r g u m e n t

name and

is either

that of

a procedure.

has two parts:

an o p t i o n a l

label,

which

is an identi-

and a statement.

Etcetera.

Comments

F r o m the above operator lity,

a n n o t a t i o n s it

transpires

that

for "either",

the p a i r e d

operators

stands

and

"(...)"

fix + in rule

N e x t we o b s e r v e recursively. (2);

delimits

4, the infix

F o r example:

and an

(else)

Finally we conclude must constitute equations,

7.1 Domains

syntax d e f i n e s

a statement

is

that

the d o m a i n s

the d e f i n i t i o n

of A b s t r a c t

denoted

both a

(then)

Stmt statement

consequence

by the rule

left-hand

recursive

sides

set of

"=" or "::"

Objects

we shall

example,

as to some of the a b s t r a c t

as well

the d o m a i n

to the m u t u a l l y

symbol be

In the following

shown.

e.g.

(8), both of w h i c h are statements.

some kind of s o l u t i o n

whether

"I"

for o p t i o n a -

(=) an i f - t h e n - e l s e

statex~ent c o n t a i n s

alternative

expression

"[...]"

the scope of the infix ~ in rule 3, the sufm i in rule 6, and the suffix ~ in rule 10.

that the above

and an i f - t h e n - e l s e

the d o m a i n

rely on your

returning

yourself

syntax

to the above

examples

previously

130

The aim of section 7 is to teach you how to d e c o m p o s e the m o r e general task of defining r e c u r s i v e classes of a b s t r a c t objects.

Sections

2-3-4-5-6 already taught you the m o r e isolated c o n s t r u c t i o n of set, tuple, map,

tree and function domains.

Motivation:

The r e a s o n why we in general, w i s h to d e f i n e a r b i t r a r i l y c o m p o u n d e d classes is the following.

The m e t a - l a n g u a g e architectures:

is used, primarily,

to d e s c r i b e complex software

p r o g r a m m i n g languages,

data bases, o p e r a t i n g system

command & control language interfaces; language processors,

etcetera.

and their stepwise realization:

Just like we o r d i n a r i l y d e s c r i b e the

concrete text strings, m a k i n g up e.g. programs, in terms of e.g.

queries and commands,

BNF g r a m m a r s -- so we now desire to give a b s t r a c t i o n s

of these classes of objects. Likewise: level language program,

just as we, w h e n coding a higher-

a data base data definition,

n o r m a l l y as part of v a r i a b l e declarations,

etcetera,

define,

the structure of our inter-

nal, stored objects -- so we now desire to give storage l a y o u t - i n d e p e n d e n t a b s t r a c t i o n s of the m o r e intrinsic of these v a l u e classes.

Syntactic & Semantic Domains:

In the m o t i v a t i o n above, two kinds of a b s t r a c t o b j e c t classes w e r e singled out. The ones

input to the software systems being defined,

viz.: p r o g r a m texts, data base q u e r y & update commands, system job control language commands,

operating

etc. And the ones manipulated,

and, as we shall take it in general, d e n o t e d by these inputs, viz.: internal data structures; sources,

catalogues,

files & records;

processes,

re-

ercetera. We shall g e n e r a l l y refer to the former object clas-

ses as being of syntactic nature, and the latter as being semantic. S y n t a c t i c and semantic domains will,

in the m e t a - l a n g u a g e be d e f i n e d

using the p r o g r a m m i n g c o n s t r u c t of abstract

syntax.

The "programming construct" of BNF g r a m m a r s or some e x t e n d e d v a r i a n t thereof is u s u a l l y applied when d e f i n i n g sets of c o n c r e t e text strings

131

-- i.e. context-free facility of PASCAL,

"languages".

And the type and mode, definition

respectively ALGOL 68, is the corresponding pro-

gramming construct for the internal data structures.

In the meta-lan-

guage the same tool will be applied in the construction of potentially, and usually,

infinite classes,

or as we shall prefer to call them,

domains of abstract objects.

Motivation:

The reason why we apply the same tool and why this tool is neither that of e.g. BNF, the PASCAL type definition nor the ALGOL 68 mode definition facility, strings

is that we, on one hand, neither want to deal with text

(or corresponding parse trees),

nor, on the other hand, are

concerned about storage space and access-efficient

layout of objects.

Instead we desire to provide what we believe to be appropriate & fitting representational abstractions.

Representational Abstractions:

By representational output terminal-,

abstraction is meant the target system

or machine-storage

of software function concepts,

device)

especially objects,

emphasizing the

choice of such abstractions whose, usually composite, most directly expresses intrinsic,

(e.g. input/

independent specification (logical)

type

i.e. to our understanding relevant,

properties of the notions being specified.

Domain Definitions ~ Compositions In order: (I)

to decompose the task of constructing domains, composing them from constituent domains,

(2)

i.e. of

and in order

to permit the constructions of reflexive domains,

i.e.

composite domains whose objects contain properly embedded objects of the same kind

(-- or domain)

the meta-language provides~the conventional notion of definitions.

132

Definitions / Rules A domain definition consists,

as does any definition,

of two parts. A

left- and a right hand side. Other words are lhs, respectively rhs; and definiendum

("that ~hich is being defined"),

respectively

("that which defines it"). We shall use the words abstract

definiens

syntax

rule synonymously with the concept of a domain definition. Abstract syntax rules all have their lhs's being simple names, identifiers.

i.e.

The rhs's are usually compound expressions henceforth

referred to as logical type, or domain expressions. The first point,

above, about decomposing the task of defining domains

is achieved by the ability to use, in the rhs's of some rules, the lhs identifier of some other rule. The second point, then, is achieved by permitting that

the use, in the rhs of any rule, of the lhs identifier of

(or those) rule(s).

Compositions / ~ 2 ~ ! ~

E~pressions

In order: (3) to model notions of software systems representationally abstract,

and in order

(4) to provide a reasonably fitting variety of choices for abstracting objects the meta-language centers its abstract compound objects around the mathematically tractable concepts of sets, ~ ! ~ , together with associated,

functions and ~ e e s

primitive operations.

Domain Q~erators: As a consequence the meta-language provides a number of operations which apply to arbitrary

(constituent, elementary &/or composite)

mains to denote set-, tuple-, map-,

These operators have already been introduced, ,

the latter

+

((...)) denoting

~

~

~

do-

function- and abstract tree domains.

and are:

(...)

(implicit or anonymous)

tree construction.

133

In the compounding, tree c o n s t r u c t o r

(D I

u s u a l l y s i g n a l l e d by the implicit,

or anonymous,

(..4), of m o r e t h a n one domain:

D2

...

D n)

n~2

•

there is an i n v i s i b l e " c a r t e s i a n p r o d u c t - l l k e

t!

operator,

x. T h a t is,

you m i g h t read the above as:

(D 1

x D2

x ...

x Dn).

The p o i n t about the use in this m e t a - l a n g u a g e of the c a r t e s i a n o p e r a t i o n is that it is only used w h e n domains of trees of two or m o r e subcomponents are denoted. Not,

e.g., w h e n tuple domains are to be constructed.

T h e s e can o n l y be constructed, operations.

in this m e t a - l a n g u a g e ,

Thus, w h e r e c o n t e x t permits,

constructors,

A

using the ~ or +

we m a y d r o p i m p l i c i t tree

as in:

-~

B C

w h i c h is taken to be identical to:

A

~

(B C)

That is: the p r e c e d e n c e of x is higher than any other infix operator, but lower than any suffix operator.

We u s u a l l y o m i t w r i t i n g the x opera-

tor.

The following d o m a i n o p e r a t o r s a s s e m b l e not n e c e s s a r i l y d i s j o i n t dom a i n s into

'unions' of these:

-- the latter a p p l i c a b l e only in c o n n e c t i o n w i t h m a p domains, p l a i n e d in section 4.1. The

J o p e r a t o z will be further d e f i n e d below.

F i n a l l y the operators: [...]

-- o p t i o n a l i t y

(...)

-- g r o u p i n g / d e l i m i t i n g

enables s h o r t n e s s of d e s c r i p t i o n s . T h e former: [A]

~-

A

as ex-

D nil.

134

The latter

can e a s i l y be c o n f u s e d w i t h the tree c o n s t r u c t i o n

Therefore:

when

(...)

surrounds

infix d o m a i n operator, them,

e.g.

(A ~

serves

tree d o m a i n

I (B-set

to indicate,

w i t h no

separating

construction;

otherwise

(...)

as in :

C)) ~,

i.e.

delimit,

the scope

scope rules

of infix or suffix d o m a i n

are the c o n v e n t i o n a l

ones.

C~_mm_u~a~ivi~[ and A s s o c i a t i v ! ~ y

infix o p e r a t o r s

tivity

~

M

The c o r r e s p o n d i n g

Infix O p e r a t o r

With

expressions

operator,

C),

(...) d e n o t e s

operators.

two or m o r e d o m a i n

than the c a r t e s i a n

as in: (A ~ B - s e t

then

other

operator.

the q u e s t i o n

of their c o m m u t a t i v i t y

and a s s o c i a -

arises: I , U

are c o m m u t a t i v e

, ~ , ~ The c a r t e s i a n

associates

product

operator,

to the right.

x, does not associate~

Ex_am_Rles 44-45-46: (i) The d o m a i n s

A

denoted

i B

by:

and

are i d e n t i c a l l y

the same,

(A ~

B)

U

B i A

and so are:

D)

,

and :

(C ~ D))

,

and :

(C ~

(2) The domains: A ~ A

(B ~

~ B ~

are i d e n t i c a l l y

C ~ D

the same.

Writing

the former

is a c l a r i f i c a t i o n

of the

135

latter,

should you have forgotten

the rules of associativity.

Thus the

domain:

((A

is distinct

~

B)

~

C)

~ D

from the domain denoted by the former expressions.

(3) The tree domains:

(A

x B

are all distinct was

x CJj

((A

x BJ

and

x C),

(in fact, disjoint).

(A

x

(B

x CJ)

Only in this,

the 3rd example,

(°..) used for tree domain construction.

Semantics

of the

I Operatqr

Of the new domain expression

operators

section 7 only the m e a n i n g of

I remains

Let A and B be d o m a i n expressions,

A

([...]j

(...),

I) introduced

in

to be explained.

denoting

A, r e s p e c t i v e l y

B. Then:

I B

denotes: AUB where

U is the

A

I B

(potentially

~

infinite

{ o

! oE

A

set) union operator;

vo£

B

i.e. :

}

Comment:

Thus

f does not denote the discriminated

In Scott 76 the disjoint union operator A

+B

~

{

(A__.,aJ

or disjoint is represented

I a £ A }

{ (B, bJ I

6B}

U

union operation. by +, and:

136

The "tagging" of the A + B the o r i g i n a t i n g domain, lap, and an A + B

domain elements, w i t h a "label" indicating is useful w h e n e v e r

(2) the need arises for testing,

(i) domains A and B oversay in some function, w h e t h e r

object comes from A or from B.

Since the

I o p e r a t o r does not separate the operand domains it is the

task of the definer to see to it that

J o p e r a n d domains are d i s j o i n t

w h e n e v e r some functions a p p l i c a b l e to the union d o m a i n need a s c e r t a i n o r i g i n a t i n g domain.

Constructin~ ~!~2!~

Domains

Let us assume that a union domain,

D1

is required.

I D2

l ...

r o u g h l y of the type:

I Dn

Let us further assume that for some, or all, i # j :

D° is not d i s j o i n t from D.

Since D i and D j

o v e r l a p there is no d i r e c t way of s e p a r a t i n g

(some) D i

objects from D.. J I n t r o d u c i n g the a b s t r a c t syntax tree d o m a i n c o n s t r u c t i n g rules:

A I :: D 1 A 2 :: D 2 w , ,

A

n

:: D

n

and :

A1 J A2

(in lieu of D I marking

(mk-A1,

I ...

i D2

I An

J ...

mk-A 2 ....

in the u n i o n d o m a i n A 1

I Dn), , mk-An)

I A2

I ~..

by d i s t i n c t n e s s of l e f t - h a n d side Thus we introduce desired.

:: a b s t r a c t

e f f e c t i v e l y c o r r e s p o n d s to a d i s t i n c t of r e s p e c t i v e DI, I A n . Distinctness (Ai,

Aj

D 2,

....

D n objects

is solely a c h i e v e d

) names.

syntax rules w h e n e v e r d i s j o i n t n e s s is

137

7.2 A b s t r a c t Syntaxes & Rules

Abstract Syntaxes

Abstract-Syntax

::=

Rule i Rule 2 Rule

is an informal

r

"extended" BNF, or BNF-like,

syntactical d e s c r i p t i o n

d e f i n i n g an a b s t r a c t syntax as c o n s i s t i n g of a number o f rules. Each rule:

Rule

::=

Identifier = D o m a i n - E x p r e s s i o n

::=

Identifier:: Domain-Expression

b a s i c a l l y c o n s i s t s of two parts: a left-hand side definiendum, w h i c h is an identifier; expression.

and a r i g h t - h a n d side definiens, w h i c h is a d o m a i n

The two rule parts are separated either by an e q u a l i t y

o p e r a t o r or by the s o - c a l l e d tree d o m a i n c o n s t r u c t o r Both the or

d~f

=

and the

)" The latter,

A

::

B1

in addition,

B2

.

,

.

'constructs'

operator.

trees.

(like:

Its use in:

Bn

could be taken as an a b b r e v i a t i o n for the ::

(::)

o p e r a t o r s are d e f i n i t i o n symbols

::

(=)

(intended, reflexive)

use of

in: A

=

::(B 1

B2

.~.

Bn).

Context Constraint

In a c o m p l e t e m e t a - l a n g u a g e p r o g r a m there m u s t be no two rules of any one or pair of a b s t r a c t syntaxes w i t h identical definienda,

i.e. lhs

identifiers.

/s-Function:

Any a b s t r a c t syntax rule

!~!!S!~!£

cate f u n c t i o n /s-Identifier:

introduces,

i.e. defines,

a predi-

138

type:

OBJ ~ BOOL

is-Identifier:

w h i c h applies to any object and yields true if it is an o b j e c t in the d o m a i n d e n o t e d by Identifier, o t h e r w i s e false.

Note:

We could have c h o s e n to write:

obj 6 Identifier instead of:

i8-Identifier(obj) but, except for a few cases, we reserve the former form for set m e m b e r ship tests where t h e

set is not one d e f i n e d as a D o m a i n as d e f i n e d by

some a b s t r a c t syntax. The exceptions are those i l l u s t r a t e d by the following descriptor

and quantified expressions

(see sections 1.5 & 1.4.1):

(Ax £ !dentifier)(P(x)) (VX 6 Identifier)(F(x)) (Hx £ Identifier)(F(x)) (B!x £ Identifier)(F(x))

Exam~!~ ~Z: Given the i n t r o d u c t o r y a b s t r a c t syntax example, and given:

i8-ID(id),

is-Scalar Type(st),

is-Stmt(sl),

i8-Stmt(s2),

is-Named-Stmt(nsl),

and is-Expr(e)

is-Stmt(s),

is-Named-Stmt(ns2),

we are able to construct:

m k-Program (8) ink-Block ( [id-~mk-Type (st, nil) ], { }~ )

pr

ink-Named-Strut (nil, s)

ns

mk-IfCe, 81,82)

if

etc.. Let us call these four objects pr, bl, nB and if. Now:

bl

139

N is-Program(hi)

is-Program(pr) is-Stmt(pr)

is-Stmt(bl)

is-Block(pr)

is-Block(hi)

i8-Named-Stmt(pr)

is-Named-Stmt(bl)

is-If(pr)

is-If(bl) N is-Program(if)

is-Program(he) is-Stmt(ns)

is-Stmt(if)

is-Block(he)

is-Block(if)

is-Named-Stmt(ns)

is-Named-Stmt(if) is-If(if)

N is-If(he) etc..

Further Context Constraint A z-rule, when expressible in the form:

Identifier

=

D 1 D 2 ... D n

(n~2)

D I D 2 ... D n

(n~2)

is identical to the rule:

Identifier

::

Semantics of Abstract Syntaxes The prescription for computing most of the domains designated by compound domain expressions has

already been given. Allowing now for do-

main definitions,

in fact for several such, and, in addi-

i.e. rules,

tion, for potentially mutually recursive rules, we require a more comprehensive prescription for computing the domains given an arbitrary abstract syntax. We shall only do that informally here, relying in general on the formal foundations laid by Scott. An abstract syntax can, speaking rather formally,

[Scott 1976]. be viewed syntacti-

cally as an equation set. Its meaning is a family of named sets of mathematical objects being the minimal,

fix-point solution to the equa-

tion set. That is: to each lhs there corresponds a potentially infinite class of finite objects,

the domain. These domains are the smallest

such classes which, when substituted in lieu of their identifying names

I40

in the equation lhs and rhs's will,

satisfy the equations.

The bit

about the fix-point ~omes into the picture since our equations may be mutually recursive.

The equation:

D

=

D-~D m

has the following solution:

D:

{[],[[]~[]],[[]~[[]~[]]],[[[1~[]]~[]]

with : D

=

(DMD)

J A

"adding":

{[a I

*

[]] ....

[a 1 ~ a 1 ] . [a I

~

. . .

al,a 2

to the above solution.

~

a2,...,a

n

~

a n ]....

.... };

141

7.3 A b s t r a c t S y n t a x o r i e n t e d C o m b i n a t o r s

The m e t a - l a n g u a g e

(structured-)

s p e c i f i c a l l y c o m p l e m e n t i n g the t e r n a t i v e operator,

expression

and s t a t e m e n t c o m b i n a t o r s

(abstract syntax)

d o m a i n e x p r e s s i o n al-

i, are:

The M c C a r t h £ C o n d i t i o n a l Clause:

(pe I ~

e 1,

pe 2 ~

a 2,

o , ,

pe n ~

o n)

The Cases C o n d i t i o n a l Clause:

da8e8

~0:

(e I -~ cl, e I -~ a2, o ° o

e

Here p e i stand statement, expression.

n

-~ d

n

)

for p r e d i c a t e

e x p r e s s i o n , cj

and e k for expressions.

for either e x p r e s s i o ~

or

A clause is either a s t a t e m e n t or an

If either of the above c o n d i t i o n a l clauses is

(intended to

be) of the e x p r e s s i o n type,

then all c. are (to be) expressions. SimiJ larly they are all to be statements if the above clauses are to be

c o n d i t i o n a l statements.

We refer to the e k e x p r e s s i o n s as follows:

as the root expression and e k ,

for 1~k<__n,

e0

as the branch expressions.

G i v e n the a b s t r a c t syntax for e x p r e s s i o n s of some source language:

142

1

Expr

=

Infix

I Rhs-ref

2

Infix

::

Expr Op Expr

3

Rhs-ref

::

Var-ref Id

4

Con-var-ref

::

5

Conet

=

INTG

6

Var-ref

::

Id

7

Op

=

Int-Op

We can define

a function,

I BOOL I Bool-Op

ex-tp,-which

given

I PROC

DICT

=

Id ~ (Type

9

Type

::

Scalar-type

10

Scalar-type

=

~Z

t h e Scalar-type

~ Const

[Expr +]

8

computes

f Con-var-ref

I Rel-Op a dictionary:

I ...)

[(Expr

! ~)+]

I BOOL

of an e x p r e s s i o n ,

e:

ex-tpCe, dict)=

ii.0

case8

.I

e

(mk-Infix(

.2

,opj

)

.3

(is-Int-Op(op )

~

.4

is-Bool-Op(op)

~

~NT, B00~,

.5

ie-Rel-Op(op)

~

BOOL),

mk-Rhs-ref(mk-Var-ref(id,

.6

))

8-Scalar-type(dict(id)),

.7

mk-Con-var-ref(

.8

)

.9 .i0

i8-B00L(e)

.ii

type:

Observe

how,

structs.

in t h i s

Relate

function,

Expr DICT

the

case,

and observe

how they

in t h e c a s e s

name

arguments

branch

BOOL))

Scalar-type

we nested

structures

constructs those

~

~

the

Cases

of the abstract "match".

Observe

expressions.

of t h e mk-

functions

and the McCarthy syntax

con-

t h e ex-tp

n e x t t h e u s e o f mk-

Observe

which

and

finally

that we only

we explicitly

require.

-- a n n o t a t i o n s : An expression rence,

is e i t h e r

a controlled

an infix

variable

expression,

reference

a right-hand-side

or a constant.

refe-

~43

An infix e x p r e s s i o n

has three parts:

two o p e r a n d

expressions

and an

operator. A right-hand-side A controlled

variable

variable

reference

reference

is a v a r i a b l e

is an identifier.

A constant

is e i t h e r

an integer

A variable

reference

has an i d e n t i f i e r

an ar r a y length

location,

An o p e r a t o r rator,

or a boolean.

then an index

expression

list,

is e i t h e r

list,

and,

if this

which

identifier

is a non-zero,

denotes

finite

else nil.

an integer

or a r e l a t i o n a l

reference.

(arithmetic)

operator,

a boolean

ope-

operator.

-- comments: An e x p r e s s i o n

either

an e x p r e s s i o n

is

an e x p r e s s i o n

-- w h i c h

certained.

denotes

(said)

Given

an integer

either

(to be)

is o t h e r w i s e

or a boolean. ~NT or

well-formed

that the type w i t h w h i c h

(to be)

Hence

the type of

BOOL. The type of

-- can be s t a t i c a l l y

a variable

as-

or formal p a r a m e -

ter is declared: 12

Block ::

(Id ~ Type) Proc-set Named-Stmt

13

Proc

::

Id Parm

14

Parm

::

Id (Type t PROC_)

is r e c o r d e d vironment,

in some

Stmt

(compile-time)

the f u n c t i o n

dictionary,

ex-tp computes

also

called

(at compile-time)

static

en-

the type of

any expression.

-- annotations,

continued:

ex-tpis g i v e n an expression, If e

(.i)

et and a dictionary,

is an infix e x p r e s s i o n

as some mk-Infix(el,op, e2), w h e r e

(.2),

i.e.

dict.

if e can be e x p r e s s e d

el,op and e2 b e c o m e the names of those

Expr, Op, r e s p e c t i v e l y Expr o b j e c t s of w h i c h e is m a d e up, then the type of e is a s c e r t a i n a b l e .3) an integer either

(.4)

from the kind of o p e r a t o r

operator,

a b o o l e a n or

that op is.

then the type of e is ~NT; (.5) a r e l a t i o n a l

If op is

if op instead

(or comparison)

is

operator,

then the type of e is BO0~. If e

(.I)

expressed

is a r i g h t - h a n d

side r e f e r e n c e

as some mk-Rhs-ref(vr),

(meta-)expressible

(.6),

i.e.

if e can be

vr is a v a r i a b l e r e f e r e n c e

as some mk-Var-ref(id, el), w h e r e

the names of the Id, r e s p e c t i v e l y m a d e up,

where

id and el b e c o m e

[Expr +] o b j e c t s of w h i c h e can be

then the type of e can be looked up in the d i c t i o n a r y

as that

144

of the Scalar-type component of the Type object with which id is associated.

PART

III

COMBINATORS

In part II, i.e. in sections 2-7 inclusive, of constructing domains of objects, ing primitive,

we dealt with all aspects

constructing objects and perform-

i.e. language-defined operations on objects.

Certain desired transformations on objects are, however,

of a complexi-

ty which cannot easily be described by some such operator/operand expression,

regardless of its composition.

customary in programming,

To that end, and as is quite

the meta-language provides a number of con-

structs which facilitate the gradual composition of transformations and processes on objects. We call these constructs for combinators.

They

are: Variables:

Declarations,

Assignment & the State

Structured Clauses Blocks: Let & Return Exits So far we have officially dealt only with the applicative aspects of the meta-language. constructs, ever,

Introducing variables implies introducing imperative

i.e. statements.

The applicative part of the language,

how-

includes the let constructs of, and hence also, blocks, as well

as most of the structured clauses. We say, in general,

that the appli-

cative constructs of the language permit the expression of composite transformations on objects. The imperative constructs correspondingly enable the decomposed,

stepwise statement of processes on objects.

145

8. VARIABLES

Exam~!~

~:

The following four function definitions all define ~

to denote the fac

torial function:

1

fo(n)

=

if n=O then i else n*fo(n-1)

2

fl(n)

=

(dcl Z := I t~pe N1; ~0 r i=I t__oon do

,i

.2 .3

3

Z :: ( ~ ) * i ; return(c v))

f2(n)

=

.i .2

~ := (S~)*i;

.3

4

(dc l ~ := 1 type N1; [or all i E {l:n} d~o return(c u))

f3(n)

=

.2 .3

(dcl Z := 1 type N1, while

.4

(ci % O) do (Z :: ( £ i ) * ( ~ ) ; ~ := (c£)

.5

- 1);

return(c u))

The first defines ~ applicatively;

the remaining three,

We say that the parenthesized constructs: blocks.

imperatively.

(dcl ... return(...))

~ and, only in the last definition,

~ are

(assignable) variab-

les. They form part or all of the state current in these blocks. other

(externally declared)

variables

fo:

NO ~ NI

If no

'exist', then they form all of

the state. The logical type of the four f's are:

type:

are

146

type: where

Z denotes

the blocks,

the

the state

to this space

z where

fl,f2,f3:

....

N O ~ (~ ~ (Z NI)) space.

... e l l i p s i s

refers

to p o s s i b l y

state t r a n s f o r m a t i o n

'equivalent'

8.1 D e c l a r a t i o n s

change.

Thus

declared

variables.

state,

and h e n c e

it

that

by:

the four f u n c t i o n s a global

can indeed be

state.

& The State

the e x a m p l e s

normally

not f i n d a need for other

of h i g h e r - l e v e l

The m e a n i n g

any global

indicated

even w h e n c o n s i d e r i n g

Although

models

externally

f2 nor f3 a s s i g n to any such g l o b a l v a r i a b l e s

is in fact the i d e n t i t y shown

~, inside

k ~#.~o)

is easy to see that they do not alter the p o t e n t i a l

of ~ and

is:

k cL # ~ )

Since none of the f1"

The c o n t r i b u t i o n s

above

featured

b l o ck

local d e c l a r a t i o n s

than global v a r i a b l e s

we shall

in a b s t r a c t

software.

of a declaration:

dol V~r := ... type D -- in w h i c h we m a y omit the type state,

D clause -- is that of joining to our

s, a contribution:

U [~ It is u n d e r s t o o d In general,

~ obj] that V a ~ is not a l r e a d y

the state

space,

Z, g i v e n a c o l l e c t i o n

tions:

dcl ~I := ... type DI, ~2 := ... type D2, ~Vn

declared,

:= ... type Dn;

i.e. of

that

Va~ ~6dom ~.

(global)

declara-

147

can be d e f i n e d as:

= (~I ~ D1) ~ (~2 ~ D2) k "'" ~ (~n ~ Dn) The d o m a i n expressions:

(V-i ~ D i) are d e g e n e r a t e in that the d e n o t e d map d o m a i n s are singular, sist of just one element,

the

(quotation-like)

i.e. con-

o b j e c t ~i w h i c h can be

r e g a r d e d as d e n o t i n g itself.

Our source language example features the a b i l i t y to input data from an (one) e x t e r n a l device,

to o u t p u t data to an

d i s t i n c t from the input device,

(one) external device --

and to declare v a r i a b l e s in any

block. The r e l e v a n t s y n t a c t i c domains,

Block

::

(Id ~ Type)

Stmt

=

In

In

::

Var-ref

... Stmt

Out

::

Expr

Assign

::

Var-ref Expr

I Assign

I Out

(nested)

c o n t i n u i n g example 31, are:

I ...

The semantic functions a s c r i b i n g m e a n i n g to these source c o n s t r u c t s w i l l be based on the f o l l o w i n g three

dcl ~

ST~

(global)

variables:

:=

<...> t~pe

(INTGIBOOL)

,

:=

<>

type

(INTGIBOOL) ~,

:=

[]

~

sTa;

w h e r e STG was d e f i n e d in the last e x a m p l e of section 4.4.

The state space,

Z, of the e l a b o r a t i o n functions,

= ( ~

~

(INTGIBOOL)~)

is:

148

8.2 V a r i a b l e

References

Prelude

Recall

the i n t r o d u c t o r y

(~) o c c u r r e d

The

left-hand

(state)

tion.

of section

side o c c u r r e n c e

denotes

The r i g h t - h a n d

The m e t a - l a n g u a g e

breaks w i t h

then you are r e q u i r e d

itself,

i.e.

side o c c u r r e n c e

~ But here we t r a d i t i o n a l l y

content,

8. V a r i a b l e

identifiers

in two contexts:

location.

itself

examples

expect this

of

the m e t a - s t o r a g e V likewise

the v a l u e k e p t tradition.

to p e r f o r m

denotes

in the

V loca ~

If you need the

the c o p e r a t i o n

to V.

end-of-Prelude

If

V is the name of a d e c l a r e d

de___ll NV

then

:=

...

type

V is said to d e n o t e

variable:

D

itself,

or if need arises

for m o r e precision,

N

to d e n o t e

a re~D

object,

To get at the v a l u e

i.e.

'stored'

a reference

in ~ a p p l y

to an o b j e c t of type D.

the c o n t e n t s - o f

operation

de-

noted by c:

cV V and c V

~

are m e t a - l a n g u a g e

is e x p l a i n e d

expressions.

Given

the state,

~:

as :

oc£). If V is of type r e f D

, then c V

N

m

ces ~. Thus ~ d e n o t e s objects; states

a function

w h i c h we g e n e r a l i z e

to states

'paired'

is of type D. That

is:

N

c de-referen--

from

state

to a f u n c t i o n

with objects:

variables

and

states

from s t a t e - v a r i a b l e

to

and

149

c

~

Xu.hs.(s,s(v))

c

6

(V ~

(x X

(z o s J ) ) )

8.3 A s s i g n m e n t

A s s i g n m e n t is a m e t a - l a n g u a g e statement:

:= expr If ~ is of type r e f D

then expr m u s t be of a type D' , included in D,

i.e. D'qD, e.g. D~D'

The m e a n i n g of a s s i g n m e n t is as you think it. Formally,

i.e. :

:=

N

Xu. Xobj.ha. (~+[v~obj])

:=

6

(V ~ (OBJ ~ (X ~ Z)))

We now c o n c l u d e the e x a m p l e s of sections

however:

4.4, 6.3 and 8.1. Recall in

p a r t i c u l a r the last example of section 4.4.

The e l a b o r a t i o n f u n c t i o n s a s c r i b i n g m e a n i n g to the source language In,

Out and Assign s t a t e m e n t s will themselves e m p l o y , b u t now, m e t a - l a n g u a g e assignments.

Since the b a s i c source language means of r e f e r r i n g to a

v a r i a b l e is t h r o u g h :

Var-ref

::

Id [Expr +]

we define a set of a u x i l i a r y functions:

type: eval-Var-ref:

eval-Var-ref

Var-ref ~ (ENV ~ (Z ~ (Z Scalar-loc))

contents:

Scalar-lot

~ (~ ~ (~ (INTGIBOOL)))

assign:

Scalar-loc

(INTGIBOOL)

takes a v a r i a b l e reference,

~ (~ ~ ~)

an e n v i r o n m e n t and a state,

and p r o d u c e s the same state and the scalar l o c a t i o n d e n o t e d by the v a r i a b l e reference.

The need for a c c e s s i n g the state arises as a result

150

of potentially evaluating array variable subscripts. Whereas

eval-Var-ref

applies to a syntactic object

the environment;

eontents

(Var-ref),

and hence needs

and assign apply only to semantic objects,

and hence do not require the environment.

Finally:

objects assigned

to storage locations must have their type match the type of the location. Recall that the storage model of the last example of section 4.4 distinguished between integer- and boolean locations:

v-tp-match(v,

0 .i .2

sloc)=

(is-INTG(v)

~ is-Intg-loc(sloc),

is-BOOL(V)

~ is-Bool-loc(sloc))

type:

(INTGIBOOL)

(Intg-locLBool-loc)

Now:

i. int-In(mk-In(vr)} (p)=

.2

then error

.3

else

(let s l o c :

.4

eval-Var-ref(vr)(p),

iv

.S

if

.6

v-~p-match(iv, sloc) then

.7

: hd c ~ ;

(In k

:= tl c ~ ;

assign(sloe, iv))

.8

else error) type: In ~ (ENV ~ (E ~ E))

2. int-Out(mk-Out(e))(p) =

.1

(let ov : eval-Expr(e)(p);

type:

Out ~ (ENV ~ (~ ~ E))

3. int-Assign(mk-Assign(vr, e))(O) = .! .2 .3

(let s l o c : val

eval-Var-ref(vr)(o), : eval-Expr(e)(o);

assign(sloc,val)) type: Assign ~ (ENV ~ (E ~ Z))

~ BOOL

151

The a u x i l i a r y functions:

4. e v a l - V a r - r e f ( m k - V a r - r e f ( i d , s s l ) ) ( p ) = .i

if ssl=nil

.2

then r e t u r n ( o ( i d ) )

.3 ~

else

(let arrloc = p(id)

.4

let il

.5

if

in

: < eval-Expr(ssl[i])(O)

il

l 1 < i < l e n s s l >;

N6 dom arrloc

.6

then error

.7

else r e t u r n ( a r r l o c ~ l ) ) )

5. c o n t e n t s ( 1 ) = .i •2

6. oi

(let V : ( s S l ~ ) ( 1 ) ; i_~ v = u n d e f i n e d

•3

then error

.4

else return(V))

assign(l,V)= STG

:= a S T G

+ [l~v]

-- a n n o t a t i o n s

io I n t e r p r e t i n g an I n p u t s t a t e m e n t p r o c e e d s as follows: is no m o r e ~nput, then we evaluate

(.2) i n t e r p r e t a t i o n halts,

(.1) If there

otherwise

(.3-.8)

(.3) the scalar location denoted by the variable refe-

rence c o n s t i t u t i n g the Input s t a t e m e n t and input stream value.

If

(.4) retrieve the front

(.5) the type of this Calue matches that of

the scalar l o c a t i o n then

(.6-.7) we p r o c e e d to

(.6)

~nput stream by the element value just retrieved,

'shorten'

and

the

(.7) to assign

this value to the scalar storage location; o t h e r w i s e i n t e r p r e t a t i o n halts.

2. I n t e r p r e t i n g an

Output s t a t e m e n t consists,

rather m o r e simply, of

(.I) e v a l u a t i n g the e x p r e s s i o n it is c o m p o s e d of and ing the r e s u l t i n g output value to the Output stream.

(.2) of append-

152

Etc. for 3., int-Assign.

4.

Evaluating a variable reference which consists of a possibly void array subccript lows:

list and the variable

(.i) If the subscript

fier is shown,

guaranteed,

by well-formedness

to denote a scalar variable,

from the environment directly. list is present,

identifier proceeds as fol-

list is absent,

then

then

(.2) the identi-

context conditions

not

whose location can be obtained

(.3-.7)

If instead the subscript

(.3) the identifier

denotes an array variable

location is kept in the environment. The subscript list is guaranteed to consist of proper expressions all yielding integer

whose

values.

Well-formedness

context conditions

but see

[Jones 1978a]. We therefore

expressions to obtain an not one of the array, the denoted

index

then

for this are not shown,

(.4) evaluate all the subscript

list.

(.5) If this index

(.6) interpretation

scalar location

fails,

is obtained by applying

list is

otherwise

the array

location, which is a map from index lists to scalar locations, the computed index

to

list.

Comments In the above definitions "parallel":

1.3-1.4,

certain

3.1-3.2.

proceed sequentially,

'pairs'

of evaluations

In [Jones 1978a]

in the order listed.

proceeded

in

the same evaluations

This gives rise to two dis-

tinct semantics!

8.4 Derived References Section 8.2 dealt only with simple variable ences denoting use, ware,

the location of an

'entire'

since 1973, of the meta-language, has not been registered

references. variable.

That is: refer-

In the design and

a need, when abstracting

for easily denoting references

soft-

to proper

components of store composite objects. When applying

the m e t a - l a n g u a g e

to lower-level

rather more implementation-biased

abstractions,

specifications,

The following notation is therefore offered.

i.e. to

such a need may arise.

153

to TUPLE Elements

Sub-References Given:

(0)

d,c,,1Tu~l~ :=

<.'..>

type D*

Retrieving

the i'th component

of ~ T u ~

(i)

l~)Ci]

is basically

expressible

with the selective update of that tuple position basically as:

~

(2)

:: ~ T U ~

It is now suggested

(3)

~{~"

to the i'th position of ~

,

permitting

(I)

[i])

(2) as:

Tu~!£" [i] :: d

Sub-References

t__ooMAp Range Elements

The forms corresponding type map:

(0)

+ [i~d];

Tu!%,p./~'[i]

(i')

(2')

expressible

to let:

denote the reference to be rewritten:

and

as:

dcl ~

to (i,2,3,1',2')

:= [... ] type A ~ D; m

are: {i)

(0 ~ )

(a)

<2)

~

::_o~

(3)

~"

(a)

(i')

s ( ~ " (a))

(2')

~'(a)

:= b

+ [a~bJ

above, but for variables

of

154

-- w h e r e a E d o m c ~ p r i o r

to

(2).

S u b - R e f e r e n c e s to Sub-"TREE"s.

Given:

D

::

s-nm1:D 1 8-nm2:D 2 ... s-nml:D 1

and:

(0)

del Tree

:= mk-D(...)

The forms c o r r e s p o n d i n g to

type D.

(1,2,3,1'~2')

above are now:

(I)

s-rim. (e Tree)

1
(2)

(let mk-D(d I ..... d i .... ,d l) := a_Tr~ze. lae~£ := mk-D(dl,...,d i',...,dl))

w h e r e all d . for j#i are unchanged, @ 8-nm. sub-"tree". Now:

(3)

s-nm,'Tree

(i')

e(s-nm.'Treg)

(2')

e-nm.'Tree

i.e. w h e r e

(2) only

'changes'

the

:= d.'

Discussion The reader m a y v e r i f y that a similar need for v a r i a b l e s c o n t a i n i n g sets does not arise. Also:

the b e n e f i t of the d e r i v e d reference operation,

h i g h e r in forms

Finally:

(2') than

(i') -- cf. forms

(2) and

denoted by " , is

(i), respectively.

the semantics of the d e r i v e d r e f e r e n c e operator, " , is fully

e x p l a i n e d by the e q u i v a l e n c e of forms spectively.

(i) and

(i'), (2)

and

(2'), re-

9 STRUCTURED CLAUSES

As used in this section a clause is either a s t a t e m e n t or an expression.

It turns out that to each s t r u c t u r e d statement, tion,

and block,

there c o r r e s p o n d s a structured expression.

such clauses s y n t a c t i c a l l y looks v e r y m u c h

see next sec-

The c o n d i t i o n a l form of

alike, w h e r e a s this is not

the case for the i t e r a t i v e clauses.

9.1 O v e r v i e w

Let in the f o l l o w i n g 8 and S(...)

stand for statements,

s u i t a b l y d e c o r a t e d e's for expressions, p r e d i c a t e expressions,

E(...) and

suitably d e c o r a t e d p e ' s

and s u i t a b l y d e c o r a t e d c's for clauses.

for It is

f u r t h e r assumed that the c's of a g i v e n c o n d i t i o n a l s t r u c t u r e are either all statements,

or all expressions,

leading to this c o n d i t i o n a l in turn

being a statement, r e s p e c t i v e l y an expression.

The following p r e s e n t s the various s t r u c t u r e d clauses in a schematic way:

C o n d i t i o n a l Clauses

(i)

if

(2)

(pc I ~

c 1,

pe 2 ~

c2,

•

pe

aI

else

c2

and

° °

(2 I)

(pc I ~

01,

Pe 2 ~

c2,

. . .

pe n

(3)

then

~

cases

c n)

T

and

CO:

~

(3') c a s e s

c n)

eo:

(e I ~

c I,

(e I ~

c 1,

e2 ~

c 2,

e2 ~

c 2,

en

cn )

T

c n)

~

156

Iterative Clauses:

(4)

fo r i = m t_~o n d_~o S(i)

(4')

<E(i)

(5')

{E(id)

(5)

for all id6set

(5")

d_oo S(id)

J m

I id 6 set}

lid ~ E(map(id))lid6dommap] f(obj)=

if P(obj) (6)

while pe do s

then

(6')

F(obj)

else G(obj,f(H(obj))) w h e r e in the last schema P being a predicate.

((6'))

P, F, G and H are a p p r o p r i a t e functions,

(4, 5, 6) are statements;

(4', 5' , 5") are expres-

sions, and so is an a p p l i c a t i o n of f.

~5_~_~!~

-- ~ :

I l l u s t r a t i o n s of the d u a l i t y b e t w e e n clauses (5) and

(5'),

(4) and

(4'), r e s p e c t i v e l y

(5"), have a l r e a d y been given -- see sections 3.4, re-

spectively 2.4, 4.4.

The d u a l i t y of the c o n d i t i o n a l statements and conditional e x p r e s s i o n s need not be further discussed.

The f o l l o w i n g examples illustrate the d u a l i t y of forms

TO sum the elements of a tuple,

(6) and

(6').

t, of integers:

Sum(t)= sum

N

~

:= 0 type INTG;

while ' (c ~) ~ <> d_~o (SU~ := ( c _ ~ ) + hdc~;

i_ff t = <>

then else hd t + sum(tl t)

return(c sum) ) S u b s e q u e n t e l a b o r a t i o n functions will i l l u s t r a t e the power and n e a t n e s s of r e c u r s i v e d e f i n i t i o n s c e n t e r e d around a simple ~_~f-then-else

clause.

157

9.2 D e t a i l e d Syntax & S e m a n t i c s 9.2.1 I f - t h e n - e l s e C o n d i t i o n a l

Schema:

i_f expr

predicate-expression

then clause

consequent

else clause

alternative

E l a b o r a t i o n of an if-then-else clause proceeds as follows: premiss-

(or test-)

p r e d i c a t e e x p r e s s i o n is evaluated.

first the

If it does not

y i e l d a truth v a l u e an error has o c c u r r e d -- and the m e t a - l a n g u a g e prog r a m is in error!

If the premiss yields truth then the consequent

clause is elaborated.

O t h e r w i s e the alternative clause. Any e l a b o r a t i o n

of either the c o n s e q u e n t - or the a l t e r n a t i v e clause strictly succeeds the e v a l u a t i o n of the premiss°

E~2~ra_n~_!n~ Notes: i.

Observe that the form :

i_~ expr then stmt

is not provided.

Instead the programmer,

if so forced,

is adviced

to use:

if expr then stmt else I for I see section 1.2. N o t e that the c o n v e r s e is possible:

i_~

Nexpr

and that the

then I else stmt 'similar' p r o b l e m is not r e l e v a n t for if-then-...

expressions~

2.

The premiss

sometimes relates as follows to either the consequent

or a l t e r n a t i v e clause:

158

i_ff ( 3 x . . . ) ( P ( x ) J then

(let x be s.t.

~(x);

cC(xJ) else

...

or, e.g. :

if~(Bsy...)(p(yjj then

...

else

(let

z =

(Ax)(P(x));

~C(z))

W h e r e e v e r the

'connection'

is so obvious,

then we informally,

but

strictly s p e a k i n g erroneously, write:

if

(3x...)(P(x)) then

cC(x)

else

...

respectively:

i_L~(3!x°..)(P(x)) then

...

else

aC(x)

etcetera.

The

'shifts'

in identifier naming is, of course,

rial. Thus the x of the latter two p r e m i s s e s

(informally)

far as the entire c o n s e q u e n t and a l t e r n a t i v e clauses.

9.2.2 M c C a r t h Y C o n d i t i o n a l

Schema:

(e I

~

esl,

e2

-~

es2J

-~

es

,o. e n

and:

) n

n < 2

immatehind

as

159

(e I

~

esl,

e2

~

es2,

~

es

.,.

T

n>2

) n

where

the

McCarthy All e i

We give

T of the latter and Cases

(1
form is a m e t a - l a n g u a g e

constructs

are p r e d i c a t e

the s e m a n t i c s

the i f - t h e n - e l s e

(i_~ e I t h e n

in the e

n

(or propositional)

of the above

keyword

'position',

i.e.

only used

in

in lieu of e . n

expressions.

in terms of their t r a n s c r i p t i o n

into

form:

es 1

else (if e 2 t h e n

es 2

else (

ooo

else (if e n the____~nes n else

error)..°)))

respectively:

(i~ e I t h e n

es 1

else (i_~ e 2 t h e n (

.o.

else

The

same remarks

i~.~-then-else identifier e8

.:

esn...)))

concerning

construct,

defined

informal

apply

in some e i

with (l
name the

binding constraint

restricted

and of

scope the

as for the scope

of

an

to the c o r r e s p o n d i n g

160

(3,.,x...)(P(x))

~

ES(x),

.., ...

...)

9.2.3 The Cases C o n d i t i o n a l

Schema:

ca8~8 ~0: (e I

~

esl,

e2

~

es2,

~n

~

esn)

and:

case8

eO:

(e I

~

e81,

e2

~

e82,

T

~

es n)

w i t h f as d e f i n e d above. The form of e. (l
is either an ordinary

i.e. one all of whose free identifiers are bound by/in the

s u r r o u n d i n g context,

or it is one of the s o - c a l l e d defining e x p r e s s i o n

forms:

{dl,d2,...,d k} m k - N m ( d l , d 2 , . . o , d k) id, est where the d.'s (1<j
id r e p r e s e n t s

~2~_~'~_~ ~2~: U s u a l l y the dj's of an immediate d e f i n i n g e x p r e s s i o n are identifiers.

161

Some of these may be bound in the containing scope. If all are bound or constants,

then we have an ordinary expression.

We first assume ordinary,

i.e. bound expressions, and explicate through

reduction to earlier understood forms:

(let v 0 : eO; i f VO=e I then

es 1

else (if VO=e 2 then e8 2 else (

,..

else (if VO=e n then es n else e r r o r ) . o . ) ) ) respectively:

(let v 0 : eo; i_~ Vo=e I then es 1 else (if VO=e 2 then

es 2

else (

...

else

es

n

...)))

We explain the free identifier,

defining expression variants by speci-

fically presenting an atypical

combination and then transcribing it to

an if-then-else form combined with let blocks. The example assumes all branch defining expressions identifiers free and rather casually mixes sets, tuples and trees!

162

cases

eo:

({idl,id2,..o,idk}

~ es 1,



~ es 2,

m k - N m ( i d l , . . . , i f k)

~ es 3,

id

~ e84,

~..

e.g.

®,.)

transcribes

into:

(let VO: eo; if is-SET(V O) ^ c a r d v o = k then

(let {idl,id2,...,idk}

= v 0 i__nn

es I ) else (if is-TUPLE(V O) ^ ~ v o = k then

(let = v 0 i__nn es 2)

else (if is-Nm(v O) then

(let m k - N m ( i d l , i d 2 , . . . , i d k) = v 0 i__nn

else

es 3 ) (let id = v O i_~n es4))))

This

latter

tively

First

form is now a n n o t a t e d

to the former

object.

elaborate, fically:

Following

in turn,

e 0, is evaluated. the listing

successive

we first ask w h e t h e r

k. If a fit is thus naming

these ~dl,

commented)

branches

v0

until

a match

is a set and,

found we d i s s o l v e

~d2,

in the cases

If v 0 is not a se~ it is then asked w h e t h e r

This

terminates

if so, of length k. If a fit is thus

elaboration

found ....

nor a tree of type N m then v 0 is r e n a m e d

to no e l a b o r a t i o n

as here:

id,

'corresponds'

ever of s u c c e e d i n g

Speci-

the set v 0 into its k e l e m e n t s

clause.

a free name,

is found.

..., idk, w h e r e u p o n the e x p r e s s i o n -

is elaborated.

the

form we now

if so, of c a r d i n a l i t y

esl,

tuple,

alterna-

The name 4 0 i d e n t i f i e s

given

clause,

Thus

referring

form:

the base expression,

evaluated

(i.e.

etc.

it is a tuple,

and

If v 0 is not a set,

id and es 4 is elaborated.

to a T - c l a u s e

branches.

or s t a t e m e n t

of the cases

-- leading

The scope of the free identifiers of the branch-expressions the corresponding expression,

or statement,

is that of

clause.

, o o

And so on: many variations,

combinations and permutations

ings of free- & bound variables).

The above

'schematic'

(e.g. order-

examples have

attempted to convey the general idea of defining expressions,

their

possible mixture of free- & bound variables and even constants. reader should,

from this, be abl~ to extrapolate.

this: since it is an abstraction,

The

The basic point is

i.e. meta-language and since there

is generally ~2~ to be an interpreter for it, anything sensible and context-wise obvious is to be allowed.

Ex_am_ple 54:

We shall use the meta-language conditional expressions and recursion to exemplify simpler versions of the conditional statements.

That is:

we applicatively define imperative constructs!

Abstract Syntax: The syntactic domains:

Cond

=

If

I MeG

I Case

If

::

Expr

Stmt

MaC

::

ExSt +

[Stmt]

Case

::

Expr

ExSt +

ExSt

::

Expr

Stmt

where E x p r

and S t m t

Stmt

[Stmt]

are the meta-language expression and statement do-

mains:

The semantic domains)

0 £ ENV ~ E STG

first the textual,

=

Id

=

LOC

~ m

(LOG

then the temporal:

°..)

~ OBJ m

where Id is the syntactic domain of identifiers, analyzed domain of locations.

LOC

the further un-

|84

Semantic Functions:

Let I and V be names of the generic functions elaborating meta-language statements,

respectively expressions, N

N

i.e.:

N

type:

I:

Stmt ~ (ENV ~ (~ ~ ~))

type:

V:

Expr ~ (ENV ~ (~ ~ ~ OBJJ)

I {8tmtJ (pJ (~)= cases

stmt:

(ink-If(p, c, a) (let

(s',b)

= V(p)(p)(o)

in

~b then I(c)(p)(~') else

I(a)(p)(~')),

mk-McC (es l, t) (let mcc(lesJ (~)= ( (Ise~<>) (let

(~',b)

= V(s-Expr(hlse))(@)(~)

in

if b then I(8-Stmt(h lse))(p)(~') else mce(t lse)(~')), (t~nil)

I(tJ(pJ(~J, T ~ error)

in

mcc (es l) (a J), ink-Cases (e, esl, t) (let (s',v)

= V(e)Cp)(~)

in

let case(lse)(~)= ((lse~<>) (let

(~',v')

= V(s-Expr(hlse))(p)(~)

if V--v ' then I(s-Stmt(h lse))(p)(~') else case(t lse)(~')), (t@nil) I(tJ(~J, T ~ error) in case (es5) (a ')), .°o)

i_~n

185

9.2.4 The Ordered,

Iterative For-To-Do Statement

Schema:

for

i d = e x p r m t_~o e x p r n d_~o stmt

i d m u s t be free in the s u r r o u n d i n g context,

e x p r m and e x p r n m u s t be

integer v a l u e d expressions. All o c c u r r e n c e s of id in 8tmt are free in stmt.

We u s u a l l y c o n s t r a i n e x p r m and e x p r n to be s o - c a l l e d ~ k ~

~P~k2~.

These are e x p r e s s i o n s w h o s e value can be a s c e r t a i n e d statically, without r e f e r e n c e to any c o m p u t a t i o n

(e.g. state). As such,

sions are u s u a l l y either c o n s t a n t s

static expres-

(viz.: e x p r m = I) or simple opera-

t o r / o p e r a n d expressions i n v o l v i n g only textual,

i.e. syntactic domain

objects.

The C o n t r o l l e d V a r i a b l e

i d is c a l l e d a, or t h e , c o n t r o l l e d variable.

sense of d e n o t i n g a R E F e r e n c e ,

It is not a v a r i a b l e in the

and thus it cannot be changed in stmt.

i d d e n o t e s an integer.

The first o c c u r r e n c e of i d in "for id =..." is the d e f i n i n g occurrence° It binds all

(free) o c c u r r e n c e s of i d in stmt.

The scope of this con-

trolled v a r i a b l e is the for statement in w h i c h it is defined.

We first e x p l i c a t e the p r i m a r i l y intended usages of the for statement: namely the ones w h i c h have e x p r m and e x p r n being static e x p r e s s i o n s e v a l u a t i n g to m, r e s p e c t i v e l y n. Let S ( i d ) to stmt.

Then:

fo r i d = m t o n d o S ( i d )

SCm) ;SCm+1} ;. . . ;SCn-1)

;SCn}

be another way of a l l u d i n g

166

Thus if m
then:

"for id = m t_~o n d__~oS(id)

=

"~".

Given S(id),

S(k)

m e a n s the s u b s t i t u t i o n of all id in S by k.

We then e x p l a i n the m e a n i n g of for statement w h o s e from and to expressions,

expr m & expr n are e x p r e s s i o n s of any kind. To this end we apply

the m e t a - l a n g u a g e

itself~

Let the for s%aZement s y n t a c t i c d o m a i n s p e c i f i c a t i o n be:

For

::

Id Expr

where I d c T O K E N ,

and E x p r

Expr

Stmt

& Stmt

denote the class of r e s p e c t i v e l y source-

language e x p r e s s i o n s and statements.

Let the semantic domains p e r t a i n i n g to the i n t e r p r e t a t i o n of F o r Statem e n t s be the temporal store:

q £STG

=

L O C ~ OBJ m

w h i c h maps L O C a t i o n s

p 6ENV

=

to OBjects,

Id ~

and the s i m p l i f i e d textual environment:

(LOCIINTGI...)

w h i c h maps s o u r c e - l a n g u a g e text I d e n t i f i e r s they are names of d e c l a r e d variables,

into either L O C a t i o n s ,

or to I N T e G e r s ,

if

if they are e.g.

c o n t r o l l e d v a r i a b l e names, or . . . .

Let V denote the generic e x p r e s s i o n e v a l u a t i o n f u n c t i o n w h i c h applies to source

- l a n g u a g e expressions,

environments

& states/st6res

state changes & objects -- in this case I N T e G e r s .

and yields

~ denotes the generic

s t a t e m e n t i n t e r p r e t a t i o n w h i c h applies to s o u r c e - l a n g u a g e statements, v i r o n m e n t s & s t a t e s / s t o r e s and yields state changes.

en

I67

(mk-For (id, fe, te, sJ ) (p) (~)= oi .2

(let (~',f) : V(fe)(p)(~), (~",t) = Y(te)(p)(~) in

°3

let ~"'6{~',S"} in

o4

let for (p')(~)=

o5 .6

i_ff P'(id)>t then

o7

else

(let ~' = I(s)(g')(~)

.8 .9

in

for (g '+ [id~(k '(id))+l]) (~ ')); for(pU[id~i]) (c5"' ))

Annotations:

.1-.2

Both s p e c i f i c a t i o n expressions, expression,

the f r o m e x p r e s s i o n and the to

are e ~ a l u a t e d in p a r a l l e l

","

(or in any order),

and b o t h m a y lead to i m p l i c i t state changes a")

.3

(~', r e s p e c t i v e l y

and to the e x p l i c i t l y d e s i r e d from, f, and to, t, values.

This line i l l u s t r a t e s the problem: or ~", to choose.

w h i c h new

(or next)

state,~'

In this case the p r o b l e m has b e e n b r o u g h t

upon us by our insistance on p a r a l l e l e v a l u a t i o n of all specif i c a t i o n expressions.

Had our pragmatics" lead us to choose se-

q u e n t i a l i t y of from- and to e x p r e s s i o n s e v a l u a t i o n there w o u l d have been no need for a n o n - d e t e r m i n i s t i c choice.

.4

A local function,

for, is r e c u r s i v e l y

(.4 vs.

.8) defined w h i c h

if applied:

.5

will test w h e t h e r the c o n t r o l l e d v a r i a b l e value gone b e y o n d the limit

.6

(t),

if so, the final state is the one c u r r e n t w h e n the last invocation

(.8 or

.9) of for was made,

i.e. at the end of last itera-

tion, r e s p e c t i v e l y w h e n for was first c a l l e d

.7

.8

(p'(id)) has

(initialized);

o t h e r w i s e the value of the c o n t r o l l e d v a r i a b l e 'body',

s, of the for statement

bounds,

and the

preted,

leading to a new state,

W i t h this state, and the (textual)

is still w i t h i n shall be Inter-

~'.

Wupdated'

e n v i r o n m e n t w h i c h binds the

name of the c o n t r o l l e d v a r i a b l e to its i n c r e m e n t e d

v a l u e the for loop is invoked

(recursively).

168

This completes the d e f i n i t i o n of the a u x i l i a r y for function,

w h i c h is first a c t i v a t e d w i t h the

.9

'initial'

state, ~', and an

e n v i r o n m e n t w h i c h binds the c o n t r o l l e d v a r i a b l e to its initial value,

i.

Note that the e n v i r o n m e n t s are simply e x t e n d e d v e r s i o n s of the

i0

e n v i r o n m e n t in w h i c h the for statemen% is interpreted.

In summary:

the m e t a - l a n g u a g e

for loop was c o n c e i v e d of as a m e a n s for

tl. Hence the s t a n d a r d

iterating t h r o u g h syntactic tuple structures,

r e q u i r e m e n t that expr m and expr n be static expressions,

the former

u s u a l l y 1, the latter u s u a l l y ~ t l .

E~E~E

Ex_am_ples 56 & 57:

We now illustrate i m p e r a t i v e and a p p l i c a t i v e d e f i n i t i o n s of the Compound

Statement

source language construct:

Cmpd

::

Stmt*

The i m p e r a t i v e v e r s i o n is b a s i c a l l y b a s e d on a state:

Z.

=

(STG~,~~ ST@) _U ...

Int-Cmpd(mk-Cmpd(stl))(p) fo r i=I to l s t l type:

=

d_2 int-Stmt(stl[i])(p)

Cmpd ~ (ENV i ~ (~i ~ ~i ))

The a p p l i c a t i v e v e r s i o n is s i m i l a r l y based on a state:

Z

a

STG ...

::

~-Gmpd(mk-ampd(stl ) ) (p) (0)= /f st/=<>

then else

(let ~' = I-Stmt(hstl)(p)(e)

in

I-Cmpd (mk-Cmpd (t 8 t l ) ) (p ) (~ ')) type:

Cmpd ~ (ENV a ~ (Z a ~ Xa))

169 where correspondingly:

type:

int-Stmt:

Stmt

~

N (ENV i ~

type:

I-Stmt:

Stmt

~

(ENV a ~

(Z i ~ Zij)

N

(Z a ~ Za))

9.2.5 The u n o r d e r e d F o r - A l l & P a r a l l e l S t a t e m e n t s

The For-All S t a t e m e n t

Schema:

fPr

all

def

6 set d__oostmt

where def and stmt p a i r w i s e are of the forms:

id

N S (id)

(cd 1, cd 2, • . ., cd n} S (idl, id2, . . . , idm)

m k - N m (ed I ..... edn)

w h e r e a p r o p e r subset of cdl,

ed2,

....

cd n may be constants,

otherwise

of either of the above four listed forms, u s u a l l y identifiers, T h e s e m u s t all be distinct.

And where idl,

id2,

...,

id!

id m are the iden-

tifiers of d e f free in the c o n t a i n i n g context. All such m u s t be free in S. It m u s t be s t a t i c a l l y d e c i d a b l e that eet denotes a set. And if either of the latter three d e f forms are used, ally d e c i d a b l e that set is of a logical type, X-eetj X ~ O r

N m is c o n t a i n e d in Y; viz.:

X-set

then it m u s t be staticY, such that either some c Y, X ~ c Y or: N m c Y~

The C o n t r o l l e d V a r i a b l e s

The i d e n t i f i e r s of d e f free in the c o n t a i n i n g c o n t e x t are the c o n t r o l l e d variables.

Again,

as in section

9.2.4 they are not a s s i g n a b l e but di-

r e c t l y denotes n o n - R E F e r e n c e O B J e c t s .

The i d e n t i f i e r o c c u r r e n c e s d e f i n i n g occurrences.

in d e f free in the c o n t a i n i n g context are

T h e y bind all their

(free) o c c u r r e n c e s

in Stmt

The scope of these c o n t r o l l e d v a r i a b l e s is the for statement in w h i c h they are defined.

(S).

170

In this ment

section we only e x p l i c a t e

for the simple

the semantics

case of static

set e x p r e s s i o n s

fier def's -- this is also the m o s t of k objects,

and name

these

of the for-all and simple

stateidenti-

Let set d e n o t e

common case.

a set

idl,id2, .... id k. T h a t is set N {idl,id2 ,

...,idk}:

~or all idE{idl,id2, .... id k} d_~o S(id)

// {~idl),S(id 2) ..... S(idk)}

The P a r a l l e l

Statement

Schema:

//{stmtl,stmt2,...,stmtn}

n>2

Sea~i~ : Elaboration parallel, clause

of the s t a t e m e n t s

"independently"

terminates

stmtl,

stmt2,

of each other.

as a r e s u l t of all

..., 8tmt n p r o c e e d s

Elaboration

statements

of this

in

collateral

having been e l a b o r a t e d .

E_x~!es _5_8-_S2 We now i l l u s t r a t e to the parallel parallel,

All

::

of a source

Instead

language

of e l a b o r a t i n g

in any,

arbitrary

statement

similar

the s t a t e m e n t s

in

order:

Strut-set

tive

::

statement.

they are just e x e c u t e d

is the syntactic

)-

the s e m a n t i c s

o..

domain

specification.

The d e f i n i t i o n

is kept a p p l i c a -

171

I-All(mk-All(stmts))(O)(~)= if stmts={} then elee (let s £ 8tmts in let a' = I-Stmt(s)(g)(s)

in

I-All(mk-All(stmts~{s} ) ) (p) (a ')) type: All ~ (EN~ ~ (~ ~ ~))

A for-all source language construct could be given the following definition:

ForAll

::

::

Id Expr Stmt

...

I-ForAll(mk-ForAll(id, e, s) ) (g) (~)= (let (s',set) = V-Expr(e)(O)(s)

in

let all(coll)(~)= if coll={} then else (let obj 6 toll in let ~' = I-Stmt(s)(p+[id~obj])(~) all(coll~{obj}) (~ '))

in in

all (set) (s ')) type: ForAll ~ (ENV ~ (Z ~ ~)) where it is assumed that the evaluation function, which elaborates id, finds the meaning of id just by looking up in the environment~

type: I-Stmt:

Stmt ~ (ENV ~ (Z ~ X))

t~pe: V-Expr:

Expr ~ (ENV ~ (Z ~ (Z OBJ)))

9.2.6 The While-Do Statement Schema:

while expr do stmt where it is statically decidable that expr is a truth-valued expression.

172

expr is usually an impure expression,

i.e. one whose value depends on

the current state. The state is, of course, potentially being changed by stmt.~

As you might expect it -- but here is an applicatively expressed forma lization of the imperative while construct.

_~x~!e _6_0: Abstract Syntax: Wh

::

E x p r Stmt

for the syntactic domain. And:

£ STG

=

p £ ENV

=

LOG ~ OBJ m Id ~ (LOCI...)

for the semantic domains.

I (mk-Wh(e, s)) (p) (~)= (let w h ( ~ ) = Clet

(~',b)

= V(e)(p)(~)

i_~n

ifb then

(let 6" = I ( s ) ( p ) ( ~ ' )

in

wh(~")) else

~')

wh(~) ) type: I : Wh ~ type:

(ENV ~

wh: ~ ~ £

(~ ~ ~) )

in

~73

Dijkstra's Guarded,

rg E RepGuard w i t h STG and ENV

Repetitive Construct

::

(Expr

[Di~kstra 75 ]:

Stmt)-set

as above, has the f o l l o w i n g

'informal'

semantics:

Execute rg as long as e v a l u a t i o n of at least one e x p r e s s i o n in the un= o r d e r e d set of pairs of Expression-Statements

zields

true:

~(mk-RepGuard(ese))(p)(a)= .1

(let gwh(ses)(~) =

/_Z se~={}

.2 .3

then

.4

else

(let

(e,s) E see

in

.5

let (~',b) = V ( e ) ( o ) ( ~ )

.6

~b

.7

then

.8

in

else gwh(ses~{(e~s)})(~))

in

gwh(ess)(e)) t,,~Pe: RepGuard

In this definition, i.e.:

(let ~" = I(s)(p)(~') gwh(ess) (~") )

.9 .i0

in

~ (ENV ~ (~ ~ Z))

e v a l u a t i o n of guards

(e) m a y cause side-effects,

~ goes to ~'. Thus r e p e a t e d e v a l u a t i o n s of some

(one) guard,

in =

itially y i e l d i n g falsity, m i g h t e v e n t u a l l y p r o d u c e truth -- had we not p a s s e d the initial state tions

(~, s u b s e q u e n t l y ~) onto a l t e r n a t i v e evalua=

(.9). D o i n g so also secures D i j k s t r a ' s r e q u i r e m e n t that if some

guard is chosen,

then it was

true in the 'initial ~ state

(~, subse=

q u e n t l y ~).

The n o n - d e t e r m i n i s t i c a s p e c t of this c o n s t r u c t is e x h i b i t e d by the ar= b i t r a r y set e l e m e n t s e l e c t i o n of line

.4.

The reader m a y v e r i f y that this c o m m a n d is a (sledge-hammer ?) ization of the while

do c o n s t r u c t above~

general=

174

10. BLOCKS

A c o m p o u n d statement:

(stmtl;

stmt2;

.,. ; stmt n)

is a s e q u e n c e of two or m o r e statements. The semicolon,

";", acts as

the c o m b i n a t o r here.

A block:

(let id = expr d i__nnexpr b )

(let id = expr in stmt)

(let id : exprd;

(~et id : expr;

(dcl vr := exprd;

expr b)

(dcl vr := expr;

expr b)

consists of a (let)

d e f i n i t i o n of a constant,

a (dcl)

(of a variable)

declaration

an expression,

or a statement

stmt) stmt)

non-re_~erence object,

or

-- on one hand --, c o m p o u n d e d w i t h

(-sequence)

b i n a t o r s here are either the semicolon,

-- on the other hand. The com=

";", or the "in" symbol.

This section will not bring very m a n y examples.

Previous

sections abound

w i t h examples of blocks. We leave it to the reader to look these up for re-confirmation:

R e f e r e n c e to block-exam~!e~:

P a r e n t h e s i z e d numerals refer to example numbers, these refer to formulae

(i) and line number

the i.j-k trailing

(j-k) sequences.

A p p l i c a t i v e e x p r e s s i o n blocks: (0)11.3-8, (0)18.8-21,

(0)11.6-8,

(0)16.1-6,

(0) 17.3-7,

(0)18.3-21,

(0) 20.3-11 . . . .

I m p e r a t i v e e x p r e s s i o n blocks: (31) 14.3-6, (52) 5.1-4,

(31)14.12-17,

(50) 2.0-3,

(50) 3.0-3,

...

S t a t e m e n t blocks: (31) 13.1-8,

(52) 1.3-8,

(52)2.1-2,

(52) 3.1-3,

...

(52) 4.3-7,

175

The B l o c k C o n c e p t

The b l o c k

concept

tion of scope.

of the m e t a - l a n g u a g e

Blocks

essentially

d e a l s w i t h the no-

are of the forms:

(let id = expr in clause)

and:

(let id : expr; clause).

We have, duce

however,

in p a s t examples,

also p e r m i t t e d

ourselves

to intro-

local variables:

(del id := expr }Epe D; clause). In all three cases id stands s t a n t quantity. it is defined. first

for a locally,

We say that the Only

two blocks

in this

last case id d e n o t e s

a block,

scope of id is the block:

textual

id d e n o t e s

i.e.

part,

may

(...)

it be r e f e r r e d

the v a l u e of expr upon block

the l o c a t i o n

defined,

of a m e t a - s t o r a g e

cell,

in w h i c h

to.

entry. i.e.

con-

In the In the

an ob-

ject in the d o m a i n of Z:

z

. . . .

u

(zd ~

D)

--

u

[i !-,

obj]

In pa r t i c u l a r :

where

...

i d is the d e n o t a t i o n

of id, and obj is the v a l u e of expr upon

block entry.

The

let

(or dcl) d e f i n i t i o n s

of id in clause.

Thus

of id are said to bind any free o c c u r r e n c e s

the scope of id extends

to inner,

nested

blocks

in w h i c h id is not redefined.

clause m a y be a m e t a - l a n g u a g e statements.

expression

or a s e q u e n c e

of one or m o r e

176

10.1 Let C o n s t r u c t s

O b s e r v e the two d i s t i n c t cases of let constructs:

The § £ n t a ~ ! c ,

let construct:

o~ a ~ ! ! c a t i v e

(let id = expr i__nn clause)

If expr is a ~ e

S~£~!2~,

i.e. an e x p r e s s i o n w h o s e e v a l u a t i o n does

not require access to any state components,

then we use

"=" and "i~n"

as delimiters.

The semantic,

or ~ £ ~ ! Z 2

let construct:

(let id : expr; clause) If, on the other hand,

e v a l u a t i o n of expr requires access to the state,

i.e. if expr is an ! ~ ! Y ~ ,

or ! ~ E S ,

~P~!2~

, then we use ....

and ";" as delimiters.

A s s u m e id to o c c u r free in clause,

i.e. think of clause as C(id). T h e n

the m e a n i n g of the syntactic let clause block is C(expr),

i.e. can be

o b t a i n e d by substituting expr for all free o c c u r r e n c e s of id in clause. Note that the s u b s t i t u t i o n could be done on the syntactic level,

by ~!~S!~S

texts. The meaning,

however,

i.e.

of the semantic let clause

block is C(val), w h e r e val is the value of expr u p o n block entry. That is: the m e a n i n g can be o b t a i n e d by

e~£kik~ki~

free o c c u r r e n c e s of id in clause.

Let C o n s t r u c t V a r i a n t s

A v e r y useful

let v a r i a n t is:

(let obj £ D be s.t. clause)

P(obj);

values of expr for all

177

w h i c h we u n d e r s t a n d

let obj be an o b j e c t

as:

such that it satisfies

the p r e d i c a t e

in the d o m a i n

P. Ot h e r variants,

or set D

which

are simple

cases of the a b o v e are:

(Set obj 6 Set; clause) and:

(let obj be s.t. P(obj); clause) The a b o v e

three v a r i a n t s

construct

from the b l o c k body

lar,

but s y n t a c t i c

were

indicated,

by the

";" s e p a r a t i n g

constructs

would

instead

of the infix

The

O b j e c t Let , D e c o m p o s i t i o n

following

are useful,

so-called

composite

let constructs:

(let m k - D ( d l , d 2 , . ~ , d n) = expr d i__nn clause) (let = expr t in clause) and:

let ~dl,d2,...,d n} = expr s i~n clause) Their

respective

meanings

are:

expr d m u s t e v a l u a t e to a D tree object, D

::

D 1 D 2 .o. D n

then the a b o v e "is e q u i v a l e n t

let

";" use an in-

fix "in".

Composite

the

clause, to be of the semantic type. Simi-

to:

with:

178

Cle__~t tree = expr d i_nn

(!~t d I d2

= s-D1(tree), = s-D2(tree) ,

dn = s-D n (tree) clause)).

in

expr t must evaluate to an n-tuple: (let tuple = expr t inn (let d I

= tuple[1],

d2

= tuple[2],

dn

= tuple[n]

__in

clause)). expr s must evaluate to a set of cardinality n. The 'assignment' of set objects to d i is arbitrary:

(let set = expr s in (let d I E set i_~n (~t

d 2 E set~{d I} i__nn

(let d s 6 set~(dl,d 2} i__nn (let d n E 8et~{dl,d 2 .... ,dn_ I} in clause)...))))

Simultaneous & Recursive Let Definitions

The form:

(let d I = el, d 2 = e2, o l .

d n = e n in clause) simultaneously defines the objects tO be the

(nz2)

d l , d 2 , . . . , d n.

They are, in general,

("smallest" such) objects which satisfy the

simultaneous)

equations.

(above set of

This description permits djWs to occur recur-

sively in the equation set. The dj.'s might be composite constructs,

179

introduced

in the p r e v i o u s

subsection,

constituent

(free)

recursively

in the e q u a t i o n

identifiers

For the story on r e c u r s i v e

(ultimately

The

definitions

Conventions

form:

let d I = e I i_nn let d 2 = e 2 i_nn

let d .......

= e ~

in n

--

clause)

is a s h o r t - h a n d

for:

(Zet d I = e I ~n (let d 2 = e~ i~n (o,°

(let d

= e

in

clause)...)))

The

form :

(let m k - A (

,c,

) = ea

in

clause)

where

e.g.:

A

::

is a s h o r t - h a n d

B C D,

for:

(let m k - A ( b , c , d ) clause)

occurring

in dj)

m a y occur

set.

6.2.

Notational

in w h i c h case we m e a n that the

= ea

in

--

of f u n c t i o n s

we refer

to section

180

It is used to alert the reader to the non-use of the B and D components of the A tree d e n o t e d by e .

Similarly for anonymous trees; and:

(let

<x~

,z,

> = e t i__nn

clause)

w h i c h is the same as:

(let let

t = e t i_~n x =

t[1],

z = t[3]

in

clause ) .

10.2 Pure & Impure E x p r e s s i o n s

A ~ure

(or applicative)

S ~ ! 2 ~

is one whose e v a l u a t i o n never re-

quires access to the state.

An !mR~re

(or imperative)

~£S££!2~

is one whose e v a l u a t i o n p o t e n t i a l l y

r e q u i r e s access to the state.

G i v e n that X. denotes the state space of an i m p e r a t i v e

(global v a r i a b l e

only) m o d e l we can say that the type of the d e n o t a t i o n of an impure exp r e s s i o n is either of the form:

xi ~ (£i OBJ) or of the form:

x. ~ oBJ The former type hints that e v a l u a t i o n of the m e t a - l a n g u a g e e x p r e s s i o n p o t e n t i a l l y leads to a (side-effect)

state-change, w h e r e a s the latter

type only expresses that the state is a c c e s s e d in order to c o m p o s e the resulting OBJect

value.

181

The choice of forming an e x p r e s s i o n either as a pure-, expression,

is solely d e t e r m i n e d

by the kind of object to be denoted.

That is: even though some abstract model global

state variables,

or as an impure,

is p r i m a r i l y centered around

some objects may still be denotable by pure

expressions. If at least one target expressions pure,

of a conditional

then all such target expressions

ment is further m o t i v a t e d expression

expression

are to be impure.

in [Jones 1978a].

is im-

This require-

To render an otherwise pure

return.

impure prefix it with the operator

See section 10.6.

10.3 The ";" Combinator The ";" is a combinator. tically,

Its use can be explained

and semantically.

rative clauses:

Syntactically

statements;

from a statement;

semantic

and a statement

(... 8tmtl;

in two ways:

speaking,

let clauses;

syntac-

";" separates a semantic

impe-

l~t clause

from an impure expression:

8tmt 2 ...)

(...

let x I : exprl;

let x2: expr2;

(...

let x: expr; iexpr)

...)

(... 8tmt; iexpr) Semantically

speaking

";" denotes

functional

of the d e n o t a t i o n of a m e t a - l a n g u a g e ment,

semantic

composition.

Since the type

let clause,

let, or state-

stmt, is: let,

stmt: Z. ~ Z.

The construct:

(ci;e2) where

(ci,c2) are either

statements),

(semantic

lets,

statements)

means:

Xs.(e2(cI(s))) where

ai is the m e a n i n g of ei

(i=1,2). Thus:

or

(statements,

182

lal . ha2. hs. (c2 (ci Ca)))

N

;

i.e.

£

10.4 C o m P o u n d

(Z ~ Z) * ((Z ~ Z) * (Z~Z))

Statements

The m e t a - l a n g u a g e

(stmtl; The body of a to as clause

permits

parenthesizing

block,

section

8tmt2;

...;

i.e.

the s y n t a c t i c

10.1, m a y be a s t a t e m e n t

statement:

construct

referred

sequence:

8tmt n

difference

the latter

The formal m e a n i n g

to be a c o m p o u n d

..~ ; stmt n)

(statement-)

is no semantic

Sequences

any s t a t e m e n t

stmt2;

in e.g.

stmtl; There

& Statement

since

between

these two constructs.

it is always

We omit

superfluous.

is:

X~.stmtn(Stmtn_1(...(stmt2(stmt1(~)))...)) where

stmt°

We re f e r

is the m e a n i n g

to

[Jones

of the basic

1978a]

Statement-

a state-change.

is as you w o u l d

& Expression

A statement-block

evaluated,

for a f u r t h e r

l-definition

of the m e a n i n g s

statements.

The i n f o r m a l m e a n i n g

10.5

of stmt..

expect

it to be.

Blocks

is a statement.

The block,

An e x p r e s s i o n - b l o c k

when

interpreted,

is an expression.

m a y e f f e c t a state-change,

but always,

effects

The block,

in addition,

when

delivers

a value: N

A statement

stmt-block:

X. * X.

expr-block:

Zi ~

block consists

(E i OBJ)

of a s e q u e n c e

of one or m o r e

syntactic

and/or

183

semantic

let clauses

f o l l o w e d by a sequence of one or m o r e statements.

An e x p r e s s i o n b l o c k is either a pure- or an impuretive-,

r e s p e c t i v e l y an imperative-)

c o n s i s t s of one or m o r e s y n t a c t i c

expression.

let clauses

(i.e. an applica-

A pure e x p r e s s i o n block

f o l l o w e d by a pure ex-

pression. An impure e x p r e s s i o n block consists of a n o n - z e r o length seq u e n c e of zero, one or m o r e s y n t a c t i c - or s e m a n t i c

let clauses

followed

either by an impure e x p r e s s i o n or a s t a t e m e n t all of w h o s e s y n t a c t i c a l l y p o s s i b l e e x e c u t i o n paths end w i t h an impure expression.

Since only well-

s t r u c t u r e d statements are p e r m i t t e d the test for this latter is quite simple.

10.6 Return

From the e x p l a n a t i o n o f " / " it follows that if a s t a t e m e n t sequence, an e x p r e s s i o n block,

is to be followed by an expression,

of

then the type

of this e x p r e s s i o n m u s t be:

Z -~ (X OBJ)

i.e.

impure.

In general,

if the c o n t e x t d e t e r m i n e s that an e x p r e s s i o n be impure,

the value to be y i e l d e d can be d e n o t e d by a pure expression,

and

e, then we

need to r e n d e r e impure. This is the p u r p o s e of the m o n a d i c e x p r e s s i o n operator return.

return

N

kobj. h<~. (~, o b j )

return

6

(OBJ ~

(~ ~

(~ O B J ) ) )

Ex ~ ! e s See examples:

(31) 14.6,

(31) 14.17,

(50) 2.3,

(50) 3.3,

(50) 4.5.

184

ii. EXITs

Even though the m e t a - l a n g u a g e conventional

GOTO construct.

The exit mechanisms,

has i m p e r a t i v e Hence

in m a n y ways,

say, w i t h o u t b e i n g g r o s s l y wrong, albeit,

in general,

unlabelled,

it lacks

replace

source

Observe

the d i s t i n c t i o n

in p a r t i c u l a r

1

Block

2 3

the GOT0 construct.

determined,

language!

when modeling Therefore:

a structured

::

(Id ~ Type)

Named-Stmt

::

[Lbl] Stmt

Stmt

=

Block

of the same list,

read carefully.

and m e t a - l a n g u a g e

constructs,

... N a m e d - S t m t *

I Gore

whether

been executed,

t ...

through

or out of the c o n t a i n i n g

or w h e t h e r -- as w e r e

of n e s t e d (normal)

Block to a s t a t e m e n t

Block,

in fact it m a y

due to all statements

Goto,

due to a global

in e.g.

the same

example

31,

4 i n t - B l o c k ( m k - B l o c k ( d c l s , p r o c s , n s t l ) ) (p, ca)= .i (let aid 6 AID be s.t. aid ~c ca in J lbl £ Labels(nstl)

.3

+[ v ~ g e t - l o c ( d c l s ( v ) ) ( p )

.4

+[ s-ID(p) ~ eval-Proc(p)(p')

.6

I p 6 procs

always (let loce

.7

= {p'(v)

Set sloes = { ...

.8 .9

i v £ domdcls

S T ~ :=

I v 6 domdcle} see example

31 ... }

c~slo~)

in i n t - N a m e d - S t m t - l i s t ( n s t l ) ( p , caU{aid},aid)) tRpe:

Block ~ ((ENV AID) ~ (X ~ ~))

i_~n i_nn

having

'clean-up' section

first take place:

let p' : p+[ lbl ~ mk-LAB(aid, lbl)

T h a t is:

list to another

Each time a Block a c t i v a t i o n

levels.

epilogue

illustrated

structures.

of a N a m e d - S t a t e m e n t

list of the next e m b r a c i n g

go out of any such n u m b e r

logue actions

the GOTO c o n c e p t of our r u n n i n g

Gotos m a y not go into p h r a s e

language

of the N a m e d - S t a t e m e n t

.5

GOTO,

and -- in any case --

in the f o l l o w i n g

between s0~6e-

Gotos m a y e.g. go from one s t a t e m e n t

.2

You m a y

the block constructs.

In this source

must

the

p r o g r a m point.

example

is left,

it lacks

labels.

that exit p r o v i d e s

to a d y n a m i c a l l y

We use the exit m e c h a n i s m

statement

constructs,

] ];

epi-

4.5 --

185

.4

eval-Proc

is the i m p e r a t i v e

in e x a m p l e

.2

42

(section

The d e n o t a t i o n

.i

serves

to keep

(identifiers

The b l o c k e n v i r o n m e n t list w i t h this

Since p r o c e d u r e s

track of a c t i v e

na m e d

statement

blocks,

source

activation

from w i t h i n

current

language

passed

identifier

not

activations.

of its n a m e d

statement

(identifier).

and -- i n d e p e n d e n t l y a procedure

lists of any of its embracing,

(thus recursively)

.4-.8

an a c t i v a t i o n

by all)

all Labels

m a y be recursive,

the e n v i r o n m e n t

We shall r e t u r n

selects

selected

associates

(unique)

since gotos m a y o c c u r

lines

is in the domain:

a c t i o n of a Block

in the set of

.4

6.3)°

activations.

The p r o l o g u e

o2

V-Pro, as used

40's

:: AID Lbl

The AID c o m p o n e n t block

of e x a m p l e

6, r e s p e c t i v e l y

of a label

LAB

version

thereof

(activation) including

--

to the

defining,

to eval-Proc is the e n v i r o n m e n t

being

defined.

to lines

.5-~9,

& .3 of int-Block

which

-- on the w h o l e

of example

31,

section

-- r e s e m b l e

4.5.

5 int-Named-Stmt-list (nstl) (g, aa, aid)= .i (tixe

[ mk-LAB(aid, 1) ~ cue-int-Named-Stmt-list(ijnstl)(p,

.2 .3

i 1 < i < len nstl ^ 8-Lbl(nstl[i] i_~n cue-int-Named-Stmt-list(1,nstl)(p,

ca))

6 cue-int-Named-Stmt-list(i,nstl)(p, ca))= .i

for j=i to l e n n e t l

d_~oint-stmt(s-Stmt(nstl[j]))(p, ca)

7 int-Stmt(stmt)(p, ca)= .1 .2

case8 stmt: (mk-Goto(lbl)

.3

mk-Block(.°.)

..

°..)

~

exi~(o(lbl)) ,

~ int-Block(stm~J(p, ca),

-- annotations:

5.0

Interpreting

a named

statement

list is the same as:

ca) = l ~ nil ]

186

5.3

interpreting

that list as from its Ist statement.

T h a t is: the tixe is not

'executed'

(exit spelled in Polish) clause of lines 5.1-5.2 by the m e t a - l a n g u a g e e l a b o r a t o r w h e n first en ~

tering the int-Named-Stmt-list 'discover'

6.0

functions. We shall s u b s e q u e n t l y

the p u r p o s e of the tixe clause.

Having cued this function w i t h i, i.e. having given it the startw o r d i, interpretation

of the statements

of the

(named)

statement

list

6.1

p r o c e e d s linearly, -- provided,

as from the cued, ith, s t a t e m e n t until the last

of course, m e t a - e l a b o r a t i o n is not re-directed.

W h e n & how this occurs will p r e s e n t l y be uncovered.

7.1

If the interpreted

statement

7.2

a Goto, then an exit is performed.

is

a r g u m e n t is the LABel denotation,

It is g i v e n an argument.

This

mk-LAB(aid, lbl), by w h i c h this

label is known in the environment. M e t a - e l a b o r a t i o n of an exit d y n a m i c a l l y

'unravels'

the m e t a - l a n -

guage block invocations. That is: we retrace our steps, back to (here) the m o s t recent m e t a - l a n g u a g e block having a tixe clause. We say that the tixe clause stops the exit.

5.1

The tixe clause we b a c k t r a c k to, is the one a s s o c i a t e d w i t h the named s t a t e m e n t

list of w h i c h the

'offending'

Goto was an immediate

statement. The tixe clause is to be u n d e r s t o o d as follows: p a s s e d b a c k w i t h the exit

of the "map" c o m p o n e n t of the tixe clause,

cue-int-Named-Stmt-list,

if the a r g u m e n t

(7.2) is equal to some mk-LAB(aid, l) then the c o r r e s p o n d i n g

w i t h the a p p r o p r i a t e cue p o s i t i o n

(i), is

invoked; o t h e r w i s e the d e s p a t c h i n g exit is not stopped here, but p a s s e d out to the next e m b r a c i n g tixe clause -- i.e. the Goto is to an e m b r a c i n g Block.

6-7

In now

(re-)interpreting

possibly, 5.1

the

as from another,

These are stopped,

(same) named statement

cued, position,

thus recursively,

by the

list, but,

new Gotos m a y occur. 'same'

tixe clause.

187

7.1

If the interpreted statement

is instead,

in c o n t r a s t to a n n o t a t i o n s

7.1-7.3 above,

7.3

a Block, the~ that, nested,

And so on. p a s s e d on

Block is interpreted.

exits are always stopped by an alway8 clause before being (4.5-4.8).

Comments The "maps" of tixe clauses may,

as we have done in the above annotations,

be c o n s i d e r e d ~2~ to be "computed" w h e n the m e t a - l a n g u a g e e l a b o r a t o r enters a m e t a - l a n g u a g e block having a tixe clause.

The domains of such

"maps" are c o n s t r a i n e d to be s t a t i c a l l y determinable, in the cue-int-.., object,

e l a b o r a t i o n function,

and finite.

Since,

nstl is a static (i.e. fixed)

this c o n s t r a i n t is satisfied.

You m a y in fact v i e w the d o m a i n of the "map" of the tixe clause as being 'computed' u p o n entry to the m e t a - l a n g u a g e block of w h i c h it is part. Now,

for this source language,

the test for w h e t h e r the "returned" argu-

m e n t of an exit belongs to such a "map" is likewise

'statically'

deci-

dable since o n l y Gotos w i t h c o n s t a n t Label d e s i g n a t o r s w e r e permitted.

II.i The Exit M e c h a n i s m s

In the f o l l o w i n g the language constructs, d e a l t w i t h and mentioned, those of the meta-language~

and not c o n s t r u c t s of a ~ 0 ~ c z

are

language

being modeled.

V a r i a b l e s p r e s u p p o s e declarations,

and d e c l a r a t i o n s define a state.

S t a t e m e n t s are r e q u e s t s for state changes, mers,

and denote state t r a n s f o r -

i.e. functions from states to states. The serial s t a t e m e n t compo-

sition o p e r a t o r ";"

(semicolon)

thus denotes functional c o m p o s i t i o n .

In c o m p o u n d e x p r e s s i o n s all c o m p o n e n t s u b - e x p r e s s i o n s are

(usually)

c o m p l e t e l y e v a l u a t e d before any result v a l u e is yielded.

In this section we shall d e s c r i b e the o n l y s t a t e m e n t - and e x p r e s s i o n c o n s t r u c t a v a i l a b l e for c h a n g i n g the m e t a - l a n g u a g e s t a t e m e n t interpre-

188

tation-,

respectively

The exit m e c h a n i s m statements

language,

sion

the e x p r e s s i o n

n o w to be e x p l a i n e d

offers

-- in one sense a r e s t r i c t e d

gotos.

conventional

statements

controlling

gotos

to

In particular: (arbitrary

exits p r o v i d e

evaluation-,

-- in the c o n t e x t

form of,

or a l t e r n a t i v e

instead of providing,

or p h r a s e - s t r u c t u r e

such g o t o s

part.

to

in the meta-

constrained)

to s t a t e m e n t - b l o c k

of

labelled

or b l o c k - e x p r e s -

"ends".

In the c o n t e x t

of an a p p l i c a t i v e

language

it is an a l t o g e t h e r

new con-

struct.

The m e t a - l a n g u a g e

provides

exit,

1,2

(alway8

.i

stopping

constructs:

F(...)

in C(...))

(tra£ exit(def)

4.0

.I

with

F(def)

in C(...))

(tixe

5.0

.i Lines

designators:

exit(expr)

and three kinds of exit

3.0

two k i n d s of exit

[ G(def)

~ F(def)

I P(def)

]

in C(...)) 3.0,

4.0 and 5.0 schematize

prefixed

Clauses

1 or 2 can o c c u r w h e r e m e t a - l a n g u a g e

m a y occur. plicative

Thus

by a stopping

the stopping

C(...),

the exit m e c h a n i s m

construct

ping clause,

construct

-- see

[Bj~rner

as will be seen,

clauses.

becomes

statements

is an imperative,

restricted

blocks.

The forms

d e f can be of either of the forms:

{ dl,d2,...,d n } < d l , d 2, . . . ,d n > m k - D ( d l , d 2, • . . ,dn) , id, c~t

or e x p r e s s i o n s

as w e l l

as an ap-

The use of the always

77e].

is, however,

Any clause,

a block.

(d 1,d 2, •.., d n) , or

stop-

to i m p e r a t i v e

189

w h e r e id stand for terals),

(free or bound)

identifiers,

cst for constants

(li-

d i for forms of the above kind, and w h e r e the def form need

not c o n t a i n any free identifiers.

11.2 P r a g m a t i c s & S e m a n t i c s of the E x i t M e c h a n i s m

The exit concept is based on the f o l l o w i n g four principles:

(I)

The first basic p r i n c i p l e of exit is to p e r m i t goto-like of e l a b o r a t i o n evaluation)

(statement interpretation,

transfer

respectively expression

c o n t r o l to block b o u n d a r i e s -- i.e. to just outside

their t e r m i n a t i n g part. In particular:

e l a b o r a t i o n of any exit not d e f i n i t i v e l y stopped

in a block p r o p e r l y c o n t a i n e d in C(...) will result in immediate t e r m i n a t i o n of any further parts of C(...)

, this to be f o l l o w e d

by e l a b o r a t i o n of some F(...).

(if) The second basic p r i n c i p l e of exit is to p e r m i t the u s e r to (implicitly)

specify w h i c h

(dynamically enclosing)

block end the

exits go tO: A block w i t h no stopping clause is said to not d e f i n i t i v e l y stop any exit. A tra P exit unit w h o s e e l a b o r a t i o n m a y result in an exit is likewise said to not d e f i n i t i v e l y stop an a r b i t r a r y exit. nally:

if an e l a b o r a t i o n of P(.°.)

Fi-

is c o m p l e t e d w i t h no exit then

the exit is said to be d e f i n i t i v e l y trapped.

In that case elabo-

ration of the block c o n s i s t s of e l a b o r a t i o n of the part of C(...) up to the exit f o l l o w e d by e l a b o r a t i o n of the P(...). The p o t e n t i a l state t r a n s f o r m a t i o n y i e l d e d by an i m p e r a t i v e block is in this case the serial c o m p o s i t i o n of the two net effects. For the case the block is a b l o c k - e x p r e s s i o n of d e f i n i t i v e entrapment,

P(...) m u s t in this case, namely that

y i e l d a value.

~II) The third basic p r i n c i p l e of exit is to p e r m i t the m e t a - l a n g u a g e p r o g r a m m e r to specify that c e r t a i n actions be taken at any stopping block end. The stop clauses serves this purpose,

exits from m u l t i p l y nested

blocks m a y cause s u c c e s s i v e s t o p p i n g actions, out), block.

one per block

(inside-

and each being t e r m i n a t e d by an exit to the next e n c l o s i n g

190

An exit not d e f i n i t i v e l y stopped by a stop clause of the (outermost)

block of a f u n c t i o n d e f i n i t i o n is d y n a m i c a l l y p a s s e d to the

immediately function,

e m b r a c i n g block in w h i c h the actual r e f e r e n c e to the

i.e.

"to this f u n c t i o n definition",

occurred.

The always stop clause u n c o n d i t i o n a l l y filters any exit, its

F(...) is elaborated, and the exit p a s s e d on to outer blocks. In consequence:

exits of one f u n c t i o n d e f i n i t i o n may, d e p e n d i n g

on dynamic calling patterns,

be trapped by a m u l t i t u d e of stop

clauses of blocks c o n t a i n e d in various

(other)

function defini-

tions. An exit of an a c t i v a t i o n of a r e c u r s i v e l y defined f u n c t i o n m a y thus be stopped by a prior,

temporarily suspended activation

of that "same" function.

(IV) The fourth basic p r i n c i p l e of the exit mechanism,

i.e. the joint

use of exits and stopping clauses is finally to c o m m u n i c a t e inform a t i o n from the

(usually

only d y n a m i c a l l y determinable)

point of

exit to trap exit and tixe stop clauses' F(.o.). The idea being to let the e l a b o r a t i o n of F(...) In particular:

the value,

depend on exit "returned"

v, of the expr of exit(expr)

the proper stop clause is found;

data. is obtained;

and v is s u b s t i t u t e d for all free

o c c u r r e n c e s of that unit's formal p a r a m e t e r def in that unit's

F(...) r e s u l t i n g in F'(...)o Then F'(...) is elaborated.

Scope Rules

A n a l t e r n a t i v e w a y of d e s c r i b i n g some of the linguistic p r o p e r t i e s the exit mechanism)

Two scope aspects are important: A syntactic tic

(of

is now presented.

(or static),

and a seman-

(or dynamic).

The ~ £ ~ ! ~

~2~

~!~

±S c o n c e r n e d w i t h the scope of i d e n t i f i e r s

o c c u r r i n g in the def form of the trap exit clause. free in the e m b r a c i n g context, fiers in the c o r r e s p o n d i n g

bind

Identifiers of def,

free o c c u r r e n c e s of these identi-

F(def). The static scope rules of the tixe

"map" are the same as those of any i m p l i c i t map

(set or tuple)

construc-

tion. The semantic scope rule is c o n c e r n e d w i t h the scope of the alway,s, tra~

exit and tixe clauses.

191

The dynamic scope rules of the always and tra~ exit clauses is the text C(...); w h e r e a s the dynamic scope rule of the tixe clause includes both the tixe

"map" and the text C(...)!

an exit

Thus:

'occurring'

F(def), of 3.0 or

as a r e s u l t of e l a b o r a t i n g

4.0, if not stopped in F(...), is ~2~ stopped by this

(3.0, r e s p e c t i v e l y

4.0) i n s t a n c e of the always, r e s p e c t i v e l y tra P exit clause.

Instead it

is p a s s e d out to p o s s i b l y e m b r a c i n g meta-blocks.

An exit

'occurring'

of a tixe clause

"map",

as a result of e l a b o r a t i n g some F(def) of 5.0, i.eo

if not trapped in F(...), is trapped by this tixe

(5.0). Thus the tixe clause is said to apply

~S~!E~!£!

Some E q u i v a l e n c e T r a n s f o r m a t i o n s

The always stop clause in:

(always F(...) in C(...)) is s e m a n t i c a l l y e q u i v a l e n t to:

(.trap exit(id) with (F(.~.); exit(id)) in C(...))

In g e n e r a l a b l o c k w i t h no stopping clause:

(let x : E(...); C(...)) is identical to a block w i t h the simple gate:

(tra~ exit(id) with exit(id) in (let : E(...); C(...))). W h e n no block t e r m i n a t i o n actions are n e e d e d in an i m p e r a t i v e block, then we write:

(trap exit with I in C(...))

192

Correspondingly,

w h e n the v a l u e p a s s e d back

(by the exit) u n c o n d i t i o -

nally is to become the result of the block, we write:

(trap exit(id) with id in C(...)) or:

(trap exit(id) with return(id) in C(...)) d e p e n d e n t on w h e t h e r the block

Finally:

(-expression)

is pure or impure.

'mixed', nested uses of exit(e) and exit, and thus e.g.

(trap exit with V(.o.) i_~nC(...)) and (traP exit(id) with F(id) i__nnC(...)) do

not m a k e sense:

(tra~ exit(id) with

F1(id)

in (...) (trap exit with F2(...) in (... exit(expr) ...))

Etcetera~

C o n t i n u i n g our d i r e c t o r y example,

DIR

=

Rid ~ RES

RES

=

VAL i DIR

from e x a m p l e s

19 & 29, we recall:

m

with:

retrieve-res(dir, ridl)= ((ridl = <>) ~ dir, T

~ (let rid = hdridl

in

if rid E dora dir then retrieve-res(dir(rid),t_klridl) else undefined)) N

t~pe: DIR Rid ~

RES

193

Users of the s y s t e m d i r e c t o r y each have their q u a l i f i e d name, uid in

Rid*, o t h e r w i s e g u a r a n t e e d to d e s i g n a t e a DIR object: is-DIR (re trieve-res (Di r , ui d) ) Users issue r e s o u r c e names, rid in Rid + , d e s i g n a t i n g values in the gio= bal directory, by uid

Dir, as follo~s:

let dir

be the d i r e c t o r y d e s i g n a t e d

:

let dir = retrieve-res(Dir, uid) If rid is some

then either rid names an entry in dir,

the r e s u l t is dir(rid).

through,

and we are

Or rid does not name an entry in dir.

We now chop off the last Rid e l e m e n t of uid-- to resume the search as from the d i r e c t o r y d e s i g n a t e d by the r e s u l t i n g If rid is some

DIR

e n t r y in di~,

resQurce name: we

('remaining')

uid,.

then rid I either names a

and we search as from the d e s i g n a t e d directory, w i t h

<~id2,...,ridn>,

or rid I

'back' up the d i r e c t o r y hierarchy,

the root,

forn>l,

does not name a DIR entry, and

to a level one higher,

i.e. nearer

than that at w h i c h we o r i g i n a l l y started , or at w h i c h the

search w h i c h just failed took place.

We c o m p l e t e the above i n c o m p l e t e

d e s c r i p t i o n by giving the formal d e f i n i t i o n of the p r o p e r search algo= rithm:

search(uid, vid)(updown)(Dir)= .i 2 3

(let dir = retrieve-res(Dir, uid) in (trap exit with if updown =

DOW~

4

then exit

5

else if u i d = <>

6

then undefined

7

else search(fst(uid),vid)(UP)(Dir)

.9

then if h d v i d

6domdir

.10

then dir(hdvid)

.ll

else exit

.12

i_~n

else if h_ddvid~6 dom dir

.13

then exit

.14

else search(uid~,tlvid)(DOWN)(Dir))) type: Rid* Rid + ~ ((UPIDOWN)

~ (DIR ~ RES))

Ig4

where:

fst(ridl)

=


I I < i < (lenridl) - 1 >

Given the global directory, and a 'relative'

Dir, w h i c h we could omit as a parameter,

resource name,

rid, we initially invoke the above

search function with the users identification

and the updown

marker

set to UP. We may tie up any loose ends in your understanding rithm, by the following, a node,

alternative

towards the leaves,

Then rid designates path

characterization:

N, in the directory hierarchy

There are now three possibilities path,

of the search algo=

(or:

"tree",

uid designates

see example 19).

for rid. Either there is a d~wnward

from N whose sequence of edge labels is rid.

the object

'hanging'

on to the other end of this

(as seen from N). If there is no such path,

starting at N, then

rid might still designate an object in the hierarchy,

but now as from

a node

and N. Search

N', between the root of the overall directory

starts with the node N' immediately

above N.

The purpose of the u~down marker is to guidethe ~ a ~ up beyond already searched The third possibility,

mechanism

in backing

'subtrees'.

for rid, is that there is no resource,

relative

to uid, that is named by it.

The Zahn Event M e c h a n i s m matically

[Zahn 7h, Knu%h 74~ Hal&s

looks like:

lo__~stmtlO u n t i l e i d l do s t m t l l , eid2 do s t m t l 2 , ,

°

,

e i d n do s t m t l n

pool An abstract syntax is:

75, Bj~rner

YTd] sche=

195

Zahn

::

Stmt +

(Eid ~ Stmt +) m

No s t a t e m e n t in any stmtl i

(1
may name any event:

event eid on any eidj

(1<_j
Event

::

Eid

as a statement,

Stmt

=

i.e. with:

Event

i Zahn

i o..

the static w e l l - f o r m e d n e s s c r i t e r i a can be c o m p l e t e l y specified:

is-wf-Stmt(8 ) (eids )= .i

cases 8:

•2

(mk-Event(eid)

.3

~ s i d e eids,

mk-Zahn(stlO, esm) ~ (¥c E elem8 stlO) is-wf-Stmt(c) (eids U dom esm)

.4 .5

^(reid E dom esm)

.6

(Vc E elem8 (esm(eid) ) )

.7

is-wf-Stmt (c) (eids~dom esm),

.8

.

The informal,

. .

~

.

.

.)

i n c o m p l e t e s e m a n t i c s is: ~tmtlO

If an e v e n t is i n t e r p r e t e d in $tmtlO terminated.

stmtl k

then i n t e r p r e t a t i o n of stmtlO

If the e v e n t names some eid~

is interpreted.

is r e p e a t e d l y interpreted.

This terminates i n t e r p r e t a t i o n of the mechanism.

If the e v e n t names some p r o p e r l y c o n t a i n i n g mechanisms'

Stmtl£ is obeyed,

Zidl,

then its

..., etc. Formally, we can capture things m u c h m o r e

succinctly:

Assuming :

Z = (STG ~ STG)U( . . . . . . . we get an i m p e r a t i v e formulation:

t~pe:

is

(15~k< n), then the c o r r e s p o n d i n g

int-stmt:

strut ~ (ENV ~ (Z

~

Z))

196

int-Stmt(s) (env)= ~8e8

8 :

(ink-Event (ei d) exit(eid) , mk-Zahn (8 t l, esm) (tixe

[eid ~ int-Stmt-list(esm(eid))(env)

I eid 6 dom esm]

in while

true do int-Stmt-list(stl)(env)),

int-Stmt-list(stl)(env.)= for i=I to lenstl

do int-Stmt(stl[i])(env)

It is thus we o b s e r v e that the tixe c o n s t r u c t closely p a r a l l e l s the Zahn e v e n t mechanism.

The reader is,however, w e l l - a d v i c e d to study

[Jones 78a,ySb] in order to d i s c o v e r the neatness of the h-calculus semantics g i v e n there for this m e t a - l a n g u a g e combinator.

197

PART IV ABSTRACT MODELS

Part I exemplified a complete,

abstract model.

Its components were:

abstract syntaxes for both syntactic & semantic domains; dynamic]

(1)

(2) [static and

consistency constraints on objects of these domains -- called

is-wf-..,

functions;

(3) semantic elaboration-

, and

(4) auxiliary func-

tion definitions. In part II, sections 2.1, 3.1, 4.1, 5.1, 6.1 and 7 taught the notation for, and techniques of, defining domains.

Sections 2.2, 3.2, 4.2, 5.2

and 6.2 taught the notation for representing objects of these domains. Sections 2.3, 3.3, 4.3, 5.3 and 6.3 finally taught the notation for, and techniques of, expressing transformations on objects.

Part III generally taught the notation for, and techniques of, stating processes,

respectively composite transformations,

on objects.

Part IV finally closes the story on the meta-language. pieces of the meta-language introduced formally, plified in parts II & I I I , function

definitions.

and also heavily exem-

we can now formally introduce the notion of

Function definitions have, however,

extensively exemplified. on the meta-language.

With the bits and

already been

Section 12 will therefore wrap-up our tutorial

The section can best be understood if you fre-

quently compare the formal information and schematized "examples" with examples 0-63~ That is: we do n ~

present comprehensive,

dels involving function definitions, jects!

abstract mo-

although those are its prime sub-

198

12 F u n c t i o n

In section

Definitions

Abstract

&

5 we introduced

objects,

for r e p r e s e n t i n g

FunCTion

objects.

Recall

the a b s t r a c t m o d e l s

on the other w e gave

The

of e.g.

O n one hand we gave

of a syntactic i.e.

an o b j e c t

an A R G ~ ( X ~ )

abstract

examples

in Prc

syntaxes

for semantic

40),

we call a semantic

This

tion 5, is d e s c r i b e d

function,

for s y n t a c t i c domains.

is an o b j e c t

domains, The m e a n i n g

of a Proce-

in A R G ~ ( Z ~ ) .

its denotation,

elaboration

function

like all the FunCTion

by the m e t a - l a n g u a g e

on

the story we started

The m e a n i n g

takes a Pro o b j e c t and yields

object,

It is a function.

(example

of FunCTion

0,19,29,42,51-52,54-55,58-

syntaxes

object.

domains

and for o p e r a t i o n s

abstract

object was a semantic

"thing" w h i c h

for d e n o t i n g

FunCTion objects,

there.

dure,

the n o t a t i o n

In a sense we are here c o n t i n u i n g

giving

59-60,61.

Models

i.e.

(V-Prc).

objects

of sec-

c o n s t r u c t we call a f u n c t i o n

definition.

12.1 The S y n t a x of F u n c t i o n

A function definition

consists

a body:

The body

C(...) clause:

1
these

in d.'s,

identifiers

Observe

type:

is any s t a t e m e n t

occurring

formal

D 1 D 2 ... D k or e x p r e s s i o n

parameter

and the f u n c t i o n in C(...).

the f o l l o w i n g

~

(Dk+ I ~ (... -~ (P n

clause you choose.

identifiers. name,

They,

The d i for

or any i d e n t i f i e r s

lid, bind free o c c u r r e n c e s

between

the d °'s of the formal

fier,

and is then either syntax rule:

of

parameter

clause.

If d i is of the form , the D~ is either

abstract

~ D')...)

The D.'s and D are d o m a i n expressions.

relations

list and the D .'s of the ~ F $

(i)

of three parts:

f i d ( d l , d 2 , . . . , d k ) ( d k + 1 ) . . . ( d n )=

a header:

a type

Definitions

an identi-

the name of a d o m a i n d e f i n e d by some

199

D.

=

D*,

D.

=

D+

or

D. c D*; or D i is

(directly)

either D* or D + -- for some D.

(2) If d i is of the form { d i l , d i 2 , . . . , d i m }

D.

=

then:

D-set

etcetera.

(3) If d i is of the form m k - ~ ( d i l , d i 2 , . . . , d i m ) ,

then there is an ab-

stract syntax rule:

Di

::

Dil Di2

... Dim

(4) If d i is of the form ( d i l , d i 2 , . . . , d i m ) , r e s p e c t i v e l y

mk(di2, di2 .... ,dim), (Dil Di2

then D i is of the form :

... Dim)

We do not p r e s e n t l y see a need for w r i t i n g di's

in forms other than

the above, w h e r e u l t i m a t e l y d ..'s j end up as identifiers, the di's be identifiers.

In the latter case Di's m a y be any appro-

priate d o m a i n expression, forms

or letting

not just an identifier.

E x p e r i e n c e shows

(1)-(2) to r a r e l y Occur.

This c o n t i n u e s example 40. Now,

PROC

=

ARG ~ ~ (Z ~ Z)

Prc

::

Id ~ Block

let:

and:

ENV

=

Id ~ DEN

DEN

=

LOCI

PROC

W i t h these p r e r e q u i s i t e s we could also w r i t e the V-Prc f u n c t i o n d e f i n i t i o n in this way:

elaboration

200

V-Pro(p) (p)= (let mk-Pro(idl, bl) = p

in

let fct(al)(~)=

• •

. )

in

fat) ) type:

Pro ~ (ENV ~ PROC)

type:

Prc ~ ((Id ~ DEN) ~ (ARG* ~ (Z ~ Z)))

or

Relating the last type

clause to the formal p a r a m e t e r list

we observe that p is of type Pro,

((p)(p))

p of type (Id~DEN), and the result

y i e l d e d by V-Pro is w h a t e v e r remains to the right of the arrow after the ENV specificationl

The form of D remains to be constrained.

(5)

If the body,

C(...), of the function d e f i n i t i o n is a s t a t e m e n t

(-block), then D is of the form: Z ~ Z, or:

I ~ Z

w h e r e Z is the state resulting from global v a r i a b l e declarations.

(6)

If the body,

C(...), is instead an impure e x p r e s s i o n

(-block),

then D is of the form:

Z ~ (Z D'), or:

X ~ (Z D')

where D' denotes the domain of results y i e l d e d by C(...) w i t h Z as in (7)

(5).

If finally C(...) is a pure expression,

D is any d o m a i n e x p r e s s i o n

(etcetera -- c o n c e r n i n g r e l a t i o n to C(...))°

(applicative) I-Block, I-Stmt-list, and I-Stmt, d e f i n i t i o n s of example 42, w e r e all Z. But £hen the X was not

O b s e r v e that D of e.g. the pure

201

that of any global v a r i a b l e state space -- since there was none --, but e x p l i c i t l y d e f i n e d in example 42 formula 2!

end-of-example

Sch~nfinckeling/Currying

The "back-to-back"

("dos-~-dos")

parentheses,

")(", of the formal para-

m e t e r list, e.g. to the left of di, m a y be replaced, i=k+l

, by commas

"," -- p r o v i d e d we s i m u l t a n e o u r s l y delete the "~ ("

in the type clause, (matching)

starting w i t h

to the left of the c o r r e s p o n d i n g Di, and delete a

right p a r e n t h e s e s

(")").

F o r m a l Ex_am_~!es

f(a)(b)(e)(d)

= C(...)

type:

= C(..,)

type: A B - (C-(D~E))

f(a, b, c) (d)

=

~ :

A S C .

f(a,b,c,d)

= C(...)

type:

A B C D

A--(B--(C~(D--E)))

is one way, f(a, b) (c) (d) is another way, C(...)

(D-E)

and: -

E

is a final way of f o l l o w i n g the s o - c a l l e d d e - S c h ~ n f i n c k e ! i n g or deC u r r y i n g rule g i v e n above.

The form: f'(a)(b,e)(d) is, however,

= C(...)

type

A-((B

C)-(D--E))

not a curryi'ng of f's d e f i n i t i o n above. D e - C u r r y i n g f'

w o u l d lead to: f'(a,(b,e),d)

= C(...)

type

A

(B C) D

-

E

The c o n c l u s i o n to be d r a w n from the last example is that the type clause: type:

g':

(D 1 D 2 ... D n)

--

is a l t o g e t h e r d i s t i n c t from: t_~:

g":

D 1 D 2 ... D n

"

D

D

202

A l t h o u g h we m i g h t

(sloppily) write:

g'(dl,d2,...,d n) where, m o r e correctly, we should write:

g'((dl,d ~ .... ,dn)) to d i s t i n g u i s h it from the

(correct):

g"(dl,d2,...,d n) end-of-formal-examples

The rule for removing covered in section 6.2

")("s etc. can be used in reverse -- and this was (see s u b s e c t i o n on l-Expressions).

In 6.2 we

"Curry", whereas here we "de-Curry". As implied by the last,

formal,

example above, we m u s t observe the dual role of parentheses:

delimiting

and a n o n y m o u s tree d o m a i n & tree o b j e c t constructionl has an extra pair of b r a c k e t / b r a c e / p a r e n t h e s i s our {}, <>,

(),

If your k e y b o a r d

delimiters

(other than

[], then use them to distinguish!

The C u r r y i n g / d e - C u r r y i n g Rule is one form of s y n t a c t i c t r a n s f o r m a t i o n on function definitions.

It involved the header~type-clause

'pair'. Se-

mantics r e m a i n e d invariant!

Formal P a r a m e t e r S y n t a c t i c T r a n s f o r m a t i o n s

A n o t h e r kind of syntactic t r a n s f o r m a t i o n rule involves the h e a d e r / b o d y 'pair'.

It can m o s t simply be dealt w i t h by listing the f o l l o w i n g se-

mantic identities:

f( ) = C(...)

(i) f(d) = Clet = d i__nnC(...)) f(mk-Di(dil,di2 ..... dim)) = C(o..) (2)

=_

f(d) = (let mk-Di(dil,di2,...,dim) etc..

= d i_~n C(...))

It is here assumed that d is not free in C(...).

20S

12.2 The S e m a n t i c s of F u n c t i o n D e f i n i t i o n s & A b s t r a c t M o d e l s

The i d e n t i f i e r s o c c u r r i n g in the h e a d e r of a f u n c t i o n d e f i n i t i o n bind all their

(free) o c c u r r e n c e s

in the body~ U s u a l l y there is no need to

r e - d e f i n e i d e n t i f i e r s in any block.

General

An a b s t r a c t m o d e l c o n s i s t s of a set of f u n c t i o n definitions, a b s t r a c t syntaxes,

a set of

and p o s s i b l y also a set of v a r i a b l e declarations.

All names of d e f i n e d functions,

d o m a i n s and v a r i a b l e s are g l o b a l l y known.

The f u n c t i o n d e n o t e d by any such, g l o b a l f u n c t i o n d e f i n i t i o n headers' first identifier,

i.e. by the f u n c t i o n identifier,

w o u l d expect. Formally:

~d,

is the one you

it is the least f i x - p o i n t s o l u t i o n to the equa-

tion set that the f u n c t i o n d e f i n i t i o n s

form.

I n f o r m a l l y we o b s e r v e that an a b s t r a c t m o d e l is all d e f i n i t i o n s -- and no real "action"~ N o b o d y really invokes any of the s p e c i f i e d functions.

A n a b s t r a c t m o d e l d e f i n e s a class of systems.

E x a m p l e 0 d e f i n e d the s t r u c t u r e and p o s s i b l e b e h a v i o r a l p a t t e r n s of a class of grocery stores.

E x a m p l e s 3-8, 12-13,

17-18,

20-25,

27-28 & 35 d e f i n e d f r a g m e n t s of

classes and m a n i p u l a t i o n s of file systems.

E x a m p l e s 19,29&62 d e f i n e d the s t r u c t u r e and o p e r a t i o n s on a class of o p e r a t i n g s y s t e m directories.

E x a m p l e s 30-34, 3 6 - 3 8 , 4 0 , 4 2 - 4 3 , 4 7 , 4 9 , 6 1 , 6 3 , 7 0 defined f r a g m e n t s of structures and m e a n i n g of some class of programs,

i.e. a source language.

If you come w i t h a p a r t i c u l a r g r o c e r y store, or a p a r t i c u l a r file system, or a p a r t i c u l a r d i r e c t o r y and a c o r r e s p o n d i n g a c t i o n

(e.g. put-

204

chase, read, respectively catalog), then the definitions, dels,

tell you what to expect happening.

state c o n f i g u r a t i o n

i.e.

the mo-

If you come with a particular

and a program then the model will compute you a re-

sult. However,

you need not come with a semantic and a syntactic

object.

Come

just with a syntactic object. And the model will produce the answer: this syntactic object denotes

such-and-such

a function from semantic

objects to semantic objects. If you are asking for the meaning of say a Purchase, "stick" your mk-Purchase(...) function.

example

object into the Elab-Purchase

0, then semantic

That is: ~2~ decide which part of your model to concentrate

on. T h e r e f o r e we, the model builders, tic function is the most important,

do not tell you w h i c h one seman-

i.e. which one should always be in-

voked first when "starting up" a model! end-of-exam~! 2

A Note on Input/Output Based on the d i s c u s s i o n

(of example 69) it should n o w be easy to under-

stand why the m e t a - l a n g u a g e

has no input~output

A program in the m e t a - l a n g u a g e

defines

constructs.

a function.

from syntactic objects to semantic objects.

The m e a n i n g

The prime means for expres-

sing this function is the set of function definitions. taxes describe

the domain and range of this meaning

of syntactic objects,

function

The abstract

function:

and the class of semantic objects.

PART V: MISCELLANEAE

There remains only to formally in examples

throughout

introduce

this tutorial.

the elementary

syn

the class

domains used

205

13 E L E M e n t a r y

Data Types

U s u a l l y a p r o g r a m m i n g language comes ready-made,

e q u i p p e d w i t h a set of

basic data types.

A number of such have been e m p l o y e d in the e x a m p l e s g i v e n so far. These are:

.i

R a t i o n a l NUMbers, --with tion,

INTeGers

the operations: ceil~

.2

BOOLeans

.3

QUOTations

.4

TOKENs

(...,-2,-I,0,1,2,...),

+, -, ~, ~,

Natural numbers

<, <, =, ~j >, >, e x p o n e n t i a -

f l o o r ~ etc.

(true,

false)

(8, ~ ,

~

-- w i t h the operations: ~, v, ^, D, m.

. . . . ) -- w i t h the operations:

=, #.

(-- for w h i c h no r e p r e s e n t a t i o n is r e q u i r e d --) -- w i t h

the operations:

=, #.

Other e l e m e n t a r y data types could be considered.

(A data type is a set of objects and a set of operations.

For a data

type to be e l e m e n t a r y its objects m u s t all be c o n s i d e r e d elementary,

i.e.

h a v i n g no structure.

The data types so far f o r m a l l y i n t r o d u c e d were:

SET;

TUPLE;

They w e r e all C O M P o s i t e .

MAP,

FCT;

TREE

Thus the 0BJects of the m e t a - l a n g u a g e satisfy:

OBJ

=

ELEM

COMP

=

SET

j COMP I TUPLE

I MAP

I FCT

I TREE

where the five s u b - d o m a i n s of C O M P are all c o n s i d e r e d disjoint.

In this t u t o r i a l we take

ELEM

=

E L E M to be:

NUM

The f o l l o w i n g r e l a t i o n s apply:

i BOOL

I QUOT

J TOKEN

2~

N 1 c N O c INTG

O t h e r w i s e the E L E M

c NUM

sub-domains are c o n s i d e r e d disjoint.)

If you need to introduce further objects or domains of objects -- by almost all means~ At least as long as they are in k e e p i n g w i t h the principles of a b s t r a c t i o n s

(exemplified),

and thus of the m e t a - l a n g u a g e °

13.1 Rational N U M b e r s

Useful domains are:

NUM

R a t i o n a l numbers,

i.e. the numbers that arise as the

result of integer

(non-zero)

INTG

Integers

NO

N a t u r a l numbers,

divisions.

in p a r t i c u l a r the p o s i t i v e integers

including 0.

NI

N a t u r a l numbers larger than or equal to i.

We only find a need to r e p r e s e n t the integers: ...,

-3,

-2,

-1,

O, 1, 2, 3, ...

Useful o p e r a t o r s / o p e r a t i o n s are: +

addition

-

subtraction multiplication

/

division:

integer d i v i s i o n leaving q u o t i e n t v o i d i n g remainder,

if I N T G

(No,

or N I) r e s u l t is

expected. etc.

If you would like to use:

ceil r

smallest integer larger than or equal to its only operand,

floor r

largest integer smaller than or equal to its only operand,

ij

the e x p o n e n t i a t i o n of i by j

207

etc.s

then we see no p r o b l e m in you doing so. E t c e t e r a -- for the intro-

d u c t i o n and proper e x p l a n a t i o n of your own o p e r a t o r s sgn ....

(mod,

ln, rmd,

).

Programming Note

We a b s t r a c t numerals by the numbers they denote. stants of e x p r e s s i o n s are INTeGers

13.2 BOOLeans

Thus in example 49 con-

(and B00Leans).

& Logic E x p r e s s i o n s

We name the d o m a i n in question:

B00L

Booleans values

In this tutorial we c o u n t on it having just two objects w h i c h we represent:

Useful o p e r a t o r s / o p e r a t i o n s are:

N

negation~

v

or,

^, &

and

=, ~

implication

(two forms provided),

and

(two forms provided).

In order to c o m p a c t formulae we take the ^, v, m o p e r a t o r s as non-commutative!

Thus if in blAbZ bl is false,

if bl in blvb2

b~ is never evaluated. L i k e w i s e

is true.

Predicate Expressions

Besides the p r o p o s i t i o n a l e x p r e s s i o n s w h i c h can be formed using expressions d e n o t i n g b o o l e a n s and the above, c o n v e n t i o n a l operators,

proper

use of the m e t a - l a n g u a g e h e a v i l y relies on the p o s s i b i l i t y of forming q u a n t i f i e d expressions:

208

We

(VxJ(P(xJ)

(Wx £ Set)(P(x))

(3x)CP(xJ)

(3x 6 Set)(P(x))

(3!xJ(P(xJ)

(B'x E Set)(P(x))

'read'

the above expressions:

"for all x in the x for which

set Set the p r e d i c a t e

the predicate

P(x) is true",

P(x) is true",

Set for w h i c h the p r e d i c a t e which

"for all x the p r e d i c a t e

"there

P(x) is true",

exists

"there

P(x) holds".

exists

In your r e a d i n g

the f o r m u l a e

'aloud'

exists

a unique

you can e.g.

'object x', etc.

We refer

to e x a m p l e s

0, 9, i0,

ii,

31

(i0), etc.

Comments:

For the case w h e r e

Set = {Ol,O2,...,On} the q u a n t i f i e d

expressions

can be simply

transliterated:

(Vx £ SetJ(P(x)) P(o I) ^ P(o 2) ^ .,.

^ P(o n)

(Bx E Set)(P(x)) P(o I) v P(o 2) v ...

v P(o n)

(3!x E Set)(P(x)) if (3x 6 Set)(P(x)) then (let o£Set be s.t. P(o) in (¥x 6 Set~{o})(~P(x))) else false,

Also:

"there

an x in the

an

set x for

P(x) holds", and "there exists a unique x in the set Set for which

we did in the last two forms -- and you can i n s t e a d of x' or

P(x) is true",

'x' say

v a r y as 'objects

209

-(3x) (P(x) )

=-

(¥x) (~P(x) )

-(3x 6 Set)(P(x))

=-

{,Vx E Set)(~P(x))

13.3 QUOTations The subject domain is here named:

QUOT Quotations are objects whose representations

can be said to denote them-

selves. They are not to be confused with characters and characterstrings of conventional languages. ably) upper-case letters,

G

~. . . . .

~, ~ ,

We choose under-dashed sequences of and

(prefer-

(rarely) other symbols:

~ .....

~,

~,

~ .....

~ ....

, ~-.-~

....

The only two operations intended are:

=

equality

#

non-equality

(Quotations correspond to the enumerated type objects of PASCAL, but we define no ordering on them.)

If you wish to use quotations

characters then observe that ABC is indivisible; these modeling strings,

to model

and if you wish to use

then make tuples of quotations!

The following formulae may complete the syntax of example 49:

~oo~-Op

=

~E~

Re 1-Op

=

LARG

I o~ I £~Z I LAEQ

I EQ

I NEQ

I SMALI

SMEQ

An evaluation function for the expressions of example 49 might use these quotations:

210

eval-Expr(e)(p)= dace8

e:

(ink-Infix ( le , op , re ) (let Iv : e v a l - E x p r ( l e ) ( p ) , rv o~8e8

: eval-Expr(re)(p); op:

(ADD

~ return(lv+rv),

SUB

~ return(lv-rv),

° . ,

AND

~ return(lvArv),

OR

~ return(lvvrv),

LARG ~ return(lv>rv),

SMEQ ~ return(Iv
Expr ~

(ENV ~

(Z ~

(X VALJJ)

Here it was assumed that IV and rv were of the appropriate type. Suppose the language is statically type checkable,

then:

ie-wf-Expr(e)(dict)=

( m k - I n f i x ( l e , o p , re) (i8-wf-Expr(le)^ is-wf-Expr(re)^ (let

~t = e - t p ( l e ) ( d i c t ) , rt = e - t p ( r e ) ( d i c t ) ;

(is-Bool-Op(op) T

~ It = I N T = rt))),

°..) E x p r ~ (DICT ~ BOOL)

type:

where: DICT

=

Id ~

~ It = BOOL = rt,

(INTIBOOL)

13.4 T O K E N s The subject domain is named:

211

TOKEN

Tokens are objects for which we seek no representation. The only two operations provided are: =

equality in-equality

When modeling the identifiers of software systems system directory,

(e.g. the operating

examples 19 & 29; the file system file identifiers,

examples 20, 24-25, 27-28 & 36; the source language variable procedure and formal parameter identifers,

examples 30-31-32-33,

when modeling labels of a goto language storage addresses, TOKENs.

36 etcetera),

(example 61), or when modeling

or as we call them: Locations

(example 30-31) we use

That is:

Rid

=

TOKEN

(exs. 19!,

Fid

=

TOKEN

(exs. 20),

Id

=

TOKEN

(exs. 30-33,

Lbl

=

TOKEN

(ex. 61),

LOC

=

TOKEN

(ex. 30), and

Scalar-Loc

=

TOKEN

(ex. 31).

36,...),

When in e.g. examples 24-25 & 27 we write suitably decorated f i d ~ s , these are meta-language

identifiers naming otherwise unrepresented F i d

objects.

When in example 31 we need to 'generate' "pull them out of the S c a l a r - L o t

(let

sloc

E Scalar-Loc

be

new S e a l a r - L o c a t i o n s ,

then we

bag":

8.t.

P(sloc)

o..)

81oc

names a T O K E N

object. We need not know "what it looks like":

212

PART VI:

POSTLUDE

This completes

the informal introduction

to the meta-language.

ACKNOWLEDGEMENTS: The author is pleased to acknowledge the IBM Vienna Laboratory,

all of his former colleagues

and Mrs.Jytte

handling of eight IBM "golf ball"

S~llested

type-fonts~

for her expert

of

213

EXAMPLEINDEX:

0.

Grocery Store.

A Complete Model: Abstract Domains,

Objects,

Syntax,

Operations,

Func=

tion Definitions. i.

School-Class

of Students.

Section Introduction: stract Syntax,

Sets, Ab=

Domains,

Objects,

Operations. 2.

Collections

of Classes

Set Domains.

of Integers. 3.

Files: Unordered Collec= tions of Records.

4.

Collections

of Integers.

5.

Records,

6.

-"-

7.

File Manipulations

Explicit Set Constructions.

Files.

&

Primitive

Set Operations.

Record Handling.

Imperative 9.

Equivalence

Classes.

Set Operations.

Complete Specification: Syntax,

Function Definitions.

i0.

Coarsest Partitionings.

_._

ll.

Pascal Triangle.

Section Introduction: mains,

Abstract

Objects,

Tuples,

Applicative

Do=

& Im-

perative Function Definitions. 12.

Ordered Fields of Records.

13.

-- | I

Tuple Domains,

Abstract Syntax.

Tuple Enumerations.

214

14.

Fibonacci Numbers

Tuple Enumerations.

15.

Pascal Triangle.

Implicit Tuple Enumeration.

16.

Value Stacks.

Tuple Domain & Primitive Tuple Operations.

17.

Primitive Tuple Operations.

File Handling.

Applicative

18.

& Imperative Tuple

Operations. 19.

Section Introduction:

System Directory.

stract Syntax, Operations, 20.

File System & Files.

21.

Files.

22.

w

Objects,

Map Domains.

I I

File System & Files.

Explicit Map Constructions. Implicit Map Constructions.

25. 26.

Domains,

Function Definitions.

Ilm

23. 24.

Maps, Ab=

Implicit Map Construction:

Conceptual Example.

Scope of Identifiers,

the

Abstract

Syntax.

27.

File System & Files.

Imperative Map Operations.

28. 29.

Primitive Map Operations.

Function Definitions,

System Directory.

Map Opera=

tions. 30.

Progr.Lang.:States ronments

& Envi=

as Models of Var=

iables & Scopes.

Map Domains,

Primitive Operations,

Abstract Syntax.

215

31.

32.

Prgr.Lang. :Model of Block

Abstract Syntax, Map Domains,

Concept & Storage.

Function Definitions.

Prgr.Lang. :Blocks.

Trees, Syntactic Domains. Trees, Abstract Syntax.

33. 34.

Prgr. Lang.: Statements.

35.

System Directory & Direc= tory Update Commands °

36.

Prgr. Lang.: Procedures.

37.

Prgr. Lang.: Statements.

Selector Functions,

Abstract

Syntax. mT~

38. 39.

Factorial Function.

Section Introduction:

Functions,

Function Definitions,

Block Ex =

pressions. 40.

Prgr.Lang.:Procedures.

Function Denotations,

Semantic

Domains, Syntactic Domains, Ab= stract Syntax, Elaboration Func= tions. 41.

Meta-Language:

Type of

Function Types.

Primitive Operations. 42.

Prgr.Lang.:Blocks

& Sta=

tements.

Abstract Syntax, Elaboration Function Definitions,

Function

Application. 43.

Prgr.Lang.

Section Introduction: Syntax.

44-46.

Conceptual Examples.

Abstract Syntax.

47.

Prgr.Lang.:Syntax

~8-functions.

Abstract

216

48.

Reflexive Domains.

Abstract Syntax,

Map Domains,

Map Objects. 49.

Prgr.Lang.:Expressions.

Abstract Syntax, McCarthy Condi= tional Clause,

50.

Factorial Function.

Function Definition.

Section Introduction: Applicative

Variables,

& Imperative Function

Definitions,

Expression Blocks,

The State. 51.

Prgr.Lang.:Modeling Variables,

52.

Global Variables,

The State.

Input, Output.

Prgr.Lang.:Assignment,

Elaboration-

& Auxiliary Function

Input, Output.

Definitions,

Variables,

Assign=

men,. 53.

Conceptual

Example.

Imperative

& Applicative

Combi=

nators. 54.

Prgr.Lang.:Structured

Abstract Syntax,

Statements.

Structured Applicative

Semantic Domains,

Clauses:

cases, if,

Definitions

of Impe=

rative Features.

55.

56.

Prgr.Lang.:For-To-Do

Abstract Syntax,

Statement.

Elaboration Function Definitions.

Prgr.Lang.:Compound

-"- &: for-to-do• Imperative

Statement.

finition. -"-

57. 58.

Prgr.Lang.:Arbitrary

Semantic Domains•

but Applicative

De=

Definition.

Ifm

Ordering. 59.

-"-

For-All Statement

60.

Prgr.Lang.:

While-Do

lib

Recursive

("sledge-hammer")

nition of ("egg")

while.

Defi =

217

61.

Prgr.Lang.:Guarded

Repe=

titive Command.

62.

Prgr.Lang.:GOTO

Elaboration Function Definition, Applicative Definition.

& Block

exit and tixe

Concept Model. 63.

System Directory:

Hierar=

exit and trap

chical Entry Access. 64.

Prgr.Lang.:Zahn's

Event

exit and t~xe

Mechanism. 65.

Prgr.Lang.:Procedures.

Abstract Syntax, Syntactic & Se = mantic Domains,

Elaboration Func=

tion Definitions. 66.

Prgr. Lang. :States.

Imperative & Applicative

67.

Prgr.Lang.:Expressions.

Quotations.

68.

Prgr.Lang.:Names

Tokens.

dresses.

& Ad=

'States'.

THE META-LANGUAGE:A REFERENCEMANUAL

Cliff B.Jones

Abstract: The recent work of the Vienna Laboratory on the sub= ject of semantic definitions has used the "denotational semantics"

approach. Although this is a clear break

with the earlier abstract interpreter approach,

the

newer meta-language has tried to preserve and even improve upon the readability of the earlier "VDL" no = tation. The meta-language described here has been used in the definitions of large programming languages and systems. This paper is not a tutorial;

rather it pro =

vides a reference document for the meta-language.

CONTENTS

0.

Introduction

220

I.

Logic Notation

223

2.

Elementary Objects

224

3.

Composite Objects

225

3.1

Sets

226

3.2

Pairs

228

3.3

Maps

228

3.4

Tuples

230

3.5

Trees

231

3.6

Functions

232

3.7

Implicit Definition

235

4.

Object Description

236

5.

The r61e of "undefined"

239

6.

Defining Semantics

240

6.1

States & State Transitions

241

6.2

A Macro-expansion Process

243

6.3

Simplifying Extended Expressions

251

6.4

Basic Combinators

258

6.5

Other Issues

258

APPENDICES I

Concrete Syntax

261

II

Conventions

265

III

Example definition

266-277

220

0. I N T R O D U C T I O N Q

This paper is intended to p r o v i d e a r e f e r e n c e d o c u m e n t w h i c h d e s c r i b e s the m e t a - l a n g u a g e used t h r o u g h o u t this volume.

It is equally i m p o r t a n t

to a p p r e c i a t e w h i c h o b j e c t i v e s are not b e i n g aimed for here. On the one h a n d this d o c u m e n t is d e f i n i t e l y not a tutorial, neither for den o t a t i o n a l semantics nor for the specific m e t a - l a n g u a g e used. of this paper no m o t i v a t i o n at all is provided,

In m u c h

the reader who is not

familiar w i t h the general ideas is r e c o m m e n d e d to read Bj~rner 78b before a t t e m p t i n g to use this paper. On the other h a n d this d o c u m e n t does not p r o v i d e a formal

"foundation" for the m e t a - l a n g u a g e in the

style of, say, Mosses 75.

The a i m of this

"reference manual"

is to p r o v i d e a d o c u m e n t w h e r e

readers or writers of the m e t a - l a n g u a g e can find a d e s c r i p t i o n of its constructs in terms of some other notation. As such, this d o c u m e n t does not n e c e s s a r i l y i n t r o d u c e all terms and n o t a t i o n in a strict leftt o - r i g h t order.

The n o t a t i o n to be i n t r o d u c e d is p r i m a r i l y intended for the purpose of d e f i n i n g languages or systems using the a p p r o a c h k n o w n as "denotational semantics";

a l t h o u g h it can also be used as a sort of p r o g r a m m i n g lan-

guage this is not its purpose. A general

"denotational" a p p r o a c h can

be expected to yield a d e f i n i t i o n w h i c h can be viewed in four parts:

~)

A b s t r a c t syntax of the language to be studied

~)

Context Conditions

~)

S e m a n t i c Objects

~v)

M e a n i n g function(s)

Before e m b a r k i n g on d e f i n i n g the m e a n i n g of a language it is o b v i o u s l y e s s e n t i a l to fix w h a t

("object")

language is to be studied:

the task of the first two parts of a definition.

this is

The a b s t r a c t syntax

defines a class of objects w h i c h are abstractions of the actual texts of the language. syntax:

(The class of texts w o u l d be d e s c r i b e d by a c o n c r e t e

this subject is w i d e l y d o c u m e n t e d and in c o n s e q u e n c e need not

occupy space here).

The a b s t r a c t s y n t a x of a language is "context free"

and it is thus impossible to r e s t r i c t the class of a b s t r a c t texts to those which are o b v i o u s l y meaningful.

For example,

in a p r o g r a m m i n g

language it is impossible to specify that all valid programs m u s t use only d e c l a r e d identifiers. the m e a n i n g functions,

Rather than leave such c h e c k i n g to cloud

a s e p a r a t e section defines p r e d i c a t e s over the

221

objects of the a b s t r a c t syntax.

Such p r e d i c a t e s define a sub-set of

the objects w h i c h are s p e c i f i e d by the a b s t r a c t syntax;

those objects

w h i c h s a t i s f y the c o n t e x t c o n d i t i o n s are said to be "well-formed". The m e a n i n g functions p r o v i d e d e n o t a t i o n s only for w e l l - f o r m e d objects.

The third p a r t of a d e f i n i t i o n defines sets of semantic objects. the d e n o t a t i o n s c h o s e n for a language states)

Both

(e.g. c o n t i n u o u s functions over

and any a u x i l i a r y objects such as environments are described.

In a sense,

this part of a d e f i n i t i o n is unnecessary~

The a b s t r a c t

syntax is the only way in w h i c h the class of source objects is d e l i m i t ed

(unless a translator f u n c t i o n from c o n c r e t e syntax is written);

the

d e n o t a t i o n s and a u x i l i a r y objects w h i c h can be created by the m e a n i n g f u n c t i o n s could,

in fact, be d e d u c e d from those functions. However,

the s e p a r a t e d e s c r i p t i o n of semantic objects

is both an invaluable aid

to the reader of a d e f i n i t i o n and an i m p o r t a n t tool to be used during the d e v e l o p m e n t of the m e a n i n g functions.

The first three parts of a definition,

then, have defined a class of

w e l l - f o r m e d a b s t r a c t objects and a class of semantic objects: m e a n i n g is d e f i n e d by a f u n c t i o n m a p p i n g the former into the latter. This mapping will be d e f i n e d by a family of

(recursive)

functions. An o b j e c t i v e

of a d e n o t a t i o n a l d e f i n i t i o n is that the m e a n i n g of a c o m p o s i t e o b j e c t should be created from the m e a n i n g s of its components. G i v e n this objective there w i l l n o r m a l l y be one semantic f u n c t i o n for each sub-class of a b s t r a c t objects.

H a v i n g o u t l i n e d the "denotational method"

in general,

a few comments

can now be made on the spefic m e t a - l a n g u a g e used in this volume. n o t a t i o n was r e f e r r e d to w i t h i n the Vienna Lab as "Meta-IV").

(The

It is

i m p o r t a n t to a p p r e c i a t e that the authors do not regard the m e t a - l a n guage as any sort of fixed standard.

Rather,

it is o f f e r r e d as a basis

w h i c h has been shown to be a d e q u a t e for a v a r i e t y of definitions,

and

w h i c h can be e x p e c t e d to be a d e q u a t e for d e f i n i n g other related systems. Even for such systems the e x i s t a n c e of a b o d y of n o t a t i o n does not elim i n a t e the d i f f i c u l t i e s of c h o o s i n g suitable abstractions their definition.

Moreover,

for use in

it m u s t be r e a l i z e d that an a t t e m p t to ap-

ply the ideas of d e n o t a t i o n a l semantics to systems of an e n t i r e l y different nature will require the i n v e n t i o n of suitable extensions to the n o t a t i o n p r e s e n t e d here. T h e r e does, however,

appear to be some virtue

in a d e g r e e of s t a n d a r d i s a t i o n in the b a s i c notation.

222

The n o t a t i o n used by the O x f o r d U n i v e r s i t y group

(cf. Stoy 74)

for de-

n o t a t i o n a l semantics d e f i n i t i o n s is rather d i f f e r e n t in a p p e a r a n c e from that p r e s e n t e d here and it may be useful to s p e c u l a t e as to the cause. The O x f o r d group h a v e b e e n p r i n c i p a l l y c o n c e r n e d w i t h q u e s t i o n s of foundations and have w o r k e d w i t h r e l a t i v e l y small languages. They have,

in fact, chosen languages w h i c h illustrate the key p r o b l e m s with

a m i n i m u m of u n n e c e s s a r y detail.

In contrast,

tended to tackle

languages and systems. Furthermore,

larger

(given)

the languages have u s u a l l y b e e n d e f i n e d

the Vienna group have

"warts and all". For a defi-

nition of a certain size it becomes v i r t u a l l y i m p o s s i b l e to r e m e m b e r enough c o n v e n t i o n s to permit use of single c h a r a c t e r names,

type clauses

given i m p l i c i t l y by Greek letters chosen for p a r a m e t e r s etc. Thus,

for

large languages a d i f f e r e n t style is adopted to provide a readable definition. For example, possible,

(longer)

a syntax is e m p l o y e d w h i c h is as a b s t r a c t as

f u n c t i o n names are u s e d in the hope that they are

s u g g e s t i v e to the reader etc.

It is i n t e r e s t i n g to compare the rela-

tive merits of s u c c i n c t n e s s and r e a d a b i l i t y on Mosses 74 and Henhapl

78. The various topics are d i s t r i b u t e d t h r o u g h o u t this paper as follows. S e c t i o n 4 is c o n c e r n e d with the a b s t r a c t syntax notation. The actual objects

(and their operators)

w h i c h have been found to be of use in

earlier a p p l i c a t i o n s of this m e t a - l a n g u a g e ,

are d e s c r i b e d in sections

2 and 3. S e c t i o n s 1 and 5 b r i e f l y outline the logic n o t a t i o n used. The heart of the m e t a - l a n g u a g e is the means for d e f i n i n g and c o m b i n i n g m e a n i n g functions:

this is d e s c r i b e d in section 6. The subject of ar-

bitrary order or m e r g i n g of o p e r a t i o n s

is c o m p l e t e l y omitted from

this paper for reasons given in section 6.

An outline concrete syntax for the m e t a - l a n g u a g e is given in a p p e n d i x I and a p p e n d i x II lists some c o n v e n t i o n s w h i c h have been used in earlier definitions. A p p e n d i x III contains a d e f i n i t i o n of a small language, close study of w h i c h should provide the reader w i t h a clear u n d e r s t a n d i n g of the use of the notation.

223

i. LOGIC N O T A T I O N

In d e f i n i n g any language s o m e t h i n g has to be taken as a basis. For the d e s c r i p t i o n of the o p e r a t o r s of the m e t a - l a n g u a g e ,

the f i r s t - o r d e r pre-

dicate calculus w i t h e q u a l i t y is chosen. T h e r e are two reasons for this choice. Firstly, provided

a c o n s i s t e n t and c o m p l e t e a x i o m a t i c d e f i n i t i o n can be

(e.g. Kleene

67). Secondly, it is w i d e l y enough u n d e r s t o o d

that the p r e s e n t a t i o n here can be r e s t r i c t e d to p r o v i d i n g

"readings"

for the p a r t i c u l a r symbols chosen.

Fig.

I-! d i s p l a y s the n o t a t i o n a d o p t e d t h r o u g h o u t this paper. The con-

straints on b o u n d e d q u a n t i f i e r s are used in p r e f e r e n c e to implications (Thus:

(Vx£NatO)(lis-prime(4.x)) (Vx)(x6Nat 0 ~ lis-prime(4ox))

, rather than

)

in order to reduce the number of "undefined" operands°

However,

the

p r o b l e m of the m e a n i n g of the logical operators w i t h u n d e f i n e d values m u s t be faced and is d i s c u s s e d in section 5. The c o n s t r a i n t s on quantifiers m a y be o m i t t e d w h e r e the context makes t h e m obvious.

The

(iota) d e s c r i p t i o n o p e r a t o r yields the unique o b j e c t s a t i s f y i n g a

predicate.

It is an error to use the o p e r a t o r if no, or m o r e than one,

v a l u e s a t i s f i e s the predicate.

(B:XoEX)(P(Xo)) Here again, text.

Thus:

~ p((~xEX)(p(x)))

the c o n s t r a i n t may be omitted if it is clear from the con-

224

Symbol

Reading

TRUE FALSE

truth values

&

and

V

or

implies equivalence not V

for all

3

there exists

3"

there exists exactly one the unique object

(¥x£X)(p(x)) (vxlc(x))(p(x))

for all members of set X, p(x) for all x satisfying c, p(x) similarly for other quantifier8

fig. I-1: Logic notation

2. ELEMENTARY OBJECTS

In writing a definition it will normally be necessary to use objects which are structured

(i.e. composite).

together with their operators, will, however,

Some types of composite objects,

are described in section 3. A definition

also have to employ certain basic objects whose struc-

ture is of no interest for the system being defined. For example, many definitions will require natural numbers but will wish to treat them as elementary objects. Two standard objects,

the truth values, have already been introduced:

225

TRUE,

FALSE

A n o t h e r o b j e c t w h i c h w i l l be e x p l a i n e d b e l o w holder for an o m i t t e d b r a n c h in a tree)

(roughly,

it is a place

is:

NIL An a u t h o r may also e n u m e r a t e any other objects r e q u i r e d for his defin i t i o n in a n o t a t i o n e x p l a i n e d in section 4. The only p r o p e r t y which is assumed about e l e m e n t a r y objects is that they are d i s t i n g u i s h a b l e . Thus two m e a n i n g f u l o p e r a t o r s are the e q u a l i t y operators

(=,#). A m o n g

the e l e m e n t a r y objects to be e n u m e r a t e d for a d e f i n i t i o n are "references"

(see s e c t i o n 6.1).

In a d d i t i o n to those objects w h i c h can be enumerated,

a definition

w i l l u s u a l l y also require k n o w n objects like natural numbers,

integers,

reals etc. W i t h such familiar sets one may also w i s h to adopt some of their standard o p e r a t o r s

(e.g. <,~,/). Any d e f i n i t i o n should include

a list of such a s s u m e d objects and their operators.

S e c t i o n 3.1 lists

some s u g g e s t e d names for sets of such objects. All d e f i n i t i o n s w i l l be a s s u m e d to use the s t a n d a r d p r o p o s i t i o n a l c o n n e c t i v e s on the truth values.

3. C O M P O S I T E OBJECTS

A d e f i n i t i o n w i l l have to d e f i n e a number of classes of objects, least the texts of the l a n g u a g e or s y s t e m b e i n g defined.

not

The style of

d e f i n i n g classes of objects is d e s c r i b e d in s e c t i o n 4. This s e c t i o n w i l l i n t r o d u c e a number of classes of objects which, are u s e f u l in b u i l d i n g a b s t r a c t i o n s a p p r o p r i a t e for m o s t systems. The objects g i v e n here,

in d i s t i n c t i o n to those d i s c u s s e d in section 2, have structure.

Thus o p e r a t i o n s will be introduced for m a n i p u l a t i n g

(building), decom-

posing and i n t e r r o g a t i n g the objects of each class. The test for eq u a l i t y is a v a i l a b l e for each class and w i l l be defined.

The objects are d e f i n e d in the first p l a c e in terms of the logic not a t i o n i n t r o d u c e d in section i; there is then a layer by layer cons t r u c t i o n of each m o r e c o m p l e x class of objects. struction,

B e c a u s e of this con-

c e r t a i n objects of d i f f e r e n t classes are formally identical:

226

in fact d e f i n i t i o n s

will

ensure

that the types

are not mixed.

3.1 Sets

Sets are c h a r a c t e r i z e d object

is a m e m b e r

by the m e m b e r s

they contain.

of a set is achieved

Testing whether

by a two p l a c e

an

infix operator:

e£S

This

is a p r o p o s i t i o n a l

Its c o n v e r s e

Fig.

3-I uses

expression

and thus y i e l d s TRUE or FALSE.

is written:

the test for m e m b e r s h i p

tice that the d i s t r i b u t e d

to d e f i n e

union_ is d e f i n e d

the set operators.

only for sets of sets.

Set O p e r a t o r

Definition

S = T

e£S~=~e£T

S UT

{xlxCS v x6T}

unio n S

{eI(Bs6S)(e6s)}

s nT~

{xlx6s & x~T}

s -~

{=Ix£s & xCT}

ScT

e6S ~ e6T

scT

Sc_T & S%T

Fig.

3-I: Set o p e r a t o r s

The basic way of c o n s t r u c t i n g predicate,

those

No-

elements

sets is by i m p l i c i t l y

of some other

set w h i c h

defining,

via a

are to be included:

227

XoE{X£Sip(x)}

~

(Xo6O & p(Xo))

W h e r e some set is clearly implied as the r a n g e by the c o n t e x t in w h i c h a f o r m u l a appears,

the "6S" can be omitted.

It is p o s s i b l e to v i e w the e x p l i c i t e n u m e r a t i o n of the elements of a (finite)

set as an abbreviation:

{Xl~X 2 ..... x n} = {xlx=x I v x = x ~ v . . , In particular,

v x = x n}

for the empty set:

Thus :

"1(Bx o) (Xo6 { }) For two integers a set of integers can be d e f i n e d by the abbreviation:

{i:j} A= {x£intli<x<j } W h e r e context makes clear w h i c h variable(s)

is

(are) to be c o n s i d e r e d

bound:

{f(x) Ip(x)} ~- {zI(3x)(p(x)

& z=f(x))}

The n u m b e r of e l e m e n t s in a finite set can be d e t e r m i n e d by:

card {} = 0 Xo~S ~ card (SU{Xo}) = card S + 1 It is well k n o w n that an u n c o n s t r a i n e d v i e w of sets will p e r m i t the p o s s i b i l i t y of p a r a d o x i c a l sets

(e.g. {SIS(S} ) : s t a r t i n g from non-pa-

r a d o x i c a l sets and u s i n g the o p e r a t o r s g i v e n here this d a n g e r d o e s not exist.

The f o l l o w i n g standard sets w i l l be used:

Bool = {TRUE, FALSE} Nat = {I, 2 . . . . }

228

N a t 0 = {0, Int

I, 3,

= { ....

-1,

o~.} O, 1,

..o}

3.2 Pairs

In b u i l d i n g the s u b s e q u e n t

notion

a n o t a t i o n for ordered pairs:

of M A P

it w i l l be n e c e s s a r y to have

such a n o t a t i o n is introduced in this

section but will not be used other than w i t h i n section 3 (a general tuple n o t a t i o n is d e v e l o p e d in section 3.4.)

The objects c o n s i d e r e d here will be b e s t u n d e r s t o o d as ordered pairs:

pair(el,

e~)

£ PAIR

They, and their operations,

p a i r ( e I, e 2) = {el,

are d e f i n e d via sets:

{e I , e2}}

S e l e c t i o n of elements is achieved by:

first(pr)

=

(lel)(Be2)Cpr

= {e I , {e I, e2}})

second(pr)

=

(~e2)(3el)CPr

= {e 1,

(e I, e2}})

Notice that it is an immediate c o n s e q u e n c e of the d e f i n i t i o n that:

p a i r ( e 1, e 2) = p a i r ( e l ' ,

e 2 ') ~=~ ~e I = e I ' & e 2 = e2')

3.3 Maps The M a p s

to be i n t r o d u c e d here are a r e s t i c t i o n of the general functions

to be covered in section 3.6. The r e s t r i c t i o n is that the d o m a i n of a map is finite and c o n s t r u c t a b l e

(i.e. every way of g e n e r a t i n g a map

also shows how to compute the domain). The u s e f u l n e s s of this restricted class of functions

(along w i t h its separate notation)

comes from

their use in a definition. The basic m o d e l is a set of pairs w h i c h pair a u n i q u e second element w i t h any first element:

229

for m6Map: PI" P2 £m & first(Pl) For some MAP

= first(P2)

~ Pl = P2

m, the O p e r a t i o n s of domain, a p p l i c a t i o n and range are

d e f i n e d in terms of the set model:

domm = {dl(3pEm)(d = first(p))} m(d) = (Ir)(palr(d,r)Em) rn~m = {m(d) IdEdomm} The actual c o m p u t a t i o n of the d o m a i n of a map can be shown for each of the m a p g e n e r a t i n g e x p r e s s i o n s below.

(The range o p e r a t i o n is also re-

cursive b e c a u s e d o m a i n is). N o t i c e that a p p l y i n g a map to an element o u t s i d e its d o m a i n is undefined.

The m a p c o n s t r u c t o r s and o p e r a t o r s are d e f i n e d in fig.

3-2. The b a s i c

way of c o n s t r u c t i n g maps is by i m p l i c i t l y d e f i n i n g the pairs they should comtain.

Strictly,

the set from w h i c h d is chosen should be spe-

cified h~t this w i l l be a s s u m e d to be given by the context. As w i t h sets a finite e n u m e r a t i o n of the elements

in a map is r e g a r d e d as an

abbreviation.

Notation

Meaning

Domain

[c~rIp(d,r) ]

{pair(d,r) Ip(d,r) }

{d I(3r) (p(d,r) ) }

[dF r I..... dn~r n]

[d~*rl (d=d I & r=rl)v... {d=dn & r=r n) ]

{dI ..... dn}

jr m U n

~d°mm U domn

m+n

[c~rldEdomn & r=n(d)v

domm U domn

m}8

d£(domm-domn) & r--re(d)] [~-~(d) Id~(do~nns) ]

do~ a s

m\s

[ d~m (d) [dE (do....~-s) ]

do___~ - s

] ~ [&~m(n(d) ) IdEdomn]

domn

for: dommndomn = {} mUn

for: ~ g ~ _ o ~ rn'n

fig.

3-2: M a p s

230

Notice that the union o p e r a t o r is d e f i n e d b e t w e e n maps w h o s e domains are disjoint. The normal

(set) union symbol will be used b e c a u s e it

is clear that maps are being combined.

3.4 Tuples

The objects d e s c r i b e d here will be familiar as u n b o u n d e d but following Reynolds

(finite)

lists,

76 we yield in the face of the e s t a b l i s h e d use

in c o m p u t i n g of this term.

(Although the term "list" will be used in

informal discussions).

Tuples are m o d e l l e d on maps and are either empty or have a head and a tail component. The tail c o m p o n e n t of a tuple is always a tuple. Tuples are finite,

that is after a finite number of selections of the tail

c o m p o n e n t an empty tuple w i l l be located.

t6TUPLE

~

(domt = {} v domt = {H_DD, T L} & t(T_kL)6TUPLE)

The tuple n o t a t i o n

(including e x p l i c i t enumeration)

is d e f i n e d in fig.

3-3. Unlike sets, tuples provide an ordered access to their elements (by hd or indexing). For this r e a s o n care m u s t be taken in the choice of an i m p l i c i t list notation.

In order to ensure that an order is de-

fined for the c r e a t e d list, g e n e r a t i o n is d e f i n e d only for

(modifica-

tion of) a s u b - l i s t of a given list. Thus:

N o t i c e that the d i s t r i b u t e d c o n c a t e n a t i o n tuples of tuples.

("cone")

is only d e f i n e d for

231

Notation

Definition

<>

[]

<ela...jen>

[HD~e I, 2L__~[....

Tn~[~D+en,2n+[]]...]]

for tup~<>:

h_!dtup

tup(H~D)

for tup~<>: t ltup

tup (T i)

lentup for 1&i~lentup:tup(i)

(HDEdomtup~O,T~lentltup+l) (i=1~h_ddtup, T~(t_~ltup)(i-1))

tupl^tup2

(I tup)(lentup

= lentupl+lentup2

~ tup(i)=tup1(i))

(l
~ tup(i+lentupl)=tup2(i)))

conc tt

(tt=<> ~ <>, T~h_ddtt^conctltt)

elemstup

{tup(i)II~i
indstup

{1:lentup}

fig.

&

(l
&

3-3: tuple n o t a t i o n

3.5 Trees

In o r d e r to d e f i n e s t r u c t u r e s w h i c h c o r r e s p o n d programs etc., of objects

(abstract forms of)

into new objects and these c o m b i n a t i o n s m u s t be r e c o g n i s -

a b l e and d e c o m p o s a b l e . functions"

to

it will be n e c e s s a r y to have a w a y of c o m b i n i n g instances

Such objects w i l l be b u i l t by " a o n s t r u c t o r

the only e s s e n t i a l p r o p e r t y of w h i c h is their uniqueness.

mk-a(xl,x 2 ..... x n) = mk-a'(x I ~,x 2' ..... Xn') ~=~ (a=a' & Xl=X 1 ' & x2=x 2' & ... & Xn=Xn') (The names of c o n s t r u c t o r

functions are always formed by the prefix

"mk-" and the name of the r e l e v a n t a b s t r a c t s y n t a x rule:

for the re-

232

lation to a b s t r a c t s y n t a x see section 4).

One t e c h n i q u e for d e c o m p o s i n g a c o n s t r u c t e d o b j e c t w i l l be to d e f i n e "selector functions"

mk-a(s-l:x ~-1(a)

I,

in the constructor:

8 - 2 : x 2,

...,

= x I & s-2(a)

s - n : x n) = a = x 2 & ...

& s-n(a)

= xn

N o t i c e that, a l t h o u g h the selector functions do not play a part in the d i s t i n c t i o n b e t w e e n objects,

the rules about o b j e c t d e s c r i p t i o n

(see

section 4) p r e v e n t any confusion. A c o n v e n i e n t intuitive v i e w of the r e s u l t of a c o n s t r u c t o r f u n c t i o n is a labelled tree, thus:

a

•\ xI

x2

Xn

A p a r t from u s i n g selector functions,

an object may be d e c o m p o s e d by

w r i t i n g the constructor in a d e f i n i n g p o s i t i o n l e f t - h a n d - s i d e of a " l e t " ) .

(e.g. p a r a m e t e r name,

This achieves a c o m p l e t e d e c o m p o s i t i o n in

one step. Using the let c o n s t r u c t of section 3.6:

let m k - a ( s - l : n l ,

s-2:n2,

...,

s - m ; n m)

=

a

l let n I = s - 1 ( a ) let n2.

~let

n

m

s-2(a)

s-m(a)

3.6 F u n c t i o n s We shall be interested in d e f i n i n g functions over d e f i n e d domains w h i c h d e l i v e r results in d e f i n e d ranges. This, w i l l be written:

f:D~R

so called type,

information

233

If the d o m a i n is, in fact, a c a r t e s i a n p r o d u c t of sets,

this is w r i t t e n

(without ,,x,, symbols):

f:

D I

D 2

...

Dn

~, R

Similar e x t e n s i o n s hold for the range.

(Strictly all functions take one

a r g u m e n t w h i c h is a tuple, but the actual tupling and d e c o m p o s i t i o n will be s y s t e m a t i c a l l y omitted).

The simpler functions to be d e f i n e d will define a r e s u l t for any v a l u e in their domain:

they are total and the u n d e c o r a t e d arrow will be used

to s e p a r a t e the d o m a i n and range. F u n c t i o n s w h i c h may be u n d e f i n e d for some input values are said to be p a r t i a l and will use the symbol ~, for example:

It is assumed that the reader is f a m i l i a r w i t h the s t a n d a r d w a y s of w r i t i n g and n a m i n g functions even w h e r e r e c u r s i o n is involved,

f(x)

=

o..

x

..o

f

thus:

...

A n o t a t i o n will be r e q u i r e d w h i c h enables the c r e a t i o n of

functions

w i t h o u t h a v i n g to p r o v i d e names. A brief i n t r o d u c t i o n to the lambda n o t a t i o n is g i v e n here,

for further i n f o r m a t i o n c o n s u l t Stoy 74.

Instead of d e f i n i n g f by some e x p r e s s i o n in terms of its arguments (e.g.

f(x)

=

e(x)

),

the lambda n o t a t i o n provides a way of d e f i n i n g instances of functions in the f o r m "~" f o l l o w e d by a r g u m e n t list f o l l o w e d by " " f o l l o w e d by d e f i n i n g expression,

thus:

~x.e(x9

Named functions can be a p p l i e d to arguments and a simple symbol subs t i t u t i o n for the p a r a m e t e r s can be u s e d to d e t e r m i n e the value. simple cases,

In

the same r u l e w i l l p r o v i d e an e v a l u a t i o n m e c h a n i s m for

lambda e x p r e s s i o n application,

thus:

234

(~x.5)(7)

=

5

(hx.x)(7)

=

7

(lx.(~y.x+y))(7)

Notice

that this

now d e f i n e

I=

= ~y.7+y

last a p p l i c a t i o n

the i d e n t i t y

yields

a function

as result.

We can

function:

lx.x

The first o p e r a t o r

to be c o n s i d e r e d

for functions

is f u n c t i o n a l

compo-

sition:

f'g

The

= ~x.f(g(x))

notation

"let"

nal d e v i c e

can then be used

let .

or

.

let e

i.e.

x = .

.

... .

.

x =

the

cursive

in

The p u r p o s e of local

of this n o t a t i o -

abbreviations

which

Thus:

¢(x)

.

...

~

(hx.e(x))(...)

(x)

this basic

use,

if a n e w line is used~

the

let

n o t a t i o n w i l l be used

to introduce

re-

definitions:

let f =

...

...

f

the m e a n i n g

of the d e f i n i n g

Several

introduction

in an expression.

"in" can be d r o p p e d

Beyond

with

can now be introduced.

is to p e r m i t

that f is to name the least fixed p o i n t

(see Park 69)

equation.

notational

w a y s of c o m p u t i n g

devices

will permit

a result.

The b a s i c

the s p e c i f i c a t i o n conditional

of different

expression

form should

be familiar:

if p

then

A multiple

e I else

e2

(two or greater)

split can be a c h i e v e d

by the case construct:

235

Gases

V:

V1 ~

e1

V2 ~

e2

"if

v = v I then

els____e_ei f

else

Vn_ 1 ~ en_ I T ~e n

eI

v = v 2 then

e2

if_ v = V n _ I t h e n

else

en_ 1 e

n

A l t e r n a t i v e l y a m u l t i p l e split can be a c h i e v e d by the "McMarthy conditional expression"

Pl ~

VI"P2

form:

-~ V n _ 1 , T -~ v n ~ V2"''''Pn-1 "i-i~ Pl t h e n v 1 else

i_f P2

then

v2

else if

else

if Pn-1

else

v

then

Vn_ 1

In either the case c o n s t r u c t or c o n d i t i o n a l e x p r e s s i o n s the "T" clause can be omitted if the p r e c e d i n g cases cover all possibilities.

If, how-

ever, none of the tests are s a t i s f i e d the result is undefined.

The s u b j e c t functions,

and their definition,

is r e t u r n e d to in section

6.

3.7 I m p l i c i t D e f i n i t i o n

As has b e e n p o i n t e d out earlier,

the m e t a - l a n g u a g e p r e s e n t e d here

should not be c o n s i d e r e d to be closed in any way. One p a r t i c u l a r way in w h i c h it is "open-ended" is in the ability to use objects w h o s e c h a r a c t e r i s a t i o n is implicit.

Such d e f i n i t i o n s are u s u a l l y d i f f i c u l t

(see Beki6 70b) and in languages

where they can be avoided a c o n s t r u c t i v e

form is p r e f e r r e d

dix III and Henhapl 78). For general a p p r o a c h e s p l i c i t d e f i n i t i o n see Guttag

or L i s k o v 75.

(cf. appen-

to. the p r o b l e m of im-

236

4. O B J E C T D E S C R I P T I O N

If a d e f i n i t i o n c o n s i s t e d solely of functions c r e a t i n g objects,

the

only use for d e s c r i b i n g classes of objects w o u l d be as a comment for the reader. This is, in fact, the case for m a n y objects and,

for exam-

ple, one could deduce from a d e f i n i t i o n the class of p o s s i b l e states w h i c h could be generated. T h e r e is, however,

another use for o b j e c t

d e s c r i p t i o n s w h i c h amounts to a necessity. W h e n a d e f i n i t i o n is to be presented, which

one m u s t h a v e a way of d e f i n i n g the e x a c t class of objects

is to be considered.

Such a d e f i n i t i o n will not n o r m a l l y be prac-

tical via its g e n e r a t i o n f u n c t i o n and it is then a r e q u i r e m e n t to h a v e a n o t a t i o n for d e s c r i b i n g classes of objects.

In a simple language it w o u l d be p o s s i b l e to a s s o c i a t e m e a n i n g directly with c o n c r e t e forms of the o b j e c t language texts. Some languages offer a "rich" choice of r e p r e s e n t a t i o n s w h i c h are s e m a n t i c a l l y equivalent. An a b s t r a c t syntax not only offers a way of d e f i n i n g some "normal form" for such expressions,

it also omits the details w h i c h are

p r e s e n t only to ensure u n a m b i g u o u s parsing. J u d i c i o u s choice of objects used

(e.g. sets of declarations)

can also shorten the s e m a n t i c d e s c r i p -

tions.

Objects will be d e s c r i b e d by an a b s t r a c t syntax.

(cf. c o n c r e t e syntaxes

w h i c h d e f i n e a set of strings). The m e m b e r s of the set of rules comprising an a b s t r a c t syntax will each define and name a set of objects. Each a b s t r a c t syntax class will be d e f i n e d as follows:

flAME {=1::}RULE By c o n v e n t i o n the first c h a r a c t e r of a NAME is an upper case character. The choice b e t w e e n the "::" and "=" d e f i n i t i o n symbols and the form of the RULE dictate the set of objects w h i c h is to be a s s o c i a t e d w i t h NAME. The m a j o r i t y of this section is c o n c e r n e d w i t h d e f i n i n g the sets given by the various possibilities.

Before e m b a r k i n g on this we note that a

p r e d i c a t e w h i c h tests for m e m b e r s h i p of a p a r t i c u l a r class of objects is i m p l i c i t l y defined for each NAME.

is-e(t)

Thus

# tee

w h e r e @ is a NAME d e f i n e d w i t h i n an a b s t r a c t syntax.

237

A R U L E consists of one or m o r e T E R M S

s e p a r a t e d by v e r t i c a l bars

(i.e.

"I", read as "or").

TERMS

are b u i l t up by j u x t a p o s e d ITEMS.

Unless a t e r m c o n t a i n s exactly

one item it is c o n s i d e r e d to be bracketed. dified NAMES,

W i t h i n a TERM,

I T E M S are either NAMEs,

mo-

lists of u n d e r s c o r e d symbols, or b r a c k e t e d TERMs.

the m e a n i n g of a N A M E

is the set of objects d e f i n e d by

its rule; that of a m o d i f i e d N A M E is e x p l a i n e d later; that of a list of u n d e r s c o r e d symbols is the unit set c o n t a i n i n g an e l e m e n t a r y o b j e c t d i s t i n c t from that d e n o t e d by any other string of u n d e r s c o r e d characters; a b r a c k e t e d T E R M denotes a c o n s t r u c t e d

(i.e. tree-like)

object.

This last case r e q u i r e s m o r e explanation. S e c t i o n 3.5 has i n t r o d u c e d c o n s t r u c t o r functions and the p o s s i b i l i t y to v i e w

them as trees. A

b r a c k e t e d term d e n o t e s the set of o b j e c t s o b t a i n e d by a p p l y i n g a cons t r u c t o r to elements of the c a r t e s i a n p r o d u c t of the sets d e n o t e d by the I T E M S w i t h i n the brackets. of a "::" symbol,

If the term occurs alone to the r i g h t

the name of the constructor is the NAME,

found on the

left hand side of the "::" symbol, p r e c e d e d by "mk-". Thus:

N :: N 1 N 2 ... N m defines

N = { m k - n ( n l , n 2 .... ,nm) In16N 1 ~ n 2 6 N 2 & ... & n m E N m } The other contexts are as an o p t i o n w i t h i n a TERM. "mk-a"

in w h i c h a b r a c k e t e d T E R M has b e e n allowed above

(separated by "or" form other TERMS)

(i.e. a is a name not used for any rule). N o t i c e that this can

introduce

(sub-)classes of objects w h i c h are not d i s t i n g u i s h a b l e .

The set of objects d e n o t e d by an "=rule" "or"s)

or as an I T E M

In either of these cases the name of the c o n s t r u c t o r is

(which c o n t a i n s zero or more

is the union of the sets d e n o t e d by the T E R M S

rated by the "or"s). Fig.

(which are sepa-

4-1 p r o v i d e s some examples of rules and the

set of objects s a t i s f y i n g them.

238

Rule

set of objects

A=B A::B A=BIC A=(BC) ID A::CID A=BI(CID)

B {mk-a(b)Ib£B} BUC {mk-~(b,c) Ib6B & c6C} U D not d e f i n e d erroneous

fiE. 4-I: examples of rules

"Modified names" and the sets of objects they denote are given in fig.

4-2.

Modified Name

Set d e n o t e d

N-set N• N+

power N {l£TUPLElll}

Is]

BU{NIL} {m6MAPIdomm c B & rngm c C}

B~a B ~ C m

{m£(B~C) Im(dl)=m(d 2) ~ dl=d 2}

B~C B~a

continuous functions

where:

partial functions N, B and C can be TERMS

(bracketed by implication)

fig. 4-2: M e a n i n g of m o d i f i e d names

239

There are o c c a s i o n s w h e r e a class of m a p o b j e c t s terms of other m a p types.

is

to be d e f i n e d in

If the new map is d e f i n e d over the u n i o n of

the d o m a i n s a f r e e d o m is i n t r o d u c e d w h i c h may be unwanted.

This can be

avoided by using:

M = M1

U M2

w h i c h defines M to be a set of maps:

{mEMAPldomm

= domMl

U domM2

&

rngm

= rngM1

U r n~M2

&

(a£domM1

~ m(a)6rngM1)

(aEdQmM2

~ m(a)Ern~M2)}

&

A used c o n s t r u c t o r can be c o m p a r e d with a b s t r a c t syntax rules w h e n the s y n t a x d e s c r i b e d is of i n t e r n a l

(semantic)

objects.

Because c o n s t r u c -

tors can also be u s e d to d e c o m p o s e texts of the o b j e c t language, a c o m p a r i s o n is also p o s s i b l e b e t w e e n the a b s t r a c t syntax of the texts being d e f i n e d and their use in the s e m a n t i c rules.

In all cases w h e r e such a c o m p a r i -

son is p o s s i b l e the used constructors,

their selectors and their argu-

m e n t s m u s t c o n f o r m to the rules d e s c r i b i n g the class of objects.

5. THE ROLE OF "UNDEFINED"

The t r e a t m e n t of logic in s e c t i o n 2 is s o m e w h a t o v e r - s i m p l i f i e d in that (in c o m m o n w i t h m o s t text books)

the p o s s i b i l i t y that e x p r e s s i o n s m i g h t

be u n d e f i n e d has b e e n ignored. A l t h o u g h the f r e q u e n c y has been reduced by the use of b o u n d e d quantifiers, dEdomm

expressions

like:

& m(d)Ee

x = 0 v y/x>10

w i l l be found. For such e x p r e s s i o n s the "conditional expression" (cf. Walk 69) are assumed.

a & b ~ if

a then

b else

forms

For example:

FALSE

This m i n i m i z e s the danger of e x p r e s s i o n s b e i n g m a d e u n d e f i n e d by their operands.

(Notice that Jones ?2 and D i j k s t r a 76 adopt s e p a r a t e symbols

240

for the conditional forms.)

6. D E F I N I N G

SEMANTICS

As explained in the introduction,

the general approach to defining the

semantics of a language is to define a function which maps its formed)

elements to some class of understood denotations.

(well-

For the lan-

guages which are most commonly considered interesting these denotations will have to be functions. Because most computer languages embody some form of assignment operation the functions will normally be state transformations

(functions from states to states).

In languages which have

a procedure concept in its full generality the state transformations will, in fact, have to be very general functions which can be applied to functions

(even themselves)

and yield functions as results.

general functions were permitted without restriction,

If such

it would be pos-

sible to generate the sort of paradoxes which Russell observed in set theory. However,

it has been shown

(cf. Scott 71) that the restriction

to monotone and continuous constructions ensures that a model can be constructed and thus guarantees that inconsistencies are avoided. As this result is both of considerable importance and difficulty, be inappropriate to repeat that work here

it would

(for an excellent tutorial

see Stoy 74). This paper will nOt, then, provide a complete treatment of the foundations of the meta-language. here is to accept

(gratefully)

Rather, the approach taken

that models of the lambda calculus exist

and to define meta-language expressions by specifying the closed larmbda expressions into which an object program is mapped.

In fact, a few

extra combinators are adopted from Stoy 74: these are discussed in section 6.4. The meaning function,

then, is a way of mapping the object language to

lambda expressions which, language

in turn, denote functions.

(i.e. one with a recursive syntax)

ly not be given extensionally.

For an infinite

this function can obvious-

It is, indeed, very important to con-

struct the meaning function in a way which associates

(functional) de-

notations with parts of the constructs of the object language. Furthermore, the meaning of compound constructs of the object language should depend only on the meaning of the components of such compounds.

This

approach provides a natural way of categorising the meta-language constructs used in defining the meaning functions.

Those parts of the

241

m e t a - ! a n g u a g e d i s c u s s e d in section 6.2 can be v i e w e d as a m a c r o - e x p a n sion scheme for

(abstract)

p r o g r a m s of the o b j e c t language. W h a t is

c r e a t e d from this e x p a n s i o n is an e x p r e s s i o n in an e n r i c h e d lambda notation.

("sugared")

S e c t i o n 6.3 e x p l a i n s m o s t of the extra n o t a t i o n w h i c h

is u s e d to aid r e a d a b i l i t y in terms of pure lambda n o t a t i o n plus two c o m b i n a t o r s w h i c h are d i s c u s s e d in s e c t i o n 6.4. The basic ideas of states and state t r a n s i t i o n f u n c t i o n s are r e v i e w e d in the first subs e c t i o n below.

The w h o l e t r e a t m e n t of a r b i t r a r y order has been excised from this volume. This p r o b l e m had b e e n tackled in the framework of a b s t r a c t interpreters

(see Walk 69) and was r e c o g n i s e d in Beki~ 74. The general prob-

lem of how to d e f i n e the m e r g i n g of c o - o p e r a t i n g p r o c e s s e s using a den o t a t i o n a l sematics a p p r o a c h is, however, some extent safe basis

"open".

very c o m p l e x and still to

In v i e w of the aim of this volume to p r e s e n t a

for d e f i n i t i o n w o r k it was decided that the problems

ed in m e r g i n g should be dropped. unordered constructs

involv-

T h e r e is some d i s c u s s i o n of a p p a r e n t l y

in section 6.5.

6.1 States and State T r a n s i t i o n s

Most l a n g u a g e d e f i n i t i o n s use a basic semantic o b j e c t w h i c h is a state. Such a state is a m a p p i n g from some class of names or their surrogates (e.g. locations) provides

to w h a t e v e r values can be manipulated.

Such a state

the v e h i c l e for d e f i n i n g the d e n o t a t i o n s of names. C o n s t r u c t s

w h i c h have an a s s i g n m e n t nature

(nearly all i n t e r e s t i n g languages con-

tain some) w i l l n a t u r a l l y be g r a n t e d d e n o t a t i o n s w h i c h are functions from states to states. Such functions are u s u a l l y called state transitions. Thus for some class of c o n s t r u c t s e:

m-@:

@ -~ T r

Tr=2~2

The n o t a t i o n specific to states and t r a n s i t i o n s can now be introduced.

It w i l l n o r m a l l y be n e c e s s a r y to have some s t r u c t u r e w i t h i n states one c o m p o n e n t for storage,

(e.g.

one for files). This is r e f l e c t e d by intro-

d u c i n g a class of e l e m e n t a r y objects called references. References can be e x p l i c i t l y e n u m e r a t e d by w r i t i n g t h e m as strings of u n d e r l i n e d upper-

242

case characters. The only operators d e f i n e d over r e f e r e n c e s are the tests for

(in)equality. A state will be a m a p p i n g from such references

to any sort of objects,

=

REF

~ m

thus:

OBJECT

The basic way of d e f i n i n g a new state is by s p e c i f y i n g a d i f f e r e n c e from an e x i s t i n g state. A state t r a n s i t i o n is s p e c i f i e d by w r i t i n g a m e t a - l a n g u a g e a s s i g n m e n t s t a t e m e n t w h i c h uses the r e f e r e n c e to have a d i f f e r e n t value)

(which is

on the left and a value on the right. Thus

the m e t a - l a n g u a g e a s s i g n m e n t defines a transition: N

(r

:=

V):

Z ~

and is d e f i n e d as:

r

:=

v

A

=

~cr.c~+[r~v]

Unlike m o s t p r o g r a m m i n g languages, (rather than its value) of an assignment. must be used

a r e f e r e n c e always denotes itself

even if it is w r i t t e n on the r i g h t - h a n d - s i d e

If the v a l u e is r e q u i r e d the contents O p e r a t o r

"~"

(see s e c t i o n 6.3 for further details).

If a semantic f u n c t i o n maps elements of some class @ into transformations, the type w i l l be s p e c i f i e d as:

m-O:

O~

w i t h the meaning:

m-O:

0 ~

( ~ ~ ~)

Further, w i t h value r e t u r n i n g t r a n s f o r m a t i o n s

m-O:O~R

stands for :

m-O:

@ ~

( ~ ~ Z R)

(see below):

243

H a v i n g i n t r o d u c e d the ideas of states and state transitions,

it w o u l d

be p o s s i b l e to build up ways of d e s c r i b i n g i n c r e a s i n g l y more c o m p l e x transitions. This is not the a p p r o a c h taken here. Rather,

transitions

have b e e n i n t r o d u c e d only to p r o v i d e m o t i v a t i o n for the s u c c e e d i n g three sub-sections.

The t r e a t m e n t is now t o p - d o w n in that the means of

c r e a t i n g e x t e n d e d e x p r e s s i o n s p r e c e d e s the d e s c r i p t i o n of the e x t e n d e d expressions

in terms of basic combinators,

so that only in section 6.4

is the t r e a t m e n t back to the level of lambda expressions.

6.2 A M a c r o - e x p a n s i o n Process

The a s s i g n m e n t c o n c e p t in the m e t a - l a n g u a g e together w i t h the combinators to be i n t r o d u c e d in s u b s e q u e n t sub-sections provide ways of writing c o m p l e x tranformations.

G i v e n some o b j e c t l a n g u a g e it is not dif-

ficult to w r i t e for any p a r t i c u l a r p r o g r a m a c o r r e s p o n d i n g m e t a - l a n g u a g e e x p r e s s i o n w h i c h denotes the f u n c t i o n w h i c h captures the m e a n i n g of that p a r t i c u l a r program. guages,

Since the task in hand is d e f i n i n g whole lan-

a way m u s t be p r o v i d e d for g e n e r a t i n g the c o r r e s p o n d i n g meta-

language e x p r e s s i o n s for any

(well-formed)

program. The g e n e r a t i o n it-

self, w h i c h is the s u b j e c t of this sub-section, as a m a c r o - e x p a n s i o n process.

can best be u n d e r s t o o d

By this is m e a n t that the parts of the

m e t a - l a n g u a g e d e s c r i b e d in this section rely on the text and e n v i r o n m e n t alone. This e x p a n s i o n is rather obvious and w i l l be e x p l a i n e d w i t h a m i n i m u m of formalism.

In a d e f i n i t i o n there w i l l be

(notionally)

for each d e f i n e d class of

the a b s t r a c t syntax one semantic rule. This semantic rule maps objects of the class to their d e n o t a t i o n s .

The m o s t basic part of the m a c r o -

e x p a n s i o n process is the a p p l i c a t i o n of the r e l e v a n t rules to the text components. reasons.

The q u a l i f i c a t i o n

Partly,

"notionally" has been added above for two

it w o u l d be u n f o r t u n a t e to apply any rule w h i c h dic-

tated a structure on the semantic functions. Thus v e r y short s e m a n t i c functions may be better conbined w i t h that c o r r e s p o n d i n g to the syntax class w h i c h uses them. More importantly,

syntax rules w h i c h simply list

options w o u l d have c o r r e s p o n d i n g s e m a n t i c rules w h i c h w e r e simply case distinctions

s e l e c t i n g other s e m a n t i c rules. These

"splitting"

(or

,|

routing " structors rules.

rules) (i.e.

are o m i t t e d and only syntax rules w h i c h define con-

"::rules") w i l l n o r m a l l y have c o r r e s p o n d i n g semantic

244

The syntax for an infinite language will be recursive.

In c o n s e q u e n c e

the c o r r e s p o n d i n g semantic rules m u s t also be a family of m u t u a l l y resursive functions. However,

it was pointed out in the d i s c u s s i o n of

objects that v a l i d tree objects w i l l always be finite. This g u a r a n t e e s that the m a c r o - e x p a n s i o n process e n v i s a g e d will terminate.

A trivial language can be used to illustrate this b a s i c expansion. l a n g u a g e to be c o n s i d e r e d is that of b i n a r y numerals.

The

It is, of course,

so simple that the c o r r e s p o n d i n g d e n o t a t i o n s are not t r a n s f o r m a t i o n s but the natural numbers. The syntax of the language is:

Bin-digit

= ~I~

Bin-numeral

=

[Bin-numeral]

Bin-digit

Given the c h o i c e of d e n o t a t i o n s semantic functions are r e q u i r e d of types:

m-d:

Bin-digit

~ Nat 0

m-n:

Bin-numeral

~ Nat 0

Appropriate

m-d(d)

functions m i g h t be:

= i f d=O

then

0 else

m-n(mk-bin-numeral(n,d))

I

= if n=NIL else

then m - d ( d )

2.m-n(n)+m-d(d)

For any e l e m e n t of the o b j e c t language tion will create a finite expression.

(Bin-numeral)

the m e a n i n g func-

In this simple language the ex-

p r e s s i o n will contain only a r i t h m e t i c objects and it can be s i m p l i f i e d by the laws of a r i t h m e t i c to a natural number

(the r e q u i r e d denotation).

A number of points have, however, b e e n illustrated.

It was o b s e r v e d in

section 3.5 that objects can be d e c o m p o s e d by w r i t i n g the c o n s t r u c t o r "on the left of a let":

the use of the c o n s t r u c t o r in the p a r a m e t e r

p o s i t i o n of m - n is a further a p p l i c a t i o n of this idea and is e q u i v a l e n t to: m-n(nm)

=

(let m k - b i n - n u m e r a l ( n , d )

= nm

..o) F u r t h e r m o r e the c o n d i t i o n a l s t a t e m e n t used in the d e f i n i t i o n of m - n is entirely d e p e n d e n t on the text b e i n g a n a l y z e d and is a p a r t o f t h e macroe x p a n s i o n process.

245

Of the three forms of c o n d i t i o n a l

expression

case is always d e p e n d a n t o n the text alone, are always d e p e n d a n t in either way.

The

in s u b - s e c t i o n

6.3.

should be obvious:

on d y n a m i c

tests w h i c h The m e a n i n g either

somewhat

of o m i t t i n g tions°

A

The need

rules

B u t an a r t i f i c i a l

conditionals

else can be used

values

of the t e x t - d e p e n d a n t

by the adoption,

semantic

and /f then

on d y n a m i c

one or the other

ing on the r e s u l t of the test. reduced

values

depend

in the m e t a - l a n g u a g e , "McCarthy"

expansion

are d i s c u s s e d

/_~ then

else

is c h o s e n depend-

for the case c o n s t r u c t

in large d e f i n i t i o n s ,

has b e e n

of the p r a c t i c e

for s y n t a x classes w h i c h are lists of op-

example

can be c o n s t r u c t e d

for the syntax:

= BtcI

B :: X C::XY D :: X Y Z The definition:

fn-a(a)

has

= cases a: mk-b(x)

~ f(x)

mk-c(x,y)

~ g(x,y)

mk-d(x,y,z)

~ h(x,y,z)

the meaning:

fn-a(a)

=

i_~ (3x)(mk-b(x)=a)

then

(let mk-b(x)=a

else i ~ (3x, y)(mk-c(x,y)=a) else i~

(Bx, y,z)(mk-dCx, y,z)=a)

A case c l a u s e w i t h

a final

none of the p r e c e d i n g sent it is an error

A similar

static

If a textual mantic

rule

then

then

"T~" c l a u s e will

predicates

were

in f(x))

(let mk-c(x,y)=a

true.

(let mk-d(x,y,z)=a ~_~nh(x,y,z)) use

object which is likely

this

last o p t i o n

If no such clause

for none of the p r e d i c a t e s

expansion

in g(x,y))

if

is pre-

to be satisfied.

from the text is g i v e n by the for construct. is a list is to be g i v e n

a meaning,

to be formed from a for construct,

i=l t__oou d_~o f(list(i))

thus:

the se-

246

this can be s t a t i c a l l y e x p a n d e d into:

f(list(1));f(list(l+l));...;f(list(u))

w h e r e the ";" c o m b i n a t o r b e t w e e n t r a n s f o r m a t i o n s

is that e x p l a i n e d in

section 6.3. S i m i l a r l y a v a l u e r e t u r n i n g t r a n s f o r m a t i o n can be used to define a list to be c r e a t e d from the list in the text by:

let vl:



w i t h the m e a n i n g

(again expressed

in terms of c o m b i n a t o r s to be defined

in the next sub-section):

let vll

: vt(list(1));

let vlsl

: vt(list(l+IJ);

. . °

let vlu

: vt(list(u));

let vl

=

D e f i n i t i o n s of p r o g r a m m i n g languages have u n i v e r s a l l y adopted the conc e p t of an e n v i r o n m e n t to h a n d l e the problems r e l a t e d to b l o c k structure. C o n s t r u c t i o n of e x p l i c i t e n v i r o n m e n t s use of the m e t a - l a n g u a g e ;

is a c h i e v e d by s t a n d a r d

the rSle of the e x p l i c i t e n v i r o n m e n t in the

m a c r o - e x p a n s i o n process is d i s c u s s e d at the end of this sub-section. There is, however,

a n o t h e r topic to be d i s c u s s e d first and that is the

exit m e c h a n i s m of the m e t a - l a n g u a g e .

The e x i t - m e c h a n i s m is d i s c u s s e d in d e t a i l e l s e w h e r e in this v o l u m e (Jones 78b) and a s t e p - b y - s t e p m o t i v a t i o n of the a p p r o a c h has b e e n presented in Jones 75. Here, only a brief r e v i e w of the idea is given. For a simple language mal termination)

(i.e. one w i t h o u t constructs w h i c h cause abnor-

the t r a n s f o r m a t i o n s

to be used as d e n o t a t i o n s will be:

T = ~ Z The exit a p p r o a c h to languages w h i c h permit abnormal t e r m i n a t i o n

is to

use d e n o t a t i o n s w h i c h are t r a n s f o r m a t i o n s of the type:

E = Z "~ Z [Abn] Here,

just as Z is c h o s e n to fit the p a r t i c u l a r language,

the class

247

Abn

is a set of objects w h i c h can be used for the language in q u e s t i o n

to indicate w h a t sort of a b n o r m a l t e r m i n a t i o n has occured. Of importance for the m e t a - l a n g u a g e is o n l y the d i s t i n c t i o n b e t w e e n NIL omitted)

(Abn

and an actual Abn value. A p a r t i c u l a r element of E w h i c h

takes an e l e m e n t of Z into a pair w h i c h contains a e l e m e n t of Z and NIL

is a "normal" transition.

normal s i t u a t i o n is to be resolved.

(possibly different)

In other words no ab-

On the other hand,

if the second

element of the o u t p u t pair is not NIL , it provides not only the knowledge that an a b n o r m a l s i t u a t i o n is to be resolved, f o r m a t i o n w h i c h aids resolution. ments,

for example,

but also some in-

In a simple language w i t h goto state-

the set Abn m i g h t be identical w i t h label identi-

fiers. A n u n r e s o l v e d goto is then d e n o t e d by an e l e m e n t of E w h i c h yields the label as the second c o m p o n e n t of the result.

tion"

It is "resolu-

which is of concern in this section b e c a u s e it employs a sort

of i m p l i c i t environment. The exit and normal successor b i n a t o r s are d e f i n e d in the next sub-section;

(i.e. ";") com-

the t e c h n i q u e for resolv-

ing exits plays a part in the m a c r o - e x p a n s i o n scheme. Firstly,

however,

the d e f i n i t i o n s are provided.

The basic c o n s t r u c t to be u s e d is written:

tixe

[a~tl(a) Ip(a)]

i_nn t 2

I n t u i t i v e l y this r e q u i r e s that the basic t r a n f o r m a t i o n used is t2;

(in E) to be

if for a p a r t i c u l a r ~£Z this results in a NIL Abn compo-

nent then that element of t 2 is also an element of the overall transformation;

if, however,

an a b n o r m a l c o m p o n e n t is r e t u r n e d w h i c h satis-

fies the p r e d i c a t e p then t r a n s f o r m a t i o n t I is u s e d to a t t e m p t to resolve the a b n o r m a l i t y ;

if an a b n o r m a l r e s u l t is d e l i v e r e d by t2, but

this v a l u e does not satisfy p, then the same a b n o r m a l r e s u l t is d e l i v e r ed by the overall construct. To d e f i n e this f o r m a l l y the types are given first,

suppose:

t I : Abn ~ E t2 : E p : [Abn] E

~ Bool

= ~ ~ ~ [Abn]

then the type of the c o n s t r u c t is:

(tixe

[a~tl(a) Ip(a)]

i_~n t2): E

248

and the d e f i n i t i o n is:

(tixe [a~t1(a) jp(a)] in t 2) (let e = [a~tl(a) Jp(a)] let r(s,a) = (a6dome~r'e(a)(~),T~<~,a>) r t 2) N o t i c e that r in the above e x p a n s i o n is u s e d recursively.

Thus if a-

nother a b n o r m a l s i t u a t i o n results w h i c h still satisfies p, the e f f e c t d e f i n e d in e w i l l again be used. This r e c u r s i v e form fits the p r o b l e m of goto h a n d l i n g

(see the d e f i n i t i o n in a p p e n d i x III) v e r y well.

earlier d e f i n i t i o n s a n o n - r e c u r s i v e

In

"trap" was u s e d w i t h w h i c h it was

then n e c e s s a r y to c o n s t r u c t the r e q u i r e d r e c u r s i o n in the semantic functions.

For:

t I : Abn ~ E t2 : E the type of the trap c o n s t r u c t is:

(trap(a) with tl(a);t2):

E

and the d e f i n i t i o n is:

trap(a) ~,ith tl(a);t ~ (let h(~,a) = (a~NIL~tI(a)(a),T~<~,NIL>) h't 2) R e t u r n i n g to the "tixe" construct, in the m a c r o - e x p a n s i o n .

Firstly,

it is n e c e s s a r y to explain its role

it could be argued that,

w h i c h is u s e d v e r y few times in a d e f i n i t i o n volume),

for a concept

(cf. Henhapl 78 in this

it is not w o r t h p r o v i d i n g a special m e t a - l a n g u a g e construct.

The j u s t i f i c a t i o n for so d o i n g is p r e c i s e l y to provide a f r a m e w o r k for the r e s o l u t i o n of exits w h i c h does fit w i t h a m a c r o - e x p a n s i o n v i e w of the text. The key p o i n t is the use of a m a p p i n g in the The finiteness c r i t e r i a of m a p p i n g s is met because,

tixe construct. for finite texts,

the p r e d i c a t e p m u s t y i e l d a finite number of a b n o r m a l c o n d i t i o n s to be resolved.

In order for the overall tixe c o n s t r u c t to y i e l d a deno-

tation for a text, b o t h the t I and t 2 s e m a n t i c functions should only be used on sub-parts of the overall text being defined. R e f e r r i n g to the semantic function "i-named-stmt-l~st" dix III,

in the d e f i n i t i o n in appen-

it w i l l be seen that the role of the tixe c o n s t r u c t is essen-

249

tially to g e n e r a t e a static e n v i r o n m e n t the elements of w h i c h are mutually d e p e n d a n t on one another.

(The d i s c u s s i o n of this sort of re-

c u r s i o n is g i v e n under the general topic of environments).

The r e m a i n i n g topic to be e x p l a i n e d w i t h regard to the m a c r o - e x p a n s i o n is the r61e of the e n v i r o n m e n t o b j e c t

(Env). In a language w i t h o u t

block s t r u c t u r e it w o u l d be p o s s i b l e to w r i t e semantic functions for each class

m-O:

@ ~

(0) of a b s t r a c t syntax objects.

(2 ~ ~)

In a language w h i c h permits r e d e f i n i t i o n of identifiers at d i f f e r e n t levels of the block structure,

an e n v i r o n m e n t is introduced,

so that

m o s t semantic functions are of type:

m-O: 0 Env -~ (2 ~ 2)

The h i g h e s t

(program)

c o n s t r u c t of the language has a c o r r e s p o n d i n g

semantic rule w h i c h creates an empty e n v i r o n m e n t and this semantic rule is thus still of type:

m-program:

P r o g r a m ~ (2 ~ 2)

If the language to be d e f i n e d p e r m i t s

recursion

(e.g. r e c u r s i v e pro-

cedures in A l g o l 60) the equations for c r e a t i n g e n v i r o n m e n t s will t h e m s e l v e s be recursive.

This r e c u r s i o n must, of course, be u n d e r s t o o d

for the w h o l e d e f i n i t i o n to be sound.

If the d e f i n i t i o n w e r e in fact to be treated as though it w e r e an a b stract interpreter,

it w o u l d be fairly easy to clarify the r e c u r s i v e

equations on e n v i r o n m e n t s by a d o p t i n g an a p p r o p r i a t e mode for param e t e r passing. One w a y of e n s u r i n g that a d e n o t a t i o n a l v i e w was sound w o u l d be to set up an o r d e r i n g over environments.

Such an o r d e r i n g

could be d e f i n e d p o i n t w i s e over the t r a n s f o r m a t i o n s to be held as values in the environments.

Here an a l t e r n a t i v e v i e w is taken. E s s e n t i a l l y

the e n v i r o n m e n t is v i e w e d as a w a y of a v o i d i n g a name c r e a t i o n process for the d e n o t a t i o n s

to be stored therein.

The m o t i v a t i o n for introduc-

ing this "linguistic level '~ can b e s t be given by, initially, r e s t r i c t ing the d i s c u s s i o n to a language w h i c h only has local variables no procedures). For any p a r t i c u l a r p r o g r a m in the language, to w r i t e an a s s o c i a t e d e x t e n d e d lambda expression.

Thus:

(i.e.

it is easy

250

begin integer a,b; .o. end m i g h t h a v e a d e n o t a t i o n like:

(let la:get-loc(a) ; let lb:get-loc(b) ; ...) AS has been stated repeatedly,

the p r o b l e m that m u s t be solved is to

provide a way of g e n e r a t i n g d e n o t a t i o n s for any program. ty of u s i n g an elipses n o t a t i o n was excluded,

The possibili-

but the e n v i r o n m e n t can

be seen p r e c i s e l y as a way of taking away the need for such a n o t a t i o n for the c r e a t i o n of names for the location. Thus for a program:

be~in integer s,d; ... c:=d+e;

... end

the e n v i r o n m e n t m i g h t be such that the d e n o t a t i o n of the b o d y is created by:

i-body((...c:=d+c;..°), The d e f i n i t i o n of i-body

[c~Ic, d~ld]) will be such that this expands to:

° . .

let vd : aontents(Id); let vc : contents(lc); assign (l c,(vd+vc));

In o t h e r words,

the e n v i r o n m e n t itself d i s a p p e a r s e n t i r e l y d u r i n g the

m a c r o - e x p a n s i o n process.

The functions defining

the m e a n i n g of blocks

will create new locations for locally d e c l a r e d identifiers. For block s t r u c t u r e d languages the outer e n v i r o n m e n t is u p d a t e d w i t h a p a i r i n g of the local names w i t h the new locations. This m o d i f i e d e n v i r o n m e n t has two uses:

for local uses of identifiers the location is o b t a i n e d

from the environment;

for nested blocks it is the basis for g e n e r a t i n g

further environments.

In order to exhibit the d e n o t e d expression,

is n e c e s s a r y to create

(arbitrary)

it

names for the locations.

It is now n e c e s s a r y to show how such an e x p l a n a t i o n can be e x t e n d e d to cover the m o r e interesting case of languages w h i c h p e r m i t r e c u r s i v e procedures. For a program:

251

begin

pl:prog

...

p2

...;

p2:~roc

...

pl

...

p2

...;

pl

end

the d e f i n i t i o n will g e n e r a t e a d e n o t a t i o n for the block via:

let

nenv

=

env+[pl~e-proc-den((...pl...),nenv), p2~e-proc-den((,..pl...p2...),nenv)]

i-body((...pl...),nenv)

I n t r o d u c i n g names for the p r o c e d u r e denotations,

let

pdenl

=

...

pden2

...

let

pden2

=

...

pdenl

...

...

pdenl

...

pden2

this expands to:

...

This time the d i s a p p e a r a n c e of n e n v

is d o u b l y welcome: w i t h it has gone

the r e c u r s i o n w h o s e least fixed p o i n t could only be d i s c u s s e d in terms of an ordering. A d i f f e r e n t r e c u r s i o n notations)

(that in terms of p r o c e d u r e de-

has become v i s i b l e but for one thing it was there anyway

and for a n o t h e r it is p r e c i s e l y the r e c u r s i o n over t r a n s f o r m a t i o n s w h i c h has to be e x p l a i n e d below.

This section,

then, has shown how a d e f i n i t i o n can be viewed as a se-

ries of macros w h i c h expand objects of the language to be d e f i n e d into expressions

in an e x t e n d e d lambda notation. At the expense of introduc-

ing the c o n c e p t of names for locations and p r o c e d u r e denotations,

the

e x p l a n a t i o n of these e x t e n d e d e x p r e s s i o n s b e l o w will not be b u r d e n e d w i t h the c o n c e p t of environments.

6,3 S i m p l i f y i n g E x t e n d e d E x p r e s s i o n s

The p r e v i o u s s u b - s e c t i o n has shown how a d e f i n i t i o n of the type given in a p p e n d i x III can be used to create

(by macro-expansion)

an expres-

sion w h i c h is the d e n o t a t i o n of the g i v e n o b j e c t language text. This e x p r e s s i o n itself denotes a transformation.

However,

the e x p r e s s i o n

is not yet in pure lambda n o t a t i o n and the purpose of this s u b - s e c t i o n

252

will be to explain those c o m b i n a t o r s w h i c h can be regarded simply as "synSactic sugar" for m a k i n g the g e n e r a t e d r e s u l t more readable.

It will be easier to c o m p r e h e n d the full combinator d e f i n i t i o n s idea is first e x p l a i n e d w i t h a simplified problem.

if the

Suppose the d e n o t a -

tion of some c o m p o u n d object:

a£A

where

A=BC is sought.

m-b

Given two functions:

: B ~ (~ ~ ~)

there are m a n y p o s s i b l e ways of c o m b i n i n g them to create a t r a n s f o r m a tion. Given the o b j e c t i v e that the d e n o t a t i o n s of c o m p o u n d objects should depend only on the d e n o t a t i o n s of their components, most pleasing combinations

one of the

is a c o m p o s i t i o n of the two created func-

tions. Thus:

m-a(mk-a(b,c)) = m-c(c)'m-b(b) = hs.(m-c(c)(m-b(b)(~))) One o b j e c t i v e of i n t r o d u c i n g c o m b i n a t o r s

(like composition)

void having to w r i t e out many "l"'s and "~"'s.

free"

is to a-

In a d d i t i o n to a "a-

style, a m u c h m o r e natural d e f i n i t i o n can be a c h i e v e d by the

use of well c h o s e n combinators.

In this case we can d e f i n e a "semico-

lon" combinator:

for :

tI

: ~

t2

"E~2

the type is:

(tl;t2)

: ~ ~

and the definition:

tl;t 2

~ t2"t I

and then rewrite the above example:

m-aCmk-a(b,c))

= m-bCb); m-c(c)

253

In a simple l a n g u a g e definition, ments

the m e a n i n g of a sequence of state-

is likely to be the c o m p o s i t i o n of the m e a n i n g s of the single

statements.

Since,

in the c o n c r e t e s y n t a x of such an o b j e c t language,

the e l e m e n t s of the s e q u e n c e are likely to be s e p a r a t e d by ";", a p l e a s i n g symmetry has b e e n created.

Notice, however,

that the m e t a -

l a n g u a g e s e m i c o l o n o p e r a t o r has b e e n f o r m a l l y d e f i n e d and there is no element of c i r c u l a r i t y in such a link b e t w e e n object and m e t a - l ~ n g u a g e . It w o u l d be useful to d e f i n e a few other c o m b i n a t o r s on these simple t r a n s f o r m a t i o n s .

(e.g. ~ ,

while)

This is not done here since the lan-

guages w h i c h are of g e n e r a l i n t e r e s t r e q u i r e s l i g h t l y m o r e c o m p l e x denotations.

S i n c e the c o m b i n a t o r s given b e l o w can be s p e c i a l i z e d v e r y

e a s i l y to those for the simple transformations,

a t t e n t i o n is now turned

to the more general versions.

The object language features w h i c h d e m a n d richer d e n o t a t i o n s are those w h i c h m a n i f e s t an "abnormal exit" behaviour. is "goto",

The a r c h e t y p a l s t a t e m e n t

but also m u c h error h a n d l i n g can b e s t be dealt w i t h in the

same way. One a p p r o a c h to this p r o b l e m is to use t r a n s f o r m a t i o n s w h i c h c r e a t e states and o p t i o n a l a b n o r m a l indications.

The type of a t r a n s f o r m a t i o n now becomes:

E =

~ ~

where Abn

Z [Abn]

is chosen for a p a r t i c u l a r definition.

of such a (partial)

The intuitive m e a n i n g

f u n c t i o n is that it maps state values

w h o s e first element is always a

(possibly different)

the case that the c o m p u t a t i o n was be the e l e m e n t a r y o b j e c t NIL;

into pairs

state value;

in

"normal", the second c o m p o n e n t w i l l

if t e r m i n a t i o n was abnormal,

the second

c o m p o n e n t w i l l be o t h e r than NI___~Land its actual v a l u e w i l l p r o v i d e inf o r m a t i o n about the e n c o u n t e r e d exception.

The n o t a t i o n i n t r o d u c e d for type clauses m u s t now be extended. than write:

m-9:

(9 Env -~ (~ ~ ~ [Abn])

such f u n c t i o n types w i l l be written:

m~8:

8 Env ==~

Rather

2~

and for value r e t u r n i n g transformations:

m-8:

@ Env ~ (Z ~ Z {Abn]

Val)

is written:

m-8:

0 Env =~ Val

It is now n e c e s s a r y to d e f i n e the combinators w h i c h are used to combine t r a n s f o r m a t i o n s of type E. F i r s t l y if a simple t r a n s f o r m a t i o n N

t:Z~Z is w r i t t e n in a context w h e r e a t r a n s f o r m a t i o n of type E is required, it is interpreted as:

t ~ I~. that is, viewing

t:E it is e n s u r e d that it always has a normal termination. ticular

Notice,

in p a r

"I" the identity over E gives:

I ~ I~.<~,NIL> The full s e m i c o l o n c o m b i n a t o r can now be introduced.

I n t u i t i v e l y its

purpose is to avoid a p p l y i n g the second t r a n s f o r m a t i o n if the first results in abnormal termination.

Formally,

types:

tI : E t2 : E then the type of the result is:

(tl;t 2) : E and its definition:

(tl;t 2) ~ (l~,a.a=NIL~t2(~),T~<~,a>)'t

I

given t r a n s f o r m a t i o n s w i t h

255

In order exit

to signal,

is to occur,

(exit(v))

and

combinator

v

(in Abn),

is used,

that an a b n o r m a l

its type

is:

its d e f i n i t i o n :

error

defined tation

~ lo.<s,v>

construct

result

this,

the exit case;

error

tixe

Thus

the v a l u e

applying

result

is used

to i n d i c a t e

of e r r o r

anywhere

for the w h o l e

text.

c a n b e used w i t h the rule that no tixe

that no

in the d e n o To a c h i e v e

covers

the

thus:

A = exit

(ERROR)

combinator,

and the s e m i c o l o n

cation

of the m e t a - l a n g u a g e

is given.

is to show an a b n o r m a l

ERROR

The

some g i v e n v a l u e

: E

(exi~(v))

The

with

the exit

combinator

subsequent

of a s e c o n d

is " a l w a y s " .

w h i c h was

explained

as part of the m a c r o - s c h e m e ,

have p r o v i d e d

transformations. transformation

two ways

A combinator

in both n o r m a l

of c o n d i t i o n a l l y

which

causes

and a b n o r m a l

applicases

Given:

N

e : E

then the type

(always

is:

t in e)

: E

and the d e f i n i t i o n :

(always

t in e) (ls,a.)'e

If t is, component

in fact,

of type E then

functions.

a way analogous semicolon

if a n o n - N I L

second

is ever returned.

(There are o c c a s i o n s w i t h pure

it is an error

where

an exit

to the s e m i c o l o n

is d e f i n e d

or e r r o r

It is s t r a i g h t f o r w a r d

in terms of

construct to r e d e f i n e

combinator.

is r e q u i r e d composition

H a v i n g done

(the revised)

also in

so, of course,

composition).

256

This concludes the combinators w h i c h are e s p e c i a l l y d e s i g n e d for building up e x p r e s s i o n s from

(expressions denoting)

t r a n s f o r m a t i o n s of type

E. A t t e n t i o n is now turned to value r e t u r n i n g t r a n s f o r m a t i o n s of type:

R = Z : Z [Abn]

V

The m o s t basic way of g e n e r a t i n g such a t r a n s f o r m a t i o n is by the r e t u r n combinator. Thus:

for vEV,

(return(v)) : R

is defined:

(return(V)) ~ I ~ . < S , N I L , v >

A t r a n s f o r m a t i o n of type R may be placed after one of type E

(separat-

ed by ";") and make the w h o l e of type R. Thus given:

t:E r : R

then:

(t;r)

: R

is defined:

(t;r) ~ ( l s , a . ( a = N I L ~ r ( ~ ) , T ~ < q , a , ~ > ) )

"t

N o t i c e that as a c o n s e q u e n c e of this d e f i n i t i o n abnormal exit results in r e t u r n i n g an u n d e f i n e d

(here ~) result.

The value g e n e r a t e d by a v a l u e r e t u r n i n g t r a n s f o r m a t i o n can be used in a f o l l o w i n g t r a n s f o r m a t i o n in a way w h i c h is analogous to the simple let shown below. Given:

r:R t : V~E

then: (let v : r ; t ( v ) )

: E

257

is defined:

(let

v:r;t(v)) (le, a , v . ( a = N I L ~ t ( v ) ( s ) , T ~ < e , a > ) ) ' r

To r e d u c e tents

the n u m b e r

operator

of s e p a r a t e

(S) is c o n s i d e r e d

cases

to be d i s t i n g u i s h e d ,

to be a v a l u e r e t u r n i n g

the con-

transformation.

Thus:

c : REF

~ R

and :

c_r = l a . < o , ~ ( r ) >

The contents occur

operator,

in c o n t e x t s

meaning

...

or any o t h e r v a l u e r e t u r n i n g

where

the c o n s t r u c t

r

...

(while

A = (let

r d__oot) ~

The r e c u r s i v e

v:r;

...

items

form

v : el in

The r e c u r s i v e

(let

defines

for values.

The

this rule m u s t be i n t e r p r e t e d

as:

v = el

(let w =

(le__~t v:r;

of s y n t a c t i c

side d e f i n e s

(t;w)

else

I)

in w)

that w should be the

e2(v))

~

are more b a s i c

sorts of t r a n s f o r m a t i o n s . )

an a b b r e v i a t i o n :

(IV.e2Cv))(el)

let:

e2(v))

composition

sugar to be d e f i n e d

to p a r t i c u l a r

let p r o v i d e s

f o r m of

in

if v then

of the equation.

~

(Iv~.e2(v'))(Ylv.el(v))

v to be be the m i n i m a l

Functional

...)

combinator

(i.e. are not s p e c i a l i z e d its s i m p l e s t

v

let on the r i g h t hand

fixed-point

The remaining

(let

only

is:

In the case of the w h i l e

minimal

is d e f i n e d

transformation,can

fixed p o i n t of e x p r e s s i o n

is s t r a i g h t f o r w a r d :

el.

In

258

(f'g) = (~x.f(g(x)))

The d y n a m i c c o n d i t i o n a l is d e f i n e d in terms of a c o m b i n a t o r d i s c u s s e d in the next section:

(if V then t I else t 2) ~ cond(tl,t2)(v)

6.4 Basic C o m b i n a t o r s

A d e f i n i t i o n as v i e w e d in section 6.2 is a way of generating, object text w h o s e m e a n i n g is sought,

for any

an e x p r e s s i o n in an e x t e n d e d lamb-

da notation. The length of such e x p r e s s i o n s

is reduced and the reada-

b i l i t y much increased by the use of various combinators.

S e c t i o n 6.3

has shown how these can be e l i m i n a t e d in a way w h i c h yields a m u c h longer e x p r e s s i o n w h o s e s t r u c t u r e corresponds m u c h less closely to that of the o r i g i n a l text. The a d v a n t a g e of this e x p r e s s i o n is ever,

how-

that it is almost in pure lambda n o t a t i o n and it is now only

n e c e s s a r y to discuss the m e a n i n g of two r e m a i n i n g combinators.

In fact all that is done at this p o i n t is to rely on the w o r k of others. Thus along with the models of the lambda calculus in Stoy 74, the minimal fixed point o p e r a t o r

(Y) and the "doubly strict" c o n d i t i o n a l are

adopted:

cond(tl,t2)(T) cond(tl,t2)(TRUE) cond(tl,t~)(FALSE)

= X = t1 = t 2.

cond(tl,t2)(±)

= ±

The a d e q u a c y of the d o u b l y strict functions comes from the e x p l i c i t t r e a t m e n t of errors in the m e t a - l a n g u a g e .

6.5 O t h e r Issues The q u e s t i o n of how to define a r b i t r a r y order of e v a l u a t i o n in a language has been omitted for reasons explained elsewhere. ever,

There are, how-

some points w h e r e it appears to occur in the d e f i n i t i o n s given

259

in this volume. C o n s i d e r the use of:

let l£Sc-loc be 8.t. R-STG

Clearly,

l~dom a R-STG

:= C R - S T G U [l~?]

this intends to show a f r e e d o m of choice w h i c h w o u l d be lost

by p r e - d e f i n i n g an order over elements of So-lot and always c h o o s i n g the "next" free location. E q u a l l y clearly,

it w o u l d be u n n e c e s s a r i l y

c o m p l e x to use some general t r e a t m e n t for n o n - d e t e r m i n i s m functions are Z~Z-8et) construct.

Essentially,

(e.g. all

in order to p r o v i d e a formal d e f i n i t i o n of this it is clear that the p a r t i c u l a r choice makes

no d i f f e r e n c e and it is no m o r e w o r t h w h i l e to prove this c l a i m than it is to o v e r - d e f i n e

(see Jones 77c) and then prove w h a t p r o p e r t i e s

of the d e f i n i t i o n are irrelevant.

It must, however,

be clear that the "let be s.t." c o n s t r u c t could be

used u n w i s e l y and each use should really be a c c o m p a n i e d by its own arg u m e n t of w e l l - f o u n d e d n e s s .

Similarly,

the simple rule that v a l u e r e t u r n i n g t r a n s f o r m a t i o n s can

be w r i t t e n in p o s i t i o n s w h e r e values are r e q u i r e d presents a danger. The e x p a n s i o n g i v e n in s e c t i o n 6.3 that they should be e x t r a c t e d and formed into a p r e c e d i n g

let is only clear if either there is only

one such value r e t u r n i n g t r a n s f o r m a t i o n or if their order will have no e f f e c t on the result. This latter is the case in:

l#t nenv

: env+([gdoe-type(dclm(id),env)lid£do_~mdclm ] U ...)

F i n a l l y the topic of errors in the d e f i n i t i o n should be mentioned. A t a n u m b e r of points it has b e e n i n d i c a t e d that s o m e t h i n g is simply cons i d e r e d to be a w r o n g use of the m e t a - l a n g u a g e case construct).

(~i)(?
In such a case,

or

n o t h i n g is defined.

(e.g. an i n c o m p l e t e

just as with:

J'ABC'

This is in d i s t i n c t i o n to the use of error w h i c h

shows that the o b j e c t text is d e f i n e d by the d e f i n i t i o n to be in error. In this case it is p e r m i t t e d for a any r e s u l t sult:)

(although a d i a g n o s t i c

(valid)

i m p l e m e n t a t i o n to p r o d u c e

is, of course,

the m o s t useful re-

260

ACKNOWLEDGEMENTS The basis of the work on formal definition was laid in the Vienna Laboratory during the 1960's; Bekic 70a already showed a dissatisfaction with the "abstract interpreter" approach;

the actual meta-language d e s

cribed in this paper was developed at that Laboratory during the period 1973/75.

This author would like to acknowledge the stimulus and enjoy-

ment he has derived from his years in Vienna.

In particular the co-

operation with Hans Beki~ both in writing the notation section of Beki~ 74 and in discussing a draft of this paper, have been invaluable.

261

APPEND IX ~: C o n c r e t e S £ n t a x of the M e t a - l a n ~ u a g e The rules given b e l o w are an outline of a c o n c r e t e syntax in the notation of Walk 69. Basically,

the rules are context-free,

but sub-classes

of e x p r e s s i o n s are u s e d in order to indicate the types of p e r m i t t e d arguments to operators.

W r i t t e n d e f i n i t i o n s use a number of r e l a x a t i o n s on this syntax w h i c h are not f o r m a l l y defined.

a) B r a c k e t s around blocks and cond-stmts

as w e l l as commas and "in" are

o m i t t e d w h e r e i n d e n t a t i o n or line breaks m a k e the r e s u l t unambiguous.

b) Comments,

enclosed in " / ~ / "

may be used freely.

c) W h e r e an e x p r e s s i o n occurs at the end of an expr-ld,

"result is"

can be used.

d) The order of p r e c e d e n c e of operators

(standard)

is m o d i f i e d by use

of blanks and line-breaks in order to avoid e x c e s s i v e bracketing.

defn tr-defn tr-id

::= {.{fn-defnltr-defn}...} :: tr-id{(defs)} . . . . block

defs

::=

def construcor

::= v-idlconstructor

u s u a l l y begins w i t h

"i-" or "e-"

[,.def...]

"mk-" followed by name of a b s t r a c t syntax class (possibly followed by defs in parenthesis)

block

::= ([exit-spec][let-cl]{;.stmt..,})

exit-spec

::= tixe map-expr in

let-el

::= let def:expr;

expr-block

strut

as block but is value r e t u r n i n g

:~= stmt ~b lock Icond-stmtliter-stmtI~Tat-ldlassign-stmtl int-stmtlreturn-stmtll lexit-stmtlerror

262

cond-stmt

::= i_ff expr then stmt [else stmt] I ({,.{expr~stmt}...}[,T~stmt]I (cases expr:

iter-stmt

{,.{expr~stmt}...}[,T~stmt])

::= for v-id=expr

to expr do stmt

I

while expr do stmt 8tmt-ld assign-stmt int-stmt return-stmt

::= (Idl;stmt) ::= v-id:=expr ::= tr-id~(args)}o.. ::= return(expr)

exit-stmt

::= exit(args)

fn-defn

::= fn-id(defs)

expr

::= prefix-exprlinfix-exprlquant-exprlconstlfn-refleval-stmt

= pure-expr

var-refl(expr)Icond-exprlexpr-blocklexpr-ld fn-ref

::= fn-id(args)

eval-stmt

::= eval-id{(args)}...

args

::= [,.expr...]

var-ref cond-expr

::= [£] v-id[~args !] ::= if expr then expr else expr

I

({,.{expr~expr}...}E,T~expr])I (cases expr:{,.~expr~expr}...}[,T~expr]) expr- ld

::= (ldl;expr)

Idl

::= {;.ld...}

ld

::= let {deflfn-id(defs)} as expr but does not

pure-expr

expr-block,

= expr i__nn (directly)

contain:

~, eval-stmt

@eneral e x p r e s s i o n s

prefix-expr

::= h_!d tuple-expr

dessr-expr

::

(ideffEset-expr])(log-expr)

see also selectors and c o n s t r u c t o r s of a b s t r a c t syntax.

263

arith-ex~r

prefix-expr ::= len tuple-exprlcard set-expr see also o p e r a t o r s

on any s t a n d a r d

sets.

log-expr

prefix-expr ::= llog-expr infix-expr ::= log-expr {&Ivl~l~}log-exprl expr68et-expr 1 set-expr {clc}8et-expr expr {=l#}expr quant-expr

::= ({VIBIBf}def[6set-expr])(log-expr)

const

::= TRUEIFALSE

see also o p e r a t o r s fixed to a b s t r a c t

(e.g. syntax

relational) class

on s t a n d a r d

names.

set-expr

prefix-expr ::= {unionLRower}set-expr 1 {domlrn~}map-expr I {~ndslelems}tuple-expr infix-expr

::= 8et-expr{UInl-}set-expr

const

::= ~[,.expr..~]~ I ~exprllog-expr~l iarith-expr:arith-expr~

see also s t a n d a r d

set names:

Bool, Nat, Nat', Int

sets

and

"is-" pre-

284

tuple-expr

prefix-expr

::= {tllconc}tuple-expr

infix-expr

::= tuple-expr^tuple-expr

const

::= <[,.expr...]> I

map-expr

infix-expr

::= map-expr{+IUl'}map-expr map-expr{\I~}set-expr

const

::= k~,.{expr~expr}...}~I kexpr~expr~log-expr~

285

A P P E N D I X If: C o n v e n t i o n s

A p a r t from n o t a t i o n w h i c h guage,

is strictly part of the d e s c r i b e d m e t a - l a n -

a number of c o n v e n t i o n s have d e v e l o p e d in its use. k ~ i l e changes

to the n o t a t i o n should be r e f l e c t e d in a r e v i s e d d e f i n i t i o n of the meta-language,

the c o n v e n t i o n s can be ignored w i t h impunity.

This a p p e n d i x liSts some p o s s i b l e naming conventions:

usage

example

keyword

ofo_r

underlined sequence

operators

dom

of lower case

variables

val

sequence of 1.c.

of list type

intl

last letter "l"

of set type

cas

last letter "8"

of map type

dclm

last .letter "m"

class names

Program

first u.c., rest 1.c.

e l e m e n t a r y objects

INT

u n d e r l i n e d sequence of u.c.

references

R-STG

first letter "R"

context conditions

is-wf-expr

selector names

s-bdl

convention

(1.c.)

p r e d i c a t e names begins

"is-w f-"

begins

"s-"

266

A P P E N D I X III: E~ample D e f i n i t i o n

This a p p e n d i x p r e s e n t s an example w h o s e study will c o n s i d e r a b l y increase the reader's u n d e r s t a n d i n g of the m e t a v l a n g u a g e .

The d e f i n i t i o n

itself is d i v i d e d into a b s t r a c t syntax, c o n t e x t conditions,

semantic

objects and semantic function parts. Before these are p r e s e n t e d a few points of e x p l a n a t i o n will be offered.

(In a d d i t i o n Bj~rner 78b has

taken examples from this d e f i n i t i o n and thus p r o v i d e d a useful introduction).

The a b s t r a c t syntax should p r e s e n t no difficulties.

The c o n t e x t c o n d i t i o n s are also straightforward,

but note that in ad-

d i t i o n to the c o n v e n t i o n for d r o p p i n g formulae c o r r e s p o n d i n g to "splitting rules",

an obvious e x t e n s i o n permits equations

for rules of the

form:

A :: B C D to be omitted if they are of exactly the form:

is-wf-a(mk-a(b,c,d),env) = is-wf-b(bjenv) & is-wf-c(c, env) & is-wf-d(djenv) Notice that the context c o n d i t i o n is-wf-block

shows that r e c u r s i v e

calls of procedures are allowed w h i l e references identifiers w i t h i n the d e f i n i t i o n s of v a r i a b l e s prohibited.

to locally d e c l a r e d (i.e. b o u n d lists)

are

It can also be o b s e r v e d that is-wf-for shows that the con-

trol v a r i a b l e of a for c o n s t r u c t is strictly local to the body of the

for. The d e s c r i p t i o n of the semantic objects yields m o s t insight into the language. The state is divided into three components of w h i c h the m o s t important is storage; of mapping.

this is d e f i n e d as a d i s j o i n t u n i o n of two types

The e n v i r o n m e n t a u x i l i a r y object p r o v i d e s d e n o t a t i o n s

the identifiers. are locations}

In the simple case for variables,

for

these d e n o t a t i o n s

for arrays the locations are themselves

(one-one) map-

pings. For control v a r i a b l e identifiers the d e n o t a t i o n is simply an (cf. i-for, e-con-var-ref). P r o c e d u r e d e n o t a t i o n s are functions from a r g u m e n t lists

integer because no a s s i g n m e n t to such v a r i a b l e is allowed (and Aid-set)

to t r a n s f o r m a t i o n s

(cf. e-proc-den, w h i c h is a function

267

rather than a transformation,

and i-call).

The basic model for goto

definition is discussed in Jones 78b. Here, because procedures can be passed as arguments,

there is an additional problem of locating the

proper generation of a label. This problem is handled by activation identifiers. For a more detailed description of this approach see Jones 75. Given an understanding of the semantic objects an examination of the "type" clauses of the semantic functions should give an overview of the whole definition. Notice that i-program does not create a (value returning)

is the only function which

transformation.

The function i-

block defines nenv recursively to create the appropriate procedure denotations

(see section 6.2). The handling of exits is simplified in

this language

(cf. i-named-stmt-list)

since no compound

statement is

available.

ABSTRACT

SYNTAX

Program

:: Stmt

Stmt

=

Block

:: s-dcls:(Id~Type)

BlocklIflForlCalllGotoIAssignIInIOutINULL Proc-set Named-stmt •

Type

:: 8-sc-type:

Proc

:: 8-nm: Id Parm • Stmt

Parm

:: s-id:

Named-stmt

:: s-nm:[Id]

Scalar-type

s-bds:[(Exprl~) +]

Id s-attr:(TypelPROC) s-stmt:

Stmt

If

:: s-b: Expr s-th:

For

:: s-con-var:Ids-init:

Call

:: s-pn: Id s-args:(Var-refIId)~

Goto

:: Id

Assign

:: s-lhs:

Stmt s-el: Stmt Expr s-step: Expr s-limit: Expr Stmt

Var-ref s-rhs: Expr

In

:: Var-ref

Out

:: Expr

Expr

=

Infix-expr

:: Expr Op Expr

Rhs-ref

:: Var-ref

Var-ref

:: Id s-sscs:[Expr +]

Infix-exprlRhs-reflCo~-var-reflConst

C o n - v a r - r e f :: Id Const

=

Int-constIBool-const

disjoint

Op

=

Int-opIBool-opIComp-o p

disjoint

Scalar-type

= INTIBOOL

268

CONTEXT CONDITIONS

Env-static

= Id ~ (Type

I PROC, I LABEL

is-wf-program(mk-program(t))

I CON-VAR)

= is-wf-stmt(t,[])

i8-wf-block(mk-block(dclm,procs,nsl),env) let II = <s-nm(nsl(i)) let pnm8 = {8-nm(p) is-unique-id8(ll) (plEproc8

aet

I l

[ pEproc8}

&

& p26procs

is-disjoint(<dom

=

& p1~p2 ~ s-nm(pl)~s-nm(p2))

dclm, pnms,

elems

&

ll>) &

renv = env \ (dom dclm U pnm8 U elemsll)

let nenv = renv U [id ~ star(dclm(id)) [id ~ PROC [id ~ LABEL

Iid

Iid

£ pnms]

6 dom dclm]

I i d E elems

ll]

(dcl£rng dclm ~ is-wf-type-dcl(dcl,renv)) (prEprocs ~ i8-wf-proc(pr,nenv))

U

U &

&

(l
is-wf-type-del(mk-type(sctp, bdl),env) is-wf-type(mk-type(sctp,bdl),env) (bdl=NIL

= &

v

is-expr-list(bdl)

& (l
is-wf-proc(mk-proc(nm,parml, st), env) = is-unique-ids(<8-id(parml(i))

I l)

&

(let nenv = env + [s-id(parml(i)) ~ s-attr(parml(i)) is-wf-stmt(st,nenv)

)

I i£[1:len parml}]

289

i s - w f - p a r m ( m k - p a r m ( i d , attr),env) attr=PROC v s-bds(attr)=NIL

i8-wf-if(mk-if(b,

= v i8-~-list(s-bda(attr))

, ),env) = e x - t p ( b , e n v ) = B O O L

i a - w f - f o r ~ m k - f o r ( i d , init,atep, limit, st),env) = let nenv = env + [id ~ CON-VAR] ex-tp(init, env) = ex-tp(step, env) = ex-tp(limit, env) = I N T is-wf-stmt(st,nenv)

i s - w f - c a l l ( m k - c a l l ( p n , al),env) = pn E dom env & e n v ( p n ) = P R O C

&

(l
is-wf-goto(mk-goto(id),env)

= idEdom env & e n v ( i d ) = L A B E L

ia-wf-assign(mk-assign(lhs,rhs),env) is-acalar(lhs,env) ex-tp(rha,env)

v env(al(iJ)=PROC)

=

&

= var-ref-tp(lhs,env)

is-wf-in(mk-in(vr),env)

= is-scalar(vr, env)

i a - w f - i n f i x - e x p r ( m k - i n f i x - e x p r ( e l , o p , e2),env) = is-int-op(op)

& e x - t p ( e l , e n v ) = e x - t p ( e 2 , env)=IN T v

ia-bool-op(op)

& ex-tp(el,env)=ex-tp(e2,env)=BOOL

is-eomp-op(op)

& e x - t p ( e l , e n v ) = e x - t p ( e 2 , env)=INT

is-wf-rhs-ref(mk-rhs-ref(r),env)

= is-scalar(r, env)

v

&

270

is-wf-var-ref(mk-var-ref(id, el),env) idEdom

env & i s - t y p e ( e n v ( i d ) )

(el=NIL

=

&

v (s-bds(env(id))~NI k & fen el = len s - b d s ( e n v ( i d ) ) (1
&

el ~ e x - t p ( e i ( i ) , e n v ) = I N T ) ) )

is-scalar(mk-var-ref(id, sscl),env)

=

sscl=NIL ~ s-bds(env(id))=NIL

is-wf-con-var-ref(mk-con-var-ref(id),env) idEdom

ex-tp(e,env) cases

=

env & e n v ( i d ) = C O N - V A R

=

e:

m k - i n f i x - e x p r ( e l , o p , e2) (is-int-op(op)

~ INT

is-bool-op(op)

~ BOOL

is-comp-op(op)

~ BOOL)

mk-rhs-ref(vr)

~ var-ref-tp(vr,env)

mk-con-var-ref(id) T

~ INT.

~ (is-int-const(e)

~ INT

is-bool-const(e)

Car-ref-tp(mk-var-ref(id,

is-unique-ids(idl) type:

),env)

~ BOOL)

= s-sc-type(envCid))

= /~ true i f f no d u p l i c a t e s

*/

Id ~ ~ Hool

star(t)

= /~ all b o u n d s

changed

to ~ ~/

type: T y p e ~ Type

is-disjoint(el)

= /~ teste

type: Set ~ ~ Bool

set8 p a i r w i s e

disjoint

~/

271

is-scalar-type(t)

is-array-type(t)

SEMANTIC

= is-type(t)

= id-type(t)

& s-bds(t)=NIL

& s-bds(t)#NIL

OBJECTS

State

(R-STG~Storage)

Storage

(Bool-loc ~ (Bool

U ( R - I N ~ Value ~) U

Value

=

Int

Env

=

Id ~ (Loc

i Con-var-den

Array-loc

I Scalar-lot

Loc Array-lot

:

(Int + ~ Bool-loc)

Scalar-loc

=

Bool-loc

Con-var-den

=

Int

Label-den

:: Aid Id

I Label-den

Proc-den)

I (Int+ ~ Int-loc)

l£Array-loc ~ ( 3 i l 6 N a t + ) ( d o m

I Int-loc

is an i n f i n i t e set

Proc-den

:: ((Loc I Proc-den)~

Tr

=

State ~ State Abn

Abn

=

[Label-den]

Int-loc

}

Aid-set ~ Tr)

N

infinite

sets s.t.

Bool-loc N Int-loc ={}

Bool-loc

FUNCTIONS

i-program(mk-program(t)J(inl)

=

(let in-state = [R-STG~[], let fln-state

R-IN~inl,

R-OUT~<>]

= i-stmt(t,[],{})(in-state)

fin-state(R-OUT) ) type: Program ~ (Value • ~ Value ~)

i-stmt:

I k ))

I Bool

constraint:

Aid

( R - O U T ~ Value ~)

I k )) ~ (Int-loc ~ (Int

Stmt Env Aid-set

-~

1 =rect(il))

272

i-block(mk-blockCdclm, procs~nsl),env, cas) = (let aidEAid be s.t. aidEcas let nenv: env + ([id ~ mk-label-den(aid, id) lid ~ e-type(delm(id),env) [s-nm(p) ~ e-proc(p,neno)

I is-cont(id, nsl)] U I idEdomdclm]

U

I pEprocs]);

always (let l o c s =

{nenv(id)

I idEdomdclm~

let sclocs = {lElocs

I is-scalar-loc(1)}

uni°n{rgnl R-STG

U

I 1Elocs & lis-scalar-loc(1)}

:= ~ R - S T G ~ s c l o c s

) i__nni-named-stmt-list(nsl,nenv, aasU{aid},aid) )

e-type(mk-type(sctp~bdl),env)

=

i_~ bdl=NIL then (let 1EScalar-loc be s.t. is-tp-scalar-loc(sctp, 1) & 1Edom c R-STG R-STG

:= c R-STG U [1 ~ ~];

return(1) ) else (let ebdl: <e-expr(bdl(i),env) i_~ (3iE~l:lenbdl~)(ebdl(i)
I l; then error;

let 1EArray-loc be s.t. sclErng

1 ~ is-tp-scalar-loc(sctp, s c l ) &

dom 1 = rect(ebdl) rng 1 n d o m c R-STG

return(l)

type: Type Env

R-STG = ~}

:= ~ R__-STGU[scl~~

) ~ Loc

& I sclErn~ 1];

273

e-proc(mk-proc(,parml,st),env)

=

let f(denl, cas) = (if lendenl~lenparml

v

(3iE{l:lenparml~J(~is-pmatch(denl(i),s-attr(parml(i))) then error; let lenv = env + [8-id(parml(i))

~ denl(i)

I i E {l:len parml}]

i-etmt(st, lenv, cas)

) mk-proc-den(f) type:

Proc Env ~ Proc-den

i-named-stmt-list(nsl, tixe

env, cas,a~d)

=

[mk-label-den(a~d, tid)~it-named-stmt-list(tno, I 1~tno~lennsl

i__nnit-named-stmt-list(1,nsl, type:

Named-stmt • Env Aid-set

it-named-stmt-liet(i,nsl,env,

nsl, env, aas.

& s-nm(nsl(tno))=tid#NIL]

env, cas)

Aid

cas) =

for j = i to fen nsl do i-stmt(s-stmt(nsl(j)),env~cae) type:

Nat Named-stmt~

Env Aid-set

i-if(mk-~f(be, th, elJ,env, cas) = (let by:

e-expr(be, env);

if by then i-stmt(th,env, cas) else

i-etmt(el,env, cae)

274

i-for(mk-for(cv, ie,se, le,st),env,cas)

=

(let i: e-expr(ie, env); let s: e-expr(se, env); let l: e-expr(le, env); l_~et f(x) = if (s>O ~ x~l,

s
s=O ~ TRUE)

then (i-etmt(et, env+[cv~x],cae);f(x+s))

f(i) )

i-aall(mk-call(pldjal),envjcas) (let mk-proc-den(f)

=

= env(pid)

let dl:
~ e-var-ref(al(i),env),

T

~ env(al(i))

f(dl, cas) )

i-goto(mk-goto(id),env)

=

exit(env(id))

i-assign(mk-assign(vr,

e),env)

=

(let l: e-var-ref(vr, env); let v: e-expr(e,env); assign(1,vJ

i-in(mk-in(vr)jenv) (if c R-IN

=

= <> then error;

let l: e-var-ref(vr, env); let v: hd e R-IN; i f lie-vmatch(v,var-ref-tp(vr)) else (R-IN

:= tl c R-IN;

assign(1,v)

then error

i 1<~
al>;

275

i-out(mk-out(e),env)

=

(let v: e-expr(e,env); R-OUT )

e-expr:

:= c R-OUT ^

Expr Env

~

Value •

e-infix-expr(mk-infix-expr(el,op, e2),env)

x

(let v1: e-expr(el,env); let v2: e-expr(e2, env); let v: apply-op(vl,op, v2); return(v) )

e-rhs-ref(mk-rhs-ref(vr),env)

=

(let l: e-var-ref(vr, env); content,(l) )

e-var-ref(mk-var-ref(id, sscl),env) if sscl=NIL

=

then return(~nv(id))

else (let a l o c =

env(id)

let esscl:

<e-expr(sscl(i),envJ

i f esecIEdom

I 1;

aloc then error;

return(aloc(esscl))) type:

Var-ref Env

~

Loc

e-con-var-ref(mk-con-var-ref(id),env)

e-aonst(e,)

= return(env(id))

= /~ return a Value corresponding

to the Constant

~/

276

apply-op(vl,op,v2) type:

Value Op Value

assign(l,vJ R-STG

~

Value */

Value

=

:= c R-STG + [l ~ v~

type: Scalar-Ice pre:

= /* Returns an appropriate

Value

ICdo~ c R-STG,

is-lmatch(l,v)

contents(l) = let v: c R-ST@(IJ; if V=? then error; else return(v)

type: S c a l a r - l o c pre:

~

Value

IEdom c R-STG

rect(il)

= /* generates a dense rectangle of integers

*/

type: Int + ~ (Int+)-set pre:

1
fen il ~ il(i)~l

is-lmatch(1,v)

= /* ,checks location and value are of same scalar type */

type: S c a l a r - l o c Value ~ Bool

is-vmatch(v, tJ = /* checks value is of scalar type */ type:

Value S c a l a r - t y p e ~ Bool

is-pmatch(d,s) type:

(Loc

= /*

checks the argument matchs parameter specification *~

i Proc-den)

(Type

i PROa) ~ Bool

277

i s - t p - s c a l a r - l o c ( t p , l) = tp=BOOL ~ is-bool-loc(1) tp=INT ~ is-int-loc(1)

type:

Scalar-type

i s - c o n t ( i d , nsl) type:

Scalar-lot

~ Bool

= (3iE{l:~ennsl~)(~d=s-nm(nsl(i))

Id N a m e d - s t m t ~ ~ Bool

DENOTATIONALSEMANTICSOF GOTO: AN EXIT FORMULATION AND ITS RELATION TO CONTINUATIONS

Cliff B.Jones

Abstract: This paper discusses the problem of providing a defini= tion for the "GOTO" statement within the framework of denotational

semantics.

The accepted approach to the

problem is to use "Continuations".

An alternative "Exit

Formulation" is described in this paper. A small language is introduced which illustrates the difficulties caused by statements which terminate abnormally.

For this lan=

guage definitions based on both approaches are provided. A proof of equivalence of the two definitions is then given. In a closing discussion it is pointed out that continuations can define a wider class of languages than exits, although the latter have been shown to be adequate to define languages as complex as PL/I.

CONTENTS

l°

Introduction

Z80

2.

Notation

281

3.

A Small Language

282

4.

Definition By Exit

285

5.

Definition By Continuations

289

6.

Equivalence of the Two Definitions

292

7.

Discussion

302-304

Fig.l:

The Language

Fig.2:

Definition Using Exit Combinators

Fig.3:

Definition by Exit M e c h a n i s m w i t h Combinators

Fig.4:

Definition

Using Continuations

Fig.5:

Definition

Using Continuations

to be Defined

283 286

Definition Using Continuations Recomputed

Fig.7:

-293 --

at Each C o m p o u n d Statement

Definition Using

(E) Continuations

W i t h o u t Environments

289 291

with Merge of c - c and c - l Fig.6:

Expanded

296

-300

280

i. I N T R O D U C T I O N

There exists by now a c o n s i d e r a b l e body of w o r k on the formal definition of p r o g r a m m i n g languages

(see Lucas 78, in this volume,

for a hi-

storical review). M o s t of the w o r k can be c a t e g o r i s e d as either "abstract interpreters",

"denotational semantics" or "axiomatic"~ This

p a p e r attempts to make a c o n t r i b u t i o n to the u n d e r s t a n d i n g of denotational semantics. This a p p r o a c h is p a r t i c u l a r l y

a s s o c i a t e d w i t h the

P r o g r a m m i n g R e s e a r c h G r o u p at Oxford University.

E v o l v i n g from the

earlier work on abstract interpreters

(see Lucas 69) the m o r e recent

w o r k of the V i e n n a L a b o r a t o r y has also u s e d the d e n o t a t i o n a l style (see Beki6 74).

A l a n g u a g e can be given by the set of its texts. To define the semantics of a l a n g u a g e one m u s t a s s o c i a t e a m e a n i n g or d e n o t a t i o n w i t h each text in the set. Since the set of texts will, languages, be of i n f i n i t e cardinality,

for i n t e r e s t i n g

this link w i l l be shown by de-

fining a function from the set of textstto a set of d e n o t a t i o n s . such a d e f i n i t i o n of a large language to be comprehensible,

For

it is re-

q u i r e d that the d e n o t a t i o n of a c o m p o u n d text should d e p e n d solely on the d e n o t a t i o n s of its c o m p o n e n t parts. (Clearly, this rule m u s t be applied ohly to a sensible level: a s c r i b i n g m e a n i n g to single characters and then t r y i n g to c o n s t r u c t the m e a n i n g of identifiers and k e y w o r d s is u n l i k e l y to prove illuminating.

The limit of sensible d e c o m p o s i t i o n

is u s u a l l y indicated by the a b s t r a c t s y n t ~

of a language.)

In order

for a f u n c t i o n from texts to d e n o t a t i o n s to define the semantics of the texts,

it is o b v i o u s l y a p r e - r e q u i s i t e that the d e n o t a t i o n s

themselves

should be objects w i t h known meanings. One c h a r a c t e r i s t i c of d e n o t a t i o nal semantics is the use of m a t h e m a t i c a l objects

(especially functions)

as the denotations.

This accounts

m a t i c a l semantics".

In fact the functions chosen as d e n o t a t i o n s are

for the a l t e r n a t i v e name of "mathe-

of a very general form and it has b e e n a c o n s i d e r a b l e task to show that such functions do indeed h a v e a c o n s i s t e n t m e a n i n g

(see Scott 71).

T h e r e is, w i t h i n the " d e n o t a t i o n a l school", a g r e e m e n t as to the concepts r e q u i r e d to p r o v i d e d e f i n i t i o n s of simple languages. a number of notatiQnal d i f f e r e n c e s

lead to d i f f e r e n c e s

of c o n c e p t u a l l y similar definitions,

see next section).

(However,

in the a p p e a r a n c e Reme~nbering the

"denotational rule" that d e n o t a t i o n s of c o m p o s i t e objects should be b u i l t from the d e n o t a t i o n s of their components,

the following o b s e r v a -

tions can be made. For a p u r e l y functional l a n g u a g e it is easy to agree a definition;

for a language w h i c h includes a n assignment c o n s t r u c t

281

the c o n c e p t of a store

(i.e. a m a p p i n g from identifiers to values)

per-

mits d e n o t a t i o n s to be d e f i n e d w h i c h are functions from stores to stores;

the g e n e r a l l y a c c e p t e d a p p r o a c h to block s t r u c t u r e d languages

is to i n t r o d u c e locations and e n v i r o n m e n t s . W h i l s t refs Mosses 74 and Beki~ 74 build from this basic list of a g r e e m e n t s and tackle similar large languages, a n i m p o r t a n t d i f f e r e n c e can be found.

The i m p o r t a n t d i f f e r e n c e b e t w e e n the Oxford and V i e n n a groups can be f o u n d in their a p p r o a c h to p r o b l e m s of abnormal termination. The arc h e t y p a l p r o b l e m in this c a t e g o r y is the "goto" statement. A d e f i n i tion c o n f o r m i n g to the d e n o t a t i o n a l rule is d i f f i c u l t to c o n s t r u c t for languages w h i c h include goto statements p r e c i s e l y b e c a u s e their effect is to t r a n s f e r control across the s t r u c t u r e over w h i c h the d e n o t a t i o n s are b e i n g constructed.

(This p o w e r of goto statements has led to a

m o v e m e n t for their elimination. here.

This c o n t r o v e r s y is not e n t e r e d into

Rather, models are e x p l a i n e d w h i c h are general enough to model

goto. On such m o d e l s one can then compare a l t e r n a t i v e language constructs w h i c h m i g h t offer the d e s i r a b l e features, w i t h o u t the danger, of goto statements. Of course,

a language feature may e v e n t u a l l y be

s e l e c t e d for w h i c h simpler models are possible. W h a t the m o d e l s here offer is a basis from w h i c h to work.) tions"

The O x f o r d group use "continua-

(see Strachey 74) to d e f i n e g o t o - l i k e constructs:

tion in section 5 b e l o w is in this guage is d e f i n e d u s i n g the V i e n n a

the d e f i n i -

style. The same small example lan"exit" a p p r o a c h in section 4. The

language itself is introduced i n f o r m a l l y in section 3 after some comments on notation. G i v e n two d e f i n i t i o n s of the same language, q u e s t i o n of their r e l a t i o n s h i p can be posed:

the

e q u i v a l e n c e is p r o v e d in

section 6. W h i l s t both c o n t i n u a t i o n s and exits h a v e been shown to be p o w e r f u l enough to d e f i n e c o m m o n l y used p r o g r a m m i n g languages, two a p p r o a c h e s are not of e q u i v a l e n t power,

the

section 7 contains some

c o n c l u d i n g c o m m e n t s on this point.

2. N O T A T I O N

The basis of the n o t a t i o n to be u s e d in this p a p e r is taken from logic and lambda calculus and will p r o b a b l y be familiar from the literature. The items of special i n t e r e s t w i t h i n this p a p e r are i n t r o d u c e d b e l o w as required. A m o r e c o m p l e t e e x p l a n a t i o n is a v a i l a b l e elsewhere in this v o l u m e

(Jones 78a); Jones 75 p r o v i d e s a s t e p w i s e d e v e l o p m e n t of

the exit concept.

282

One of the m o s t d a n g e r o u s traps

when

c o m p a r i n g two languages is to

let the superficial syntactic d i f f e r e n c e s confuse the real issue w h i c h is that of meaning. The d i f f e r e n c e in a p p e a r a n c e b e t w e e n the O x f o r d and V i e n n a d e f i n i t i o n s is very striking. The former group

has achiev-

ed s u c c i n c t n e s s in o r d e r to f a c i l i t a t e formal r e a s o n i n g about smaller definitions, w h i l s t the tasks tackled by the V i e n n a group have led them to strive for readability.

This paper, b e i n g b a s e d on a very small

language, c o m p r o m i s e s a little for the sake of compactness. Thus short names are u s e d for the syntactic classes and "<>" is used instead of a named

(tree) c o n s t r u c t o r w h e r e c o n t e x t makes the choice clear

(the con-

vention for d r o p p i n g semantic rules for syntax classes d e f i n e d to be a list of a l t e r n a t i v e s is also followed). O t h e r than this the d e f i n i tions, even that by continuations,

are given in a V i e n n a - s t y l e .

The

issue to be r e v i e w e d is the d i f f e r e n c e s b e t w e e n the d o m a i n s and function types. Choices like the use of d i f f e r e n t b r a c k e t symbols,

expli-

cit versus i m p l i c i t typing of functions and the d e g r e e of a b s t r a c t n e s s for the syntax m i g h t influence the number of c h a r a c t e r s in a d e f i n i t i o n but would,

if u s e d on one of the definitions,

serve only to cloud the

m a i n distinction.

3. A SMALL L A N G U A G E

This section introduces the language w h i c h will be used as the basis for the r e m a i n d e r of the paper. The basic statements of the language are "goto" and an u n a n a l y z e d class of e l e m e n t a r y statements. A b o u t these latter all n e c e s s a r y k n o w l e d g e is g i v e n by the f u n c t i o n "el-sem" which associates a state-transformation class Z) w i t h each m e m b e r of El-stmt.

(i.e. a function over the

Statements can be o p t i o n a l l y

named and lists thereof can be formed into c o m p o m n d statements.

Such

compound statements are also statements and thus can be named and used as elements of other lists. The a b s t r a c t syntax of the language is given,

along w i t h a full name for each class of objects to aid compre-

hension,

in f~g.

I. The s t r u c t u r e of the classes Id and E l - s t m t is not

further defined.

~:

In this paper a s u p e r s c r i p t 0 is to be read as the functional c o m p o s i t i o n operator. It is e l s e w h e r e r e p r e s e n t e d by the fat dot: ,.

283

P

Program

::

C

Compound statement

C

::

s-b:Ns ~

Named s t a t e m e n t

N8

::

s-n:[Id]

statement

s

:

cI

Goto s t a t e m e n t

G

::

Id

Elementary statement

E1

::

El-stmt

Identifiers

Id

IE

A b s t r a c t syntax

Full name

Fig.

s-b:S

I: The L a n g u a g e to be D e f i n e d

In o r d e r to f a c i l i t a t e d i s c u s s i o n of the i d e n t i f i e r p r e f i x e s of statements,

two p r e d i c a t e s w h i c h check for the

(direct and indirect)

con-

t a i n m e n t of identifiers and a f u n c t i o n y i e l d i n g the index of that s t a t e m e n t w h i c h c o n t a i n s an identifier (under the a s s u m p t i o n that it is c o n t a i n e d somewhere)

is~doontCid, nsI)~=> type:

Id Ns*

~

are introduced:

(Bi6{1 -lenr~sl}) Cs-nOnsl(i) = id)

Bool

is-cont(id, ns l) ~

(is-dcont (id, nsl) v (Bi£~l:,,lennsl})(s-bO-nsl(i) E C & is-cont(id, s-bOs-bOnsl(i))))

type:

Id Ns • ~

Bool

ind( id, ns I)= is-doont(id, nsl) T

~-

~

(li) (s-nOnsl(i)=id)

(li)(s-bOnsl(iJ £ C

type:

Id N8~

pre:

i8-eont(id, nsl)

~

Nat

& is-cont(id, s-bOs-bOnsl(i)))

284

It is assumed that w e l l - f o r m e d programs satisfy the context condition that all label identifiers used in goto statements are c o n t a i n e d exactly once w i t h i n the program. With respect to the statement list w i t h i n w h i c h the goto is placed,

the target s t a t e m e n t may be w i t h i n the same

list, w i t h i n a c o n t a i n i n g list or w i t h i n a c o m p o u n d statement w h i c h is a member of the same list~ The local "hop" and the abnormal exit from a list should require no comment. The ability to jump into a p h r a s e s t r u c t u r e is allowed, b e c a u s e it is included in m a n y p r o g r a m m i n g languages

(cf. Algol

60 "goto" into b r a n c h e s of c o n d i t i o n a l state-

ments.)

The choice of features in this language has b e e n m a d e w i t h some care in order to exhibit m o s t of the c o m p l e x i t y of large languages in a framework of reasonable size. Thus the ability to hop b e t w e e n elements of a list has been s u p p l e m e n t e d by p e r m i t t i n g goto statements to enter and leave syntactic units. In fact if the reader compares this language to Algol 60 (see Henhapl 78 in this volume)

only the ability to pass

labels and p r o c e d u r e s as p a r a m e t e r s forces an e x t e n s i o n of the ideas used here. A b n o r m a l t e r m i n a t i o n of a block via a goto s t a t e m e n t is a s t r a i g h t f o r w a r d e x t e n s i o n and the problems a s s o c i a t e d w i t h r e d e f i n i tion of names in a b l o c k - s t r u c t u r e d language can be solved in a uniform way for v a r i a b l e and label identifiers

(see Beki~ 74 for a dis-

c u s s i o n of label variables).

The e l e m e n t a r y statements of the language are a s s u m e d to cause changes to a class of states

el-sem:

Were

(Z):

El-stmt ~

(Z ~ Z)

it not for the inclusion of the "goto" construct,

it w o u l d be

s t r a i g h t f o r w a r d to p r o v i d e a d e f i n i t i o n w h i c h a s s o c i a t e d a t r a n s f o r m a t i o n w i t h any elements of S.

(The d e n o t a t i o n of a list of statements

b e i n g the c o m p o s i t i o n of the d e n o t a t i o n s of the e l e m e n t s of the list.) W h i l s t as a result of the c o n t e x t c o n d i t i o n given above, the d e n o t a t i o n of a w h o l e p r o g r a m w i l l be such a transformation,

it is not p o s s i b l e

to ~scribe such a simple d e n o t a t i o n to "goto" statements. sections offer d i f f e r e n t solutions to this problem.

The next two

285

4. D E F I N I T I O N BY E X I T

The d i f f i c u l t y of finding a suitable d e f i n i t i o n for a language w h i c h includes goto s t a t e m e n t s is that its a b i l i t y to cut across syntactic units forces changes on the semantics of all such units. A m o t i v a t i o n of the exit a p p r o a c h to be defined in this section was to m i n i m i z e the e f f e c t Of these changes on the overall a p p e a r a n c e of a definition.

The

key to a c h i e v i n g the d e s i r e d e f f e c t w i t h o u t w r i t i n g it into all of the semantic equations is to d e f i n e a p p r o p r i a t e combinators. simple language

(i.e. one w i t h o u t goto statements)

Thus in a

a c o m b i n a t o r denot-

ing f u n c t i o n a l c o m p o s i t i o n m i g h t be w r i t t e n ";". If this same symbol is r e i n t e r p r e t e d as the more c o m p l e x c o m b i n a t o r used below,

a defini-

tion for a language w i t h goto statements can p r e s e r v e a simpler app e a r a n c e except, of course,

for those semantic e q u a t i o n s w h i c h deal

s p e c i f i c a l l y w i t h goto statements.

The basic idea of d e f i n i t i o n by exit is to associate a d e n o t a t i o n with e a c h statement w h i c h is a function of type:

E

=

Z~ZA

=

Idl

where:

A

N~L

Thus the d e n o t a t i o n of a s t a t e m e n t is a f u n c t i o n from states to pairs: the first e l e m e n t is a state and the second is either an i d e n t i f i e r or

NIL. In the case that a p p l y i n g the d e n o t a t i o n of a s t a t e m e n t to a state results in no "goto", the r e s p e c t i v e range e l e m e n t will be the result state p a i r e d w i t h NIL. If, however,

a "goto" is e n c o u n t e r e d to a label

not c o n t a i n e d w i t h i n the statement,

the range e l e m e n t w i l l pair the

state r e f l e c t i n g state t r a n s i t i o n up to the time of the "goto" w i t h the target label.

The definition,

using c o m b i n a t o r s w h o s e m e a n i n g is m a d e p r e c i s e belowr

is given in fig 2. The f u n c t i o n names all b e g i n w i t h that they are

part

"x-" to signify

of the exit-style definition. It is not d i f f i c u l t

to p r o v i d e an i n t u i t i v e u n d e r s t a n d i n g of this definition.

The func-

tion x-g w h i c h d e f i n e s the s e m a n t i c s of goto statements uses the "exit" combinator (identifier)

w h i c h simply pairs the a r g u m e n t state w i t h the given value. W h e r e v e r

a simple

(Z~Z) f u n c t i o n is shown it is

i n t e r p r e t e d as y i e l d i n g NIL p a i r e d w i t h w h a t e v e r the o u t p u t state

286

x-p()

x-e(ep)

=

=

x-c(cp)

x-cp(NIL, cp)

x-cp(ido,<nsl>)

=

tixe [ id~x-l(id, nsl) in

I ia-cont(id, nsl)

]

x-l(ido, nsl)

x-l(ido, nsl) = ido=NIL

x-nsl(nsl, i)

i8-deont(ido, nsl)~

x-nsl(nsl, ind(ido,nsl))

T

(let i = ind(ido, nsl) x-cp (ido, s-b (nsl (i) ) ); x-nsl(nsl, i+l) )

x-nsl(nsl, i) = i
(x-s (s-b (nsl(i) ) ) ;x-nsl(nsl,i+l) ) I

T

x-g()

=

x-el(<el>)

exit(id)

=

el-sem(el)

fig 2: D e f i n i t i o n u s i n g exit c o m b i n a t o r s

w o u l d have been. is the i d e n t i t y of the excised nother

This

explains

x-el and the second case of x-nsl

on E). The fact that these denotations,

and thus

(I that

x-s, are of type E force their c o m b i n a t i o n w i t h one a-

to be more complex°

The

";" c o m b i n a t o r

applies

the s e c o n d E

287

t r a n s f o r m a t i o n o n l y if the second c o m p o n e n t of the first result is NIL, o t h e r w i s e the result of the two c o m p o s e d t r a n s f o r m a t i o n s is e x a c t l y that of the first. It remains only to explain x - c p . tor " t i x e "

(spell back-to-front~)

";". If a normal p a i r in

(i.e. NIL

H e r e the combina-

is for the c o n v e r s e situation from

second component)

t r a n s f o r m a t i o n n o t h i n g m o r e is done;

some r e s t r i c t e d set of exit values, t r a n s f o r m a t i o n re£urns a n o n - N I L

is the r e s u l t of the

the first m a p p i n g defines,

for

the a c t i o n to be taken if the i__nn

result. It is i m p o r t a n t to realize

that this m a p p i n g covers a finite number of cases w h i c h can be d e t e r m i n e d from the text b e i n g defined.

The types of the semantic functions can be given:

x-p:

P ~ E

x-c:

C ~ E

x-cp:

[Id]

C

x-l:

lid]

Ns*

x-nsl:

Ns ~ N a t

x-s:

S~

x-g:

G ~ E

x-el:

E1 ~ E

E E E (assumed)

E

The formal m e a n i n g s of the c o m b i n a t o r s is now given. The format used for these d e f i n i t i o n s

is first to list any assumptions,

type of the c o m b i n a t o r e x p r e s s i o n the d e f i n i t i o n

then show the

(after a ":") and finally to p r o v i d e

(after "~").

F i r s t l y the e x i t

combinator:

for i d E I d exit(id)

: E

exit(id)

A ~a.<~,id> =

The p r o m o t i o n of a simple t r a n s f o r m a t i o n to one of type E is g o v e r n e d by context:

for t : Z~Z in a c o n t e x t r e q u i r i n g E t : E

In particular:

288

I ~- I~.<s, NIL> The s e m i c o l o n combinator is defined as:

for t I and t 2 : E

(tl;t 2) : E (tl;t ~) ~ (l~,ido.(ido=NIL~t2(s),T~
for t I : Id ~ E,

t 2 : E,

ido>))Ot I

is "tix~":

p : [Id] ~ Bool

(tixe [a~tl[a) Ip[a)] i__nnt 2) : E (tixe

[a~t1(a) Ip(a)] i__nnt 2) (let e = [a~t1(a) Ip(a)] 0 let r(e, ido) = (ido6dome ~ r e(ido)(s),T~<~,~do>) rot2 )

N o t i c e that r is used recursively,

thus the effort to resolve an ab-

normal exit w i t h t I continues until p is not satisfied.

Fig 3 p r o v i d e s a r e w r i t i n g of the exit d e f i n i t i o n with the above combinator d e f i n i t i o n s applied to provide a d e f i n i t i o n in almost-pure lambda notation. A l t h o u g h this is more c o n v e n i e n t for the proofs of section 6, the c o m b i n a t o r s h a v e c o n s i d e r a b l e v a l u e in p r o v i d i n g a shorter and m o r e intuitive d e f i n i t i o n of a large language

(compare

refs Beki6 74 and Allen 72).

N o t i c e that the only labels w h i c h are returned from c o m p o n e n t s of the function) in the text argument.

(non-NIL second

"x-l" are those w h i c h are not c o n t a i n e d

Thus it can be proved:

pre-x-l(ido, nsl) <=> (ido=NIL ¥ is-aont(ido, nsl)) post-x-l(~do, nsl,~,~',ido') <=> (ide'=NIL v ~is-contCido',n~l)) and b e c a u s e of the context c o n d i t i o n it is p o s s i b l e to show that x-p is of type:

~ ~ NIL and from this extract a d e n o t a t i o n of type:

Z ~

289

x-cp(ido,<nsl>)

=

let e = [id ~ x - l ( i d , nsl) lis-cont(id, nsl)] let r(a, ido')

= (ido'£dome

~ rOe(ido')(c),

T ~ <s, ido'>)

fox - 1 (ido, ns l)

x-l(ido,nsl)

=

ido=NIL

~ x-ns I (ns l, 1 )

i 8 - d c o n t ( i d o , nsl) ~ x - n s l ( n s l , ind(ido, nsl)) T

~

(let i = ind(ido, nsl) (la, ido '. (ido '=NIL ~ x-nsl(nsl, i+l) (s) , T ~ <s,ido'>))Ox-cp(ido, s-bOnsl(i))

)

x-nsl(nsl,i) i
= ~

((l~,ido'. ( i d o ' = N I L ~ x - n s l ( n s l , i+l),

T ~ <e, ido'>)) 0

x-s(s-b(nsl(i)))) T

~ h~.<S,NIL>

x-g()

x-el(<el>)

x-p,

x-c

=

la.

=

h~. <el-sere(el) ( ~ ) , N I L >

unchanged

F i g 3: Definition by exit mechanism with combinators expanded

5. D E F I N I T I O N

BY C O N T I N U A T I O N S

This section introduces the more widely used continuation approach for the definition of languages which include goto statements. As with exits, this approach recognises that denotations of type Z~Z will not

290

suffice. W h i l e c o n t i n u a t i o n s themselves are:

T = Z ~ Z

the denotations of s t a t e m e n t - l i k e constructs become:

T~T

The q u e s t i o n of the m e a n i n g of goto s t a t e m e n t s is handled by a s s o c i a t ing c o n t i n u a t i o n s w i t h identifiers.

The d e n o t a t i o n of a goto state:

m e n t for any c o n t i n u a t i o n is then the c o n t i n u a t i o n a s s o c i a t e d w i t h the c o n t a i n e d identifier.

In a c o m p l e x l a n g u a g e definition, b l o c k struc-

ture w o u l d anyway force the use of an e x p l i c i t e n v i r o n m e n t a r g u m e n t to the semantic functions and this can be used to record the a s s o c i a t e d c o n t i n u a t i o n for labels. Thus,

Env

=

Id

Intuitively,

~

in the current case:

T

one can consider statement d e n o t a t i o n s as yielding,

a given s u b s e q u e n t c o m p u t a t i o n

(i.e. continuation),

for

the overall compu-

tation s t a r t i n g at this statement. Notice that this is not simply the c o m p o s i t i o n of two functions of type Z~Z b e c a u s e of the p o s s i b i l i t y of "goto". The label d e n o t a t i o n s are the transitions r e s u l t i n g from starting e x e c u t i o n at that label and e x e c u t i n g to the end of the program. Thus a f u n c t i o n of type Z~Z is a s s o c i a t e d w i t h a text given a particular e n v i r o n m e n t and continuation. A m o r e c o m p l e t e d e s c r i p t i o n of the m e t h o d of c o n t i n u a t i o n s

is given in S t r a c h e y

t i n u a t i o n s is given in f i g w h i c h are c o n t i n u a t i o n s

4.

The d e f i n i t i o n by con-

?4.

(The use of braces to b r a c k e t arguments

is adopted for the b e n e f i t of the reader.)

Since there are no c o m b i n a t o r s to be explained in this definition, i n t u i t i v e e x p l a n a t i o n is offered.

this style of d e f i n i t i o n is, however, carefully

no

The reader w h o is u n f a m i l i a r with advised to study this d e f i n i t i o n

(possibly w i t h the aid of an example)

to be sure he has

grasped the rather b a c k - t o - f r o n t c o n s t r u c t i o n of denotations. types of these semantic functions are:

c-p:

P

~

T

c-c:

C

~

(Env

~

(T ~

T))

a-nsl:

Ns ~ Nat

~

(Env

~

(T ~

T))

c-8:

S

~

(Env

~

(T ~

T))

(assumed)

The

291

c-p()= let env 0 = [id~c-l(id, s-b(cp))(enVO){I}

I is-cont(id, s-b(cp))]

c-c(cp) (enVo){I }

c-c6<nsl>)

=

c-nsl(nsl, 1)

c-nsl(nsl,i) (env) {c}= i
c-g()(env){c}

=

c-el(<el>) (env){c}

env(id)

=

cOel-sem(el)

e-l(id, nsl)(env){e}= is-dcont(id, nsl) ~ a-nsl(nsl,ind(id, nsl))(env){c} T

~ (l#t i = ind(ido,nsl) c-1 (id, s-bOs-bOns 1 (i)) (env) {c-ns I (nsl,i+1) (env) {c} } )

fig 4: Definition using continuations

292

G

(Env ~

(T ~ T))

a-el:

EL

(Env ~

(T ~ T)J

e-l:

I d N8 •

(Env ~

(T ~ T))

e-g:

6. E Q U I V A L E N C E

OF THE TWO D E F I N I T I O N S

Sections 4 and 5 have both p r o v i d e d mappings

from p r o g r a m s to functions

(Z~Z) : the aim of this section is to show that the d e f i n i t i o n s are eq u i v a l e n t in the sense that they a s s o c i a t e the same t r a n s f o r m a t i o n w i t h any w e l l - f o r m e d program.

It is p o s s i b l e to d i s c e r n three important

d i f f e r e n c e s b e t w e e n the exit and c o n t i n u a t i o n definitions:

(i)

The c o n t i n u a t i o n d e f i n i t i o n associates w i t h each label identifier

a denotation execution

(i.e. continuation)

w h i c h reflects the effect of s t a r t i n g

at that label and c o n t i n u i n g to the end of the entire pro-

gram. On the other hand,

the exit d e f i n i t i o n p r o v i d e s

(see p o i n t

(ii))

d i f f e r e n t d e n o t a t i o n s for label identifiers at each n e s t e d c o m p o u n d statement:

in each case the d e n o t a t i o n c a p t u r e s the m e a n i n g of execu-

tion f r o m any contained label to the end of the current c o m p o u n d statement.

(ii)

W h e r e a s the c o n t i n u a t i o n d e f i n i t i o n passes the d e n o t a t i o n s of

label identifiers to semantic functions e x p l i c i t l y in the environment, the m e a n i n g of labels (an E) in exit d e f i n i t i o n s is used combinator)

(iii)

(by the tixe

at the level of the c o n t a i n i n g c o m p o u n d statement.

The mode of g e n e r a t i o n of the r e s p e c t i v e d e n o t a t i o n s

a p p r o a c h e s differs:

in the two

in the e x i t - s t y l e the d e n o t a t i o n of a label is

d e r i v e d by starting at that label and "composing" s e m i c o l o n combinator);

forwards

(via the

c o n t i n u a t i o n s are b u i l t up from the final trans-

f o r m a t i o n c o m p o s i n g backwards.

The proof style adopted b e l o w is to show a sequence (each with d i f f e r e n t p r e f i x e s

for the f u n c t i o n names)

each is e q u i v a l e n t to its predecessor.

of d e f i n i t i o n s and show that

Since the p o i n t of d e p a r t u r e

is the "c-" d e f i n i t i o n of section 5 and the last step shows the equivalence of the "f-" d e f i n i t i o n to the

(expanded form of the)

"x-" de-

f i n i t i o n of section 4 a c o m p l e t e p r o o f of e q u i v a l e n c e is given. A good o v e r v i e w of the r e a s o n i n g can be o b t a i n e d by u n d e r s t a n d i n g the interm e d i a t e d e f i n i t i o n s w i t h o u t f o l l o w i n g the details of the individual

293

equivalence proofs.

The first step in a sense,

(i.e. the "d-" definition)

is the second

to difference

("e-")

is purely preparatory,

as,

although this relates specifically

(i)° The step to the "f-" definition completes the reso-

lution of differences

(i) and (ii). The final step from the "f-" to

the "x-" functions resolves difference

(iii).

The first step in our equivalence is trivial. Looking at the "c-" functions,

it is obvious that e-c and c-l are both special cases of a

more general function which takes an optional identifier as its first argument.

d-l:

[Id] Ns ~ ~ (Env ~ (T ~ T))

Since a combination of these two tasks has been employed in the "x-" definition the difference must be resolved somewhere and early resolution will shorten some of the inductive arguments to be used below. In fact the definition given in fig 5 could have been presented in section 5: equivalence with that actually given follows from:

is-cont(id, nsl)

~

d-l(NIL, nsl)

c-c( <nsl>)

=

d-l(id, nsl) = c-l(id, nsl)

d-c(<nsl>)=d-l(NIL,nsl)

d-l(ido, nsl)(env){a}= ido=NIL

d-nsl(nsl, 1) (env) {c}

i8-dcont(ido, ns1)~

d-nsl(nsl, ind(ido, nsl) ) (env) {c}

T

(let i = ind(ido, nsl) d- l (ido , s-bOs-b Onsl( i) ) (env) {d-nsl(nsl, i+ l) (env) {c}i )

d-p,d-nsl, d-g~d-el:

models of respective

"c-" functions

fig 5: Definition using continuations with merge of c-c and c-1.

294

The next step in the proof also changes v e r y little. The types of the "e-" functions are the same as those of the "d-" functions. The d i f f e r ence is that some elements of the e n v i r o n m e n t denotations)

(i.e. c o n t a i n e d label

are r e c o m p u t e d at each compound statement level. W h a t has

to be proved is that the r e c o m p u t e d values are exactly the same as those already stored

(the u s e f u l n e s s of

this

step

will b e c o m e appa-

rent later). A good intuitive c o n f i r m a t i o n of this claim can be obtained by v i e w i n g the "e-" functions as a m a c r o - e x p a n s i o n and observing that the c o n t i n u a t i o n a r g u m e n t of e-cp(NIL,<nsl>) w i t h that used to generate the d e n o t a t i o n s

is ~dentical

(in env 0 of d-p)

of all

labels contained in nsl.

P r o c e e d i n g m o r e formally,

from the s u b s t i t u t i v i t y of equal values it

is obvious that:

(is-cont(id, nsl)

~

env(id)=d-l(id,nsl)(env){c))

&

(ido=NIL v is-cont(ido, nsl)) d- l (ido,nsl ) (env+[ id-~-l(id, nsl) (env) { c} lis-cont( id, nsl ) ]){c} =

d-l(ido, nsl)(env){a}

It is now n e c e s s a r y to show that for all

d-l(ido, nsl) (env){a} it is true that:

is-cont(id, nsl)

~

env(id)

= d-l(id, nsl)(env){c}

O b s e r v e that this is true for the r e f e r e n c e to d-1 from d-p.

For re-

c u r s i v e calls of d-1 consider:

id n such that is-cont(idn,nsl)

& li8-dcont(idn, nSZ)

its d e n o t a t i o n is given by:

env(id n)

=

d-l(idn, S-b 0 s-bOnsl(~n))(env){d-nsl(nsl,in+1)(env){c}}

w h e r e i n = ind(idn, nSl) but for r e c u r s i v e r e f e r e n c e s to d-l in d-nsl(nsl,in)(env){c}

295

d-nsl(nsl, i )(env){c} = d-s(s-b nsl(i ))(env){d-nsl(nsl,i +1)(env){c}} _n o n = d-l(NIL, s-bas-b nsl(in))(env){d-nsl(nsl, in+1)(env){c}} sO for:

is-cont(idn, s-bOs-bOnsl(in )) the required p r o p e r t y still

holds since the c o n t i n u a t i o n s match.

This c o n c l u d e s the a r g u m e n t and the d e f i n i t i o n in fig 6 can be seen to be e q u i v a l e n t to the "d-" functions b e c a u s e e-cp is introduced just to "recompute"

some label d e n o t a t i o n s ;

other functions are changed

a c c o r d i n g l y i n c l u d i n g the fact that ~-p need no longer g e n e r a t e an environment:

e-cp

:

[Id] C ~ (Env ~ (T ~ T))

The n e x t stage of the proof is the m o s t interesting.

B e f o r e coming to

the "f-" functions a u s e f u l lemma on c o n t i n u a t i o n s will be given. Int u i t i v e l y this lemma states that in order to achieve the same effect as c o m p o s i n g some f u n c t i o n w i t h the d e n o t a t i o n of a statement,

that

f u n c t i o n m u s t be c o m p o s e d w i t h both the c o n t i n a t i o n and each label den o t a t i o n u s e d in d e r i v i n g the g i v e n denotation.

296

e-p()

e-c(cp)

=

=

e-c(cp) ([ ]) {I}

e-cp(NIL, cp)

e-cp(ido, <nsl>) (env) {c}= le t env' = env+[id~e-l(id, n~l)(env'){c}lis-cont(id, nsl)] e-l(ido,nsl) (env') {c}

e-l(ido,nsl)(env){c}= ido=NIL is-dcont(ido, nsl) T

e-ns

l (ns l, I ) (env) { a }

e-nsICnsl, indCido, nsl) ) (env) {c} (let i = ind(ido, nsl) e-cp(ido,s-bOnsl(i)) (env){e-nsl(nsl,i+l) (env){c}} )

e-nsl, e-g,e-el: models of respective "c-" functions

fig 6: Definition using continuations recomputed at each compound statement

297

Lemma

I

define: show for: that:

me(c, env) = [id~cOenv(~d) lidEdomenv] et is e-s(s),e-nsl(nsl,i),e-iCido,n~l) or e-cp(ido,cp) c20et(env)~el } = et(me(c2, env)){c20Cl }

Proof:

The argument consider

is by i n d u c t i o n

statements

o n the s t r u c t u r e

of the

text,

as a basis

of G and E:

0 0 a 2 e-g()(env){c} = c~ env(id) e-g()(me(c2,env)){c 2 c 1} = me(e2~env)(id) = e20env(id) a2Oe-el~<el>)(env){cl } = c20clOel-sem(el) 0 0 e-elC<el>)(me(c2,env)){a20Cl } = a 2 c I el-sem(el) next

in the basis

a C, here basis,

consider

a subsidiary

consider

elements

inductive

of

proof

Ns ~ w h e r e no e l e m e n t c o n t a i n s (on lennsl-i) is made. For the

i>lennsl:

c20e-nsl(nsl, i)(env)~01 } = c20c 1 e-nsl(nsl,i)(me(c2, env)){c20Cl } = a20c I for the i n d u c t i v e

step

i
0 c 2 e-nsl(nsl,i)(env){e I} = c20e-s(s-b(nsl(i))) (env){e-nsl(nsl,i+1)(env){Cl}

}

= e-s (s-b (ns l (i)) ) (me (c2, env) ) {c20e-ns 1 (ns l,~+1) (env) { c I } } 0 = e-s (8-b (nsl (~)) ) (me (c2, env) ) .e-ns 1 (ns l,i+1) (me (e2, env) ) {c 2 c I ~ e-nsl(nsl, i)(me(c2, env)){c20cl } } = e-s(s-b(nsl(i)))(me(c2, env)){e-nsl(nsl,i+l)(me( For e l e m e n t s the results

of for

l.H.onS l.H.onN8 •

c 2, envJ{c2Oel}}

N8 ~ w h e r e no e l e m e n t c o n t a i n s a c o m p o u n d statement, e-l(ido, nsl) and e-cp(idojcp) are i m m e d i a t e from the

above.

For the i n d u c t i v e the c o n s t r u c t i o n

step,

the only a d d i t i o n a l

of e l e m e n t s

of C, thus:

case

to be c o n s i d e r e d

is

~8

0 0 c 2 e - c ( c p ) ( e n v ) { c I} = c 2 e - c p C s - b ( c P ) J ( e n v ) { c I} 0 e - c ( c p ) ( m e ( e 2 , e n v ) ) { c 2 c 1} = e-cp ~ - b ( c p ) ) ( m e ( c 2 , e n v ) ) { c 2 0 c l }

w h i c h are equal by i n d u c t i o n hypothesis.

This c o n c l u d e s the proof of Lemma Z.

Lemma I will now be used to justify change from p a s s i n g in label denotations in e n v i r o n m e n t s

to c o m p o s i n g them w i t h the revised m e a n i n g of

the basic statement list. The r e v i s i o n to the m e a n i n g of a statement list changes

it to type E and makes any goto s t a t e m e n t cause a label

to be returned as the second c o m p o n e n t of the result. The c o m p o s i t i o n of the label d e n o t a t i o n s is now

(recursively)

d i c a t i o n of a b n o r m a l exit is present.

applied only if this in-

I n t u i t i v e l y the proof w h i c h fol-

lows shows that any e n v i r o n m e n t is e q u i v a l e n t to a c o m p o s i t i o n of a test and a c o n s t a n t environment, and any c o n t i n u a t i o n is e q u i v a l e n t to a c o m p o s i t i o n of a test and a c o n s t a n t function. Since both of these tests are the same,

lemma I can be used to factor out the test.

P r o c e e d i n g m o r e formally,

it is o b s e r v e d that though the used types

of the "e-" functions are:

e-e:

0 ~

((Id ~ T) ~

(T ~ T))

they are p e r f e c t l y general in that they also fit:

e-Q:

e

~

((Id ~ (S ~ ~)) ~ ((~ ~ ~) ~

(S ~ ~)))

Writing:

xe(nsl)

= [id ~ X ~ . < ~ , i d > J i s - c o n t ( i d , nsl) ]

xt(env, c) : ~ , a . ( a = N I L ~ c ( s ) , T ~ e n v ( a ) ( s ) )

it is immediate that:

d o m e n v = { i d j i s - c o n t ( i d , nsl)} [id~xt(env, c ) O x e ( n s l ) l i d £ d o m e n v ]

and: 0 xt(enV, c) I ~ . < ~ , N I L >

= c

= env

299

But then:

e-l(ido, nsl) (env'){c} = e-l(ido, nsl) ([id~xt(env ',e)Oxe(nsl) lidEdomenv']) {xt (env ',c) Oks. <~, NIL> } = xt(env ~ c)Oe-l(ido, nsl) (xe (nsl)) (ke. <e, NIL>} SO :

e-cp (ido, ) (env) {c} = (let env '=e~+ [id~ (ks, a. (a=NI~a (~), T~env '(a) (a) J ) 0 e-l (id , ns l) (xe (ns l) ) {ks. <~, NIL>} Iis-cont (id, ns l) ] (ks, a. (a=NIL-~ (s), T~env' (a) (s)) ) 0 e-l( ido, nsl) (xe (nsl) ) {hs. <s, NIL> }) = (let e=[id~e-l(id, nsl) (xe(nsl)){ls.}lis-cont(id, nsl) ] let r(s,a) = (aEdome ~ rOe(a) (s),T~env(a) (~)) roe -1 (ido, ns l) (xe (ns l) ) (kg. } ) Strictly,

e-p:

the w h o l e d e f i n i t i o n

P -~ (Z -~ T [Id] )

(and this was w h y p l a c e d by 7.~). be shown

has now become:

it was n e c e s s a r y

But,

as w i t h

labels

program

level

element

of the r e s u l t m u s t b e NIL.

B u t all env

arguments

cause the d e f i n i t i o n stant f u n c t i o n s Furthermore,

only considers

can be omitted.

This results

in s e c t i o n 4, it can

programs

denotations

well-formed

into the semantic

s i n c e the e n v i r o n m e n t

that T could be re-

can be returned.

for w e l l - f o r m e d

n o w give c o n s t a n t

can be m o v e d

above

the exit d e f i n i t i o n

that o n l y n o n - c o n t a i n e d it can be shown

to o b s e r v e

argument

Thus

at the

that the second

for labels!

programs

these con-

definition

of goto.

is n o w u s e d nowhere,

in the d e f i n i t i o n

Be-

in fig

7.

it

300

f-p()

f-c(cp)

= f-c(cp){la.<~,NIL>}

= f-cp(NIL, c p)

f-cp(ido,<nsl>){c}= let e = [id~f-l(id, n s l ) { l ~ . < ~ , N I L > } l i s - c o n t ( i d , 0 = (aCdome~r e ( a ) ( s ) , T ~ X c . < s , a > )

nsl)]

let r(~,a)

rOf-l(ido,nsl){hs.<s,

NI__kL>}

f-l(ido,nsl){c}= ido=NIL

~ f-nsl(nsl, 1){c}

is-dcont(ido,nsl)

~ f-nsl(nsl, ind(ido, nsl)){c}

T

~

(let i = ind(ido, nsl) f-cp(ido, s-bOnsl(i) ) {f-nsl(nsl, i+l) {c}} J

f-nsl(nslji){c} = i~lennsl

~

f-s(s-bOnsl(i)){f-nsl(nsl,

T

~

e

f-g(){c}

f-el(<el>){c}

fig

=

i+l){c}}

Xs.

=

cOel-sem(eIJ

?: Definition using

(E) continuations

The "f-" functions have the types: f-p:

P

~ E

f-c:

C

~ (E "~ E)

f-cp:

[Id] C

~ (E -~ E)

e:

Id

~ E

without environments.

301

r:

~ [Id]

f-l:

[Id] Ns ~ ~

~ E

f-nsl:

Ns • N a t

~ (E ~ EJ

f-s:

S

~

(E ~ E)

(assumed)

(E ~ E)

This definition presents one in which the earlier differences

(i) and

(ii) have been eliminated and which only requires the equivalence of

the alternative directions

for computing denotations to be established

to complete the equivalence proof to the "x-" functions of section 4.

The approach to this last difference is similar to that taken at the previous stage. Firstly a lenhma is introduced which shows that the "f-" functions are equivalent to a composition of a test and the corresponding

"x-" function. Whereas in the previous stage the test was

a simulation of the "tize" combinator,

this stage is simulating the

".," combinator. Applying this lemma generates a set of functions could be written out as "g-" functions)

(which

which pass the same constant

contlnuation" of lo. to all functions. Once again this constant can be dropped and written directly in the two places where the argument had previously been used. We then have precisely the expanded form of the "x-" functions from section 4. Formally,

the lemma is

define:

t(c) = la, a . ( a = N I L

show for:

ft(xt) is f - s ( x - s ) , f - n s l ( x - n s l ) t(c)Oxt(s) = ft(s){c}

that:

the proof

(not given here)

~ c ( ~ ) , T ~ <s,a>)

or f - l ( x - 1 )

is by a similar induction to that of Lemma

I.

Using Lemma II:

f-nsl(nsl, i){c}= i<_lennsl ~ t ( f - n s l ( n s l , i + l ) ~ c } ) O x - s ( s - b O n s l ( i ) T

~ c

respectively

)

302

and:

f-l(ido,nsl) {c}= . . .

T ~ (let i = ind(ido,nsl) t(f-nsl(nsl, i+l) {o})Ox-cp(ido, s-bOnsl(i) ) ) r e w r i t i n g the second case of f-nsl as:

Ic. and the d e f i n i t i o n of f-el as

lq. <el-sere(el) (q ) ,NIL> the c o n t i n u a t i o n a r g u m e n t s to all functions can be d r o p p e d and the "x-" functions remain.

7. D I S C U S S I O N

Two d i f f e r e n t d e f i n i t i o n s of a l a n g u a g e have b e e n g i v e n and proved equivalent.

It is i m p o r t a n t to realize that this is a limited p r o o f in

the sense that n o t h i n g has b e e n e s t a b l i s h e d about the p o w e r of the two mechanisms

in general.

In fact c o n t i n u a t i o n s can b e stored and p a s s e d

in a way w h i c h cannot be simulated by exit. Thus, c o - r o u t i n e s or like features can be defined u s i n g c o n t i n u a t i o n s but not exits

(see Rey-

nolds 74). However, b o t h a p p r o a c h e s have b e e n used to d e f i n e m a j o r prog r a m m i n g languages

(cf. Mosses 74, Beki6 74, Henhapl 78) and there is

e x p e r i e n c e from the w o r k on a b s t r a c t i n t e r p r e t e r d e f i n i t i o n s to argue that w h e r e a m o r e p o w e r f u l c o n s t r u c t is not necessary,

its use should

be avoided. The c h o i c e of

w h i c h t e c h n i q u e is m o s t a p p r o p r i a t e m i g h t well d e p e n d

on the intended use of a definition.

For general c l a r i t y it could be

that the a b i l i t y of the exit c o m b i n a t o r s to hide the effect of a goto in m o s t parts of a l a n g u a g e d e f i n i t i o n is valuable.

On the other hand,

proofs a b o u t the m e a n i n g of p r o g r a m s will anyway have to expose the c o m b i n a t o r s and a c o n t i n u a t i o n d e f i n i t i o n may be m o r e d i r e c t l y usable. E v e n h e r e there is one i m p o r t a n t a d v a n t a g e of the exit a p p r o a c h and

303

that is the ability to localize the effect of goto statements within the syntactic unit containing the goto and the label. Thus in:

begin

begin

begin

9oto l ,

end~

l:

.°.

end

end the second nested block will have a denotation of type:

-~ ~

NIL

This closing-off of the semantic effects of goto cannot be simulated with continuations.

Both the Oxford and Vienna groups have made experiments with using definitions to provide a starting point for systematic piler development

(justified)

com-

(see Milne 76, Jones 76a). It is in this area that

a more meaningful comparison of continuations and exits should be sought.

Hopefully the proof in section 6 has been presented in an intuitively

3O4

clear style. For more interesting approaches to such proofs see Reynolds 74, Reynolds 75.

ACKNOWLEDGEMENTS An earlier draft of this paper was submitted to, and eventually accepted by the IBM Journal of Research and Development.

Two of the referees

provided very valuable comments for which the author would like to express his gratitude.

(The paper was subsequently withdrawn with the ar-

greement of the editor of that journal in order to place it in the current volume.)

A FORMAL DEFINITION OF ALGOL 60 AS DESCRIBED IN THE 1975 MODIFIED REPORT

Wolfgang Henhapl & Cliff B.Jone8

Abs tract: This paper provides a formal definition of a version of the ALGOL 60 programming language.

In particular

the definition uses the denotational approach and the meta-language presented in this volume

(-- known with=

in the Vienna Laboratory as "META-IV"). As well as ex = emplifying the meta-language,

(yet) another definition

of ALGOL 60 is justified by the recent revision of the language which resolved most of the open points in the earlier "Revised Report".

CONTENTS

0.

Introduction

307

i.

Abstract

310

syntax

i.i Definitions 1.2 Translator 2.

310 notes

312

Context Conditions

313

2.1 "is-wf" Rules

314

2.2 "tp" Determining

Rules

318

2.3 Auxiliary Functions

319

3.

Semantic Objects

319

4.

Meaning Functions

320

4.1 Functions

320

from Object Language

4.2 Auxiliary Functions

334-336

307

0. I N T R O D U C T I O N

For many years the official description of ALGOL 60 has been the "Revised Report"

(Naur 65). Not only the language, but also its extreme-

ly precise description have been seen as a reference point. There were, however,

a number of known unresolved problems and most of these have

been eliminated by the recent modifications given in De Morgan 75. A number of formal definitions exist for the language of the revised report: this paper presents a denotational definition of the language as understood from the modified report

(MAR).

Before making some introductory remarks on the definition, will be made about tke language itself

three points

(as in De Morgan 75). Firstly

the modifications have followed the earlier "ECMA subset" by making the language

(almost)

now be specified,

statically typed. Although all parameters must

there is still no way of fixing the dimensions of ar-

ray parameters nor the required parameter types of procedure or function parameters

(cf. ALGOL 68). In connection with this it could be

observed that the parameter matching rules of section 4.7.5.5 are somewhat difficult.

In particular the definition given below assumes

that, for "bE name" passing of arithmetic expressions,

the types must

match exactly~

The third observation is simply one of surprise. The decision to restrict the control variable of a to be a
identifier>

(i.e. not a subscripted variable)

may or may not be wise:

but the argument that can now be defined by expansion within ALGOL is surely dangerous.

The definition given here would have

had no difficulty treating the more general case because the concept of location has anyway to be introduced for other purposes. TWO of the major points resolved by the modifications are the meaning of "own" variables and the provision of a basic set of input-output functions:

particular attention has been given to these points in the

formal definition below.

In fact, the treatment of own given here is

more detailed than that for PL/I static variables

in Walk

than perform name changes and generate dummy declarations

69. Rather in the outer-

most block, an extra environment component is used here to retain a mapping from (additional)

unique names to their locations. This "Own-

env" is used in generating the denotations for own variables for insertion in the local "Env". The input-output functions are defined to change the "Channel" components of the state (Z).

308

M u c h of the d e f i n i t i o n w h i c h follows should be easy to read after a study of the example given in Jones m i l a r to that g i v e n there

?Sa. The t r e a t m e n t of goto is si-

(for d i s c u s s i o n see Jones ZS) except that

the use of the "tixe" c o m b i n a t o r h a p b e e n h e l d here to a minimum. stead of the use in i-block,

In-

an a r g u m e n t can be m a d e for l o c a l i z i n g

the effects of goto at the level of comp-stmt,

cond-stmt and 8tmt. In

a v e r s i o n w h i c h used "tixe" at all three levels it was found advantageous to m e r g e the "cue" and "i" functions

(cf. Jones 78b).

As has b e e n d i s c u s s e d e l s e w h e r e in this volume,

the d e f i n i t i o n of ar-

b i t r a r y order of e v a l u a t i o n has not b e e n addressed: had it been, one would,

for example, have to show that the elements of an e x p r e s s i o n

can be e v a l u a t e d in any order.

W i t h the aid of the l±st of a b b r e v i a t i o n s given at the end of this introduction,

the a b s t r a c t syntax and c o n t e x t c o n d i t i o n s should be straight

forward. N o t i c e that, a l t h o u g h the a b s t r a c t syntax itself is a "con-

text-free" p r o d u c t i o n system, c o n t e x t d e p e n d a n t typing name)

is used and secured by the context conditions.

v a r i a b l e s are,

(e.g. A r r a y -

(Notice b y - v a l u e

in fact, n o n - b y - n a m e - i.e. b y - v a l u e includes n o n - p a r a -

meters). The semantic objects are the key to the definition. components, location

States c o n t a i n two

one of w h i c h stores scalar values for each c u r r e n t scalar

(the d i v i s i o n to the sub-types of Sc-loc is not necessary,

is only made to fit the i m p l e m e n t a t i o n viewpoint),

it

the other of w h i c h

c o n t a i n s an a b s t r a c t i o n of the objects w h i c h can be a c c e s s e d by the i n p u t - o u t p u t statements.

State t r a n s f o r m a t i o n s are of the type r e q u i r e d

by the "exit treatment" of goto. The c o m p o s i t e objects Stmt-env and Expr-enV are i n t r o d u c e d solely as abbreviations;

Own-env has b e e n m e n t i o n e d above; the real i n t e r e s t

lies in the d e n o t a t i o n s w h i c h can be stored in Env. Type-dens are obv i o u s l y scalar locations.

A f u n c t i o n p r o c e d u r e w h i c h is a c t i v a t e d sets

up a value to be r e t u r n e d by a s s i g n i n g to the Atv-proc-id:

again a

scalar l o c a t i o n is the a p p r o p r i a t e denotation. A r r a y d e n o t a t i o n s the

store

(one-one) m a p p i n g from all p o s s i b l e subscript v a l u e s to scalar lo-

cations;

notice that the c o n s t r a i n t requires that the d o m a i n of an ar-

ray d e n o t a t i o n is "dense". P r o c e d u r e d e n o t a t i o n s are functions which, for given arguments and a c u r r e n t set of activations, y i e l d transformations. N o t i c e that the Act-parm-dene

carry type i n f o r m a t i o n w i t h them

for c h e c k i n g w i t h i n the Proc-den. Switch d e n o t a t i o n s are similar.

SO9

The very general p a r a m e t e r p a s s i n g quires that the By-name-dens

"by name" p e r m i t t e d in A L G O L re-

are rather like p r o c e d u r e denotations.

Because formal p a r a m e t e r names can occur as D e s t i n a t i o n s

for assign-

m e n t s t a t e m e n t s it is also n e c e s s a r y to know w h e t h e r a b y - n a m e param e t e r c a n be e v a l u a t e d to a l o c a t i o n or not

(cf. e-parm-expr,

e-var-

ref, e-vat). F u r t h e r m o r e , the q u e s t i o n w h e t h e r a p a r a m e t e r is to be p a s s e d b y - n a m e or b y - v a l u e is not d e c i d a b l e at the p o i n t of call. Thus all p a r a m e t e r s are passed b y - n a m e and the Proc-den has the task of c r e a t i n g the locations to store b y - v a l u e p a r a m e t e r s

(cf. e-proc-

decl, e-val-parm). The c l a s s e s Loc and Val are a u x i l i a r y and are used only in type clauses.

G i v e n an u n d e r s t a n d i n g of the semantic objects the reader should be able to tackle s e c t i o n 4. R e m e m b e r that for "splitting" rules o n l y a type clause is given.

ACKNOWLEDGEMENT.

R e t u r n i n g the c o m p l i m e n t to Peter Mosses, one of the a u t h o r s w o u l d like to a c k n o w l e d g e that a p a r t of the i n c e n t i v e to w r i t e this defin i t i o n w a s the hope to provide an equally a b s t r a c t but m o r e r e a d a b l e d e f i n i t i o n than that in Mosses 7 ~

ABBREVIATIONS.

Abnormal c o m p o n e n t

constant

operator

actual

declaration

parameter

activation identifier

denotation

procedure

activated arithmetic

designator descriptor

reference

assignment by-name Boolean

destination element

specification statement subscripted

by-value

character compound conditional

environment

scalar

expression function

unlabelled

identifier

value

integer

variable

transformation

310

1. A B S T R A C T

SYNTAX

i.i D e f i n i t i o n s

Program

:: Block

Block

:: 8-dp:Decl-set

Stmt

:: s-lp:Id-set

Unlab-stmt

=

Comp-stmt Dummy-stmt

s-sl:Stmt* 8-sp:Unlab-stmt

I Block I Assign-stmt I Cond-stmt

Comp-stmt

:: Stmt*

Assign-stmt

:: s-lpl:Destin +

Destin

:: s-tg:Left-part

Left-part

=

Atv-proc-id

:: Id

Goto-stmt

:: Expr

s-rp:Expr s-tp:Type

Vat IAtv-proc-id

Dummy-stmt

:: DUMMY

Cond-stmt

:: s-dec:Expr

s-th:Stmt

For-stmt

:: s-cv:Var

s-cvtp:Type

For-list-elem

=

I While-elem

Expr-elem

:: Expr

While-elem

:: s-in:Expr

~-wh:Expr s-st:Expr

Expr-elem

Step-until-elem

:: 8-in:Expr

Proc-stmt

:: (Proc-des I Funct-des)

Proc-des

:: s-pn:Id

Expr

I Goto-stmt 1

I For-stmt I Proc-stmt

s-el:Stmt s-fl:For-list-elem +

s-un:Expr

s-app:Act-parm*

=

Type-const

Type-const

=

Prefix-expr I Infix=expr I Cond-expr Bool-const IArithm-const

Bool-const

:: Bool

Arithm-const

=

Rea.l-const

:: Real

Int-const Var-ref

:: Int :: Vat

Vat

=

Simple-var

Simple-vat

=

Simple-var-bn

Real-const

Simple-var-bn

:: s-nm:Id

Simple-var-bv

:: s-nm:Id

Subset-vat

=

Subscr-var-bn Subscr-var-bv

:: 8-nm:Id :: s-nm:id

s-b:Block

I Step-until-elem

I Var-ref I Label-const

I Int-const

I Subscr-var

Subscr-var-bn

I Simple-var-bv

I Subscr-var-bv

8-88cl:Expr + + s-sscl:Expr

I Switch-des

I Funct-des

311

Label-const

:: Id

Switch-des

:: s-id:Id

Funct-des Act-parm

:: s-nm:Id s-app:Act-parm • :: s-v:Act-parmv s-tp:Specifier

Act-parmv Parm-expr Array-name

= Parm-expr I Array-name I Switch-name I Proc-name I String :: Expr :: Id

Switch-name Proc-name

:: Id :: Id

String

= Char •

Char

= Implementation

Prefix-expr

:: s-opr:Prefix-opr

Prefix-opr

=

8-ssc:Expr

defined set s-op:Expr

REAL,cPLUSIREAL-MINUS

I~-PLus

i INT-~NUS

Infix-expr

:: s-opl:Expr

Infix-opr

=

I

l ~oT

s-opt:Infix-opt

s-op2:Expr

REAL-ADD IREAL-SUB I REAL-MULT I REAL-DIV I I~T-ADD

I INT-SUB I I~-MULT

s-th:Expr

I !~T-DIV

l

Cond-expr

:: s-dec:Expr

Decl Type-decl

= Type-decl I Array-decl I Switch-decl I Proc-decl :: s-id:Id s-oid:[Own-id] s-desc:Type

Array-decl Bound-pair Switch-decl Proc-decl

:: :: :: ::

s-id:Id s-oid:[Own-id] s-lbd:Expr s-ubd:Expr + s-id:Id s-el:Expr s-id:Id

s-el:Expr

s-tp:Type

s-bdl:Bound-pair +

s-tp:(Type I PROC) s-fpl:Id* s-vids:Id-set s-spm:(Id~Specifier) s-body:(Block I Code) Specifier Type-array

= Type I Type-array I Type-proc I PROC I LABEL I STRING I SWITCH :: Type

Type-proc

:: Type

Type Arithm Code

= Arithm I Boon = INT I REAL :: Tr

Tr

see

"semantic objects"

3t2

Own-id Id

infinite set infinite set

Real Int Bool

=

the set of rational numbers w i t h the usual a r i t h m e t i c

=

the set of integers

=

TRUE I FALSE

Standard-proc-name8 Real-funct-names Int-funct-name8 Prod-name8

(embedded in Real)

= Real-funat-names I Int-funct-name8 I Proc-name8 = "ab8" I "sqrt" I ,,sin,, I ,,cos,, I ,,arctan,, I ,,ln. 1 "exp" I "maxreal" I "minreal" I "epsilon" = "iabs"l "sign"J "ent er" I "l ngth"i " ax nt" i = "inchar" I "outchar" I "outstring" I "outterminator"

"stop" i "fault"1 "~nenteger" L "outinteger" I "inreal" I "outreal"

Comment:

The quotes a r o u n d the s t a n d a r d - p r o c e d u r e names indicate the t r a n s l a t e d v e r s i o n of the identifiers.

1.2 T r a n s l a t o r Notes.

A l t h o u g h n e i t h e r the c o n c r e t e syntax of A L G O L 60, nor its t r a n s l a t i o n to objects of the a b s t r a c t form are formally specified,

a number of

points should be b o r n e in mind:

-

C o n c r e t e delimiters,

comments etc. are dropped.

-

W i t h i n expressions, b r a c k e t s and rules of o p e r a t o r p r e c e d e n c e are

used tO c h o o s e the a p p r o p r i a t e tree form of "expr".

-

If the

(concrete)

it in another -

outer

b l o c k was labelled,

the t r a n s l a t o r embeds

(unlabelled) block.

The body of a p r o c e d u r e

(which is not code)

is always a b l o c k in

the a b s t r a c t form; the t r a n s l a t o r generates this b l o c k if it is not p r e s e n t in the c o n c r e t e form. -

The b o d y of a p r o c e d u r e w h i c h is code is t r a n s l a t e d into the appro-

priate state transformation.

313

-

C o n s t a n t s are, similarly,

-

The

outermost

block

t r a n s l a t e d to

(a c r e a t e d one,

(abstract)

if necessary)

values.

contains the

s t a n d a r d functions and procedures: w h e r e these cannot be e x p r e s s e d in A L G O L 60, m e t a - l a n g u a g e d e s c r i p t i o n s of the t r a n s f o r m a t i o n s are given.

-

The b o d y of the a b s t r a c t form of a for s t a t e m e n t is always a block;

if not p r e s e n t in the c o n c r e t e f o r m it is g e n e r a t e d by the translator.

-

The use of one
fiers>

list> to d e f i n e several <array

identi-

is e x p a n d e d by the translator. N o t i c e that this can no t be jus-

tified from MAR and, w i t h s i d e - e f f e c t p r o d u c i n g f u n c t i o n references the b o u n d pair list,

is s t r i c t l y wrong.

2. C O N T E X T CONDITIONS.

A n e n v i r o n m e n t is used to record s t a t i c a l l y k n o w n type information:

Static-env

= Id ~ Specifier

W i t h the e x c e p t i o n of is-wf-program,

all context conditions are,

for

a p h r a s e class 0, of type:

is-wf-@:

%

Static-enV ~ Bool

As well as the s p l i t t i n g

( " r o u t i n g ")

rules, c e r t a i n other obvious

steps have b e e n taken to s h o r t e n the functions given below,

@ :: 81 0 2 ... O n then a rule

(or part thereof)

of the form:

if-wf-g(mk-@(el,g 2 .... ,en),envj is-wf-gl(el,env)

&

i8-wf-g2(@2, env)

& .o.

is-wf-gn(gn, env) w i l l be omitted.

=

e.g.

if

in

314

2.1 is-w f Rules. is-wf-program(mk-program(b ) ) -/* for all type-decl, array-decl '8 within b, their s-¢id is unique */ & (let oads={d]within(d,b)

&

is-array-decl(d) & s-old(d) * NIL}

/* all expressions in 8-bdl of elements of oads are integer constants */) & (let env -- [n~mk-type-proc(INT) In£Int-funct-no~es ] U [~ - t y p e - p r o c ( R E A L ) InEReal-funct-names ] U [n~PROC lnEProc-names ] is-wf-b lock (b,env )) type: Program~Bool

is-wf-b lock (mk-b lock (de Zs,s t l), env) = let labl = /* list of all labels contained in stl without an intervening block */ is-uniquel(labl) & is-disjoint(<elem8 labl, {s-id(d) IdEdcls}>) & (let renv = env\{e-id(d)[d£dcle} let lenv = [s-id(d)~*(cases d: mk-type-decl(,,tp)

~ tp

mk-array-decl(,,tp,)

~ mk-type-array(tp)

mk-swi tch-dec l (, )

~ SWITCH

mk-proc-decl(,PROC,,,,)~ PHOC m k-proc-dec~(, tp,,, ,) ~ mk-type-proc(tp) )

Id£dcls] 0 [lab~LABEL llab6elems labl] let nenv = renv

U lenv

dEdcls ((is-array-decl(d)

~ i8-wf-array-decl(d, renv) ) &

(is-proc-decl(d)

~ is-wf-proc-decl(d, nenv)) &

(is-switch-decl(d) ~ is-wf-switch-decl(d, nenv)) ) & (1
315

i s-w f-as s ign-s tmt (ink-assign-strut (d l, e), env ) = 1
is-wf-goto-stmt(mk-goto-stmt(e) ,env) = expr-tp(e, env) = LABEL

is-wf-cond-stmt(mk-cond-stmt (dec, th, el), env) = expr-tp(dec, env) = BOOL

is-wf-for-stmt (mk-for-stmt( cv , cvtp,fle 1,b ) , env ) = is-simple-vat(or) is-arithm(cvtp)

& is-scalar(cv, env) &

& cvtp=var-tp(cv, env)

is-wf-expr-elem(mk-expr-elem( e ) , env ) = is-ari thm( expr-tp (e, env ) )

is-wf-whi le-elem(mk-whi le-elem( in, wh) , env ) = is-ari thm( expr-tp (in, env )) & is-BOOL (expr-tp (wh, env ) )

is-wf-step-until-elem(mk-step-until-elem(in,

st, un),env) =

is-arithm(expr-tp (in, env) ) & is-arithm(expr-tp(st, env) ) & is-arithm( expr-tp(un, env ))

is-w f-proc-des (mk-proc-des (id, ap l) , env ) -is-PROC(env(id) ) & (l
is-wf-var(v, env)

=

if is-eimple-var(v)

then is-type (env(s-nm(v) ) )

else is-type-array(env(s-nm(v) ) ) & (1<_i<_len s-sscl(v) ~ is-arithm(expr-tp(s-escl(v) (i) ,env) ) )

316

is-wf-simp le-var-bn/bv

former iff refers to by name formal parameter

i

i s-w f -subs cr-var-bn /bv ~

is-wf-label-const(mk-label-const(id),env)

= env(id) = LABEL

is-wf-switch-des (mk-switch-des (id, e), env) = env(id) = SWITCH & i8-ari thm( expr-tp (e , env ) )

is-wf-funct-des(mk-funct-des(id, aplJ,env) = is-type-proc(env(id))

&

(l
is-wf-array-name(mk-array-name(id),env)

= is-type~array(env(id))

i8-wf-switch-neone(mk-switch-name( id) ,env ) = env( id) = SWITCH

is-wf-proc-name(mk-proc-name(id),env)

= is-type-proc(env(id))

is-wf -pre f ix-expr(m~-pref ix-expr( opr , expr) ,enV ) = let tp = expr-tp(expr, env) (cases opt: NOT

~ tp = BOOL

REAL-PLUS, REAL-MINUS ~ tp = REAL INT-PLUS, INT-MINUS

~ tp = INT)

v env(id) = PROC

3t7

is-wf-infix-expr(mk-infix-expr (el, opr , e2) ~ env ) = let tpl = expr-tp(el,env) let tp2 = expr-tp(e2,env) (cases opt: REAL-ADD, REAL-SUB, REAL-MULT ~ (tpl=REAL v tp2=REAL) & is-ari~h( tpl) & is-arith( tp2) REAL-D IV

is-arith(tpl) & is-arith(tp2)

REAL-EXP

is-arith(tpl) & tp2=REAL

REAL-INT-EXP

tpI=REAL & tp2=INT

INT-ADD, INT-SUB, INT-MULT INT-DIV, INT-EXP

tpl=INT & tp2=INT is-arith(tpl) & is-arith(tp2) tpl=BOOL & tp2=BOOL_)

is-wf -cond-expr(mk-cond-exp (b , t, e ), env ) = expr-tp(b, env) = BOOL & (let tpl = expr-tp(t, env) let tp2 = expr-tp(e, env) compat-tps (tpl , tp2) )

is-wf-array-decl(mk-array-decl(,,tp, bdl) ,env) = 1<_i
is-wf-switch-decl(mk-switch-decl.(exIJjenv) 1
=

= LABEL

is-wf-proc-decl(mk-proc-decl(id, tp, fpl,vids, spm, b) ,env) = is-uniquel(fpl)

&

id E elems fpl & vids ~ elem____~sfpl & dom spm = elems fpl & (idEvlds ~ spm( id) E(TypeU {LABEL ~UType-array) ) & is-wf-b lock (b , env+ spm)

318

2~2 tp

Determinin 9 Rules.

expr- tp (expr , env ) = cases expr: BOOL

mk-boo 1-cons t () mk-int-const ()

INT

mk-rea l-const ()

REAL

mk- lab e l-cons t ()

LABEL

mk-var -ref(mk-var (var))

env (s-nm(var) )

mk-funct-des (id, )

s-type (env(id))

mk-swi tch-des ()

LABEL

mk-prefix-expr (opr,) cases opr: INT-PLUS, INT-MINUS

~ INT

REAL-PLUS, REAL-MZNUS

~ REAL

NOT

~ BOOL

mk-in f ix-expr (, opr , ) cases opr" INT-ADD, INT-SUB, INT-MULT, INT-DIV, INT-EXP

~ INT

REAL-ADD, REAL-SUB, REAL-MULT , REAL-DIV, REAL-EXP, REAL-INT-EXP ~ REAL LT, LE, EQ_, NE__,GE_, GT, AND, OR, IMPL., E#U

-" BOOL

mk-cond-expr( , t, e) le__~ttpl : expr-tp(t, env) le_~t tp2 = expr-tp(e, env) tpl = tp2

~ tpl

i8-arith(tpl) & i8-arith(tp2)

~ REAL

var-tp(v, enVs¢ = cases

~:

mk-simple-var(id, )

~ envs (id)

mk-subscr-var( id, , sscl ) ~ s-type (envs (id)

act-parmv-tp

similar to expr-tp

319

2.3 Auxiliary Functions.

compat-tps( tpl , tp2)

=

tpl = tp2 V is-arithm( tpl) & is-arithm( tp2)

type: (Type I LABEL) (Type I LABEL) ~ BOOL

is-scalar(v, env) = ie-type(env(s-nm(v))

v

is-array-type(env(s-nm(v))) & is-subscr-var(¢)

3. S E M A N T I C

OBJECTS. N

Tr

--

=

~ ~ Abn

Storage

=

(R-STG ~ Storage) - - m Sc-loc ~ Sc-val

Sc- lo c

=

Bool-loc I Real-lot I Int-loc

U

(R-CHANS ~ Channels) - - m

are disjoint,

Bool-loc, Real-lot, Int-loc Sc-va I

=

Int I Real I Bool

Channels

=

Int ~ Char s

Abn

=

[Label-den]

Stmt-env

=

(Own-env Env Aid-set)

infinite,

sets

m

Expr-env

=

(Env Aid-set)

Own-env

=

Own-id ~ (Type-den I Array-den)

Env

=

Id ~ Den

Den

=

Type-den IAtv-proc-id-den IArray-den I Proc-den I Label-den

Type-den

=

Se-loc

A tv-proc-id-den

=

Sc-loc

Array-den

=

Int + ~ Sc-lo~

Con~ traint

:

(Bipl6(Int Int)+)(doma loc=rect(ipl))

Pros-den

=

Act-parm-den ~ Aid-set ~ (2 ~ 2 Abn [Sc-val])

Act-parm-den

: : s-v:Den

m m

Switch-den I By-name-den I String

Lab e 1-den

: : Id Aid

Switch-den

=

Aid

8-tp:Specifier

Int Aid-set ~ (2 -~ ~ Abn Label-den)

infinite set

320

By-name-den

=

By-name-loc-den

: : Aid-set -~ (~ -~ ~ Loc)

By-name-loc-den I By-name-ezpr-den

By-name-expr-den :: Aid-set ~ (~ ~ Z Sc-vaZ) Loc

=

Type-den i Array-den

Abn

=

[Label-den]

Val

=

Sc-val i Label-den

Implementation-defined-const

Comment:

= ~4XINT i MINREAL I MAXREAL I EPSILON

The c o n s t a n t s are Sc-vals,

but no c h e c k is m a d e as to w h e t h e r

they are m a c h i n e representable.

4. M E A N I N G F U N C T I O N S

4.1 F u n c t i o n s from O b j e c t L a n g u a g e

i-program(p)(chans)

=

let state s = { R - S T G ~ [ ] , R - C H A N S ~ c h a n s ] let s t a t e f

= i-program1(p)(state

8)

8tatef(R-CHANS) type:

Program

~ (Channels

i-programl (mk-program(b))

~ Channels)

=

le__~town-decls = {dlwithin(d,b) & (i8-type-decl(d)vis-array-decl(d))

&

s-oid(d) • NIL} let oenv: C [8-oid(d)~e-own-type-decl(d) Id£own-decls & is-~jpe-decl(d) ] U [8-oid(d)~e-own-array-decl (d) idEown-decls & i8-array-decl (d) ]); (tixe [RET~I] i__nni-b lock (b,) ); epilogue ({s-id(d) IdEown-decl8 }, oenv) type:

Program

321

e-own-type-dec~(d) = let l:e-type-deal(d); if s-dese(d)=BOOL then assign(FALSE, l) else assign(O,l); return (5) type:

Type-decl ~ Type-den

e-own-array-decl(d) = let l:e-array-decl(d,<[~,~}>); i_~ s-tp(d)=BO0~ then for all scl6rn~l d_~oassign(FALS____~E,scl) else for all scl£rngl d_~oassign(O, scl); return (1) type:

Array-decl ~ Array-den

Standard Functions and Transput It is assumed that the translation of the standard cedures

are contained

in the

("fictitious")

tation of their proc-decl follows

functions

outer block.

and pro-

The interpre-

the normal i n t e r p r e t a t i o n

rules

(e-

proc-decl) except in the cases w h e r e the body cannot be expressed in Algol.

In these cases the state transition

explicitly Note:

of the non-Algol part is

listed below.

Referencing

the translated

identifiers we use quotes

"inreal" for the translation of the identifier inreal).

I_nn procedur e stop :

"goto ~" ~ exit(RET)

(e.g.

322

In procedure inchar:



let channel

: contents(env("c~&nnel"));

let str

= env("str")

let int

: e-left-part(mk-simple-var-bn("int"),exenv)

if channel~dom c R-CHANS then error else

(let chan:

(cR-CHANS)(channel);

if chan=

<> then error;

let char:

hdchan

let ind = i f (3i6{l:kenstr})(str(i)=char) then

(li£{l:lenstr))(str(i)=char

&

CVk6{l:i-1})(str(k)~char)) else O; R-CHANS

:= c R-CHANS [channel~tlchan];

assign(ind, int))

In procedure outchar:

<statement>

let channel

: contents(env("channel"));

let str

= env("str")

let int

: contents(env("int"));

let char

= 8tr(int)

i f channel~dom c R - C H A N S R-CHANS

then error;

:= c R-CHANS + [channel~(c R - C H A N S ) ( c h a n n e l ) ^ < c h a r >]

l_nn procedure outterminator: let channel

: contents(env("channel"));

if channel~dom c R - C H A N S R-CHANS



then error;

:= (cR-CHANS)

+

[channel~(c R - C H A N S ) ( c h a n n e l ) ^ < i m p l e m e n t a t i o n defined symbol depending

on the current

state of the channel>]

Procedures "maxint",

"minreal",

which return the appropriate

"maxreal"

and "epsilon" have bodies

Implementation-defined-const.

323

i-block(mk-block(dcls, stIJ, ) = let aidEAid be s.t. aidEcas let nenv : env + ([s-id(d)~oenv(s-oid(d)) IdEdcls & (is-type-decl(d) is-array-decl(d)) & s-oid(d) • N ~ ] U

v

[s-id(d~e-type-decl(d) IdEdcls & is-type-decl(d) & s-old(d) = NIL] U [s-id(d)~e-array-decl (d ~,<env, cas>) IdEdcls & is-array-decl (d) & s-oid(d) = NIL] 0 [s-id (d~e-swi tch-dec l (d, nenv ) IdEdc ls & is-swi tch-dec l (d) ] U [s-idCd~e-proc-decl(d, oenv,nenv) Id£dcls & is-proc-decl(d)] U [la1~k- labe 1-den (lab,aid) Iis-con tnd (lab,s t l) ]); let s~env = alwa~ ~ epi logue( {s-id(d) IdEdcls & (is-type-decl(d) v is-a~re~-deol(d) ) & s-oid(d) = NIL},nenv) in (tixe[mk-label-den(tlab,aid)~ cue-i-stmt-list(tlab,stl, st-env)

I

is-contndlCtlab,stl) ] in for i=I to lenstl d_~oi-unlab-stmt(s-spCstl(i)),stenv) ) type:

Block Stmt-env

epilogue(ids,env) = Set sclocs = {env(id) lidEids & is-sc-loc(env(id))~ union{rng(envCid)JlidEids R-STG type:

U

& is-array-den(env(id))}

:= R-STG\sclocs

Id-set Env

oue-i-stmt-llst(lab,stl,stenv)

=

let i = index.(lab,stl) cue-i-stmt(lab,stl(i),stenv); ~or j = i+I to lenstl d__ooi-unlab-stmt(s-sp(stl(i)),stenv) type:

Id Stmt • Stmt-env

pre:

is-contndl(lab,stl)

324

cue-i-stmt(lab,mk-stmt(labs,sp)jstenv)

=

i_~ ~abElabs then i-unlab-etmt(sp,stenv) else cue-i-unlab-stmt(lab,sp, stenv) type:

Id Stmt Stm.t-env

pre:

is-contnd(lab,mk-stmt(labs,sp))

cue-i-unlab-stmt:

Id Unlab-stmt Stmt-env

cue-l-cond-stmt(lab,mk-cond-stmt(,th, el),stenv) = if is-contnd(lab,th)

then cue-i-etmt(lab,th,etenv)

else pre:

cue-~-stmt(lab,el,stenv) is-contnd(lab,th) v is-con.tnd(lab, el)

cue-i-comp-~tmt(lab,mk-comp-stmt(stl),stenv)

=

cue-i-stmt-liet(lab,etl, stenv)

i-unlab-stmt: Unlab-stmt Stmt-env i-comp-stmt(mk-comp-stmt(etl),stenv)

=

~.or i~I to lenstl d_~oi-unlab-stmt(s-sp(stl(i)),stenv)

i-assign-stmt(mk-assign-stmt(dl, e),<,env, cas>) = let dl:<e-left-part(s-tg(dl(i)),<env,cas>)ll; let v:

e-expr(e,<env, cae>);

for i=I to lendl d_~o (let vc:conv(v,s-tp(dl(i))); aseiEn(va,dl(i)))

e-left-part: Left-part Expr-env ~ Sc-loc

e-atv-proc-id(mk-atv-proc-id(id),<env,>)

= env(id)

325

i-goto-stmt(mk-goto-stmt(e)j<,env,

cas>)

let ld:e-expr(e,<env,cas>); exit(ld)

i-dummy-stmt(t,stenv)

= I

i-cond-stmt(mk-cond-stmt(dec, th, el),stenv) let <,env, cas> = st-env let b:e-expr(dec,<env, cas>); i_~ b then i-unlab-stmt(s-sp(th),stenv) else

i-unlab-stmt(s-sp(el),stenv)

i-for-stmt(mk-for-stmt(cv, cvtp,flel,b),stenv)

=

~Or i=1 t__oolenflel d__ooi-for-list-elem(flel(i),cv, cvtp,b, stenv)

i-for-list-elem:

For-list-elem

Var Type Block Stmt-env

i-expr-elem(mk-expr-elem(e),cv, cvtp,b,etenv) let <,env, cas> = stenv

=

let v:e-expr(e,<env, cas>)~ let vc:conv(v, cvtp)~ let l:e-var(cv,<env, cas>); assign(re, l); i-block(b,stenv)

i-while-elem(mk-while-elem(in,wh)ocv, let <,env~cas> = stenv while (let v:e-expr(in,<env, cas>); let vc:conc(v, cvtp); let l:e-var(cv,<env, cas>); assign(vc,1); let b:e-expr(wh,<env, cas>); b

) d_~o

i-block(b,stenv)

cvtpjb,stenv)

=

326

i-step-until-elem(mk-step-until-elem(in,8t,un),cv,

cvtp~b,stenv)

let <,env,ca8> = 8tenv let exenv = <env, ca8> let vin:e-exprCin, exenv); le% vinc:conv(vin, cvtp); let l:e-var(c~,exenv); assign(vinc, 1); while

(let vst:e-expr(st, exenv); let b:e-expr(untest, exenv); b ) do (i-block(b,stenv); let vcur:contents(1)+vst; let vcurc:conv(vcur, cvtp); assign(vcurc, l))

note:

"unrest"

is a n Expr c o r r e s p o n d i n g

to

~cV-un)xsignvst~O ~

i-proc-stmt(mk-proc-stmt(desJ,<,env,cas>)

=

c~ses des: mk-proc-des(id, apl) (le__~t denl = <e-act-parm(apl(i),env)II~i~lenapl> let f = envCid) f(denl,cas)) T ~ (let v:e-funct-des(d~s,<env, cas>); i)

e-expr: Expr Expr-env ~ Val

e-bool-const(mk-bool-const(b),)

= return(b)

e-real-const(mk-real-const(r),)

= represent(r)

e-int-aonst(mk-int-eonst(i)j)

= test{i)

=

327

e-var-ref(mk-var-ref(v),<envjcas>)

=

i_~ is-simple-var-bv(v) vis-subscr-var-bv(v)vis-by-name-loc-den(env(s-nm(v)) then

(let l:e-var(v,<env,cas>);

else

(let bned = env(s-nm(v))

contents(1)) bned(cas))

e-var:

Var Expr-env

~ Sc-loc

e-simple-var-bn(mk-simple-var-bn(id),<env,

cas>)

=

let bnd = env(id) i_~ is-by-name-loc-den(bnd)

then bnd(cas)

else error

e-simple-var-bv(mk-simple-var-bv(id),<env,>)

e-subscr-var-bn(mk-subscr-var-bn(id, let, esscl:e-subscrl(sscl,<env,

= env(id)

sscl),<env,cas>)

=

cas>);

let bnd = env(id) i_f is-by-name-loc-den(bnd)

then

(let aloc:bnd(cas); i_~ essclEdomaloc

then return

(aloc(esscl)J

else error) else error

e-subscr-var-bv(mk-subscr-var-bv(id, 1,#,t esscl:e-subscrl(s~cl,<env, let a l o c =

env(id)

i_~ esscl£dRmaloc else error

sscl),<env, cas>)

cas>);

then return

(aloc(esscl))

=

328

~-subscrl(sscl, exenv) let esscl:<(let

=

essc:e-expr(sscl(i),exenv);

let i:conv(essc,~NT); i return type:

)11;

(esscl)

Expr • Expr-env ~ Int ~

e-label-const(mk-label-const(id),<env,>)

= return(env(id~

e-switch-des(mk-switch-des(id, ssc),<env, cas>) = let ess:e-expr(ssc,<env, cas>); let i:conv(ess,INT); let f = env(id) let ld:f(i,cas); return

(ld)

e-funct-de~(mk-funct-des(id, apl)~<env, cas>) = let denl = < e - a c t - p a r m ( a p l ( i ) , e n v ) I I < i < l e n a p l > let f

= env(id)

let v:f(denl,cas); return

(v)

e-act-parm(mk-act-parm(e,tp),env) let d = e-act-parmv(e,env) mk-act-parm-den(d,tp) type: A c t - p a r m Env ~ A c t - p a r m - d e n

e-act-parmV:

Act-parmv

Env ~ Den

=

329

e-parm-expr(mk-parm-expr(e),env) is-var-ref(e)

=

then

(let f(dcasJ = e-var-ref(e,<env,dcas>) mk-by-name-loc-den(fJ J else (let f(dcas) = e-expr(e,<env,dcas>) mk-by-name-expr-den(f) )

e-array-name(mk-array-name(id),envJ

= env(id)

e-switch-name(mk-switch-name(id),env)

e-proc-name(mk-proc-name(id),env)

= env(id)

= env(id)

e-string(s, env) = s

e-prefix-expr(mk-prefix-expr(opr, eJ,exenv) = le__~tv:e-expr(e, exenv); apply-prefix-opr(opr, v)

e-infix-expr(mk-infix-expr(el,opr, e2),exenv) = let vl:e-expr(el,exenv); let v2:e-expr(e2, exenvJ; apply-infix-opr(opr, vl,v2)

e-cond-expr(mk-cond-expr(b,t,e),exenv) i_~ e-expr(b, exenv) then e-expr(t, exenv) else e-expr(e, exenv)

=

330

Comment:

The evaluation of infix expressions

is from left to right.

Since IntcReal no explicit conversion from integer to real is necessary in infix and conditional expressions.

represent(r)

=

if -MAXREAL
v

M I N R E A L < r < MAXREAL

v

r=O then return

(an i m p l e m e n t a t i o n defined a p p r o x i m a t i o n of r)

el8e error

type:

Real ~ Real

test(i) = if -MAXINT
type:

Int ~ Int

a p p l y - p r e f i x - o p r ( o p r , v) = OpT:

dase8

NOT REAL~PLUS, REAL-MINUS)

type:

~ returnC~v) INT-PLUS

~ ~,eturn(v)

I N T - M I N U S ~ return(-v)

P r e f i x - o p r Sc-val ~ Sc-val

331

apply-infim-oprCopr, v,w) = cases opr: REAL-ADD

represent(v+w)

REAL-SUB

represent(v-w)

REAL-MULT

represent(v~w)

REAL-DIV

~i_~wcO then fault1 else represent(v~represent(1/w))

REAL-EXP

if v>O then value of the standard function applied on represent(v'value

exp

of the

standard function In applied on w) else fault2 REAL-INT-EXP

~ i~ v=O & w=O then fault$ else (let expn(n) = i_~ n=O then I else represent(expn(n-1)~n.

i_L w~o then expn(w) else represent(1/expn(-w)) INT-ADD

test(v+w)

INT-SUB

test(v-w)

INT-MULT

test(v~w)

INT-DIV

i_f w=O then fault1 else test(v/w)

INT-EXP

~if

w
v w=O

then fault4 else

(let expi(n)

= if n=O then 1 else test(expi(n-1)~v)

return(ezpi(w)) LT

return(v<w)

LE

return(v<w)

E_QQ

return(v=wJ

NE

return(v#w)

GE

re~urn(v>w)

GT

return(v>w)

IMPL

return(v~w)

332

type:

Comment:

EQU

~ return(V~w)

AND

~ return(v&w)

OR

~ return(vvw) Infix-opr Sc-val Sc-val ~ Sc-val

fault1 r e p r e s e n t s

the s t a t e

to the call:

faults N fault('expr

which

corresponds

fault('div by zero'~v) undefined',v)

fault3 ~ fault('expn

undefined',v)

fault4 ~ fault('expi

undefined',w)

e-type-decl(mk-type-decl(,,tp)) type:

transition,

= gen-sc-den(tp)

Type-decl ~ Sc-loc

e-array-decl(mk-array-decl(,,tp, bdl),exenv)

=

let ebds:<(let v:e-expr(s-lbd(bdl(i)),exenv); let lbd:conv(v,INT); let w:e-exprCs-ubd(bdl(i)),exenv); let ubd:conv(w,INT); i~ v>w then error; )ll; let indes = reet(ebds) let array-den:gen-array-den(indes,tp); return(array-den) type: Array-decl Expr-Env ~ Array-den

Comment:

It is a s s u m e d ments

that the g e n e r a t i o n

is erroueous,

rather

of an array w i t h o u t

than the access

ele-

to such an array.

883

e-switch-decl(mk-swgtch-decl(,exl),env)

=

let f(~nd, cas) = (i_~ 1 ~ i n d ~ l e n e x l

then e - e x p r ( e x l ( i ) , < e n v , oas>)

else error )

f type:

Switch-decl

Env ~ S w i t c h - d e n

e-proc-decl(mk-proc-decl(id, let f(denl,cas)

tp,fpl,vids, spm, b),oenv, env) :

=

(if lendenl

# lenfpl

v

(3i£{l: ~enfpl} ) (~is-parm-ok(denl(i) ,spm(fpl(i) ),fpl(i)Evids) ) then error else

(let nenv:env+ ([fpl(i)~s-v(denl(i) ) [l
then

[]

[id~gen-sc-den(tp)]));

cases b: mk-code(tr)

~ tr

T

~ i-block(b,
cas>)

epilogue ({fpl (i) 11
f type:

Proa-decl

Own-shy

Env ~ P r o c - d e n

334

is-parm-ok(, spf, bv) =

iZ

bv then

(spa=spfv is-arithm(spf) & i8-arithm(spa) v is-type-array (spf) & is-type-array (spa) & is-arithm(s-type (spa)) & i8-arithm (s-type (spf))) else ( spa=spry spf=PROC & is-type-proc(spa) v is-type-proc (spf) & is-type-proc (spa) & is-arithm(s-type (spa)) & is-aritk~(s-type(spf) )) type:

Act-parm-den

Specifier

Bool ~ Book

e-val-parm(den, sp, cas) = cases sp: mk-type-array(tp) (let aloc:gen-array-den(domden,

tp);

for essck£domden d__oo (let v:contents(den(essck)); assign(v,aloc(esscl))); return(aloc)) LABEL ~ den(cas) T (let v:(if is-by-name-expr-den(den)

then den(cas)

else (let l:den(cas); contents(1))); let vc:conv(v, sp); let l:gen-sc-den(sp); assign(vc, k); return(k)) type:

Den Specifier Aid-set ~ Den

4.2 A u x i l i a r y F u n c t i o n s

is-contnd: is-contndl: Comment:

Id Stmt ~ Book Id Stmt ~ ~ Bool

Two obvious functions for c h e c k i n g w h e t h e r the g i v e n identifier is c o n t a i n e d in the label part of a

(contained)

w h i c h is not c o n t a i n e d in an intervening block.

statement

335

index:

Id Stmt ~ ~ Nat

Comment:

For

identifiers

finds ment

list also

within(so,o) /~

Comment:

True

True

rect(ipl)

Object

disjoint

= & (l
(Int2) + ~ (Int+)-set l
~ ipl(i)(1)

a s s i g n ( v , lJ = := c R - S T G + [ l ~ v ]

Sc-val

contents(l)

So-lot

=

if c R - S T G ( 1 )

type:

o f o ~/

( O b j e c t - s e t ) • ~ Bool

type :

else

the identifier.

iff sets are p a i r w i s e

= ? then

c R-STG(1)

Sc-loc

~ Sc-val

error

~ ipl(i)(2J

function

of the state,

~ Bool

pre:

type:

this

element

iff no d u p l i c a t e s

~illlenil=lenipl

R-STG

"is-contndl"

O b j e c t • ~ Bool

is-disjoint:

Comment:

contains

i f so is a s u b - p a r t

Object

is-uniquel:

satisfy

such that the i n d e x e d

=

checks

type:

which

the index

33G

conv(v,tp) = if tp=INT then test(rounded value of v) else return(v)

pre:

is-hoof(v) ~ tp=BOOL is-real(v) ~ is-arith(tp)

gen-array-den(indls,tp)

=

let d e n : C i n d l ~ g ~ n - s c - d e n ( t p ) lindlEindls ~ return(den)

type:

Int+-set Type ~ A r r a y - d e n

gen-sc-den(tp)

=

let locE(cases

tp:

BOOL ~ Bool-loc REAL ~ R e a l - l o c INT R-STG

:= c R-STG

~ Int-loc) U [loc~];

return(loc)

type:

Type ~ Sc-loc

be s.t.

locEdom a R-STG

337

SOFTWARE ABSTRACTION PRINCIPLES: TUTORIAL EXAMPLES OF AN OPERATING SYSTEM COMMAND

LANGUAGE SPECIFICATION AND A PL/I-LIKE ON-CONDI= TION LANGUAGE DEFINITION

Dines Bj@rner

Abstract: Four groups of two, either complementing or contrasting abstraction principles are isolated: OPERATIONAL abstraction; CHICAL abstraction; TRANSPARENT,

REPRESENTATIONAL

and

CONFIGURATIONAL versus HIERAR=

STATE-MACHINE- versus REFERENTIALLY

FUNCTIONAL- abstraction;

versus MECHANICAL specification.

and DENOTATIONAL

Tools,

techniques and

examples are presented for, respectively of, each of the eight principles.

CONTENTS i.

2.

Introduction

339

-- On Abstraction Techniques

339

Example I: An Abstract Processor for an Interactive, Operating System Command Language

3.

344

A. Syntactic Domains

344

B. Semantic Domains

346

C. Semantic Domain Consistency Constraints

349

D. Dynamic Command / State Consistency Constraints

350

E. Elaboration Function Types

353

F. Elaboration Function Definitions

354

G. Auxiliary Function Types

357

H. Auxiliary Function Definitions

358

Example II: A PL/I-like On-Condition Language

360

A. Syntactic Domains

360

B. Static Context Condition Function Types

361

C. Auxiliary Text Function Types

361

D. Static

361

(Compile-time)

Domains

E. Static Context Conditions

361

F. Auxiliary Text Functions

364

G. Semantic Domains

364

H. Global State Initialization

365

I. Elaboration Function Types

365

J. Auxiliary Function Types

365

K. Semantic Function Definitions

366

Comment

372

Discussion

372

Acknowledgements

374

339

1. INTRODUCTION

The problem to be solved by the methods outlined in this paper is ultimately the construction of correctly functioning, well-understood, pleasing,

yet complex software.

It is our thesis that one way of achiev-

ing this is to use a systematic software development method which provides a formalized structure for stepwise,

increasingly more detail-

ed arguments of correctness -- a method based on systematically deriving abstractions

into concrete realizations;

i.e. on a-priori,

tic, constructive proofs rather than a-posteriori,

synthe-

analytic proofs.

Thus we see our methodology as starting with an abstract specification of the desired software item. This paper then is concerned with some of the techniques used in achieving such definitions. we cover the problems of mapping abstractions

In [Bj~rner 77c]

into concretizations.

We are there in particular concerned with the systematic derivationand proof techniques.

The objectives of an abstract software specification are basically twofold: that the resulting document serve as the basis from which an implementation take place formally,

and with respect to which correctness

criteria be stated, and a proof given. Hence we require that the specification

(or: meta-)

language be formal. Also:

that the document,

and

it alone, be the specification from which we develop user's reference (and other) manuals~

The objectives of the abstraction principles explicitly expounded in this paper are several: dictory and complete;

That the specifications be precise, non-contra-

that they be short, well-organized and comprehen-

sible; that the described systems be well-conceived, ceptions,

conceptually clean,

relevant notions;

free from mis-con-

lean and with an optimum of semantically

that their properties be well understood,

possesing

desirable properties and with a minimum of ad-hoc ideas. We find [Liskov 75] to give a fine discussion of the above points.

O nnAbstraction Techniques Before going on to exemplify uses of the meta-language

let us first

also summarize the principles used in applying constructs of this language. One thing is the notation:

its syntax & semantics. Another thing is

the intent with which it was to be applied;

its pragmatics. Any notation

can be used against its will, even a good one.

340

If you consider META-IV as an ultra-high-level

programming language,

i.e. one which although it is intended only to specify software actually results in programs which can be considered implementations, beit on a very abstract,

and in most cases not mechanizable,

al-

level, then

which are the programming disciplines around which the meta-language evolved,

and whose application exploits its capabilities

to the fullest?

We consider these to be the pre-dominant abstraction techniques: sentational- & operational- abstraction; cal abstraction; modeling;

repre-

configurational vs. hierarchi-

referential transparency vs. abstract state machine

and mechanical- vs. denotational abstraction.

At each design step and at each specification stage we carefully review the appropriateness

of each abstraction choice:

ing e.g. representationaltional abstractions;

& operational;

its level when consider-

and mechanical- vs. denota-

its mixture or blend of configuration and hierac-

chy, i.e. bottom-up synthetic vs. top-down analytic features; respectively of referential transparency or applicativeness vs. abstract state machine imperativeness;

and finally also its balance of explicitness

vs. implicitness. Before going into a brief characterization of each of the eight abstraction principles,

an outline is first given of the basic parts that make

up our specification document. A rationale is given for their inclusion. The software outputs,

'function'

to be modelled normally accepts inputs, emits

achieves the desired transformations of inputs into outputs

by means of internal data structures, terms of function definitions

and specifies transformations

(procedures, process descriptions,

in

opera-

tions). Our model hence consists of two basically distinct parts: one containing the descriptions of the input/output and internal domains -- subsequently referred to as syntactic-,

respectively semantic domains.

Another part containing a number of elaboration-

(and auxiliary-)

func-

tion definitions which to combinations of input- and semantic- domain objects ascribes their meaning,

in terms of either semantic domain ob-

ject transformations or these latter combined with output domain objects. In the next paragraphs we now treat the abstraction principles individually.

341

By REPRESENTATIONAL ABSTRACTION we understand the specification of objects irrespective of their implementation,

and such that the chosen

abstractions as closely as possible only r e f l e c t

relevant and intrin-

sic properties. Representational

abstraction of classes of objects is here expressed

in terms of so-called abstract

syntax.

Individual

instances of objects

can be abstracted by corresponding expressions of the meta-language. Representational

abstraction is applie d in the definition of both syn-

tactic- and semantic- domains and domain objects.

By OPERATIONAL ABSTRACTION we understand the specification of functions in extension.

That is: we are primarily interested in the properties of

the functions we define,

notably in the properties of that which our

defined functions define

(be they functions themselves),

they Compute; puted,

i.e. in what

less -- if at all -- interested in how results are com-

i.e. not in functions

in extension.

Operational abstrection is here expressed primarily in the form of function definitions. We express these either by a pair of pre- and postconditions on the functions sought, or by a constructive function definition. The former kind are thus usually more implicit, than the latter kind

(of more explicit definitions).

is normally still abstract,

i.e. abstract,

This latter form

in that it usually internally employs ope-

rational abstraction on representationally

abstract objects. Operational

abstraction is used in the definition of the elaboration functions,

as

well as functions of our model auxiliary to these, and to (~8-w~-O) well-~ormednessdicates

context,

'narrowing'

static condition and dynamic constraint-,

pre-

the (~-) domains otherwise defined by abstract syn-

taxes.

By CONFIGURATIONAL ABSTRACTION we understand the step-wise definition and realization of a model, or major model components, which proceeds in a synthetic manner in conceiving and documenting the desired system -- from the bottom-up -- by building layers of abstraction upon more concrete bases. From 'virtual machines':

'physical machines' we create changing raw capabilities

(the illusion of)

into sophisticated con-

cepts. Configurational abstraction composes low-level abstractions rather

'mechanizations')

Configurational

(or

into higher-level abstractions.

abstraction,

in its inner, foundational steps,

ally expresse d in rather concrete representational-

is usu-

and operational

842

forms. In its outer,

so-called

'abstract'

layers, expressional means

are normally tied to those of the procedure, module-, 'abstractions'. nique

and class- like

Configurational abstraction -- as a specification tech-

-- is brought into play whereever uncertainties concerning either

desired functions,

and/or efficient realizability dominate our under-

standing of what system we are in fact aiming at. The resulting design:

its abstraction & implementation can usually,

and

to great advantage however, be hierarchically documented. By HIERARCHICAL ABSTRACTIO N we understand the stepwlse definition of a model which proceeds in conceiving and documenting, fashion -- from the top down -- the desired system

in an analytical (components)

by

decomposing basic overall dominating concepts and transformations

into

constituent ones. Hierarchical abstraction techniques can fully exploit the representational and operational abstraction techniques descussed and elsewhere illustrated in this paper. And hierarchical abstraction is applied where a sufficiently deep understanding of our system has eventually transpired. Configurational abstraction have been used extensively in operating systems designs

[Dijkstra 68; Hansen 73] - Hierarchical abstraction

mostly in e.g. programming language semantics 78] and relational data base

[e.g. Beki{ 74~ Henhapl

(system and query language)

formalization

[Hansal 76, Nilsson 76]. Any one abstraction,

and almost any actual, conventional program al-

gorithm, usually exhibits some mixture of both. Only when the choice between configurational- and hierarchical abstraction has been made as the consequence of a careful study, and only when the resulting documentation

(respectively program code)

appear transparent. down abstract,

is clear, does the specification

The subject of choosing a bottom-up versus a top-

and/or algorithmic design idea programming strategy is,

however, a seriously undeveloped one and we shall unfortunately not contribute much to a clarification in this paper. It is our hope, to return later to a study of their

duality. Step-wise refinement,

though, i.e.

top-down, hierarchical abstraction in program algorithm and data structure design is extensively convered in [Wirth 71,75,76].

343

By a DENOTATIONAL

SPECIFICATION [Scott 71,72; Tennent 75,76; Mosses

75; Milne 76] we understand a definition which ascribes meaning to (composite)

syntactic domain objects by

functionally composing mean-

ings of proper constituent parts. Thus denotational abstraction almost invariably calls for

'homomorphic'

programming

[Burstall 69, Morris 73~

Reynolds 74, ADJ 77], i.e. referential transparency together with syntactic object

'driven' function specifications.

And denotational defi-

nitions achieve their characteristics by employing semantic domain objects of high, struct)

functional order. Thus the meaning of a program

is generally seen as a state transformation function,

transformer,

independent of program

By a MECHANICAL ABSTRACTION

(cona state

(input) data.

(which may hardly be an abstraction at ail~)

we understand a description which assigns meaning to a program struct) by explicitly prescribing computation

(i.e. state-)

(con-

sequences

given input data, thus computing result values. The meaning then becomes the state transition sequence, not the function from begin states to end states. A mechanical definition is said to be so rational)

since its direct realization is immediate

(or to be ope-

(and programmable

in most languages).

Examples We now illustrate some of the abstraction techniques through two examples. The software item to be specified in section 2 is a command language for an operating system -- naturally: strative nature. non-trivial

of hypothetical, illu-

In section 3 we give the denotational

language with PL/I-like On-Conditions.

principles examplified are these: representationalabstraction;

functional,

semantics of a

The abstraction and operational

referentially transparent abstraction in sec-

tion 2, and abstract machine/state programming featuring both local and global states, and local semantic domain objects and almost exclusively:

denotational semantics, whereby the model is

almost invariably forced to be hierarchically

It is, however,

in section 3. Finally,

specified.

an alltogether not un-important aim also to convince

you of the utility of abstractly specifying software in general, -- to take the first choice as an example, professional paper proposals

and

to suggest that future,

for e.g. command- and data base query lan-

guages be formally, hence precisely stated.

344

The p r e s e n t a t i o n s are b o t h a c c o r d i n g to our basic principle: first, and then their n a t i o n a l / n a t u r a l

formulae

language e x p l i c a t i o n i m m e d i a t e -

ly subsequent. No i n t r o d u c t i o n s m o o t h l y

'tricking' you into a subse-

q u e n t f o r m a l i s m -- as if to excuse this latter!

2. EXAMPLE I: A n A b s t r a c t Processor

for an Interactive,

O p e r a t i n g S~ste m C o m m a n d L a n g u a g e

A. S y n t a c t i c D o m a i n s

1

Cmd

=

~n I c~g I Dl

2

In

::

(InputlSourceILink)

3

Id

:

c l cL I cLc i L J

4

C

::

Cid

5

CL

::

6

CLG

::

l

(SoureeIId)

[Id]

Cid

(SourceIId)

[Id]

(LinkIId)

[Id]

aid

(SourceIId)

[Id]

(LinklId)

[Id] [Id]

7

L

::

Id

(LinkIId)

8

LG

::

Id

(LinklId

9

@

::

i0

Dl

::

(InputlId)

[Id]

(InputlId)

Id

(InputlId)

Id

Annotation

1

A job control Command is either a file Input d a t a command, a (partial or complete)

C o m p i l e - l i n k - g o command,

or

(I)

or it is a D e l e t e

file command.

2

An Input command has two parts:

Input,

Source

the d a t a p a r t c o n t a i n i n g either

or Link d a t a itself,

and the part w h i c h I d e n t i f i e s

the file name to ~e given to this data.

3

A C o m p i l e - l i n k - g o command is either a COMPILE,

COMPILE-LINK-GO, 4

a LINK,

a COMPILE-LINK,

a

a LINK-GO or just a GO command.

A COMPILE con~nand has three parts: one part I d e n t i f i e s a Compiler, another either d i r e c t l y c o n t a i n s the Source a text nal

(in the FILE

state component,

text or I d e n t i f i e s such

see below),

and a third, optio-

([]) p a r t I d e n t i f i e s the name to be given to the o b j e c t

(module)

r e s ~ i t i n g from c o m p i l a t i o n and to be o p t i o n a l l y stored in the FILE.

345

A CL@ command a d d i t i o n a l l y has a c o m p o n e n t w h i c h is either the Link d a t a itself or I d e n t i f i e s such a link d a t a file, a c o m p o n e n t w h i c h o p t i o n a l l y I d e n t i f i e s a file name for the linked load

(module) r and

a c o m p o n e n t w h i c h either is the Input d a t a for the e x e c u t i n g load module,

or I d e n t i f i e s such an input d a t a file.

Comments concerning Abstraction Principles

O b s e r v e that we h a v e attempted only to d e s c r i b e s y n t a c t i c a l l y essential c o m p o n e n t s of c o m m a n d s -- and then o n l y abstractly,

i r r e s p e c t i v e of

their p o s s i b l e w r i t t e n forms:

"ALGOL" c o m P i l e "SID" w i t h

link

["FID" ~ "PRINT"]

and e x e c u t e

with

"DID"

Thus we h a v e as far as p o s s i b l e avoided any m e n t i o n of w h a t the c o m m a n d s effect,

i.e. their m e a n i n g . Of course, your p r e v i o u s technical know-

ledge may a l r e a d y h a v e initiated some p e r s o n a l

'feel' for w h a t they

m i g h t stand for. This is b e c a u s e I h a v e chosen s u g g e s t i v e mnemonics. I could as w e l l h a v e c h o s e n x's, y's and z's, and still o b t a i n e d e x a c t l y the same d o m a i n s of m a t h e m a t i c a l objects. O n l y w h e n I deal w i t h concepts for w h i c h there either is no previous

f a m i l i a r i t y or w h i c h may

be a m b i g u o u s l y u n d e r s t o o d w h e n a p p l y i n g only an i n t u i t i v e u n d e r s t a n d ing, i.e. w h e n not r e a d i n g the entire model, o r d i n a r y care in my annotations,

shall I h a v e to take extra-

and in j u d i c i o u s l y k e e p i n g these and

the d i s c u s s i o n w i t h i n p u r e l y syntactic domain,

purely s e m a n t i c domain,

r e s p e c t i v e l y p u r e l y semantic Elaboration f u n c t i o n subject boundaries.

The commands h a v e b e e n r e p r e s e n t a t i o n a l l y abstracted. here about p o s i t i o n a l parameters,

no talk of d e l i m i t e r s or o t h e r syntactic by this a b s t r a c t syntax and Link,

see below)

'sugar'. The objects denoted

(for a d e f i n i t i o n of Id, Cid, Input,

are in fact m a t h e m a t i c a l ,

Source

not c h a r a c t e r s t r i n g s .

We use the same kind of a b s t r a c t syntax d e f i n i t i o n a l c i f y i n g both syntactic and semantic d o m a i n objects, definiens

There is no word

m n e m o n i c k e y w o r d s nor of d e f a u l t such,

f a c i l i t y for speas well as their

logical type e x p r e s s i o n s are used in type d e f i n i t i o n s

Elaboration- and A u x i l i a r y functions.

for

348

The p r e s e n t a t i o n a l structure of this abstract syntax is b a s i c a l l y hierarchical.

B. S e m a n t i c Domains

1

~

::

FILE

2

FILE

=

Id

3

SYS

=

Cid

~

Comp

4

UTIL

=

Uid

~

(Data

Input

5

Data

=

6

Input

=

7

Source

=

SYS ~

UTIL

Data

I QUOT~)

I Source

I Object

Link

I Load

~d~

i ''~

. ° .

8

Object

=

Link

9

Link

=

Id

~

Input ~ (~ ~ (~

~

Load (Id

I Con~t)

i0

Load

=

ii

Output

=

12

Comp

=

Source ~ (Object

13

Cid

=

FORTRA~

Output)

o , .

14

Uid

=

15

Text

=

...

16

Id

=

TOKEN

I ALOOL

I Text)

I COBOL

Annotations

In order to explain the m e a n i n g of our o p e r a t i n g system job c o m m a n d and c o n t r o l language we i n t r o d u c e an a b s t r a c t state space Z. A state, ~£Z, has three components:

a FILE-,

a S Y S t e m programs-,

and a UTILity

object.

2

A FILE o b j e c t is a finite d o m a i n file names)

to Data

(= ...) map from I d e n t i f i e r s

(i.e.

(-sets).

The S Y S t e m object is a ... map from names to the C o m p i l e r s themselves.

(here only:)

Compiler identifier

(Subsequently we m i g h t contem-

plate adding other systems programs to SYS: sort-, copy-, merge-, etc..) T h e UTILity c o m p o n e n t is a ..o map from i d e n t i f i c a t i o n s of Utilities to either Data or lists

(~) of QUOTations

w i s h to think of as c h a r a c t e r s t r i n g s ) .

(objects w h i c h you may

347

5

Besides Input-,

Source- and Link- Da~a (which can be d i r e c t l y in-

serted into the FILE by the c o m m a n d l a n g u a g e user) Object- and

Load c a n be filed

(as the r e s u l t of s u c c e s s f u l l y e x e c u t i n g one of

the C o m m a n d s C, CL, CLG r e s p e c t i v e l y CL, CLG, L, LG).

An Object

(module)

is a map from Link to Load.

(That is: the result

of a c o m p i l a t i o n is to be a n o b j e c t of type Object. The free identifiers of the

(compiled)

Source text h a v e not yet b e e n b o u n d to their

m e a n i n g -- w h i c h a r e to be those of I d e n t i f i e d

filed Data

(names of)

or Constants.)

9

Link is a ... m a p from (free) I d e n t i f i e r s Identifiers

I0 A Load

(of filed Data)

(module)

(of (compiler)

texts)

to

or Constants.

is a f u n c t i o n from Input to

s t a t e transforming func-

t i o n s y i e l d i n g Output.

12 A(ny)

Compiler is a (pure, i.e. not state, ~6Z, dependent)

from Source to the u n i o n

(I) d o m a i n of Object and Text

are to be the result of s u c c e s s f u l tactically,

and o t h e r w i s e erroneous,

function

(-- the former

c o m p i l a t i o n the latter of a syntext

(instead y i e l d i n g diagnos-

tics Text)). 13 S u g g e s t s p o s s i b l e compilers~

14 The UTILity c o m p o n e n t s are h e r e p r i m a r i l y intended to porary r e s u l t s i n / b e t w e e n the C-L-G steps;

clg, compile a n d bind f u n c t i o n d e f i n i t i o n s below.

16 I d e n t i f i e r s are further u n s p e c i f i e d TOKENs.

'store' tem-

for d e t a i l s see the Elab-

348

Comme n t s

on A b s t r a c t i o n

Suggests

or relies

primitive

on a c o n f i g u r a t i v e

components

conjecture

is b u i l t a more

Suggests

goes,

sophisticated.

from the m o r e The user -- we

as far as c o n c e p t u a l

not need to k n o w of its decomposition.

not o n l y a h i e r a r c h i c a l

Comp and Load objects as primitives. highly

abstraction:

-- need t h i n k only of ~, and does,

understanding

8-10,12

Principles

decomposition,

but relies

on

T h e s e are r e p r e s e n t a t i o n a l l y

abstracted.

Discussion

of A b s t r a c t i o n

Choices

Comp and Object. That of Load -Link -- we c o n s i d e r almost trivial. A n t i c i p a t i n g s u b s e q u e n t s e m a n t i c Elaboration f u n c t i o n d e s c r i p t i o n s -The c r u c i a l

abstractions

and to an even

which,

of course,

semantic

are

lesser degree

these:

that of

r e a l l y were d e v e l o p e d

domain definitions

in

'parallel'

-- we h i n g e our m o d e l

with

the above

on the ability

of the

Compiler to produce e x a c t l y a f u n c t i o n of the logical type Object (disr e g a r d i n g here d i a g n o s t i c Texts). W i t h the types we have a s c r i b e d to Object, and in p a r t i c u l a r to Load, it can be shown that the Compiler in fact

is the f u n c t i o n

notational

semantics

denoted

definition,

by an a p p r o p r i a t e ~, of the

mathematical-

Source language.

or de-

~ is to

Sburce text and p r o d u c e a f u n c t i o n w h i c h permits an act of binding. Binding is a f u n c t i o n w h i c h takes an Object m o d u l e and some Link Data and p r o d u c e s some Load module. ~ creates this f u n c t i o n by letting the free I d e n t i f i e r s of the Source text be m a p p a b l e to a v a r i e ty of Constants or FILE Data Identifiers: take the

Example:

fid-i l~ fid-i2 1

Lp.::kn i

I

load-i

fid-inJ

obj-k load-i pid... fid...

6 Object 6 Load 6 Id 6 Id

I

~

idl idl

fid-j l7

LPi "dn

rid-SnJ

lid-j21

load-j end example.

s4g

In fact, we can impose v a r y i n g degrees of easily formalizable, tersely e x p r e s s i b l e c o n s t r a i n t s on Object's

hence

and Link's:

C. S e m a n t i c Doma~in C o n s i s t e n c y c o n s t r a i n t s

Simple, Lax Version:

1.0

.i

is-wf-~(mk-~(f,s,u))= (Yo£rn~ f)

.2

(is-Object(o)

= (Vl1~12

£ dom o)(dom

D (¥11,12

£ dom o)

ll = dom 12))

R e s t r i c t i v e Version:

2.0

.i

is-wf-Z(mk-Z(f,s,u))=

(vo£rn~ f)

.2

(is-Object(o)

.3

((dom

11 = dom l~)

.4

^Crng

ll~Const c dom f)))

.5

^(V16rn~

.6

f)

(is-Link(1)

D

(rn~ l~Const c dom f))

Annotations:

(1.0-1.2 ~ 2.0-2.3)

2.1-2.4

For each Object, o, in fILE

domain

it m u s t be the case that all of its

links have the same domain of

tifiers -- since, naturally,

(free Source

that object,

just one c o m p i l a t i o n of e x a c t l y one Source these free I d e n t i f i e r s to d i f f e r e n t fiLEd

text)

Iden-

o, is the result of text.

(But: b i n d i n g

Data and Constants

should c e r t a i n l y create d i s t i n c t Load modules,

cf. example

above.)

2.4

-- A n d range I d e n t i f i e r s of Object r e s t r i c t i v e version)

Data. 2.5-2.6

-- Similar for fiLEd

m o d u l e Link's

already have b e e n d e f i n e d

Data.

must

(in this

(i.e. fiLEd

350

Comments on Abstraction Principles The domain consistency

(inspection)

functions are operationally ab-

stracted in terms of applicative, referentially transparent expressions exploying quantified predicates,

i.e. staying aloof of order of inspec-

tion~

D. Dynamic Command-State Cpnsistency/Cpnstraint Relations 1 0 1 2

pre- Elab-cmd()= (let mk-~(f,,)

=.~

i__nn

cases cmd:

3

(mk-In(,id)

-~ id N6 d o m f ,

4

mk-Dl(id)

-~ id 6 dom f ,

5

T

-~ p r e - E l a b - c l g ( < c m d , s>))

351

2.0 .I .2 .3

pre- Elab-c lg()= (le__~tmk-2(file, sys,) = s in oase8 o~: (mk-C (k, 8, o)

.4

( (k 6 ,dorasys) (is-IdCs) ~ ( (s 6,,domfile)

.5

((o~nil) mk-CL (k, s, o, l, e)

.8

is-Link (file (l) )

.i0

((e~n,il) mk-CLG (k, s, o, l, e, i)

.14

A

~ e~domfile)), ^ ^

is-Input(file (i) ) ) ) ), mk-L (o, l, e)

( (o E ~ m file) ^ is-Object(file(o)) (is-Id(1) ~ (1 E d_~_~file)

.18

is-Link(file(1))

.19

^ ^ ^

( ~ ( f i le (l) )~Const c dom file) ),

• 20

T

.21

((e#nil) mk-LG(o, l, e, i)

.23

~ (rng l~Constc_domfile))

A

~ (e~do_mmfile))),

(pre- Elab-c Ig (~mk-L (o, l, e ), a>) (is-Id(i) ~ ((i E domfile)

.24

.27

~ (rn~ l~Constcdo__~mfile))

(is,-Id(i) ~ ((i Edomfile)

.17

.26

^ ^

(pre-Elab~-clg(<mk-CL(k,s,o, l,e) , o>)

.15

.25

A

(rng(file (1) )~Const c dom file) ), T

.12

.22

dora file)),

(is-Id(1) ~ ((1Edomfile)

.Ii

.16

D o~

A

(pre-Elab-clg(<mk-C(k,s,o) , ~> )

.9

.13

A

is-Scarce (file (s) ) ) )

.6

.7

A

A A

is-lnput(file(i))))), mk-G(e,i)

((e Edomfile) A is-Load(file(e)) (is-Id(i) D ((i 6,dom file) is-Input (file (i))) ) ) ))

A A

352

Annotation: Successful

Elaboration of commands depend on basically three aspects:

(i) one is checkable without actually applying the functions implied (e.g.: Compile, Link and Go), but depends on the relation between the static command and the dynamic state, 0£Z. known by actually applying the implied ple there are no,

(2) The other can only be

(C,L,G) functions. In this exam-

(0), static context conditions imposable on commands

only, as is e.g. the case with the definition and use of procedure and label)

identifiers

(variable,

in block-structured procedure-oriented

programming languages with a fixed, strong type system, pre-Elab-cmd and pre-Elab-clg deals with

(i). The Auxiliary functions compile and

bind invoked by the Elab-el~ functions takes care of (2). 1.3

The Identifier naming Data to be fiLEd must not already be used, i.e. be 'defined'.

2.5

The fiLEd Source text Identifier must identify a Data object of type Sourae.

2.6

If an identifier,

o, is specified

(for the thus implied filing

of the Object module to result from Compilation)

then o must

not already be defined.

. . °

2.10,19 If only C.1

(not C.2)

is specified,

then this is the last

'time'/opportunity to 'catch' the equivalent of C.2.4. (Notice that we have not checked Input Link Data in D.I.3!)

Comments on Abstraction Principles Again the functions are operational abstractly specified.

The structure

of the function definition follows that of the abstract syntax definition of

(primarily)

Commands and (secondarily)

Z.

353

E. E l a b o r a t i o n

Function

Types N

N

1

ty,~,,e: E l a b - c m d :

Cmd ~

(~ ~ ~)

2

Elab-clg:

Clg ~

(Z ~ ~)

Annot a t i o n :

G iven a command semantics, states

the

Elaborate-command

a state t r a n s f o r m e r ,

to states.

when a specific

This

ascribes

a function

is the d e n o t a t i o n a l

command,

in a state a, ~6~,

i.e.

function

which denotes

from

(Operating

System)

semantics

viewpoint.

Thus,

the function,

then a new s t a t e ~ ,

to it, as its

~'6~,

will

say ~, is e x e c u t e d

arise:

let ~ = E l a b - c m d ( c m d ) (~) = ~'

Comments

We choose

on A b s t r a c t i o n

this

level of abstraction,

tics d e f i n i t i o n ,

Also

the choice

some

intend,

concerning

to the d e n o t a t i o n a l

consider

how e.g.

function,

in c o n t r a s t

since w e have not y e t d e c i d e d

how we s p e c i f i c a l l y

mited

Principle:

to i m p l e m e n t

Compilers

semanand/or

our c o m m a n d

the o p e r a t i o n a l ones

to a m e c h a n i c a l

on w h i c h machine, language.

characterstics

has been

since we anyway have d e c i d e d

are to be realized,

and the type of this

function.

only

li-

not yet to

that they p e r f o r m

354

F. E l a b o r a t i o n F u n c t i o n D e f i n i t i o n s

1.0 .i .2 .3

~lab-cmd(cmd)

=

if pre-~lab-cmd(cmd)o then (let m k - 2 ( f , s , u ) cases

.4 .5

cmd:

(mk-Id(d,i)

~ mk-2(fU[i~d],s,

mk-Dl(id)

~ mk-2(f~{id},s,

u + [MSG -~ u (M_S_G_)'~ ] ),

.6 .7

u + [MS_G_ -~ u(MS_G_)"]),

.8 T

.9 .I0 .ii

.0

error

E lab-c lg ( c lg )a = (let mk-2(f,s,u) = ~ i_nn

.2

(trap exit(~) with ~ in

.4 .5

cases clg: (mk-C(k, t, o) mk-CL (k, t, o, l, e)

compile (k, t, o)c, (let o' = compile(k,t,o)~ i_n_n bind(1,e)a'),

.6 .7

Elab-clg(cmd)a))

else

.I .3

= ~ i_~n

mk-CLG(k,t,o,l,e,i)

~ (let ~' = compile(k,t,o)o in

.8

let c" = blnd(l,e)o'

.9

execute (i) o"),

.i0

mk-L(o,l,e) mk-LG(o,l,e,i)

i_nn i_nn ~_~n

execute (i )a") ,

.14

.16

~ (let s' = mk-~(f,s,u+[OBJ~f(o)]) let c"-- bind(l,e)s'

.13

.15

~ (let s' = mk-7.(f,s,u+[OBJ~f(o)]) bind(1,e)~') ,

.Ii .12

i_nn

mk-G(e,i)

~ (let ~' = mk-2(f,s,u+[LOAD~f(e) ]) i_~n execute(i)c ') ) )

355

Annotation:

I.i

E x e c u t i o n of a cmd depends on it satisfying pendent,

syntactic-

constraints

the function inde-

and semantic domain d e p e n d e n t

consistency

specified by pre-Elab-cmd (and detailed

there and

in pre-~lab-clg). 1.6,8 MeSsaGes 'posted' 2.2

concerning

successful

completion

states

(status's)

are

in the UTILity MesSaGe component.

Erroneous,

execution-time

checkable only,

execution of the com-

pile or bind functions shall lead to exits b e i n g trapped here further execution of steps in the CL, CLG, LG commands.

-- aborting

(Abnormal t e r m i n a t i o n

in the C, L cases are of course also tr__rq~-

ped here with the same effect as if not abnormally

terminated

through an exit~) is to compile.

2.4

To Compile

2.7

To Compile-Link-Go is to compile

(in one state,

~), then

bind in the state, ~', resulting from compilation; in the state, 2.10

~", resulting

The bind o p e r a t i o n tain the named

expects

and to execute

from binding. the UTILity 0BJect component

(o) Object m o d u l e

to con-

(from the file).

2.5,7 Thus the compile o p e r a t i o n deposits

a successfully

compiled

Object in the UTILity p B ~ e c t component. 2.15

(;) to

like 2.10 but now for execute and LOAD,

2.8,13 -- like 2.5,7, but now for the objects m e n t i o n e d

above~

2.7-9 These three lines could be written:

execute(i) (bindC1, e) (compile (k, t,o)s) ) and so could lines 2.5-6 and 2.13-14,

in their form.

356

Discussion

of A b s t r a c t i o n Choices:

The restriction

that a CLG command must have not only its "C-", but

also its "L-" and "G-" state components

(syntactic)

components

in order that E l a b o r a t i o n

agreeing with certain

of any part of the CLG com-

mand may be commenced,

may seem rather limiting.

brought this semantics

only for the purposes

techniques command

-- not in order to advocate

language over those of another.

'architectural' 'calls'

thereon)

functions,

Comments

designs.

specfication

Only when we master our speci-

it is relatively

up into separate parts,

with the c o n s t r u c t i v e

thus permitting partial

on A b s t r a c t i o n

The semantics specified:

Thus

modelling

the virtues of one particular

fication tools do we feel ready to seriously,

condition

We have, however,

of exemplifying

and sensibly, easy,

to 'chop'

the p r e -

and merge these

parts of the present

~laboration

embark on

(or

£1aboration

of e.g. CLG commands.

Principles:

assignment has been part implicitly-,

one could replace

Elab-cmd

part explicitly

with a p o s t - E l a b - e m d

specifica-

tion:

3.0

p o s t - E l a b - c m d ( , ~ ~) =

1

(let m k - 2 ( f , , )

2

mk-2(f',

3

cases

= ~, ) = a'

~n

cmd:

4

(mk-In(d,i)

~

f' = f U C i ~ d ] ,

5

mk-Dl(id)

~

f' = f~{id},

6

T

~

post-

which,

together with p r e - E l a b - c m d ,

vided of course we either specify post-,

or imply the p o s t - E l a b - c l g

In general,

if:

type:

F:

A ~ B

type:

pre-F:

A ~ BOOL

type:

post-F:

(A B) ~ BOOL

then:

lab-clg(,~

uniquely determines Elab-clg

accordingly

defined by 2 above~)

t)

Elab-cmd.

(Pro-

through its

357

with :

pre-F(a) ~ (B!b 6 B)(F(a) = b) pre-F(a) ^ F(a) = b The d e f i n i t i o n of the s t e p w i s e refinement:

D

post-F(a,b).

Elab-olg p r o c e e d e d on the basis of an iterative e x i s t e n c e of compile, bind and execute was postu-

lated after the crucial issue of their logical types w e r e first settled -- see G below~ The i t e r a t i o n from the internal s p e c i f i c a t i o n of the first two of these functions o c c u r e d as the r e s u l t of first p l a n n i n g that there be an exit w i t h i n them,

and then a c t u a l l y fixing the places

of these exits and the type of the value(s)

(Z) b e i n g "returned".

2" A u x i l i a r y F u n c t i o n T y p e s

I

(Source

IId)

[Id]

~

(~ ~ ~)

2

type: compile: bind:

aid

(Link

IId)

[Id]

~

(~ ~ ~)

3

execute:

(Input

IId)

~

(~ ~ ~)

Discussion/Comments:

T h e r e is an u n f o r t u n a t e a s y m m e t r y b e t w e e n these functions:

compile re-

ceives all the i n f o r m a t i o n it requires through its three arguments,

but

b o t h bind and execute are not e x p l i c i t l y p a s s e d i n f o r m a t i o n about the

Object m o d u l e to be linked, r e s p e c t i v e l y the Load m o d u l e to be e x e c u t e d -- instead these objects are to be looked up in the UTILity components: OBJ, r e s p e c t i v e l y LOAD; a fact w h i c h is hidden. This a b s t r a c t i o n choice was m a d e after some

(trivial)

e x p e r i m e n t s w i t h e x p l i c i t passing:

the

p r e s e n t s o l u t i o n was found not only to b a l a n c e the needs better b e t w e e n on one hand the CL and CLG commands,

and those of the LG and G c o m m a n d s

on the o t h e r hand, but also to be in some accord w i t h actual o p e r a t i n g system practice

(SYSLINK,

...).

358

H. Auxiliary Function Definitions •0 .I •2

compile(k,t,o)~= (let mk-Z(f,s,u) = ~

in

let s o u r e e = if is-Id(t) then f(t) else t

i_nn

.3

let obj = (s(k)) (source)

i~n

•4

if

is-Text(obj)

•5

then exit (mk-~ (f, s, u+ [MSG ~ u (MSG)~ ]) )

•6

else (let u ' = u+[OBJ ~ obj,MS~G ~ u(MS___G)"] in if o=nil

•7

•8

then mk-~(f, s,u ')

•9

else mk-~(fU[o-~bj],s,u')))

.0 .i

bind(1,e)a= (let mk-Z(f,s,uU[OBJ~obj])

= ~

.2

let Ink = if i8-Id(1) then f(19 else 1

•3

~lnk

.4

i_~n i_nn

£ dom obj

then (let u' = u+[LOAD ~ obj(lnk),MSG ~ u(MSG)~]

in

•6

then mk-Z(f,s,u ')

.7

else mk-~(fO[e-~bj(lnk) ],s,u'+[MSG-~(MSG)~ILED>])

.8

3 •0 .i

else exit (mk-Z {f, s,u+[MSG ~ u (MSG)~<ERRONEOUS-LINK> ]) ) )

execute (i)~= (let mk-~(f,s,uU[LOAD~ load]) = s

inn

.2

let input = i~ is-Id(i) then f(i) else i

i_~n

.3

let (mk-~(f',s,u'),output) = load(input)

inn

•4

mk-7(f', s,u '+[OUTPUT ~ output]) )

Comments on Abstraction Principles It is especially in this specification step that the real our abstraction appears to yield their maximum return•

'power' of

359

Annotations:

1.3

Recalling

that the logical type of the Compiler,

s(k), is

Source ~ (Object I Text) and that that of source is Source, we see that that of obj is either Object or Text -- concerning which we assume d i s j o i n t n e s s

of domains,

although that has not yet been

imposed. 1.9 1.6

If o was specified,

then the Object obj is to be filed.

compile leaves obj in the UTILity under

In any case a successfull

OBJ. 2.3

A bind is only successful

if the right Link information

is pro-

vided.

3.3

The logical type of Load is permitting date

Discussion

executing

(... ~ ~) e.g. files,

of F & H, Functional

The s p e c i f i c a t i o n referentially

(see B.10)

(user) programs

Input ~ (Z ~ ~ Output)

to access

thus changing

(Z ~ ...) and up-

the state.

versus Machine State Programming:

of Elab-cmd has been kept completely

transparent.

The m e a n i n g of a command

functional,

tional c o m p o s i t i o n of the meanings of the command components overall meaning remains unchanged to another,

syntactically

or: Id for Input H.I.2, s t i t u e n t meaning.

if we alter any syntactic

different

H.2.2.

one

thus

is the simple func-- and the component

(Id for Source, or: Id for Link,

r e s p e c t i v e l y H.3.3)

having the same con-

360

3. E X A M P L E I_~I: A P L / I - l i k e O n - C o n d i t i o n L a n g u a g e

We b e g i n by listing and a n n o t a t i n g formulae.

Then we end by d i s c u s s i n g

a b s t r a c t i o n principles.

A. Syntactic Domains

Progr

=

Block

Block

:: Id-set

Proc

:: s - p m l : ( s - I d : I d

s-Tp:(LOCIPROC))*

Stmt

=

I On-Unit

Call

:: Id

On-Unit

:: Cid

Proc

Signal

:: Cid

Id*

(Id~Proc)

E1-Stmt

Revert

:: Cid

Expr

=

Id

I Call

Stmt + Block

I Signal

I Revert

Expr*

I Const

Const

:: INTG

Infix

:: Expr

Id Lbl

m m

TOKEN TOKEN

aid

:

~

Op

~ ]

I ~

I Infix Expr

Id U Lbl = {}

I ~

I ...

Annotations

A Program is a Block. A Block has three parts: a set of v a r i a b l e Identifiers,

a set of u n i q u e l y I d e n t i f i e d Procedures

a map), and a list of Statements.

a Block.

The p a r a m e t e r

(hence a b s t r a c t e d as

A Procedure has a p a r a m e t e r

tifiers and their c o r r e s p o n d i n g L O C a t i o n or PROCedure ment is either an E l e l e n t a r y Statement,

a Signal,

or a ReVert

list and

list consists of pairs of formal p a r a m e t e r Identype. A State-

a s u b r o u t i n e Call,

an On-Unit,

statement. An Expression

is either a v a r i a b l e or

a Constant,

or an Infix expression.

a formal p a r a m e t e r I d e n t i f i c a t i o n ,

An Infix e x p r e s s i o n has three parts: a left- and a right operand Expression, and an Operator.

361

B. Static C o n t e x t C o n d i t i o n F u n c t i o n Type s

i

t~Fe :

is-wf-Progr:

Progr

~ BOOL ~ D I C T ~ BOOL

2

is-wf-Block:

Block

3

i8-wf-Procedure:

Id P r o c ~ D I C T ~ BOOL

4

i8-wf-Stmt:

Stmt

~ D I C T ~ BOOL

5

i8-wf-Expr:

Expr

~ D I C T ~ BOOL

C. A u x i l i a r y Text F u n c t i o n T y ~

6

type:

D. Static

e-tp:

Expr ~ D I C T ~ Type

(Compile-time)

Domains:

D I C T = (Id ~ Type) Type

= LO,,,C I P R O C

I (Id ( L O C I P R O C ) ) *

E. Static C o n t e x t Conditions:

1

is-wf-Progr(p)

=

i8-wf-Block(p)[]

A Program

2

is w e l l - f o r m e d

if its B l o c k

is-wf-Block(mk-Block(ids,pm, stl))dict .1

(let diet'

=

diet + { [ i d ~ L O C

.2

=

I idEide]

U[id~s-pml(pm(~d))

I ~d6dompm])

{_~n

3

(ids N d o m p m = {})

^

4

(¥id E , d o m p m ) ( i s - w f - P r o c e d u r e ( i d , p m ( i d ) ) d i c t ' )

^

5

(Vstmt 6 r n~ stl) ( i 8 - w f - S t m t ( s t m t ) i d c t ' ) )

A Block

2.3

is well-formed.

is w e l l - f o r m e d

if:

No I d e n t i f i e r is d e f i n e d both as a v a r i a b l e and as a P r o c e d u r e name, and

362

all P r o c e d u r e s

2.4

scope, diet',

are w e l l - f o r m e d in the l e x i c o g r a p h i c a l l y e m b r a c i n g defined up till now, and

all S t a t e m e n t s are well-formed,

2-5

diet'

(2.1-2)

that it is a P R O C e d u r e

and to any P r o c e d u r e

name

-- in p a r t i c u l a r it then binds d e f i n e d Procelist w i t h its type indications.

ie-wf-Procedure(id, mk-Proc(pml, bl))dict .I

(id

.2

(vi,jEindpml)(s-Id(pml[i])=~-Id(pml[j])

.3

(let dict'

•4

=

16 { p m l [ i , 1 ] l i E i n d p m l } ) =

A ~ i=j

^

dict +[s-Id(pml[i])~S-Tp(pml[i])li6ind____pml]

in

is-wf-Block(bl)dict')

A Procedure

3.1

w h i c h to any v a r i a b l e name

that it is a variable,

dures to the formal p a r a m e t e r

3

(DICT)

is the a s s o c i a t i o n

binds the fact, L OC,

also in the context so far defined.

i8 well-formed,

in the context d~ct,

id,

the p r o c e d u r e name,

if

is not also that of a formal p a r a m e t e r

name, and

3.2

no two formal p a r a m e t e r s have the same name, and

3.3

o t h e r w i s e the body,

bl, of the p r o c e d u r e is w e l l - f o r m e d in the

context, diet', w h i c h to diet Identifiers

4

to their type indicator.

ie-wf-Stmt(s)dict .I .2

da8e8

a d d i t i o n a l l y binds formal p a r a m e t e r

=

8:

(mk-aall(id, el)

((id E domdict)

A

(re E r n g e l ) ( i s - w f - E x p r ( e ) d i c t )

^

.4

((dict(id)

v

.5

(LOC • dict(id))

.6

(let pml = dict(id);

.7

(l_pml = ~el)

.8

(Vi E indel)

.3

= PROG)

A

(v-tp(el[i])dict ~ LOC ~ s-Tp(pml[i]))))),

.9 .i0

m k - O n - U n i t ( c i d , p)

~ i s - w f - P r o c e d u r e ( c i d , p)dict,

.ll

m k - S i g n a l ( c i d , idl)

~ (rn_~idl E domdict),

.12

mk-Revert(cid)

~ true,

.13

T

is-wf-El-Stmt(s)dict)

/~ not w r i t t e n ~/

3&3

The w e l l - f o r m e d n e s s of a Statement, w h i c h kind of

4.2-9

in the c o n t e x t diet, depends on

(what case of) S t a t e m e n t it is:

In a s u b r o u t i n e Call statement,

w h i c h consists of a P r o c e d u r e

i d e n t i f i e r and an e x p r e s s i o n list: 4.2 The P r o c e d u r e i d e n t i f i e r m u s t be known, 4.4 and m u s t be that of a PROCedure, 4.3 and all e x p r e s s i o n s of the actual a r g u m e n t e x p r e s s i o n

list

m u s t be w e l l - f o r m e d . 4.5 If the p r o c e d u r e i d e n t i f i e r is that of an a c t u a l l y defined, i.e. not formal, procedure, 4.6 then: 4.7 the length of the formal p a r a m e t e r gument expression

list and the actual ar-

list m u s t be the same,

4.8 and all c o r r e s p o n d i n g

(non-formal procedure)

4.9 a r g u m e n t e x p r e s s i o n s and formal p a r a m e t e r m u s t have assignable value types.

4 .i0

In an On-Unit statement, w h i c h consists of a c o n d i t i o n identifier and a p r o c e d u r e body this combination,

since it semanti-

cally c o r r e s p o n d s very m u c h to a procedure, m u s t be a well-formed P r o c e d u r e

4.11

in the d e f i n i n g d i c t i o n a r y context.

In a Signal statement, w h i c h consists of a c o n d i t i o n i d e n t i f i e r and an a r g u m e n t

list of identifiers,

these latter m u s t be k n o w n

in the d i c t i o n a r y context -- it is not possible, namic i n h e r i t a n c e of a s s o c i a t e d On-Units, in 4.4-4.9,

that the type of these arguments

of the intended On-Unit

4.12

'procedure'

due to the dy-

to check, 'match'

parameter

as it was the type

/ist~

A Revert on any c o n d i t i o n identifier is always OK~

is-wf-Expr(e)dict = •1

•2

cas es

:

(mk-Infix (el, op, e 2 ) ~ ( i s - w f - E x p r (el) diet ^

.3

is-wf-Expr(e2)diet

.4

^

(e-tp(el)diet = LOC = e-tp(e2)dict)),

.5

m k - C o n s t (i)

~true

.6

T

~(e 6 domdiet) )

384

F. A u x i l i a r y T e x t F u n c t i o n s

e-tp(e)dict .i

ca8~8

.2

=

~:

(mk-Infix(el,op,

e2)~(op

.3

6

{EQ, N E Q } )

T

~ BOOL, ~ LOt),

.4

mk-Const(i)

~LOC,

.5

T

~dict(e))

G. S e m a n t i c D o m a i n s

STG

=

LOC

OE

=

Cid

ENV

=

Id

~ NUM m ~ ECT m ~ DEN m

DEN

=

LOC

FCT

=

DEN~

I FCT

LOC

c

TOKEN

VAL

=

NUM

=

(STG

~

~ N

m

~

(OE ~

(~ ~

~))

I BOOL

STG)

U

(ref OE

--

~ OE) m

Annotations:

A

is a f i n i t e d o m a i n m a p f r o m L O C a t i o n s

SToraGe

these are the r e t i o n a l N U M b e r s . map from Condition identifiers

To m o d e l

to the F u n C T i o n s

they denote.

the c o n c e p t of scope we use the E N V i r o n m e n t a b s t r a c t i o n . is a f i n i t e d o m a i n

ENVironment DENotations.

of a L O C a t i o n FunCTion

to a s s i g n a b l e values,

A n ~n E s t a b l i s h m e n t is a finite d o m a i n

The D E N o t a t i o n

from Program

of a P r o g r a m

text Identifiers

text Identifier

(if the I d e n t i f i e r names a v a r i a b l e ) ,

(if it names a P r o c e d u r e ) .

t i o n f r o m a list of D E N o t a t i o n s f r o m 0n E s t a b l i s h m e n t s g i v e n an O n - U n i t

or

A

or t h a t of a

sidered evaluated

Both d e n o t e F u n C T i o n s

func-

to f u n c t i o n s

f r o m states to states!

it d e n o t e s a function.

the f o r m e r the a r g u m e n t l i s t is u s u a l l y p r e d e f i n e d , ter it is p r o g r a m m e r d e f i n a b l e .

to their

is e i t h e r that

(mathematical)

(i.e. a r g u m e n t values)

to f u n c t i o n s

a Procedure

F u n C T i o n is a

An

t h a t is:

In the c a s e of

whereas

in the lat-

w h i c h c a n be con-

in the d y n a m i c c o n t e x t of the d e f i n i n q E N V i r o n m e n t ,

365

but the c a l l i n s On E s t a b l i s h m e n t . values are returned,

Since they are all subroutines,

but side-effects,

i.e. state t r a n s f o r m a t i o n s ,

no are

effected.

A LOCation

is an o t h e r w i s e u n - a n a l y z e d e l e m e n t a r y object. The auxilia-

ry category,

VAL, stands for the u n i o n of r a t i o n a l NUMber and BOOLean

values.

The state space,

Z, o m i t t i n g input/output,

r e f e r e n c e to SToraGes,

is a map from one S~Tora~e

and a m u l t i t u d e of zero, one, or m o r e r e [ e r e n c e s

to On E s t a b l i s h m e n t s to 0n E s t a b l i s h m e n t s .

H. Global State Initialization:

dc___ilST~ :: []

I.

t~pe STG

E l a b o r a t i o n F u n c t i o n Types:

!

tzpe:

int-Progr:

Z (2 Z z)

Progr

2

int-Block:

Block

3

int-Stl:

Stmt ~

4

int-Stmt:

Stmt

5

£nt-Call:

Call

6

eval-Proc:

Proc

ENV ~ OE

~

(Z ~ 2)

: E~V Z

: EaT

7

eval-arg:

Expr

: E~V : OE

% {~ Z 2 {ECT I LOC))

8

eval-Expr:

Expr

: ENV : OE

: (Z ~ Z VAL)

~. A u x i l i a r y F u n c t i o n Types

i0

free-locs:

Id-set

ENV

~(2 ~ 2)

ii

type-chk:

DEN ~

(Id (LOCIPROC)) • ~BOOL

12

free-dummy-locs:

DEN*

Expr •

~(~ ~ ~)

366

K. Semantic E l a b o r a t i o n F u n c t i o n Definitions

1

int-Progr(p)

=

int-Block(p ) ([ ]) ([ ]) To interpret

a Program

an empty ENVironment

2

is the same as interpreting

int-Block(mk-Biock(ids,pm, .i

the Block

(let env'

stl, stl)) (env) (boe) =

: env + ([id ~ get-lot()

.2

I i6ids]

U[id ~ eval-proc(pm(id))(env')

.3

dcl lee

I id£dompm]);

:= boe;

.4

int-stl(stl)(env)((boe,£oe));

.5

free-locs(ids,env'))

In&erpreting

it is in

and an empty O n - E s t a b l i s h m e n t .

a Block w h o s e locally d e f i n e d v a r i a b l e s are r e p r e s e n t e d

by ids, locally d e f i n e d p r o c e d u r e s by pm, and s t a t e m e n t list by

stl,

is:

first to a s s o c i a t e w i t h each v a r i a b l e identifier a fresh LOCation,

2.1

and

2.2

w i t h each p r o c e d u r e identifier the, thus c i r c u l a r l y

2.3

defined,

the FunCTion

it is, the latter in

d e f i n i n g environment

(').

Then to e s t a b l i s h a local on e s t a b l i s h m e n t w h i c h inherits the value of the e m b r a c i n g blocks'

2.4

on establishment,

w h e r e u p o n actual execution, place of the s t a t e m e n t

2.5

after these p r o l o g u e actions,

can take

list.

Storage a l l o c a t e d in 2.1 is freed here.

9

get-lee() .i

=

(let I 6 LOC be s.t.

1 ~E dom(~STG);

.2

sj,,2G : = ~ST.~G u [ ~ u n d e f i n ~ d ] ;

.3

return(1))

This f u n c t i o n allocates and p e r - l o c a t i o n basis.

'initializes'

to undefined,

S~Tora~e on a

367

free-locs(ids,env)

i0

=

This is block termination S~ora~e freeing epilogue action.

eval-proc(mk-Proc(pml,bl))(env) .1

(let f ( a ~ ( o e )

.2

=

=

(i_~ N t y p e - m a t c h ( a l , p m l )

.3

then error

.4

else

(let e n v ' = e n v + [ ~ - I d ( p m l [ i ] ) ~ a l [ i ] l i 6 i n d a l ]

.5

int-block(bl)(env')(oe)))

;

in

f)

12

type-match(al,pml) .i .2

=

((~al = l_pml) ^ (Vi£indal)(is-~G_(al[~])

The meaning of a P r o c e d u r e

=- s - T p ( p m l [ i ] )

= LOG_))

is the function it denotes.

is implicitly defined by what happens if it is Called. 7.4

the defining e n v i r o n m e n t formal parameter

This function Then:

is augmented with the bindings between

list identifiers and the passed actual argument

list D E N o t a t i o n s ,

7.5

whereupon the block of the P r o c e d u r e

(the 'body')

is elaborated

in the callling state, but essentially the defining e n v i r o n m e n t ~ Since the calling state involves the on-establishment, each Block

and since

potentially defines its own 'copy' which may be dynami-

cally updated,

one needs to pass the value of the current blocks'

local on establishment tion; hence,

to the invocation of the P r o c e d u r e

denota-

in line :

7.1

the functional dependency on the calling states'

7.2

The type-check is statically decidable for ordinary procedures, but not for O n - U n ~ t

procedures.

int-Stl(stl)(env)(oep) .i

on establishment.

~or i=1 do l e n s t l

= d_~o i n t - S t m t ( s t l [ i ] ) ( e n v ) ( o e p )

368

TO interpret

a list is the same as interpreting

in the order

listed.

int-Stmt(s)(env)((boev,leer)) .1

cases

2

each of its Statements

=

s:

(mk-Call(id, el)~

3

(let al : < e v a l - a r g ( e l [ i ] ) ( e n v ) ( ~ l o ~ ) l i 6 i n d e l > ;

4

let f = env(id)

5

f(al)(~loe~);

6

in

free-dummy-locs(al,el)),

7

mk-On-Unit(cid, p)~

8

(let f = eval-proc(p)(env)

9

10£r := cloer + [cid~f]),

i_~n

mk-Signal(cid,idl)~

i0

(let al = <env(idl[i])li6indidl>

ii

in

i_~ cid 6 dom(cleer)

12

then

13

(let f : (cloe~)(cid); f(al)(c£o£~))

14

else error),

15

mk-Revert(cid)~

16

i_ff cid ~6 domboev

17 18

then Ze~r

:= c £ o e ~ c i d }

19

else Ze~r

:= c£o£r + [cid~boev(cid)],

T

20

~int-E1-Stmt(s)(env)(cZoe~))

4.

To interpret

a Statement

4.2-6

interpreting

a subroutine

ing s e q u e n c e

of actions:

expression

is a f u n c t i o n

Each

4.4

and the p r o c e d u r e

statement

it is:

Call s t a t e m e n t c o n s i s t s of the follow-

of the Argument

4.3

of what

list is evaluated,

(i.e. -identifier)

denotation

retrieved

from the scope,

4.5

whereupon

it is being

~ist and the v a l u e

applied

(i.e.

to the e v a l u a t e d

contents)

argument

of the current,

local

on establishment. 4.6

The

locations

allocated

13 b e l o w -- are freed.

d u r i n g Argument

evaluation

-- see

389

4.7-9

interpreting establishment

an On-Unit

results in the u p d a t e of the local on

(known by reference)

w i t h the f u n c t i o n d e n o t e d by

the On-Unit p r o c e d u r e body in the p o s i t i o n known as cid,

i.e.

for that on c o n d i t i o n identifier.

4.10-15 interpreting

a Signal s t a t e m e n t is like Calling a subroutine,

b u t there are some s i g n i f i c a n t differences.

4 .ll

First all e x p r e s s i o n s of the a r g u m e n t identifiers,

r i g h t from the c a l l i n g

4.12

list m u s t all be

w h e r e b y their d e n o t a t i o n can be e x t r a c t e d

If the d e s i g n a t e d

(i.e. Signalling)

environment.

(cid) On-Unit has not b e e n d e f i n e d

some On-Unit of the e m b r a c i n g scope)

(by

then

4.15

an error s i t u a t i o n has arisen,

4.13

o t h e r w i s e the f u n c t i o n d e n o t e d by the s p e c i f i c a l l y Signalled

4.14

(i.e. identified)

c o n d i t i o n On-Unit

is a p p l i e d to the a r g u m e n t O b s e r V e that no environment t e n t s of the current, former is 'embedded'

list c o n c o c t e d in line 4.11° is supplied,

but that the con-

the local 0n e s t a b l i s h m e n t is. The in the f u n c t i o n denotation,

the latter

part of its functionality.

4.16-19 interpreting current,

a Revert s t a t e m e n t has the effect of letting the

the local on e s t a b l i s h m e n t h e n c e f o r t h a s s o c i a t e the de-

n o t a t i o n of the c o n d i t i o n i d e n t i f i e r with its value in the on e s t a b l i s h m e n t of the e m b r a c i n g block.

...

etcetera.

370

8

eval-arg(e)(env)(loev) .i

0a888

.2

=

e:

(mk-Infix(,,)

~ (let v : eval-expr(e)(env)(loev),

.3

l 6 LOO be s.t.

1-E

dom(cSTG);

1NE

dom(cSTG);

ST G :~ cST_~G U [l~v];

.4

return(1)),

.5 mk-Const(i)

.6

~ (let l E LOC be s,t.

.7

STG := cSTG U [l~i];

.8

return(l)), T

.9 evaluating

~

return(env(e)))

a subroutine Call argument proceeds according to the fol-

lowing basic scheme. The exemplified language has Call-by-LOCation objects other than procedures. 8.2.5

for

Thus:

Infix argument expressions

are evaluated,

a fresh S~ora~e pseu-

do location is 'fetched', and S~ora~e initialized to the argument expression value, with the new location being returned. 8.6-8

Likewise for Constant expressions.

8.9

All other expressions,

i.e. variable- and Procedure

identifiers

result directly in their denotation being retrieved from the scope.

Thus Procedure denotations

is passed by-worth~

13 free-dummy-locs(al, el) = .i

(let Ices = {al[i]

.2

STG := cSTG~locs)

I Nis-Id(el[i])

^ i£indel};

371

9

eval-expr(e)(env)(oe) .i

=

cases e:

.2

( m k - I n f i x ( e l , o p , e~)

.3

~ (let v I : e v a l - e x p r ( e l ) ( e n v ) ( o e ) ,

.4

v 2 : eval-expr(e2)(env)(oe);

.5

cases

.6

op:

(ADD ~

((Vl+V 2 ~ 2+64)

.7

~

(if OFL E domoe

.8

then

(dclr

.9

return(cr))

i0

else r e t u r n ( 2 + 6 4 ) ) ,

ii

(VI+V ~ < -2+64)

12

13

UF~ E domoe

~

(if

~

return(vl+v2)),

...),

14

T

15 16

SUB ~

17

...

.18

E_QQ ~ r e t u r n ( v 1 = v 2)

.19

...

...)),

mk-Oonst(i)

.20

~ return(d),

.21

T ~ (e_~S!~G)(env(id)))

.22

We c o n c e n t r a t e

If e v a l u a t i o n

on lines

9.6-9.11.

of an a r i t h m e t i c

expression

leads

either

of two s i t u a t i o n s

occur.

Either

there

by the programmer,

is defined,

On E s t a b l i s h m e n t , (9.9)

passing

variable becomes

for h a n d l i n g

initialized the c o n t e n t s

on-units

show a static

to the o v e r f l o w of this v a r i a b l e

test

has

case the SYSTEM a c t i o n

an O n - U n i t ,

example

value.

(9.6),

this unit

after

then

in the c u r r e n t is called

-- r e f e r e n c e

The v a l u e

(9.10)

(9.9). Thus we expect

for this

to o v e r f l o w

and then

w i t h one formal p a r a m e t e r

the p r o g r a m m e r

(9 .ii) '.

OverFLow,

to it -- as a h y p o t h e t i c a l

fined On Unit p r o c e d u r e the ~

Or:

:= v1+v2;

(oe(OFL))(r);

to a m e t a •

of the e x p r e s s i o n

execution

the p r o g r a m m e r

of type ~ a t i o n .

of the deto d e f i n e W e do not

-- b u t c o u l d have.

not d e f i n e d

an a p p r o p r i a t e

is to return,

OF_L O n - U n i t

in w h i c h

say the m a x i m u m a r i t h m e t i c - v a l u e

372

Comment From the definition we can informally derive the following informal, technical english, users programming reference manual-like,

description

of the 0n-Condition concept.

On-Units are like assignment statements. The target reference is one, of a limited variety,

of condition codes

(cid). The right-hand side

expression is restricted to be a procedure To Signal is to invoke the most recently

(4.7-9).

'assigned'

On-Unit of the name

(cid) signalled. Thus a Signal is hike a Call. To Revert is to locally re-assign ed' in the immediately,

the On-Unit most recently

'assign-

dynamically containing block.

Further: To each block activation we let there correspond an association of cids to On-Unit procedure values called an 0n-Establishment (2.3). A block activation inherits the value of this association in the invoking block 'Falling'

(respectively calling procedure)

(2.3 from 4.5 + 7.5).

back to the interpretation of an invoking block brings us

back to the on-establishment of this latter block current when this block invoked the block just terminated. Finally:

Procedures are elaborated in the defining environment

7.4-5), but in the calling on-establishment

(2.2

(4.5 ~ 7.1-5).

Discussion We shall only discuss the local/global state modeling chosen in our conceptualization of the source language On Condition-,

respectively

Variable constructs. Our first example illustrated that model components,

like the state

construct,

(Z), which are transformable by any syntactic

can indeed be an explicit parameter to functions elaborat-

ing these constructs, provided, of course, that the possibly changed state is likewise explicitly yielded as part, or all, of the result. This is the rule followed in all of the Oxford models; many examples in [Bj~rner ?Sb] also exemplified this specification style. For blockstructured imperative programming languages it soon, however, becomes rather cumbersome to write, and read, all these explicit passings and returns of such all-pervasive, components.

373

Hence itwas decided, neering,

as a c o n c e s s i o n to readability,

to p e r m i t v a r i a b l e s

to use v a r i a b l e s sparingly,

in the m e t a - l a n g u a g e .

as well as to engiThe p o i n t is now

and to h a v e their introduction,

w h e t h e r they are local or global, and their m a n i p u l a t i o n ,

the fact

r e f l e c t the

very essence of the c o n c e p t they are intended to model. Therefore:

Since s o u r c e - l a n g u a g e variables,

d e c l a r e d at any

(source-language-)

block- & p r o c e d u r e level, can be cha~ged at any other,

"inner" and

"outer" level, the storage c o m p o n e n t of the state was chosen to be m o d e l e d by a single,

global m e t a - v a r i a b l e .

(That s l - v a r i a b l e s can be

u p d a t e d on levels o u t s i d e their scope is due to the b y - ~ a t i o n

para-

meter p a s s i n g capability.)

And:

since On-Units c o r r e s p o n d to assignments

Cid) of type p r o c e d u r e ponent

(or, as in PL/I,

since such

entry-)

value,

the model com-

was also c h o s e n to be a m e t a - v a r i a b l e .

'assignments'

(names in

k e e p i n g track of current Cid to p r o c e d u r e

(on-establishment),

v a l u e associations,

to v a r i a b l e s

in one b l o c k

(£0£a)

a s s o c i a t i o n s r e c o r d e d in any c o n t a i n i n g b l o c k

Further:

are not to d i s t u r b the

(boe), we introduce one

loe, per block activation. To shield the boe, w h i c h is needed in a d i r e c t l y c o n t a i n e d b l o c k due to Reverts, it is passed

such m e t a - v a r i a b l e ,

by value,

i.e.

its c o n t e n t

0e is passed by r e~erence

(4.5 ~ 7.5 ~ 2.0 ~ 2.4); w h e r e a s the £ocal

(loer £ ~ef OE)

(2.3 ~ 2.4 ~ 4.0 ~ 4.9,4.18,

4.19) .

M o d e l i n g o n - e s t a b l i s h m e n t s by locally d e c l a r e d m e t a - l a n g u a g e v a r i a b l e s shifts the burden of definer,

'stacking ~ e m b r a c i n g o n - e s t a b l i s h m e n t s

and of u n d e r s t a n d i n g these u s u a l l y

tions away f r o m the reader,

rather

from the

mechanical descrip-

and onto the m e t a - l a n g u a g e :

its semantics,

r e s p e c t i v e l y the readers u n d e r s t a n d i n g of, in this case, recursion.

374

ACKNOWLEDGEMENTS: The author is very pleased to express,

once more, his deep gratitude

for his former colleagues at the IBM Vienna Laboratory,

and to Mrs.

Annie Rasmussen for her virtuoso juggling of eight distinct IBM "golf ball" type fonts.

REFERENCES & BIBLIOGRAPHY [ACM 65 ]

ACM: Conference on: Programming Languages and Prag= matics -- San Dimas, California, August 1965. Ex= cerpts in: Comm.ACM, vol. 9, no. 6, 1966.

[ADJ 77]

J.A.Goguen, J.W.Thatcher, E.G.Wagner & J.B.Wright: "Initial Algebra Semantics and Continuous Algebra Jour. ACM, voi.24, no.l, pp. 68-95, Jan. 1977.

[Allen 72]

C.D.AIIen, D.N.Chapman & C.B.Jones: "A Formal De= finition of ALGOL 60", IBM (Hursley) Techn.Rept.No. TR12.105, Hursley, Hants, UK., August 1972.

[Alber 69]

K.Alber, H.Goldmann, P.Lauer, P.Lucas, P.Oliva, R. Stigleitner, K.Walk & G.Zeisel: "Informal Intro= duction to the Abstract Syntax and Interpretation of PL/I", IBM (Vienna) Techn.Rept.No.TR25.099, Vien= na, Austria, June 1969.

[Backus

J.W.Backus: "The Syntax and Semantics of the Pro= posed International Algebraic Language of the Z~= rich ACM-GAMM Conference", ICIP Proceedings, Paris 1959, Butterworth's, London, pp.125-132, 1960.

59]

[Bandat 65]

K.Bandat: "Tentative Steps Towards a Formal Defini= tion of the Semantics of PL/I", IBM (Vienna) Techn. Report.No.TR25.065, Vienna, Austria, July 1965.

[Beki6 70a]

H.Beki~: "On the Formal Definition of Programming Languages", (in:) Proceedings of the European ACM Int'l.Comp.Symp.'70, Bonn, Germany, Nov.1970.

[Beki6 70b] ties",

& K.Walk: "Formalization in: [Engeler 71]

of Storage Proper=

[Beki~ 71]

....... : "Towards a Mathematical Theory of Proces= ses", IBM (Vienna) Techn.Rept.No.TR25.125, Vienna, Austria• Dec.1971.

[Beki~ 74]

• D.Bj~rner, W.Henhapl, C.B.Jones & P.Lucas: "A Formal Definition of a PL/I Subset", IBM (Vien= na) Techn.Rept.No.TR25.139, Vienna, Austria, Dec. 1974.

[Bj~rner

D.Bj~rner: "Programming Languages: ment of Interpreters & Compilers", pp.l-22.

77a]

Formal Develop= in: [Morlet 77]

~Bj~rner 77b]

......... : "Programming Languages: Linguistics Semantics" in: [Morlet 77], pp.511-536

[Bj~rner 77c]

......... : "Systematic Program Derivation Techni= ques"• Dept.of Comp. Sci.,Techn. Rept. ID677, Techn. University of Denmark• Nov.1976/April 1977.

[Bj~rner

77d]

......... : "The Systematic Development of a Compi= ling Algorithm", ! ~ , ID681, Aug.1977.

[Bj~rner

77e]

......... : "Experiments in Block~Structured GOTOLanguage Modeling", ~b~d, ID716• July 1977.

and

376

[Bj~rner 78a]

& C.B.Jones (eds.) : "The Vienna Develop= ment Method: The Meta-Language", Springer Verlag, 'Lecture Notes in Computer Science', This Volume, Heid = elberg- New York, 1978.

[Bj@rner 78b]

D.Bj~rner: Tutorial",

[Bj~rner 78c]

......... : "Software Abstraction Principles: Tutor= ial Examples of an Operating System Command Language Specification and a PL/I-like On-Condition Language Definition", in: [Bj~rner 78a] ,pp. 337-374.

[Burstall

R.M.Burstall & P.J.Landin: "Programs and their Proofs: An Algebraic Approach", in: 'Machine Intelligence', (ed.D.Michie) vo!.4,pp.17-43, Edinburgh Univ.Press, 1969.

[Chomsky

69]

59]

"Programming in the Meta-Language: in: [Bj~rner 78a] pp. 24-217.

A

N.Chomsky: "On Certain Formal Properties of Gram= mars", Information & Control, vol.2, no.2, pp.137167, 1959.

[Church 41]

A.Church: "The Calculi of Lambda-Conversion", Annals of Math.Studies, no.6, Princeton University Press, 1941.

[deBakker

69]

J.de Bakker: "Semantics of Programming Languages", in: 'Advances in Information Systems Sciences, vol. 2, chap.3, Plenum Press, pp. 173-227, 1969.

[deMorgan

75]

R.M.deMorgan, I.D.Hill & B.A.Wichman: "Modified Re = port on the Algorithmic Language ALGOL 60", BCS Comp. Journal, vol.19, pp.364-379, Nov.1976.

[Dennis 75]

J.B.Dennis: "Modularity", in: 'Software Engineering', (ed.F.L.Bauer) Springer Verlag, 'Lecture Notes in Computer Science', vol.30, Heidelberg- New York, pp. 128-182, 1975.

[Dijkstra 62]

E.W.Dijkstra: "An Attempt to Unify the Constituent Concepts of Serial Program Execution", in: 'Symbolic Languages in Data Processing', Proceedings ICC Symp. Rome 1962, Gordon & Breach, New York, pp.237-251, 1962.

[Dijkstra 68] System", [Dijkstra 75]

: The Structure of THE Multiprogramming Comm.ACM, vol.ll, no.5, pp.341-346, 1968.

• "Guarded Commands, Non.Determinacy & Formal Program Derivation", Comm.ACM, vol.18, no. 8, pp.453-457, 1975.

[Dijkstra 76] tice-Hall,

"A Discipline 1976.

of Programming",

Pren-

74]

European Comp.Mfg.Assoc.: "PL/I BASIS/l" (also: A= merican National Standards Inst.) ECMA/TCI0 & ANSI. X3Jl, Basis/l-12, July 1974.

[Elgot 64]

C.C.Elgot & A.Robinson: "Random-Access, Stored-Pro = gram Machines: an Approach to Programming Langua= ges", Jour.ACM, vol.ll, no.4, pp.365-399, 1964.

[Engeler 71]

"Symposium on Semantics of Algorithmic Languages", (ed.:E.Engeler), Springer Verlag: 'Lecture Notes in Mathematics', voi.188, 1971.

[ECMA

377

[Fleck 69]

M.Fleck: "Formal Definition of the PL/I Compile Time Facilities", IBM (Vienna) Techn.Rept.No.25. 095, Vienna, Austria, June 1965.

[Floyd 67]

R.W.Floyd: "Assigning Meanings to Programs", in: 'Mathematical Aspects of Comp.Sci.', Proceedings of Symposia in Appl.Math., vol.i9, (ed.J.Schwartz) American Math. Soc., Providence, Rhode Island, pp. 19-32, 1967.

[Forino 66]

Carraciolo di Forino: "Generalized Markov Algorithms and Automata", in: 'Automata Theory', (ed.:E.R.Ca= ianello) Academic Press, pp.l15-130, 1966.

[Guttag 77]

J.Guttag: "Abstract Data Types and the Development of Data Structures", Comm.ACM, vol.20, no.6, pp. 396-404, June 1977.

[Hal&s 75]

A.Hal~s: "Event Driven Control Statements", 15, pp.259-271, 1975.

[Hansal 76]

A.Hansal: "A Formal Definition of a Relational Data Base System", IBM (Peterlee) Techn.Rept.No.UKSC0080, June 1976.

[Hansen 73]

P.B.Hansen: "Operating System Principles", 135 top) Prentice-Hall, 1973.

[Henderson

75]

BIT, vol.

(ref.:pg.

D.A.Henderson: "The Binding Model: A Semantic Base for Modular Programming Systems", MIT (project MAC) Techn.Rept.No.TR-145, Feb.1975.

[Henhapl 70a]

W.Henhapl & C.B.Jones: "On the" Interpretation of GOTO Statements in the ULD", IBM (Vienna) Lab.Note.No.LN 25.3.065, March 1970.

[Henhapl

W.Henhapl & C.B.Jones: "A Formal Definition of ALGOL 60 as Described in the 1975 Modified Report", in: [Bj~rner 78a], pp.305-336, 1978.

78]

[Hoare 69]

C.A.R.Hoare: "The Axiomatic Basis of Computer Pro = gramming", Comm.ACM, vol.12, no.10, pp.576-583, Oct. 1969.

[Hoare 71] Approach",

-: "Procedures and Parameters: An Axiomatic in: [Engeler 71] , pp. 102-116.

[Hoare 73]

........... & N.Wirth: "An Axiomatic Definition of the Programming Language PASCAL", Acta Informatica, vol.2 , ppo335-355, 1973.

[Hoare 74]

C.A.R.Hoare & P.Lauer: "Consistent and Complementary Formal Theories of the Semantics of Programming Lan= guages", Acta Informatica, vol.3, pp.135-153, 1974.

[Izbicki

H.Izbicki: "On a Consistency Proof of a Chapter of the Formal Definition of a PL/I Subset", IBM (Vienna) Techn.Rept.No.TR25.142, Feb.1975.

75]

[Jones 70]

C.B.Jones: "Yet Another Proof of the Block Concept", IBM (Vienna) Lab.Note.No.LN25.3.075, Vienna, Austria, Aug.1975.

378

[Jones 71]

C.B.Jones & P.Lucas: "Proving Correctness of Ira= plementation Techniques", in: [Engeler 71] , pp. 178 ~ i i .

[Jones 72]

C.B.Jones: "Formal Development of Correct Algorithms: An Example Based on Earley's Recogniser", ACM SIGPLAN /SIGACT Symp. on 'Proving Assertions about Programs', Las Cruces, Jan. 72, SIGPLAN NOTICES, vol.7, no.l, pp. 150-169, 1972.

[Jones 75]

• "Formal Definition in Program Develop= ment", in: Springer Verlag 'Lecture Notes in Corn= puter Science', voi.23, pp. 387-443, 1975.

[Jones 76a]

: "Formal Definition in Compiler Develop= ment", IBM (Vienna) Techn.Rept.No.TR25.145, Vienna, Austria, Feb.1976.

[Jones 77a] ment",

• "Program Specifications and Formal Developin [Morlet 77], PP. 537-554.

[Jones 77c]

• "Implementation Bias in Constructive Specifications", IBM (LaHulpe) Manuscript, Sept. 1977.

[Jones 78a]

......... : "The Meta-Language: A Reference Manual", in: [Bj~rner 78a] , pp. 218-277.

[Jones 78b]

• "Denotational Semantics of GOTO: An Exit Formulation and its Relation to Continuations", in: [Bj~rner 78a] , pp. 278-304.

[King 75]

J.C.King: "A New Approach to Program Testing", in: Springer Verlag, 'Lecture Notes in Computer Science', voi.23, ("Programming Methodology") pp.278-290,1975.

[Kleene 67]

S.C.Kleene:

[Knuth 68]

D.E.Knuth: "Semantics of Context-Free Languages", Mathematical Systems Theory, vol.2, pp°127-145,1968.

[Knuth 74]

......... : "Structured Programming with GOTO State= ments", ACM Computing Surveys, vol.6, no.4, pp.261302, 1974.

[Landin 64]

P.J.Landin: "The Mechanical Evaluation of Expres= sions", BCS Computer Journal, vol.6, no.4, pp.308320, 1964.

[Landin 65]

. "A Correspondance Between ALGOL 60 and Church's Lambda-Notation", (2 Parts) Comm.ACM, vol. 8, nos.2-3, pp.89-101 & 158-165, Feb.-March 1965.

[Lauer 68]

P.E.Lauer: "Formal Definition of ALGOL 60", IBM (Vienna) Techn.Rept.No.TR25.088, Dec.1968.

[Lauer 71]

"Consistent Formal Theories of the Seman= tics of Programming Languages",(Ph.D.Thesis) IBM (Vienna) Techn.Rept.No.TR25.121, Nov.1971.

[Lee 72]

J.A.N.Lee: "Computer Semantics", Van Nostrand Rein= hold Co., 1972.

"Mathematical Logic", Wiley & Sons, 1967.

379

[Liskov 75]

B.H.Liskov & S.N.Zilles: "Specification Techniques for Data Abstractions", IEEE Trans.Softw.Eng.,vol. SE-I,(voI.I) no.l, pp.7-19, March 1975.

[London 70 ]

R.L.London: "Bibliography on Proving the Correctness of Computer Programs", in: 'Machine Intelligence', (eds.Meltzer & Michie), vol°5, Edinburgh Univ.Press, pp.569-580. I ~ 9 .

[Lucas 68]

P.Lucas: "Two Constructive Realizations of the Block Concept and Their Equivalence", IBM (Vienna) Techn. Rept.No.TR25.085, Vienna, Austria, June 1968.

[Lucas 69]

& K°Walk: "On the Formal Description of PL/I", Annual Review in Automatic Programming,vol. 6, pt.3, Pergamon Press, 1969.

[Lucas 73]

P.Lucas: "On Program Correctness and the Stepwise Development of Implementations", in: Proceedings 'Convegno di Informatica Teorica', Univ.of Pisa, Italy, pp.219-251, March 1973.

[Lucas 78]

: "On the Formalization of Programming Lan= guages: Early History & Main Approaches", in: [Bj~rner 78a], pp. 1 - 23.

[Madsen 77]

J.Madsen: "An Experiment in Formal Definition of Operating System Facilities", Inform.Proc.Letters, vol.6, no.6, pp. 187-189, Dec. 1977.

[Manna 72]

Z.Manna & J.Vuillemin: "Fixed-Point Approach to the Theory of Computation", Stanford Univ., Comp.Sci. Dept. & Dept.of Artif.Intell.Rept.AIM164, also: ACM SIGPLAN Notices, Jan.1972.

[McCarthy

63]

J.McCarthy: "Towards a Mathematical Science of Com= putation", in: 'Information Processing', North-Hol= land Publ., 1963.

[McCarthy

67]

& J.Painter: "Correctness of a Compiler for Arithmetic Expressions", Proceedings of Sympo= sia in Applied Mathematics, 'Mathematical Aspects of Computer Science', (ed.J.Schwartz), American Math.Soc., Rhode Island, pp. 33-41, 1967.

[McCarthy 66]

J.McCarthy: "A Formal Description ALGOL", in:

[Milne 74]

R.E.Milne: "The Formal Semantics of Computer Lan= guages and Their Implementation", Ph.D.Thesis,PRG13, Techn.Microfiche TCF-2, Oxford Univ.Prgr.Res. Grp., 1974.

[Milne 76]

& C.Strachey: "A Theory of Programming Language Semantics", Chapman and Hall, 1976.

[Milner 73]

R.Milner: "An Approach to the Semantics of Paral= lel Programs", in: Proceedings 'Convegno di In = formatica Teorica', Univ.of Pisa, Italy, pp.285 ff., March 1973.

[Morlet 77]

E.Morlet & D.Ribbens: 'International Computing Sym= posium 77', European ACM, North-Holland, 1977.

of a Subset of

380

[Morris 38]

C.Morris: "Foundations of the Theory of Signs", in: 'International Encyclopedia of Unified Science', vol°l, no.2, Univ.of Chicago Press, 1938.

[Morris 55]

........ : 'Signs, Language and Behaviour', ziller, New York, 1955.

[Morris 73]

F.L.Morris: "Advice on Structuring Compilers and Proving them Correct", in: 'Principles of Program= ming Languages', ACM SIGPLAN Symp., Boston, pp. 144-152, 0ct.1973.

[Moser 70]

E.Moser: "On a Formal Description of an Indexed Sequential Dataset", IBM (Vienna) Lab.Rept.No. LR25%1.010, March 1970.

[Mosses 74]

P.D.Mosses: " T h e M a t h e m a t i c a l Semantics of ALGOL 60", Oxford Univ.Prgr.Res.Grp., PRG-12, 1974.

[Mosses 75]

° The Semantics of Semantic Equations", in: Springer Verlag, 'Lecture Notes in Computer Science', voi.28, pp.409-422, 1975.

[Mosses 76]

.......... : "Mathematical Semantics and Compiler Generation", Ph.D.Thesis, Oxford Univ., Prgr.Res. Grp., April 1974.

[Mosses 77]

.......... : "Making Denotational Semantics Less Concrete", Pres.Bad Honnef, Germany, March 1977.

[Naur 63]

P.Naur: "Revised Report on the Algorithmic Lan= guage ALGOL 60", (editor) Comm.ACM, vol.6, no.l, pp.l ff, 1963.

[Neuhold 71]

E.Neuhold: "The Formal Description of Progra/r~ing Languages", IBM Systems Journal, vol.10, no.2, pp.86-i12, 1971.

[Nilsson 76]

J.F.Nilsson: "Relational Data Base Systems - Form= alization and Realization", Ph.D.Thesis, Dept.of Comp.Sci., Techn.Univ. of Denmark, Rept. ID641, 1976.

[Ollongren 75]

A.Ollongren: "A Definition of Programming Langu= ages by Interpreting Automata", Academic Press, 1975.

[Park 70]

D.Park: "Fixpoint Induction and Proofs of Program Properties", in: 'Machine Intelligence', (eds. Meltzer and Michie) vol.5, Edinburgh Univ.Press, pp.59-78, 1970.

[Reynolds 72]

J.C.Reynolds: "Definitional Interpreters for Higher-Order Programming Languages", Procs.25th ACM Nat'l.Conf., pp.717-740, 1972.

[Reynolds 73]

............ : "Algebraic & Mathematical Semantics", Course Notes SIS 670, Dept.of Sys.& Inf.Sci., Syracuse Univ.,N.Y., 1973.

[Reynolds 74]

. "On the Relation Between Direct and Continuation Semantics", Springer Verlag 'Lecture Notes in Computer Science', vol.14, 1974.

G.Bra=

381

[Reynolds 75]

............ : "Relational and Continuation Seman = tics for a Simple Imperative Language", 1975.

[Reynolds 76]

............ : "Topics in Programming Languages " , Course Notes SIS 830, Dept.of Sys.& Inf.Sci., Syracuse Univ., N.Y., 1974.

[Schwartz 75]

J.Schwartz: "A Comment on Correctness Proofs", SETL Newsletter 159, Courant Inst.of Math., New York University, pp.6-15, 1975.

[Scott 70]

D.Scott: "Outline of a Mathematical Theory of Com= putation", Oxford Univ.,Prgr.Res.Grp., PRG-2, Nov. 1970.

[Scott 71],

& C.Strachey: "Towards a Mathematical Se= mantics for Computer Languages", in: Proceedings of the Symposium on 'Computers and Automata', MRI Symposia, vol.XXI, Polytechnic Inst.of Brooklyn, N.Y., 1971.

[Scott 72]

D.Scott: "Mathematical Concepts in Programming Language Semantics", Proc.AFIPS, Spring Joint Computer Conference, vol.40, pp.225-234, 1972.

[Scott 76]

....... : "Data Types as Lattices", SIAM Journal on Computer Science, vol. 5, no.3 , pp. 522-587, 1976.

[Steel 66]

T.B.Steel: 'Formal Language Description Langua= ges" (editor) North-Holland Publ., 1966.

[Stoy 74]

J.Stoy: "The Scott-Strachey Approach to the Math= ematical Semantics of Programming Languages", MIT Lecture Notes, Course 6.791, Fall 1973, also: MIT Press, 1977.

[Strachey 66]

C.Strachey: "Towards a Formal Semantics", [Steel 66] , pp. 198-220.

[Strachey 73]

. "The Varieties of Programming Langu= ages", Oxford Univ.,Prgr. Res.Grp., PRG-10, March 1973.

[Strachey 74]

and C.Wadsworth: "Continuations: A Math= ematical Semantics which can deal with Full Jumps", Oxford Univ., Prgr. Res.Grp., PRG-II, 1974.

[Tennent 73]

R.D.Tennent: "The Mathematical Semantics of SNOBOL 4", in: 'Principles of Programming Languages', ACM SIGPLAN Symp., Boston, pp. 95 -107, Oct.!973.

[Tennent 76]

........... : "The Denotational Semantics of Pro= gramming Languages", Comm.ACM, vol.19, no.8, Aug. 1976.

[Todd 76]

S.J.Todd: "The Peterlee Relational Test Vehicle: A System Overview", IBM Systems Journal, vol.15, no.4, 1976.

[Urschler 69a]

G.Urschler: "Concrete Syntax of PL/I", IBM (Vienna) Techn. Rept.No. TR25.096, Vienna, Austria, June 1969.

[Ursehler 69b]

.......... : "Translation of PL/I into Abstract Syntax", IBM (Vienna) Techn.Rept.No.TR25.097, Vienna, Austria, June 1969.

in:

382

[Uzgalis 77]

J.C.Cleaveland & R.C.Uzgalis: "Grammars for Program ming Languages", Elsevier Comp.Sci.Lib., Prgr.Lang. Ser. vol.4, N.Y., 1977.

[Walk 69]

K.Walk, K.Alber, M.Fleck, H.Goldmann, P.Lauer, E.Moser, P.Oliva, H.Stigleitner & G.Zeisel: "Ab= stract Syntax and Interpretation of PL/I (ULD Version III)", IBM (Vienna) Techn.Rept.No.TR25. 098, Vienna, Austria, Apr.1969.

[Wegner 72]

P.Wegner: "The Vienna Definition Language", ACM Computing Surveys, vol.4, no.l, March 1972.

[WeissenbSck

75]

[van Wijngaarden

F.Weissenb~ck: "A Formal Interface Specification" IBM (Vienna) Techn.Rept.No.TR25.141, Vienna, Au= stria, Feb.1975. 62] A.van Wijngaarden: "Generalized ALGOL", in: 'Sym= bolic Languages in Data Processing', Proc° ICC Symp., Rome, Gordon & Breach, N.Y., pp.409-419, 1962.

[Wirth 71]

N.Wirth: "Program Development by Stepwise Refine= ment", Comm.ACM, vol.14, no.4, pp.221-227, 1971.

[Wirth 73]

....... : "Systematic 1973.

[Wirth 76]

....... : "Algorithms + Data Structures = Programs", Prentice-Hall, 1976.

[Zahn 74]

C.T.Zahn: "A Control Statement for Natural TopDown Structured Programming", in: 'Programming', Springer Verlag, 'Lecture Notes in Computer Sci.', voi.19, pp.170-180, 1974.

[Zemanek 66]

H.Zemanek: "Semiotics Comm.ACM, pp.139-143,

[Zimmermann

69]

Programming",

Prentice-Hall,

and Programming 1966.

Languages",

K.Zimmermann: "Outline of a Formal Definition of FORTRAN", IBM (Vienna) Lab.Rept.No.LR25.3.053, Vienna, Austria, June 1969.