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

Author: D. Bjorner | C.B. Jones

43 downloads 942 Views 15MB Size Report

This content was uploaded by our users and we assume good faith they have the permission to share this book. If you own the copyright to this book and it is wrongfully on our website, we offer a simple DMCA procedure to remove your content from our site. Start by pressing the button below!
Report copyright / DMCA form

DOWNLOAD PDF

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


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


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

end

@

env1,c 4

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


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


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+ ~


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 )


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


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

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:


interpretation func-

tions;

ev~l-Xyz

(for imperatively stated) respectively:

V-Xyz

for


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


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:

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~)~;

Row~ := (cRow~)~; 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:

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

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 >, ,.'',;

if {3i £ {l:len ebdl})(ebdl[i])

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 ( , 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< 1 al ] i_~n in

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 = 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 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

,

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)

=

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

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)(?) &

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 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)

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

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~))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~) 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)(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 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. } = 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. } 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.}

= 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 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

(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

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]

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),) = 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)

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 = 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 = 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 = 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 = 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,)

=

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:)

= 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))

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.

The Vienna development method: the Meta-langauge

The Vienna Development Method.. The Meta-Language

Practical HPLC Method Development

Practical HPLC Method Development

HPLC Method Development for Pharmaceuticals

The Rough Guide to Vienna

Cambridge and Vienna: Frank P. Ramsey and the Vienna Circle

Cambridge and Vienna: Frank P Ramsey and the Vienna Circle

The Voices of Wittgenstein: The Vienna Circle

Vienna Blood

The Probabilistic Method

The Discrepancy Method

The Method of Nature

The projection method

The Probabilistic Method

The Probabilistic Method

The Rietveld Method

The Breathing Method

The Activator Method

The Lotte Berk Method

The Method of Coordinates

The Monte Carlo Method

The immersed interface method

The State Space Method

Behind the Geometrical Method

The Method Trader

The Hardy-Littlewood method

The Sedona Method

The Sedona Method

The Guitar Grid Method

Vienna Secrets

The Vienna development method: the Meta-langauge

The Vienna Development Method.. The Meta-Language

Practical HPLC Method Development

Practical HPLC Method Development

HPLC Method Development for Pharmaceuticals

The Rough Guide to Vienna

Cambridge and Vienna: Frank P. Ramsey and the Vienna Circle

Cambridge and Vienna: Frank P Ramsey and the Vienna Circle

The Voices of Wittgenstein: The Vienna Circle

Vienna Blood

The Probabilistic Method

The Discrepancy Method

The Method of Nature

The projection method

The Probabilistic Method

The Probabilistic Method

The Rietveld Method

The Breathing Method

The Activator Method

The Lotte Berk Method

The Method of Coordinates

The Monte Carlo Method

The immersed interface method

The State Space Method

Behind the Geometrical Method

The Method Trader

The Hardy-Littlewood method

The Sedona Method

The Sedona Method

The Guitar Grid Method

Vienna Secrets

Recommend Documents