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!
into
into
MAP Domains -- C o n t i n u e d
The logical type expression:
(At M Sl) U_ (A~ M S~) k
..... U_ (A~ M B k)
denotes the class of objects whose m e m b e r s are finite d o m a i n m a p s as above but w i t h the r e s t r i c t i o n that A I objects, i.e. in the domain,
if at all mapped,
are m a p p e d into B I objects, A 2 objects
into B 2 objects,
(...)
.... and A k o b j e c t s into B k objects. We read the U MAP d o m a i n o p e r a t o r as a 'merge'-, rather than (as we did for I)
an 'either'-, union operation.
83
If we w i s h
cords,
to c o n s t r a i n
integer
and c h a r a c t e r s t r i n g
racte r s t r i n g s ,
U
m
The
expression
MAP Domains
Defining
logical
maps
whose
field
fields
re-
are cha-
(QUOT + ~ QUOT ++)
of the r i g h t kind
for s p e c i f y i n g
the above:
-- T e r m i n a t e d
I
(A2 ~ B e )
a class of objects
from A 1 into B1,
member
into records
into integer
type expression:
(A I ~ B1) denotes
keys
to m a p
then:
(INTG ~ I N T G O
is a d o m a i n
keys
is either
I
...
I
whose members
(Ak ~ B k)
are finite
domain,
partial
or A 2 into B2,... , or A k into B k. Thus
an A 1 ~ B 1 object,
a given
or an A 2 ~ B 2 object, .... or an
A k ~ B k object.
If f i n a l l y
any one
in its key d o m a i n
file should not m i x i n t e g e r s or r e c o r d
(INTG
~ INTG +) m (QUOT + ~ QUOT ++) m
is a d o m a i n
expression
co-domain,
and c h a r a c t e r s t r i n g s
then:
I (INTG
~ QUOT++) I m I (QUOT + ~ INTG +)
guaranteeing
this:
Note
that the d o m a i n
ex-
pression:
(INTG]QUOT+)
permits
~
any one r e c o r d
being c h a r a c t e r s t r i n g s .
(INTGIQUOT+)+
to have
some fields being
If that is your
a w a y in w h i c h you can so express
it!
integers,
others
ideas a b o u t records,
this
is
84
Note:
A map or a f u n c t i o n from subsets of A into B is said to be a partial map,
r e s p e c t i v e l y partial
function.
It is quite common to deal with
partial maps.
Prg~r _a~nin~
Note:
D e f i n i n g a class of functions using the ~ o p e r a t o r shall express that such objects have their graph, c o m p u t e d w h e n defined.
i.e. a r g u m e n t - v a l u e associations,
This is in c o n t r a s t to using the ~ and ~ ope-
rators whose use in d e f i n i n g total and partial functions shall express that the objects are i m p l i c i t l y d e f i n e d through some l-expressions-like device,
about w h i c h it can be said that the g r a p h of the
d e n o t e d function is not c o m p u t e d w h e n defined -- in fact: c o m p u t e d -- and where, infinite.
4.2
in addition,
the function domain(s)
For the story on such functions see section
is never may be
5.
R e p r e s e n t i n g Instances of MAP Objects
4.2.1 E x p l i c i t E n u m e r a t i o n Let al, a 2,
..., a d be d i s t i n c t A objects, ai!, ai2, ..., aid be distinct A i objects, b 1, b 2, ..., b d be not n e c e s s a r i l y d i s t i n c t B objects, and bjl , bj2, ..., bjd be not n e c e s s a r i l y d i s t i n c t Bj objects, then the c o n s t r u c t o r expressions:
[al~bl,a2~b2,...,ad~bd ]
and:
[ail~bjl,ai2~bj2 ..... aid~bjd ] denote maps from
(subsets of) A into B, r e s p e c t i v e l y
(subsets of) A i
into Bj, i.e. in: A m ~ B, r e s p e c t i v e l y A i ~ Bj. The c o n s t r u c t o r expression:
85
[a11~b11,a12~b12,~'°Jalm2~blml , a21~b21,a22~b22,''',a2m2~b2m2 , akl~bkl,ak~bk2,''',akmk~bkmk ] denotes a m a p in:
(At M BI)
_U (A 2 M S~)
a s s u m i n g of course that ing index,
_U ...
_U (A k M S k)
aij6Ai, bijEB i that is: that first A i r e s p e c t i v e l y B i. And:
subscript-
i, binds to domain
[ax1~byl,ax2~by2,...,axm~bym ] denotes a map in:
(ALIA21 .... A n ) ~
(BIlB21'''IBl)
provided:
axi6(AlIA21... IAn)
and
byj£(B lIB21.,. IBl).
-- is d e n o t e d by:
[]
Let
lid1, lid2,°.. , lid I let kij etc.
file names;
denote,
i.e. be a b s t r a c t i o n s of, d i s t i n c t
denote,
i.e. be a b s t r a c t i o n s of keys d i s t i n c t
for f i x e d i's; and let r.. etc. denote, n e c e s s a r i l y d i s t i n c t records.
Then:
i.e. be a b s t r a c t i o n s of not
88
[fid 1 -' [kl 1"~r11" k12"*r12" " ~ " " klnl~rln I ~" fid8
-~ [k21-~r21 , k22"~r22 , • . ., k2n2-~rsn2 ],
. . ,
lid I
[kl1~rll
is a s c h e m a t i z e d
(...)
p r o v i d e d fidi£Fid, If Key
kl2"~rl2 , . . . ,klnm~rlnl
snapshot of an object in Fid ~
kij£Key
(Key ~ REC),
and rij6REC.
= INTG and REC = QUOT ++ then:
[~ ~ <
7 ~ < < E , U , G , 2 , S_>,<S>>] r e p r e s e n t s a file of three records, w i t h keys 3,5 and ?; etc. Whereas keys of any one file need be distinct,
records or any two keys
of r e s p e c t i v e l y d i s t i n c t l y names files need not be distinct:
[fid e -~ [2-'<3, 4, 5>, 3"<3, 4, 5>], lid B -~ [3-~<3,4,5>,2-~<3,4,5>]]; in fact, as the above example of a snapshot of a small file system shows, d i s t i n c t l y named files need themselves not be distinct.
4.2.2 Implicit E n u m e r a t i o n
Let F: Dd~A
and G: D r ~B denote partial functions,
[ F(d) ~ @(r)
I P(d,r)
]
is a m a p c o n s t r u c t o r e x p r e s s i o n d e n o t i n g a map in sumed to be a predicate:
P:
Dd Dr
then :
~
B00L.
A
-* B. m
P is as-
87
Let
Fi, FTn, Gj, GIZ denote p a r t i a l functions: Fi:
FTn: G,: J G11: for
Dd Dd D r Dr
~ A i, -~ (AIIA2~... JAn), ~B. j -~ (BIIB21...IB l)
i=1,2, .... n and j=1,2,..o,l.
and :
The expressions:
[FiCd)
~ Gj(r)
!
P(d,r)],
[Fin
~ G1l(r)
I
P(d,r)]
d e n o t e m a p s from
and:
(subsets of) r e s p e c t i v e l y
A i into Bj~ and
(ALIA21... IAn) into (BIlB21... IB1). The expression:
where
[F1(d) ~ G1(r) U[F2(d) ~ G2(r)
P I (d, r) ] P2 (d, r) ]
U[Fk(d) ~ Gk(r)
Pk (d, r) ]
Pi are predicates, as above, denotes a map in: ~A I M S I)
~!~ Let
_U ~A 2 M B~)
k
"-
_U
CA~ M S~) .
~: Fr, Ff d e n o t e total (for simplicity: pure, applicative) func-
tions from records into records,
r e s p e c t i v e l y files into files. Let
s denote a file system, f some file, r some record; the next s u b s e c t i o n
(2.3.3) on operations,
note the set of filenames,
let
and, foregoing
dom s and domf
de-
r e s p e c t i v e l y the set of keys, of the f i l e
system -- r e s p e c t i v e l y of a file. Then:
[ lid ~ Ff(s(fid))
I fid 6 dom s]
[ k
I k
~ F~(f(k))
E dom f]
and :
[ fid ~ [ k ~ Fr((s(fid))(k))
1 kEdom s(fid)]
I fid 6dom s ]
88
denotes a file system,
a filer and a file system.
system is derived from a given file system, of its files; dually.
the latter by transforming
sing' programs. or 'accessing'
abstractions
Observe how randomness
f, by transforming
of various
records
(k,
file
of record and file
is p r e s e r v e d by the unorderedness
respectively
each
indivi-
Thus the above three implicit map constructor
expressions m a y be reasonable
(lid)
each of its records
The file is derived from a given file,
each of its records.
The former file
8, by transforming
of
'proces'positions'
'fetching'
files
f(k) ..... ), for transformation.
4.2.3 A Note on Scopes We have now seen three distinct m e t a - l a n g u a g e
constructs
for impli-
cit object constructions:
{ Fr(r)
I
r6f
< Fr(f[i]) 1 [ k ~ FrCf(k))
} 1
I
l f
>
k £ domf
]
In all three,F r and f were quantities sions;
and r, i and k respectively,
defined outside these expres-
were bound variables,
fined and bound to the right of the builder combinator: a scope extending respectively
[ & ]. The scope of these bound variables
i.e. nested expressions,
constructor
I, and with
to the closest embracing pair of { & }, < & >,
analog to those in ordinary programming to inner,
being de-
expressions
languages:
including
-- unless redefined
follow rules
thus they extend
{ }, < > and
[ ] based
in such inner forms,
practice which certainly can and should be avoidedl
a
The last file
system building expression of the previous example section illustrates the doubly nested use of bound variables.
Let: A ~
(B ~ C)
(A B)
"+ C m
So does:
89
be domain e x p r e s s i o n s w h e r e we do not p r e s e n t l y bother about A, B and C. Then: a£A,
for s u i t a b l y decorated,
and o c c a s i o n a l l y distinct,
b6B and c6C:
[ al
~
[bll
~
all,biB
~
a2 ~
[b21
~ c~I,b22
c12],
~ c22~b23
~ c23]
]
and
[ (al,b11)
~ ell, (a1,b12)
~ c12,
(a2, b21)
~ c21, (a2, b22)
~ c22, (a2, b23)
are examples of s o m e h o w
'equivalently'
~ c23]
d e n o t i n g e x p r e s s i o n s in that
functions can be d e f i n e d w h i c h c o n v e r t s b e t w e e n their objects.
Let,
for ease of reference,
the first d o m a i n be named X, the second
Y:
x
=
AM~MC)
Y
=
(A B) ~ C m
then:
c o n v x y (x )= [(a,b)~c
I aEdomx
A bEdom(x(a))
^ c=(z(a))(b)
]
eonvyx(y)= [ a~[b~c
I (a',b)6dom y ^ a'=a
^ c=y(a,b)]
where:
type:
convxy:
X ~ Y
type:
convyx:
Y ~ X
In fact the two f u n c t i o n s are e a c h others'
inverses.
I (a,
)6dom y
]
90
4.3 MAP O p e r a t i o n s
The following special MAP o p e r a t i o n s are provided:
U
merge,
+
override,
(...)
apply, restrict with,
l
r e s t r i c t to,
dom
domain,
rn~
range, composition
Each of these o p e r a t o r s will now be individually,
and quite infor-
mally explained:
maplUmap2
denotes a MAP p r o v i d e d the domains of mapl and map2 are disjoint,
o t h e r w i s e undefine d . The d e n o t e d map
maps d o m a i n e l e m e n t s of mapl m e n t s as does map1,
into the same range ele-
and d o m a i n e l e m e n t s of map2 into
the same range e l e m e n t s as does map2,
and m a p s nothing
else.
mapl+map2
denotes the MAP w h i c h maps d o m a i n elements of map2 into the same range e l e m e n t s as does map2,
and m a p s
those domain elements of map1 w h i c h are not in the domain of map2 into the same range e l e m e n t s as does
mapl, and maps nothing else. map(a)
denotes the range OBJect into w h i c h map m a p s a. If a is not in the d o m a i n of map the o p e r a t i o n is undefined
map~wset
denotes the MAP w h i c h m a p s those d o m a i n elements of
map w h i c h are not in the set wset into the same range elements as does map, and maps nothing else.
91
mapltset
denotes the MAP w h i c h m a p those d o m a i n elements of
map w h i c h are also in tset into the same range elem e n t s as does map, and maps nothing else.
dom map
d e n o t e s the set of objects w h i c h are d o m a i n elements of map.
d e n o t e s the SET of OBJects w h i c h are the range ele-
rng map
m e n t s of map.
map I "map 2
denotes a MAP p r o v i d e d the range of map2 is included, (~) in the d o m a i n of map1, o t h e r w i s e
i.e. c o n t a i n e d
the o p e r a t i o n is undefined.
The d e n o t e d m a p m a p s into
those range e l e m e n t s of mapl w h i c h are m a p p e d to by the d o m a i n e l e m e n t s of map1, m a p p e d into, as range elements of map2 from d o m a i n e l e m e n t s of map2. M o r e formally, and in this case c e r t a i n l y m o r e concisely:
(mapl"map2)(d) = i~ dEdommap2 then if map2(d) E dommapl then mapl(map2(d)) else undefined else undefined
Let s, id, f, r and k stand for a b s t r a c t i o n s of file systems, names,
(1)
files, records and keys,
8 U [idol]
f
then:
U [k-~r]
(2) (3) (4) (5)
id E dora8
k 6 domf
(6)
f 6 rn g 8
r 6 rng f
s + [id-~f]
f + [k-~r]
s'.{id}
f'.~k}
s(id)
f(k)
file
may be reasonable on file systems
abstractions
of the following
(left column)
an entirely new file sense of its name
[record]
[and files
typical operations
(right column)]:
into the file system
[key] not hitherto being one of a file
the system
[file];
(2) updating
the system
[a file];
an entire file
(3) deleting an entire file
[record]
[a file];
[a record];
a file of a given name
a given key] given file
is in the system
(i.e. its
is in the system
'value',
[record]
[a single record]
[keyed with k] from the system (5) asking whether
(i) writing
[a file] -- in the
named id
(4) reading an entire
[a file];
and
not name)
[record
in of
file
[a record with
(6) inquiring whether a ('value',
not key)]
[a file].
Let suitably decorated
id's and k's denote file names,
respectively
keys. Then:
(7)
s l { i d l , i d 2 ..... id n}
seems to be an acceptable
f ] { k l , k 2 ..... k m}
abstraction
for the operation of restricting
the files of a system to those of the indicated names -- i.e. deleting all other!
[respectively
are different from k.
deleting
all those file records whose keys
(l
Combining
the above operations:
(i')
8 + [ id "~ s(id)
U [k-~r] ]
+ [ id -~ s(id)
+ [k-~r] ]
(2') (3')
s + [ id-~
(s(id)'-{r}
]
(4')
(s(id) ) (k)
(5')
k 6 dom(s(id))
(6')
r £ rn~(s (id))
(7')
s + [ id -* ( ( s ( i d ) ) l { k l , k 2 ..... kn})
we get the right column equivalents,
]
on a file system.
93
4.4 MAP-oriented C o m b i n a t o r s
The same combinator:
the for-all-do statement,
as was d e f i n e d for
p r o c e s s i n g sets, is a v a i l a b l e for p r o c e s s e s on maps,
e.g.:
for all d 6 dommap do S(map(d))
We give the imperative v a r i a n t of the last of the three implicit, a p p l i c a t i v e map c o n s t r u c t i o n s shown in the example
25.
dal system := [] t,~<e (Fid ~ (Key ~ REC)), file := [] t _ ~ (Key ~ REC); (for all fid 6 doms
Ci/~
:=
d_~o
[] ;
for all k £ doms(fid) d_~o := ( c ~ )
:= ( c _ ~ )
U [ k ~ Fr ((s(fid))(k)) ] ;
u [ lid ~ Col!{ ~) ]))
4.5 F u r t h e r E x a m p l e s
Examp!~ ~ :
The i n t r o d u c t o r y example of this section is now continued.
We are
now i n t e r e s t e d in d e f i n i n g a number of a u x i l i a r y functions applicable to the o p e r a t i n g system directory. A f u n c t i o n for c a t a l o g u e i n g new entries,
i.e. new resources,
f u n c t i o n of u n c a t a l o g u e i n g e.g.
has
a l r e a d y been shown. The dual
takes a d i r e c t o r y and a non-null
r e s o u r c e name and deletes the d e s i g n a t e d resource -- i.e. returns a d i r e c t o r y in w h i c h the r e s o u r c e name is no longer a valid name:
94
1.0
u n c a t a l c g ( d i r , q)=
.I
cases
.2
q:
(
.3
T
~ dir
t_~:
Provided
~ dir~{id} +
[ hq
DIE R i d +
~
~ uncatalog(dir(hq),~q)
] )
DIR
q indeed does d e s i g n a t e
some r e s o u r c e
in dir~
q, id, r) ,q~
= dir
When
such is
the case we can show that:
uncatalog(catalog(dir,
A function
for testing w h e t h e r
deed d e s i g n a t e
a non-null
something m e a n i n g f u l l
resource
name,
in a directory,
q, does
dir,
in-
is e.g.
the following:
i s u a l i d r n ( d i r , q) = q 6 r e s n m s ( d i r ) type:
D I R R i d + ~ BOOL
where:
3.0
resnms(dir)= [
.i
I rid £ domdir ^ (is-DIR(dir(rid))
.2
T
.3 type:
another
4.0
DIR
~ rn6resnms(dir(rid)), ~ rn = <>)
}
~ Rid+-set
f u n c t i o n w o u l d be:
isrnok(dir,q)=
.i
(hq
.2
^(cases
6 dom dir) t q:
.3
(<>
~
trues
.4
T
~
isrnok(dir(~
type:
DIR
Rid +
~
q ) , ~ q)))
BOOL
w h e r e we rely on the n o n - c o m m u t a t i v e n e s s ,
in the m e t a - l a n g u a g e ,
the b o o l e a n
for r e t r i e v i n g
given
^ and v operators.
its name could
e.g.
A function
be expressed:
of
a resource
g5
5.0
.i .2
retrieve(dir, q)= cases q: (
.3
T type:
~ retrieve(dir(~q),~q)) DIR Rid +
The d o m a i n e x p r e s s i o n
~
Rid m RES
RES also defines the void map,
from no r e s o u r c e i d e n t i f i e r s to no resources,
[],
as part of its domain.
In some of the above f u n c t i o n d e f i n i t i o n s we have tacitly assumed that no
(embedded)
d i r e c t o r y was empty. A p r e d i c a t e function for
testing this w e l l - f o r m e d n e s s c r i t e r i a not e x p r e s s e d by the domain e x p r e s s i o n s m i g h t e.g.
6.0
.i .2 .3
look like:
is-wf-DIRo(dir)= (dir~[]) A(Vrid 6 dom dir) (ia-DIR(dir(rid)) type:
D is-wf-DIR ° (dir(rid)))
DIR ~ BOOL
File i d e n t i f i e r s are part of the directory.
If we e.g.
impose that
no two d i s t i n c t r e s o u r c e names, via d e s i g n a t e d file identifiers, "point" to identical files,
then the above is-wf-DIR ° m u s t be aug-
mented:
7.0 .i .2 .3 .4 .5
is-wf-DIR(dir)= i8-wf-DIRo(ir) A(Vrnl,rn 2 6 resnms(dir)) ((rnl~rn 2 ) ~(((is-Fid(retrieve(dir, rnl))Ais-Fid(r~trleve(dir, rn2) ~(retrieve(dir, rn 1) # retrieve(dir, rn2))))
96
ExamR! ~, 30:
Another
In this example we shall m o t i v a t e the m o d e l i n g of the s c o p e - b i n d i n g and variable concepts of block- & p r o c e d u r e - o r i e n t e d p r o g r a m m i n g languages by means of so-called environments, In s u b s e q u e n t examples,
r e s p e c t i v e l y abstract
(31,40,42,61), we shall then illustrate the se-
m a n t i c s m o d e l i n g of p r o c e d u r e s and blocks of such languages. duction,
stores.
into our realm of a b s t r a c t m o d e l i n g concepts,
and stores will now be argued in a few, short,
The intro-
of e n v i r o n m e n t s
illustrative,
but not
really c o m p l e t e steps. The n o t a t i o n used in the f o l l o w i n g for some arbitrary,
r e a l i s t i c source languages notions of b e g i n - e n d blocks and
v a r i a b l e d e c l a r a t i o n s and use has been d e l i b e r a t e l y c h o s e n to c o i n c i d e w i t h the m e t a - l a n g u a g e s however,
n o t a t i o n for the same constructs.
These will,
not be formally introduced till section i0.
The form:
(dcl v := e x p r type D;
C(..,)) is taken to r e p r e s e n t some source languages block c o n s t r u c t e q u a l l i n g begin,
and ")" the end).
In the semantics of this source lan-
guage v, w h i c h itself is an identifier, In fact:
in this source-,
tion of identifiers
iS
is to denote something constant.
as well as in our meta-,
c o n s t a n t over their scope,
The c o n s t a n t d e n o t a t i o n of v over the above block, scope,
is, rather c o n c r e t e l y speaking,
address)
(with "("
language,
the denota-
i.e. does not change! i.e. its d e f i n i n g
taken to be the location
(or:
of the storage cell in w h i c h are to be held values, ~v, of the
v a r i a b l e v. Thus, locations,
if by LOC, we denote the a b s t r a c t d o m a i n of storage
and by OBJ,
the values w h i c h can be held in those locations,
then the domain of storages can be a b s t r a c t e d as:
L O C ~ OBJ m We choose ~ since there will, at any point of e x e c u t i o n of our source m p r o g r a m % only be a finite number of active variables, i.e. of a l l o c a t e d storage cells. Thus we a b s t r a c t storages as u n i q u e associations, m a p s from locations to their values. To keep track of the location that v a r i a b l e identifiers denote we introduce,
speaking concrete again,
a table, h e n c e f o r t h called an environment,
in w h i c h is r e c o r d e d the a s s o c i a t i o n s of v a r i a b l e names to their locations.
97
Id ~ LOG m
where e.g. v £ Id. A g a i n the a s s o c i a t i o n is functional,
and again the
f u n c t i o n a l recordings are finite. Before a r g u e i n g why we do not directly m o d e l storages as:
Id
~.
m
OBJ
let us first see that we do indeed need the full use of the m e t a - l a n guage M A P concept, plify
'snapshots'
i.e. of the MAP operations. of environments,
of one simple block,
S i m u l t a n e o u s l y we exem-
p, and stores,
d. The example is that
c o n t a i n i n g the d e c l a r a t i o n of the v a r i a b l e named i,
nested in an outer block,
also c o n t a i n i n g the d e c l a r a t i o n of a identi-
cally named variable.
++~ + ÷ ÷ e + ÷ ÷ + + + + ÷ + ÷ + ÷ ÷ ÷ ÷ ÷ + + ÷ ÷ + + + + ÷ + + ÷ + ÷ + (p 0" ~ 0 ) ( dcl.., i := . . . ; t ÷ ÷ + + + ÷ + + + ÷ ÷ ÷ + + ÷ + ÷ + + ÷ ÷ ( P l , O l )
~+~+÷÷÷÷+÷++÷÷~÷÷+ .......... ÷÷÷C~i, ( del
i
:: ...;
oi')
... A~
L ÷ + + + + + ÷ + ÷ ÷ + ÷ ÷ ÷ + ( p ~" ~ 2 )
...
•
"
,.,
•
"
"
•
"
"
. , .
"
$~+÷+++++++++÷÷++÷÷÷÷+÷÷+÷+ ( P 2" ~ 2 ') )
[ + + + + + + + + ÷ + + + ÷ ÷ ÷ ÷ ÷ ÷ + ÷ ÷ ÷ ÷ ( P 1" °1 ") [ ÷ + ÷ + + + + + + + + + + + + ÷ ÷ ÷ ÷ + + ÷ ÷ ÷ ÷ ÷ ÷ ÷ ÷ + ( Pl ' ~1 "' ) )
[ + + + + + + + ÷ + ÷ + ÷ + ÷ ÷ + + ÷ + + + ÷ + ÷ + + + + (P O" ~ 0 ')
The e n v i r o n m e n t i m m e d i a t e l y prior to outer block e l a b o r a t i o n is P0 and the state is d 0. These are not detailed. O b e y i n g the results in the e l a b o r a t o r c l a i m i n g a new, us call its l o c a t i o n li I . Thus:
sl
=
~0 u [li I ~ 01 ]
Pl
=
PO + [i -~ li I]
with:
'first' d e c l a r a t i o n
fresh storage cell for i, let
98
Thus we use U as an a b s t r a c t i o n U since
of the storage
of the e n v i r o n m e n t
n a m e l y be a l r e a d y
in P0" O b s e r v e
"falling
the
recorded
through"
~1' where
=
this,
' on ~0 shall
~2
=
a I' U ['li2 -~ 02 ]
the storage
claimed
the storage
for the inner blocks'
e.g.
PI' r e m a i n
=
SO"
00'
=
01'~{Ii1}
i.e.:
i to e.g.
of storage
-- w h i c h
example.
a recursively of n e s t e d
are the semantics
31 and onwards
for d e c l a r e d
variables
follow
is: ~.
for the use of b o t h e n v i r o n m e n t s
j would permit modeling
[part of]
in the outer block.
as p a r t of the b l o c k epilogue.
of nested b l o c k s
convincing
not
~0"
justification
not solve the p r o b l e m
example
=
deallocation
The above e x a m p l e
fresh,
]
is p e r f o r m e d
abstracting
~ is also
aO" U ['liI ~ 01"]
U [li I ~ 0 1 "
or d e a l l o c a t i o n
(o1')! And:
i.
constant
01"
=
this b l o c k m a y
gO' U [li I -~ Ol',li 2 -~ o 2 ]
~2'~{li2}
is not a s u f f i c i e n t l y
In
=
=
any b l o c k was
to P0
PO + [i -. li 2]
01"
We n o w turn to a brief
locations
=
aO" U [li I ~ 01",li 2 ~ 02']
structure,
outside
i m a y have been u p d a t e d
=
and stores.
-- i m a y
Similarly:
a 2'
The MAP o p e r a t o r
action
that we do "fall back"
block.
for the outer blocks'
how environments,
freeing,
would
'update'
that v a r i a b l e s
Also
Pl + [i -* li 2]
with
inner
indicate
updated.
=
clash i n g
the b l o c k
the outer,
P2
That is:
Thus
--
~0' U [li I -* o1']
have had their v a l u e s
Observe
operation
li I is new, i.e. not in the d o m a i n of 00: li I .~6 dom ~0 ~ But
we use + as an a b s t r a c t i o n
when
allocation
redefining
Static
stores
defined
renaming
variable of e.g.
names the
as Id ~ OBJ. If, however, m p r o c e d u r e static r e n a m i n g
activations'
we n o r m a l l y
i denoting
distinct
expect!
we use ENV and s o m e t i m e s
X as follows:
99
ENV
= =
Finally,
Id ~ LOC m LOG ~ OBJ m
as a last example, we show the m o d e l i n g of v a r i a b l e referencing,
value access and of assignment.
'state'
For the e l a b o r a t o r modeled
(p,a) e l a b o r a t i o n of some V £ d o m p
is
(a) as:
v
i
p(v)
A c c e s s i n g the contents of a v a r i a b l e v:
c v
~(O(v))
i
and a s s i g n i n g the o b j e c t
v
o
:=
•
(value) o to v a r i a b l e v changes the state d to:
~
+
[p(v)
~
o].
The v a r i a b l e s of some source l a n g u a g e are either of scalar or array type w i t h all array objects being scalars. V a r i a b l e references, are to scalars only,
The £ £ ~ S ~ ! S
~2~!~
however,
i.e. not to arrays or a r r a y - s l i c e s thereof.
of v a r i a b l e d e c l a r a t i o n s of a block can be m o d e l e d
as a m a p from v a r i a b l e name i d e n t i f i e r s to their type:
1
Block
::
(Id ~ T y p e )
...
Stmt
Type
::
Scalar-type
[ E x p r +]
with :
2
i.e. w i t h types having an o p t i o n a l
[...] array u p p e r bounds e x p r e s s i o n
list, E x p r +. If the o p t i o n a l part is absent,
i.e. nil,
the v a r i a b l e is
a scalar.
The c o r r e s p o n d i n g
£eman~i~ ~2~5!~ of storages can be m o d e l e d as a map
from scalar l o c a t i o n s to scalar values.
100
3
STG
=
(Bool-loc
~ Bool) m
4
Bool
=
BOOL
I undefined
5
Intg
=
INTG
I undefined
U (Int-loc ~ Intg) -m
where:
E n v i r o n m e n t s keep track of v a r i a b l e name associations:
6
ENV
=
Id ~ L O C m
with :
7
LOC
= Scalar-Lot
i Array-Loc
8
Array-Loa
= (Nl++÷m I n t - L o c )
9
Scalar-Loc
= Int-Loc
U (Nl+÷÷m B o o l - L o c )
I Bool-Loc
with the c o n s t r a i n t that the integer index lists of any g i v e n array l o c a t i o n forms a 'rectangle':
i0.0
(Vl 6 A r r a y - L o c )
.i
(3il E N l + ) ( d o m I = r e c t a n g l e ( i l ) )
w h e r e we i n f o r m a l l y e x p l a i n rectangle:
ii.0
rectangle(
.1
{
The il
'picked'
is
array-dimension,
(to be)
I i k E { l : u b k} ^ l
the tuple, whose length c o r r e s p o n d s to the
and whose k'th e l e m e n t
for the k'th dimension,
dcl STG
(here) as a global m e t a - v a r i a b ! e ,
ST G:
:= [] type STG
In the block p r o l o g u e are
(ub k) is the upper-bound index
all of w h o s e lower-bounds are 1!
A p a r t i c u l a r storage is m o d e l e d
12
}.
(automatically)
(.1-.2)
allocated,
in the block epilogue:
locations of b l o c k d e c l a r e d v a r i a b l e s and these are likewise freed
(.4-.8)
101
int-Block(mk-Block(dclsj...,stl))(p)=
13
.!
(let P' : P + [id ~ get-loc(dcls(id))(p)
.2
iid
£ domdcls
.3
int-Stmt-list(stl)(p');
.4
let loc8
.5
let 81oc8 = { l I ((l£1ocs)
= { p'(id)
.6
Iid
] ;
E domdcl8
} i_~n
^ is-Scalar-Lot(l))
v((1 6 rng al) ^ (al E lots) ^
.7
is-Array-Loc(al))}
.8
:= e S l G
STG
~
~n
sloes)
with:
get-loc(mk-Type(sctp,
14.0 .i
if bdl=nil
.2
then
bdl))
(p)=
(let 1 6 Scalar-Loc
.3
.4 .5
ST~ := ~ S T G
.6
return(1))
be s.t. (Z~£ domcST__.~G)^
1-tp-match(sctp, 1)) U [l~undefined];
else
.7
(let ebdl
.8
: < eval-Expr(bdl[i])(p)
I 1 < i < lenbdl>;
if {3i £ {l:len ebdl})(ebdl[i]<1)
.9 .I0
then error
.ii
else (let 1 £ Array-Lot
.12
be 8.t.
((sol £ rn~ 1)~ 1-tp-match(sctp, sol))
.13 .14
A(dom 1 = rectangle(ebdl))
.15
A(Crng I N d o m c STy) = {});
.16
ST G := ~ S T G
.17
return(l)))
U
[ sol-undefined
I scl £ r n ~ l ] ;
and
15.0
1-tp-match(tp, 1) = ((tp=BOOL) (tp=~NT)
.1
Assuming
16
(i.e.
that the state,
Z
=
~ is-Bool-Loc(1), ~ is-Int-Loc(1))
Z, is d e s c r i b a b l e
as:
S[G ~ STG
Z is a o n e - p o i n t
m
(ST G) map),
the type of the above
functions
are:
102
type:
5.
int-Block:
Block ~ (E~V ~ (Z ~ Z))
get-Loc:
Type
~ (ENV ~ (~ ~(X LOC)))
rectangle:
NI+
~ (N1+)-set
TREEs
Ex_amples
32-33:
Blocks of some source language consists of three d i s t i n c t parts: an u n o r d e r e d set of variable ly named procedures
(Var-set
declarations,
an u n o r d e r e d set of d i s t i n c t -
and an ordered sequence of one or m o r e statements.
Id ~ Proc m
Stmt +)
The above is a domain expressions. If Var denotes the d o m a i n of v a r i a b l e identifiers,
Id that of p r o c e d u r e identifiers, Proc the domain of pro-
cedures and Stmt
the domain of statements;
then the above domain ex-
p r e s s i o n abstracts a nameless d o m a i n of blocks.
These are trees, whose
first s u b c o m p o n e n t s are sets of v a r i a b l e names,
second s u b c o m p o n e n t s
are maps from
identifiers to procedures,
and whose last subcompo-
nents are tuples of statements.
If suitably d e c o r a t e d v's,
id's, p's and s's stand for variables,
p r o c e d u r e names, procedures,
•
and statements,
then:
•
mk( {V l,V 2, . . ,v v} , [id1~Pl , td2~p 2 , . . . ,idp~pp], <s 1,s 2,.. . ,s
>)
and:
({V I,v2,o..,vv }" [idl~p1"id2~p2"" °''idp~Pp]'<Sl"S2"'"
"'e8>)
(the latter c o n s t r u c t o r e x p r e s s i o n having dropped the nameless constructor function, mk) objects.
r e p r e s e n t the way we write down such c o m p o s i t e
If b is a block, or more precisely,
d o m a i n s p e c i f i e d above,
let mk(vs,pm, sl) = b; let
if b is an object in the
then the following m e t a - l a n g u a g e combinators:
(re,pro, s1) = b;
103
provide
means
modelling
of d e c o m p o s i n g
blocks,
variables,
vs;
the s t a t e m e n t
The d o m a i n
into their p r o p e r
the m a p list,
tree
structured
constituents
from p r o c e d u r e
names
objects,
-- here
here
the set of
to procedures,
pm;
and
sl.
expression:
(s-Vars:Var-set
(with inner
(,)'s,
miter)
defines
three
selector
s-stmtl.
nameless
s-procm:(Id
around
Id m Proc,
the same d o m a i n functions,
s - s t m t l : Stmt +)
~ Proc)
m
used o n l y as s y n t a c t i c
as above,
but in a d d i t i o n
here a r b i t r a r i l y
named:
s-vars,
deli-
defines s-procm~
NOW:
let vs = s - v a r s ( b ) , pm = s - p r o c m ( b ) , sl = s - s t m t l ( b ) ;
has
the s~ne e f f e c t
other w o r d s ,
if
vs
as the p r e v i o u s
£ Var-set,
s - v a r s ( m k ( v s , p m , sl))
=
vs,
s - p r o c m ( m k ( v s , p m , sl) ) =
pm,
s-stmtl(mk(vs,pm,
sl.
We can give
sl))
=
sl
a name to the above block domain,
Block
-- note
decomposition
pm 6 I d ~ P r o c , m
::
the d r o p p i n g
Vat-set
of
(,)'s!
Id
With
~ m
combinators.
£ S t m t +,
e.g.
In
then:
Block:
Stmt +
Proc
vs, pm
and sl as before:
m k - B l o c k (vs, pm, 81)
would
~2~ have
to be our way of w r i t i n g
The trees d e n o t e d introduce
by B l o c k
selectors:
are now named
down
instances
(Block).
of blocks.
Also here we could
104
Block
::
(where the limiters).
s-vars:Var-set
s-proem: (Id ~ Proc) m
(,)'s, around Id ~ Proc, m And again:
s-stmtl:Stmt +
again are used as syntactic
s-vars(mk-Block(vs,...,...))
= vs
etc.. A benefit derived from naming the class of constructed objects,
here Block,
de-
tree
is that any object can be tested for member-
ship of the named domain:
is-Block(b)
is true provided
b is the result of some m k - B l o c k ( v s , p m , sl) -- for
any applicable vs, pm and 81.
5.1
D efinin~ Domains o_~f TRE___~EObjects
Two means of defining domains of tree objects exist in the metalanguage: (i)
Named:
Using the abstract
syntax rule d e f i n i t i o n
:: to separate definiens
D
(2)
AnonymOu§:
::
D I D 2 ... D n
Using the domain expressions
operator
(D 1 D 2 ... D n)
The former defines named or root labelled
(i)
{ m k - D ( d l , d 2, ..°, d n)
trees:
I i s - D .(d.) for all i }
The latter defines unnamed trees: (2)
{ mk(dl,d2,...,dn)
or, dropping
the mk:
symbol
from definiendum:
I i s - D i ( d i) for all i }
(...),
105
{ (dl,d 2 .... ,d n)
{ i s - D i ( d i) ~ o r all i }.
Exam~!~ 34: Statements while-do
Observe
of a source
statements
Stmt
=
Asgn
Asgn
::
Id E x p r
While
::
E x p r Stmt
IfThen
::
E x p r Stmt
are e i t h e r
assignment
statements,
statements:
J While
I IfThen
h o w the two last domains:
{ mk-While(e,s)
I is-Expr(e)
^ i8-Stmt(s)
}
{ mk-IfThen(e,8)
i is-Expr(e)
^ i8-Stmt(s)
}
are d i s j o i n t tions,
language
or if-then
-- simply b e c a u s e
mk-While
5.1.I
and m k - I f T h e n ,
Tree C o n s t r u c t o r
For any two D' and D" structing
abstract
the n a m e s of their o b j e c t m a k e
Axioms
identifiers
syntax
rules:
D'
::
A 1 A 2 ... A m
D"
::
B 1 B 2 ...
Bn
objects:
m k - D ' (al, a2, . . ., am), m k - D " ( b 1, b 2, • . ., b n) are i d e n t i c a l
if and only
func
are distinct:
if
(iff) :
being definienses
of tree con-
108
D' is the same i d e n t i f i e r
as D";
~ ~ n; ai
= bi
for i.e.
that is,
all
i,
if A. is the same
iff the two rules
For any two i m p l i c i t
above
identifier
as B.
are the same.
tree d o m a i n d e n o t i n g
expressions:
(A 1 A 2 ... A m) (B 1 B 2 ... B n) objects:
mk(al,a2,...,am) m k ( b l , b 2 , . . . , b n) or, w h i c h
is the
same:
(al,a2,...,a m) (bl,b 2 .... ,b n) are identical
iff:
m = n, a.=b. Ai
Example
is
the
and
same identifier
as
Bi
for
all
i.
35-36:
The a b s t r a c t
syntax
CTLG
=
Define
::
are i n t e n d e d
CaTaLoGues,
rules:
Fid ~ (Ktp Dtp) m Fid (Kip Dtp)
to define
the s~mantic
respectively
domain
thesyntactic
of file d e s c r i p t i o n
domain
of file d e f i n i t i o n
107
commands.
To each file,
in the catalogue,
i d e n t i f i e d by its name
is associated,
its d e s c r i p t i o n -- namely a 'pair' c o n s i s t i n g of a
Key type-, and a D a t a type-
indication,
A file d e f i n i t i o n c o m m a n d names,
(fid 6 Fid),
(in Fid)
say lid,
and gives the Key type-,
an object likewise in (Ktp Dtp).
i.e. an o b j e c t in (Xtp Dtp). the file to be defined
and Data type
indication,
In p a r t i c u l a r a catalog,
i.e.
ctl~, m a y
look like:
[ fid I ~ mk(ktPl,dtPl) , fid n ~ mk(ktPn, dtPn)
],
w i t h a define c o m m a n d looking like:
mk-Define(fid, mk(ktp, dtp)). D r o p p i n g the s o m e w h a t superfluous m e n t i o n i n g of the o t h e r w i s e nameless mk
define
(prefixing command,
(...)), we get that ctl~,
upon e x e c u t i o n of the
is a u g m e n t e d to:
ctlg U [fid ~ (ktp, dtp)] provided,
of course lid ~ 6 dom ctlg]
As a n o t h e r example of n a m e l e s s tree c o n s t r u c t i o n s
let us a b s t r a c t
the syntactic d o m a i n of p n o c e d u r e s of some source language
Proc
::
:
(Id Tp) ~ Block
(Id Tp) ~ could be w r i t t e n Parm a , i.e.:
The form
Proc
::
Parm ~ Block
::
Id Tp
provided:
Parm
In the former case the p a r a m e t e r
list is a b s t r a c t e d as a p o s s i b l y
108
z e r o - l e n g t h tuple of parameters, trees,
themselves being
their Types
these being a b s t r a c t e d as n a m e l e s s
'pairs' of formal p a r a m e t e r I d e n t i f i e r s and
(not being further specified).
p a r a m e t e r s are a b s t r a c t e d as named d e c o r a t e d id's, spectively,
(Parm)
In the latter case these trees. Given that s u i t a b l y
tp's and b's denote objects in Id, Tp and Block,
we get,
in the two cases,
re-
that:
mk-Proc ( <( idl, tP l ) , (id2, tP 2) .... , (idn, tPn ) >, b) respectively:
m k - P r o c ( <mk-Parm (id 1, tP l) , . . . , m k - P a r m (idn, tPn)>, b) display instances of p r o c e d u r e s a c c o r d i n g to either abstraction.
Thus
observe that the (,)'s in (Id Tp) ~ serve the double f u n c t i o n of constructing a domain of a n o n y m o u s trees, as well as i n d i c a t i n g the scope of the tuple d o m a i n b u i l d i n g
~ operator.
5.2 R e p r e s e n t i n g Instances o_~f TRE___EEObjects
G i v e n objects oi, e.g.: DI,
D2,
02,
...,
Dn,
(oi,o2,...,On), denote
(identical)
...,
o n of not n e c e s s a r i l y d i s t i n c t domains,
the c o n s t r u c t o r expressions:
m k ( O l , O 2 , . . . o n)
tree objects of domain:
(D I D 2 ... D n) i.e. an anonymous tree. Given that there exists an a b s t r a c t syntax rule of the form:
D
::
D I D 2 ... D n
the c o n s t r u c t o r expression:
m k - D ( O l , O 2 , . . . , o n) denotes a tree object of domain D, i.e. a root labelled tree.
409
5.3
TREE
Operations:
Selector Functions
The only special o p e r a t i o n d e f i n e d on T R E E s
is the selector function.
Names of s e l e c t o r f u n c t i o n s are either explicitly,
or implicitly,
de-
finable.
E x p l i c i t l y D e f i n e d S e l e c t o r F u n c t i o n Names
In the named tree c o n s t r u c t i n g a b s t r a c t syntax rule:
D
::
s - n m 1 : D 1 s - n m 2 : D 2 ...
s-nml:D l
as well as in the a n o n y m o u s tree c o n s t r u c t i n g d o m a i n expression:
(s-nm1:D 1 s-nm2:D 2 .~
s - n m l : D l)
the i d e n t i f i e r s :
8-nml,
8 - n m 2,
...,
s-nm l
denote selector functions obeying:
s-nml(mk-D(Ol,O2,°
~.,ol))
8-nm2(mk-D(Ol,O2,...~Ol))
=
e1
=
02
=
ol
. . .
s-nml(mk-D(Ol,O2,...~Ol)) respectively
8-nm1((Ol,O2,...,o 8-nm2((oi,o2,.
l)
=
o1
• .,o l)
=
02
• .,o l)
=
ol
. ° .
s-nml((ol,o2,. for all Ol,
0 2 ....
, oI .
In the above, explicit,
selector f u n c t i o n name d e f i n i n g forms,
assumed that all i d e n t i f i e r s
s - n m i and 8 - n m j
w i s h to omit any subset of these, past.
are distinct.
it is
You may
including all, as we have done in the
110
!~!i~!~!Y
Defined Selector F u n c t i o n Names
A s s u m i n g uniqueness of D.
D
::
, for some or all i in {l:l} in:
D 1 D 2 .,.
Dl
respectively:
c~
o~),
D2 . . .
and in particular,
a s s u m i n g that D° is an identifier,
the above two tree
d o m a i n c o n s t r u c t i n g forms define the selector function:
s-D i .
In the source language S t a t e m e n t
8-Id
Stmt
=
Asgn
Asgn
::
Id Expr
While
::
Expr
applies to A s g n
to A s g n
and While
plies to While size:
I While
Stmt
objects and yields ~he Id component;
objects and yield the E x p r component;
objects and yield the p r o p e r Stmt
'proper component'
syntax rule,
syntax rules:
since any While
is itself a Stmt
s-Expr
applies
and 8 - S t m t
component.
ap-
We empha-
object, by the first a b s t r a c t
object.
N 2 n z U n i ~ u e Selector F u n c t i o n Name C o n v e n t i o n
For the common case w h e r e two or m o r e identifiers,
D
::
D 1 D 2 ...
D1
or:
(D I D 2 ...
are the same,
o l)
the following c o n v e n t i o n is adopted:
D i and Dj,
of either:
1It
In
the form D 1 D 2 ...
the same
identifier,
s-C-I,
s-C-2,
are the s e l e c t o r respectively
In the source
For
object
...
For
::
Id E x p r
If
::
Expr
function
components
and s - S t m t - i
::
~ For
select
C component
of
the Ist,
the 2nd,...,
-- from left-to-right.
syntax rules:
I If
Expr
Stmt
Expr
Stmt ~
Stmt
s-Expr-lj as w o u l d
s-Expr-2 s-init,
Id s - i n i t : E x p r
and 8 - S t m t - 2
and s - e l s e
If
which
Statement
=
For
s-then
functions
the kth p r o p e r
language
occurrences
. . ~j s-C-k
Stmt
the s e l e c t o r
D l let there be k d i s t i n c t
say C, then:
selects
and s - E x p r - 3
s-step
select
and 8 - l i m i t
s-step:Expr
in:
s-~imit:Expr
the same I f o b j e c t
the same
Stmt*;
components
as w o u l d
in:
::
Expr
s-then:Stmt
s-else:Stmt.
leaves
unexplained
the names of the i m p l i c i t l y
E~og~_a.~_!n~ N o t e s The m e t a - l a n g u a g e fined s e l e c t o r
and:
functions
Block
::
For
::
Id-set
(Id~Prc) Stmt ~ m s-cv:Id (s-i:Expr s-b:Expr
In the
latter
form there are only
tions,
namely
the two s e l e c t i n g
objects
de-
in such forms as:
s-t:Expr) + Stmt*
two i m p l i c i t l y
the
(Expr
Expr
defined
selector
func-
Expr) + and Stmt ~ tuple
of For objects.
The r e a s o n
for i n t r o d u c i n g
pragmatic.
That
is:
there
explicit is,
selector
in m o s t cases,
function
names
no t e c h n i c a l
is m o s t l y
need
for in-
112
venting
names.
tor functions
To see "this,
recall
is to select p r o p e r
that the t e c h n i c a l
of selec.
of trees.
But this
use of the m k
function!
Let e.g.
t into its n subcomponents.
So w o u l d :
could as well be done by a
(sub-)components
purpose
'reverse'
t be an o b j e c t of
(D I D 2
then:
the
...
let
clause:
let
(oi,o2,
so-to-speak
Dn) ,
.... o n ) =
decomposes
let
01
=
o2 =
t
S-Dl(t), 8-O2(t)
,
o.°
o
=
s-D
n
provided,
of course,
for D objects
D
leading
all D i were
distinct
t, where:
::
DI D2
...
Dn
to:
let
etc..
(t) n
mk-D(Ol,O2,...,o
n)
=
t
(and)
identifiers!
Similar
1t3
6 FUNCTIONs By a function, we shall -- in a s o m e w h a t c i r c u l a r fashion -- understand an o ~ e { a ~
which, w h e n ~ ! ~
call its ar~_um_en~ ~ ! ~
to something, w h i c h we shall
a c e r t a i n thing as the v a l u e of the f u n c t i o n
for that argument.
The object to w h i c h the function is applicable, g u a r a n t e e d to yield a v a l u e
(defined result),
i.e. for w h i c h it is
c o n s t i t u t e s the d o m a i n
of the function. The y i e l d e d values c o n s t i t u t e the ~an~e domain)
(or: co-
of the function.
Two functions are i d e n t i c a l iff they the same range, and
(i) have the same domain,
(2)
(3) for each a r g u m e n t in the d o m a i n the same va-
lue. FunCTion e q u a l i t y is, however,
not a d e f i n e d operation.
To denote the value of a f u n c t i o n for a given a r g u m e n t we write a name of the function, a; the latter,
say f, f o l l o w e d by a name of the argument,
say
the former or b o t h p o s s i b l y e n c l o s e d b e t w e e n paren-
theses:
fa, f(a),
(f)(a)~ (fa), (f}a
M a n y functions can m o r e easily be d e s c r i b e d algorithmically,
i.e. by
a recipe for how to compute the result value g i v e n an a r g u m e n t value, than by e x p l i c i t or i m p l i c i t enumeration. Moreover, such,
functions, w h i c h we w i s h to m a n i p u l a t e
some,
if not m o s t
(create, pass and apply) f
have an infinite d o m a i n -- and by the p r a g m a t i c s of MAPs could not be c o n s t r u c t e d as such. Finally: m a n y functions can best be d e s c r i b e d in an implicit,
or even recursive,
the image, or thought, finitions.
way, w h i c h c e r t a i n l y does not conjure
of its graph being c o m p u t e d at the time of de-
(By the g r a p h of a f u n c t i o n we u n d e r s t a n d the set of all
a r g u m e n t result
'pairs'.)
For m a p s this g r a p h is indeed being c o m p u t e d at "time" of definition, w h e r e a s we m a y think of this g r a p h never b e i n g c o m p u t e d in c o n n e c t i o n w i t h the k i n d of f u n c t i o n d e f i n i t i o n s we are i n t e r e s t e d in in this section.
114
Ex_am_ples 39-40:
The following
is a b l o c k - e x p r e s s i o n
is that of the d e n o t a t i o n
of the m e t a - l a n g u a g e ;
of f, w h i c h
is the factorial
(le.~ f(n) = if n=O then I else nxf(n-1)
its v a l u e
function:
in
f)
Let,
as another
cedure
example,
the p r o c e d u r e
name -- and p r o c e d u r e
stract s y n t a c t i c a l l y
Prc
::
body,
describable
of some
The m e a n i n g
- name),
language
of p r o c e d u r e
be ab-
definienses
Id of the d o m a i n of formal p a r a m e t e r statement
of a procedure,
according
source
of pro-
Id ~ Block
Block of blocks -- as e.g.
may,
-- e x c l u s i v e
as:
Here Prc is the name of the d o m a i n der + body,
header
i.e.
to the school
a function
from a r g u m e n t
denotation
of these
and
blocks.
the d e n o t a t i o n
of m a t h e m a t i c a l
of a p r o c e d u r e
semantics,
lists to the d e n o t a t i o n
latter
(hea-
names,
are functions
Of blocks.
from states
name,
be taken as If the
(Z) to states
then:
Prc: ARG ~ ~ (Z ~ Z) a Pro object,
Given give
prc,
the f u n c t i o n w h i c h
i.e. itself
one of the form mk-Prc(idl, bl), we now yields
a last preparation,
procedure
rather
environment.
than c a l l i n g
the d e n o t a t i o n
denotations
of prc. Let,
be f u n c t i o n s
V-prc(mk-Prc(idl, bl))(O)(~) = (Set fct(al)(~) = (let p' = [ idl[i]~al[i]
J 1
I-Blk(bl)(o+p')(~))
fct) Observe place nored,
the following:
in a d e f i n i n g
evaluation
environment,
of a P r o c e d u r e p, and state,
and need thus not have been
shown.
as
of the d e f i n i n g
denotation
o. The state
takes is ig-
The r e s u l t of P r o c e d u r e
115
e v a l u a t i o n is a function, f c t . in the t h r e e - l i n e as follows:
let
This f u n c t i o n is c o m p l e t e l y d e s c r i b e d
clause. The d e f i n i t i o n g i v e n there can be read
is that f u n c t i o n w h i c h w h e n a p p l i e d to some a r g u m e n t
fct
list, al, and in some state,
~, will y i e l d a new state. This new state
results from I n t e r p r e t i n g the B l o c k ('slightly') fiers,
in the d e f i n i n g e n v i r o n m e n t
e x t e n d e d -- by the b i n d i n g s of formal p a r a m e t e r identito actual,
idl[i],
c a l l i n g state, function,
b~
call time, arguments,
al[i] -- and in the
~. We do not here d i s p l a y the I - B l o c k
elaboration
but see section 6.3.
6~! ' D e f i n i n ~ Domains of F u n C T i o n
Let A and B denote Domains.
Objects
To d e f i n e the class of i m p l i c i t l y l-de-
fined objects w h i c h are partial,
r e s p e c t i v e l y total functions
from
A into B, we use the d o m a i n e x p r e s s i o n o p e r a t o r s ~, r e s p e c t i v e l y ~: N
A -~B,
A -~B
A p p l y i n g the a b i l i t y to d e s c r i b e f u n c t i o n spaces to the b u i l t - i n o p e r a t i o n s of the m e t a - l a n g u a g e itself, we can now list the logical type of these: Sets:
type:
U:
SET
SET
~
SET
N:
SET
SET
~
SET
~:
SET
SET
~
SET
c:
SET
SET
~
B00L
c:
SET
SET
~
B00L
SET
~
SET
power: union: £ a,ard
OBJ
SET
~
SET
SET
~
BOOL
SET
~
NO
116
Tuples:
type:
~:
TUPLE
type:
~ TUPLE
h,
hd:
TUPLE
~ OBJ
t,
tl:
TUPLE
~ TUPLE
~,
fen:
[.]:
Maps:
TUPLE
TUPLE
TUPLE
~ NO
N1
~ OBJ
elems:
TUPLE
~ SET
ind:
TUPLE
~ N1-set
cone:
TUPLE
~ TUPLE
+:
TUPLE
MAP
~ TUPLE
~:
TUPLE
Nl-set
~ TUPLE
U:
MAP
MAP
~ MAP
+:
MAP
MAP
~ MAP
~:
MAP
SET
~ MAP
I:
MAP
SET
~ MAP
(.):
MAP
OBJ
~ OBJ
MAP
~ SET
dom: rn~: ":
MAP
MAP
~ SET
MAP
~ MAP
The reason why certain of these o p e r a t i o n s are partial functions will now be explained. just expresses: whereby:
SET-set SET-set. type:
The u n i o n o p e r a t i o n applies to sets of sets, S E T
sets of objects. We could get around this by w r i t i n g type:
union:
hd and tl applies
hd:
O B J + ~ OBJ,
SET-set
t kl:
OBJ + ~ O B J *
[i], m u s t have i lie in the i n d e x fined, type: MAP
conc cone:
~ SET,
i.e. u n i o n
to n o n - z e r o length tuples,
T U P L E ~ ~ TUPLE.
-- note totality.
set of the tuple,
is to tuples w h a t u n i o n
is to sets,
Updating
is total over
i.e.: Indexing,
otherwise unde-
i.e.
(+) tuple elements m u s t have
in (N I ~ OBJ) w i t h domain e l e m e n t s be in i n d e x set of tuple. So
not even:
type:
+:
TUPLE
(N 1 ~ OBJ)
~
TUPLE would make
+ total
over d e f i n e d domain.
6.2 R e p r e s e n t i n g Instances o f F u n C T i o n Objects This section is somewhat d i f f e r e n t l y o r g a n i z e d than were o t h e r w i s e c o m p a r a b l e earlier sections
(i.2 for i=2,3,4,5).
In a number of subsec
tions we recount basic aspects of so-called h-expressions.
117
We shall
shortly,
understanding
in a s e q u e n c e
of f u n c t i o n a l
forms w h i c h d e n o t e expressions
covered
gument-value
association
of de f i n i t i o n ,
and w h o s e
4. A n o t h e r
are used
is k n o w n
steps,
at an
to w r i t e
of forms were
the m a p
such form is that of X-
to define
(i.e. b e i n g
domain-range
arrive
The idea b e i n g
One such class
in section
Map e x p r e s s i o n s
small
abstraction.
functions.
9 ~ q ~ "
of eight
functions
fixed)
whose
ar-
at the instance
sets are i n d i v i d u a l l y
known
and finite.
Functional
Abstraction
(0)
There
are § ! ~ ! ~
(1)
Simple
names are either
thing,
or their d e n o t a t i o n
Composite
and
~2~2~
names express
of the w a y in w h i c h
proper
arbitrarily
names.
assigned
has b e e n a s s i g n e d
through
to denote
some-
an a r b i t r a r y
their s t r u c t u r e
name.
some a n a l y s i s
they denote.
(2)
A constant
is a p r o p e r
name having
(3)
A variable
is a p r o p e r
name w h o s e
a fixed,
denotation
or single denotation.
m a y range over a
set of values.
(4)
An e x p r e § s ! o n
is a name c o n t a i n i n g
o t h e r names
as proper
consti-
tuents.
Composite
(5)
names
A form is either more proper
(6)
are e x p r e s s i o n s .
In o r d e r
names
a variable
have been r e p l a c e d
to s p e a k a b o u t
form is we a b s t r a c t three
symbols:
or an e x p r e s s i o n
the
in w h i c h
one or
by variables.
function of a free v a r i a b l e
the form by p r e f i x i n g
that a
it w i t h a s e q u e n c e
of
a ~, the free variable and a dot.
ly.3+y is the f u n c t i o n of y that 3+y is; i.e. w h i c h increments any number by thr£e.
(7)
The p a s s a g e functional
from a fo_r_m to an a s s o c i a t e d abstraction.
function
is c a l l e d
118
Functionally
abstracting
ly.3+y,~x, hy.x+y r e s p e c t i v e l y by-3
function,
the a d d i t i o n (say)
lx. ly.x results
(of two numbers)
function
from
booleans
(y) to that integer x.
integers
a rather
detailed
names,
use of the concepts:
le
shall
imply the i n c l u s i o n
(identifier)s.
Forms
expressions
are h e n c e f o r t h
and the
functions
restricted
of simple
in the i n c r e m e n t function
(x) to c o n s t a n t
In the above we have e m p l o y e d
expression
3+y, x+y and hy.x into e.g.
the forms:
from
(say)
and not c o m p l e t e l y and forms.
constants
The term
and variab-
expressions.
~expressions
Any c l a u s e
(expression
or statement),
can be f u n c t i o n a l l y
abstracted,
not
variables,
(for f r e e / b o u n d
Functional
abstraction
clause,
whether
of the m e t a - l a n g u a g e
containing
free v a r i a b l e s
or
see below).
in zero v a r i a b l e s
is written:
~ () .c lause Writing,
in the m e t a - l a n g u a g e ,
the definition:
let f = h().clause or :
let f() = clause -- w h i c h
is e q u i v a l e n t
tion of no v a r i a b l e s
-- thus
scope of the definition, without
() shall
occurrence
i.e.
then denote
If the v a l u a t i o n then r e p e a t e d
f as a name
is. A n y s u b s e q u e n t
use in c o n t r a s t the function,
in the scope of the d e f i n i t i o n
the e l a b o r a t i o n
may r e s u l t
identifies
that clause
for the func-
occurrence
to definition,
whereas
in the
of f
any s u b s e q u e n t
of f of f()
shall denote
of clause.
of clause
occurrences
in d i s t i n c t
is d e p e n d e n t of f(),
f(),
i.e.
on a state
elaborated
clause,
-- not shown --
in d i f f e r e n t
'values'.
states,
T h e s e remarks
119
also apply
to functions
Functional
abstraction
lid I
of several v a r i a b l e s
in two or m o r e v a r i a b l e s
lid 2
.~
hid n
is w r i t t e n
either:
o clause
or :
l ( i d l , i d 2 .... , i d n )"
where n ~ 2 , traneous of
all i d ' s
and
to the m e t a - l a n g u a g e .
(for suitable
below)
distinct
substitutions
(D 2 ~
(...
...
Dn ~ D
... is a s h o r t e n i n g
Let i d .
range
of actual
over D, then the d e n o t e d
D1 ~
clause
~
for formal
function
(D n ~ D)
ellipsis
ex-
over D. and the values parameters,
see
is in the space:
...))
respectively:
D1 D2
The
former
form c o r r e s p o n d s
finckeling" permits ments,
of the m o r e
the a p p l i c a t i o n namely
Dk+ I ~
where
k+1
D' ~ D",
m-ary
~
of
the f i r s t
Such an a p p l i c a t i o n
n.
(strictly)
"currying" form.
less
a function
(Dk+ 2 ~
~
for m > O ,
(...
(D n
say)
also yield
= clause
~ ( i d l ~ i d 2 . . . . . i d m)
(k
a functional
will
or :
le t f =
k
n arguarguments.
in the space:
can be identified:
f(idl,id2~o.o,idm)
as here,
form also
D) ... ))
if D is a itself of n a r g u m e n t s
or "sch~n-
The former
than,
(from left-to-right,
[Of course,
let
latter,
then denotes
then a p p l i c a t i o n
functions,
to a s o - c a l l e d
familiar,
clause
space,
say
a function.]
120
where
no two id. and id. are the same.
in clause point
then the d e n o t e d
solution
to the
function
(recursive)
If f occurs
free
(see below)
is the s o - c a l l e d m i n i m a l
fix-
equation:
f(idl,id 2 ..... id m) = clause etc.
The m i n i m a l
subsequently. instead
fix-point
We could have
defining
finding
operation,
indicated
¥, will be e x p l a i n e d
any such i n t e n d e d
recursion
by
f by:
letrec f(idl,id2,...,id m) = clause respectively:
let f = ylg. h(idl,id2,...,idm) where
clause'
in clause
arises
from clause
. clause'
by s u b s t i t u t i n g
[Using g instead
of f on the r i g h t - h a n d
since -- u n d e r
the
side
letrec v e r s u s
is s t r i c t l y
We shall,
however,
recursion
when using
we choose
to o m i t the rec
sion maker.
tion
always
the only
style
(inside a c o n v e n t i o n a l
5) is by m e a n s
of a let d e f i n i t i o n
a name w h o s e
meta-language
function
denotation
b l o c ~ in w h i c h
the
f's.]
identifier
suffix on let's
and never
which
in clause.
let occurred.
Hence
can be re-
definition,
also gives name
is k n o wn w i t h i n
to m e a n
to use the ¥ recur-
in w h i c h a f u n c t i o n function
not
-- the
the user of the m e t a - l a n g u a g e
the d e f i n e d
Consequently
defined
force
speaking
let c o n v e n t i o n
left hand f is not b o u n d to any of the r i g h t - h a n d
function,
free o c c u r r e n c e s
of f by g.
necessary,
cursively
all
see secto the
the scope of the
This
is in c o n t r a s t
to
the f o r m :
¥hf.h(idlJid2,...,id m) • clause which otherwise tify it~
defines
the same function,
but does not further
iden-
121
Free and B o u n d Variables,
Scope
For the purpose of the d e f i n i t i o n of the concepts of fr§e and b0und v a r i a b l e s we c o n s i d e r the m e t a - l a n g u a g e p r o g r a m s tions)
(or: f u n c t i o n defini-
as m a d e up from the f o l l o w i n g three e x p r e s s i o n constructs:
(i) V a r i a b l e s (2) F u n c t i o n A p p l i c a t i o n s (3) F u n c t i o n A b s t r a c t i o n s
(i)
x is free in x.
(2)
x is ~ e e
in f(a)
(3)
x is ~ e e
in ly.clause
if it is ~r£e in either f, or a, or both.
if x~y
tinct from y) and x is ~ £ £
(4)
Since the n o n - r e c u r s i v e
(i.e. if x is an identifier disin clause.
let d e f i n i t i o n block:
(le_~t y = expr
i__~n
se) w h e r e se is either a m e t a - l a n g u a g e s t a t e m e n t or £xpression,
can
be u n d e r s t o o d to be a syntactic sugaring of:
(~y.se)(expr) p r o v i d e d ~@llzb~lvalue
is used, we see that fre§ness of X in a
let d e f i n i t i o n block follows the rules for ~r~§ness of x in an application.
(5)
Similar for s t a t e m e n t composition:
(stmtl; stmt2) only m a k e s sense if s t m t l
and stmt2 both denote functions from
states, ~, to states, ~P,
(stores to stores),
(stmt!; stmt2)~ is really to be u n d e r s t o o d as:
hence:
122
(let ~
= Stmt1(~)
in
stmt2(a')) w h i c h then reduces to:
(la '. (strut2 (a '))) (strut1 (a) ) A v a r i a b l e is bedrid in some e x p r e s s i o n if it occurs in the e x p r e s s i o n but is not free.
It follows then that the formal p a r a m e t e r v a r i a b l e s
(identifiers)
all of the free o c c u r r e n c e s of such identifiers in the ~2~Y,
bind
i.e. clause,
of a l-expression:
l(idl,id2,...,idm).Clause The id.'s
are called bound v a r i a b l e s .
The ~ 2 ~
of a bound v a r i a b l e is the entire b o d y - p a r t of the l-expres-
sion to w h i c h it belongs, with the specific e x c e p t i o n of each p r o p e r l y c o n t a i n e d l - e x p r e s s i o n of the b o d y - p a r t having that same bound v a r i a b l e identifier.
Application
A p p l y i n g a l-defined function:
Ivar.clause to an argument,
arg: (Ivar.clause)(arg)
then means to e v a l u a t e the e x p r e s s i o n clause' by ~ ! ~ ! ~
all free o c c u r r e n c e s of
tifier vat in c~ause
by the
(semantic)
Hence the m e t a - l a n g u a g e only has
w h i c h arises from clause
(the syntactic object)
the iden-
object denoted by arg.
S~!!zDXzYe!~-
The above a p p l i c a t i o n rule extends to functions of several arguments.
123
D e f i n i t i o n versus A p p l i c a t i o n
To write:
(let f(a)
= clause
in
C(f)) means:
let f denote the f u n c t i o n w h i c h satisfies the above e q u a t i o n and
e v a l u a t e or i n t e r p r e t C(f) in such an e n v i r o n m e n t where f is bound to that function.
It does, e.g., not mean:
e v a l u a t e clause before proce-
ding to e l a b o r a t i o n of C(f). clause is e v a l u a t e d iff f is applied and then the suitable s u b s t i t u t e d clause'
is e v a l u a t e d everytime,
afresh,
w h e n e v e r f is so applied!
The ~ O p e r a t o r
For the benefit of those who are not familiar w i t h the y operator of the l-Calculus we now p r e s e n t a d e v e l o p m e n t leading up to this o p e r a t o r and its purpose.
Let :
(let f(x) .,.)
define f r e c u r s i v e l y -- i.e.:
= F(x,f)
in
the r i g h t - h a n d side occurrence(s)
of f
in F(...) denotes the same as does the left-hand side f.
Since,
in the l-Calculus:
G = (Ix.G)(x) p r o v i d e d x does not occur
(free)
is the same as let f = Ix.F(x,f)
in G, and since let f(x) we get:
(let f = (Ig. lx. FCx, g))(f)
where g does not occur Ig.lx.F(x,g),
(free)
i.e. if we let:
= F(x,f)
in F(x,f).
in
If we ascribe the name F to
124
F = Xg. Xx.F(x,g)
then the p r e v i o u s can be written:
(let f = F(f)
Now: F is a function,
in
in fact it is a functional. And objects,
say w,
satisfying:
W = HW w h e r e H is any function,
are said to be ~ ! ~ Z ~ i ~
looking for, i.e. d e f i n i n g by the let clause,
of H. The f we are
thus is a f i x e d - p o i n t of
F. It turns out that there m a y be m a n y fixed-points of any given functional -- so, following good practice, way unique;
we select one w h i c h is in some
in particular, we choose to let such f's denote the so-
called m i n i m a l fixed-point.
This means:
tion) whose @[a~h is included
that solution, f,
(E) in any other solution.
(to the equaIt then turns
out that, under suitable and always r e a s o n a b l e c o n s t r a i n t s ty, etc.),
there exists a functional,
plied to objects,
(monotonici-
let us name it ¥, which w h e n ap-
like F, produce their m i n i m a l fixed-point!
This is the ¥ we are referring to. It is the so-called m i n i m a l fixed~2!~
~!~!~
2 ~ "
Observe the sequence,
let
f(x)
= F(x,f)
let
f
= hx.F(x,f)
let
f
= (lg. hx.F(x,g))(f)
let let
f f
= F(f) = yF
~et
f
= ¥~g.~x.F(x,g)
let
f
= ylf.~x.F(x,f)
I where : F = lg. lx.F(x,g)
That is: w r i t i n g lg.hx.F(x,g) cal meanings,
r e p e a t e d from above:
or w r i t i n g lf. hx.F(x,f)
p r o d u c e s identi-
since the h's shield the r i g h t - h a n d side f from the left-
hand side f -- they are now, formally speaking, they denote the same object:
not the same, a l t h o u g h
125
6.3 F u n C T i o n
Operations
There is only d e f i n e d one o p e r a t i o n on F u n C T i o n
(...)
objects:
apply.
In the i n t r o d u c t o r y example we i l l u s t r a t e d the 'concoction' dure denotations.
of proce-
In the following example we show their application.
Let:
1
Block
::
be an a b s t r a c t syntax
Var-set
(::-)
(Id ~ Pro)
rule.
B l o c k a b s t r a c t s the d o m a i n of the
blocks of some g o t o - f r e e source language. Variable
declarations,
Stmt ~
u n i q u e l y named
T h e y consist of three parts:
(Id) P r o c e d u r e s ,
and a S t a t e m e n t
list. Their semantics is:
type:
I-Block:
Block ~
(ENV ~ (E ~ E))
where:
2
~
=
L O C -~ VAL
3
ENV
=
Id ~ D E N
4
DEN
:
LOC
m m
i
(ARG ~ ~
(~ ~ E))
and :
5.0
I - B l o c k ( m k - B l o c k ( v a r s , procm, s t l ) ) ( p ) ( ~ ) =
.I
(let
.2
(~t,map)
= allocate(vars)(~)
let p' = P + map
.3
+
.4
[id ~ V - P r c ( p r o c m ( i d ) ) ( p ' ) ( s ' ) I id £ d o m p r o c m
.5
let o" = I - S t m t - l i s t ( s t l ) ( p ' ) ( ~ ' )
.6
~ " ~ r n g map)
Lines
in
]
.1-.4 c o n s t i t u t e the block a c t i v a t i o n prologue,
ing epilogue.
in in
line
.6 the match-
The f u n c t i o n a l l o c a t e is given v a r i a b l e names and states
and p r o d u c e s a new state in w h i c h is a l l o c a t e d all the cells c o r r e s p o n d ing to the variables,
their cell locations is r e c o r d e d in map w h i c h
126
binds v a r i a b l e
6.0
names
to these
locations:
allocate(vars)(o)=
.i
i f rare={}
.2
then [~,[])
.3
else
(let id £ vats
in
.4
let (o',map) = a l l o c a t e ( v a r e ~ { i d } ) ( s )
in
.5
let I 6 LOG be s.t.
in
.6
(s' U [l~undefined],ma p U [idol])) type: allocate: ......
1 ~6 d o m e '
Vat-set ~ (£ ~ (£ (Vat ~ LOG))) m
and:
tHpe:
[-Stmt-list:
Stmt ~ ~ (ENV ~ (X ~ ~)).
Now a statement
could be a call of a procedure:
7
Stmt
=
Call
8
Call
::
Id Expr ~
I
...
and with:
9.0
1-Stmt-list (stl) (p) (0)=
.i
i_~ stl=<>
•2
then o
.3
else
(let o' = ~ - S t m t ( h s t l ) ( p ) ( o )
.4
we end up h a v i n g
i0.0
.i
to explain:
I-Stmt(stmt)(p)(o)= casee stmt:
.2
(mk-Call(id, el)
.3
(let argl = < V-Arg(el[i])(O)(o)
.4
fct
.5
fct(argl) ) ,
where
in
~-Stmt-list(t 8tl) (p) (o') )
it is a s s u m e d
type:
= p(id)
that:
V-Arg:
Expr ~ (ENV ~ (~ ~ ARG))
i £ ind el >, in
127
in other words,
that evaluation of the amgument list does not create
side-effects by changing the state
(0).
Observe now, how the procedure denotation,
(ARG* ~ (Z ~ Z)), "time",
which is a FunCTion,
"packed" in the environment
is retrieved (10.4)
and applied
(10.5)
p' set up at prologue at "calling" time.
We have completed our task of showing the construction of FunCTion objects, the second of the introductory examples of this section; and the
~!!Se~!2~
of such objects to their arguments.
Observe that the apply operator of line .4 above, retrieving fct from the MAP object p, is a MAP operation;
whereas the apply operator of
line .5 above, applying the FunCTion object, fct, is the FunCTion operation of apply.
to its a~gument list,
128
7. A B S T R A C T
SYNTAX
Program
=
Stmt
=
Stmt Block
t If
Assign
The
above
I Goto
I
I NULL
::
(Id ~ Type) Prod-set Named-Stmt ~
Type
::
Scalar-type
Prod
::
Id Parm ~ Stmt
[(Expr
I ~)+]
Parm
::
Id (Type
Named-Stmt
::
[Id] Stmt
If
::
Expr Stmt Stmt
For
::
Id Expr Expr Expr Stmt
Call
::
Id (Var-ref
Goto
::
Id
Assign
::
Var-ref Expr
In
::
Var-ref
Out
::
Expr
Expr
=
Infix-expr
is a n e x a m p l e
to d e f i n e
guage.
Before
operators:
render
I Call
I Out
Block
tended
annotate
I For
I In
commenting
the above
itself more
IId) ~
I Rhs-ref
of a n i n c o m p l e t e ( d )
fragments
l, ~,~,
I PROC)
-set
of the
syntax open
abstract
syntactic
domains
o n its u s e of = a n d and
[...],
l e t us,
I Con-var-ref
in the w a y w e b e l i e v e
to i n s p e c t i o n
syntax.
by casual
I t is in-
of some source
:: r u l e s ;
for t h e
I Const
lan-
and of domain
sake of
instruction,
a formal model
should
readers:
-- a n n o t a t i o n
A program
is a s t a t e m e n t
A statement
is e i t h e r
or an assign,
A block uniquely
a block,
o r a n in,
has a variable associates
.
o r a n if,
o r a for,
o r a n out,
or a null.
declaration
part which
the t y p e o f t h e v a l u e s
variable,
a set of procedures,
block has
three
parts.
And
to v a r i a b l e
some,
o r all,
or a goto,
identifiers
that can be stored
a n d a l i s t of n a m e d
either,
o r a call,
statements.
of these may
in the Thus
a
be void.
129
A variable
type is e i t h e r
scalar type 'absent',
is m o d e l e d
nil. An
i.e.
a scalar or an array
whenever
same scalar
type.
(Expr I ~)+
A procedure
has an i d e n t i f y i n g
is of the
of the a rr a y is g i v e n by the l e n g t h of
name,
a parameter
specification
list,
is a statement.
specification
type description.
fier,
object being
the
list.
an a r g u m e n t
A named
[(ExprI~) +]
the o p t i o n a l
The d i m e n s i o n
A parameter
a scalar-,
In this m o d e l
a r r a y type has all a r r a y e l e m e n t s
the p r e s e n t
and a body w h i c h
type.
an array-
statement
or,
has an i d e n t i f y i n g The
formal p a r a m e t e r
type of an a r g u m e n t
name and
is either
that of
a procedure.
has two parts:
an o p t i o n a l
label,
which
is an identi-
and a statement.
Etcetera.
Comments
F r o m the above operator lity,
a n n o t a t i o n s it
transpires
that
for "either",
the p a i r e d
operators
stands
and
"(...)"
fix + in rule
N e x t we o b s e r v e recursively. (2);
delimits
4, the infix
F o r example:
and an
(else)
Finally we conclude must constitute equations,
7.1 Domains
syntax d e f i n e s
a statement
is
that
the d o m a i n s
the d e f i n i t i o n
of A b s t r a c t
denoted
both a
(then)
Stmt statement
consequence
by the rule
left-hand
recursive
sides
set of
"=" or "::"
Objects
we shall
example,
as to some of the a b s t r a c t
as well
the d o m a i n
to the m u t u a l l y
symbol be
In the following
shown.
e.g.
(8), both of w h i c h are statements.
some kind of s o l u t i o n
whether
"I"
for o p t i o n a -
(=) an i f - t h e n - e l s e
statex~ent c o n t a i n s
alternative
expression
"[...]"
the scope of the infix ~ in rule 3, the sufm i in rule 6, and the suffix ~ in rule 10.
that the above
and an i f - t h e n - e l s e
the d o m a i n
rely on your
returning
yourself
syntax
to the above
examples
previously
130
The aim of section 7 is to teach you how to d e c o m p o s e the m o r e general task of defining r e c u r s i v e classes of a b s t r a c t objects.
Sections
2-3-4-5-6 already taught you the m o r e isolated c o n s t r u c t i o n of set, tuple, map,
tree and function domains.
Motivation:
The r e a s o n why we in general, w i s h to d e f i n e a r b i t r a r i l y c o m p o u n d e d classes is the following.
The m e t a - l a n g u a g e architectures:
is used, primarily,
to d e s c r i b e complex software
p r o g r a m m i n g languages,
data bases, o p e r a t i n g system
command & control language interfaces; language processors,
etcetera.
and their stepwise realization:
Just like we o r d i n a r i l y d e s c r i b e the
concrete text strings, m a k i n g up e.g. programs, in terms of e.g.
queries and commands,
BNF g r a m m a r s -- so we now desire to give a b s t r a c t i o n s
of these classes of objects. Likewise: level language program,
just as we, w h e n coding a higher-
a data base data definition,
n o r m a l l y as part of v a r i a b l e declarations,
etcetera,
define,
the structure of our inter-
nal, stored objects -- so we now desire to give storage l a y o u t - i n d e p e n d e n t a b s t r a c t i o n s of the m o r e intrinsic of these v a l u e classes.
Syntactic & Semantic Domains:
In the m o t i v a t i o n above, two kinds of a b s t r a c t o b j e c t classes w e r e singled out. The ones
input to the software systems being defined,
viz.: p r o g r a m texts, data base q u e r y & update commands, system job control language commands,
operating
etc. And the ones manipulated,
and, as we shall take it in general, d e n o t e d by these inputs, viz.: internal data structures; sources,
catalogues,
files & records;
processes,
re-
ercetera. We shall g e n e r a l l y refer to the former object clas-
ses as being of syntactic nature, and the latter as being semantic. S y n t a c t i c and semantic domains will,
in the m e t a - l a n g u a g e be d e f i n e d
using the p r o g r a m m i n g c o n s t r u c t of abstract
syntax.
The "programming construct" of BNF g r a m m a r s or some e x t e n d e d v a r i a n t thereof is u s u a l l y applied when d e f i n i n g sets of c o n c r e t e text strings
131
-- i.e. context-free facility of PASCAL,
"languages".
And the type and mode, definition
respectively ALGOL 68, is the corresponding pro-
gramming construct for the internal data structures.
In the meta-lan-
guage the same tool will be applied in the construction of potentially, and usually,
infinite classes,
or as we shall prefer to call them,
domains of abstract objects.
Motivation:
The reason why we apply the same tool and why this tool is neither that of e.g. BNF, the PASCAL type definition nor the ALGOL 68 mode definition facility, strings
is that we, on one hand, neither want to deal with text
(or corresponding parse trees),
nor, on the other hand, are
concerned about storage space and access-efficient
layout of objects.
Instead we desire to provide what we believe to be appropriate & fitting representational abstractions.
Representational Abstractions:
By representational output terminal-,
abstraction is meant the target system
or machine-storage
of software function concepts,
device)
especially objects,
emphasizing the
choice of such abstractions whose, usually composite, most directly expresses intrinsic,
(e.g. input/
independent specification (logical)
type
i.e. to our understanding relevant,
properties of the notions being specified.
Domain Definitions ~ Compositions In order: (I)
to decompose the task of constructing domains, composing them from constituent domains,
(2)
i.e. of
and in order
to permit the constructions of reflexive domains,
i.e.
composite domains whose objects contain properly embedded objects of the same kind
(-- or domain)
the meta-language provides~the conventional notion of definitions.
132
Definitions / Rules A domain definition consists,
as does any definition,
of two parts. A
left- and a right hand side. Other words are lhs, respectively rhs; and definiendum
("that ~hich is being defined"),
respectively
("that which defines it"). We shall use the words abstract
definiens
syntax
rule synonymously with the concept of a domain definition. Abstract syntax rules all have their lhs's being simple names, identifiers.
i.e.
The rhs's are usually compound expressions henceforth
referred to as logical type, or domain expressions. The first point,
above, about decomposing the task of defining domains
is achieved by the ability to use, in the rhs's of some rules, the lhs identifier of some other rule. The second point, then, is achieved by permitting that
the use, in the rhs of any rule, of the lhs identifier of
(or those) rule(s).
Compositions / ~ 2 ~ ! ~
E~pressions
In order: (3) to model notions of software systems representationally abstract,
and in order
(4) to provide a reasonably fitting variety of choices for abstracting objects the meta-language centers its abstract compound objects around the mathematically tractable concepts of sets, ~ ! ~ , together with associated,
functions and ~ e e s
primitive operations.
Domain Q~erators: As a consequence the meta-language provides a number of operations which apply to arbitrary
(constituent, elementary &/or composite)
mains to denote set-, tuple-, map-,
These operators have already been introduced, ,
the latter
+
((...)) denoting
~
~
~
do-
function- and abstract tree domains.
and are:
(...)
(implicit or anonymous)
tree construction.
133
In the compounding, tree c o n s t r u c t o r
(D I
u s u a l l y s i g n a l l e d by the implicit,
or anonymous,
(..4), of m o r e t h a n one domain:
D2
...
D n)
n~2
•
there is an i n v i s i b l e " c a r t e s i a n p r o d u c t - l l k e
t!
operator,
x. T h a t is,
you m i g h t read the above as:
(D 1
x D2
x ...
x Dn).
The p o i n t about the use in this m e t a - l a n g u a g e of the c a r t e s i a n o p e r a t i o n is that it is only used w h e n domains of trees of two or m o r e subcomponents are denoted. Not,
e.g., w h e n tuple domains are to be constructed.
T h e s e can o n l y be constructed, operations.
in this m e t a - l a n g u a g e ,
Thus, w h e r e c o n t e x t permits,
constructors,
A
using the ~ or +
we m a y d r o p i m p l i c i t tree
as in:
-~
B C
w h i c h is taken to be identical to:
A
~
(B C)
That is: the p r e c e d e n c e of x is higher than any other infix operator, but lower than any suffix operator.
We u s u a l l y o m i t w r i t i n g the x opera-
tor.
The following d o m a i n o p e r a t o r s a s s e m b l e not n e c e s s a r i l y d i s j o i n t dom a i n s into
'unions' of these:
-- the latter a p p l i c a b l e only in c o n n e c t i o n w i t h m a p domains, p l a i n e d in section 4.1. The
J o p e r a t o z will be further d e f i n e d below.
F i n a l l y the operators: [...]
-- o p t i o n a l i t y
(...)
-- g r o u p i n g / d e l i m i t i n g
enables s h o r t n e s s of d e s c r i p t i o n s . T h e former: [A]
~-
A
as ex-
D nil.
134
The latter
can e a s i l y be c o n f u s e d w i t h the tree c o n s t r u c t i o n
Therefore:
when
(...)
surrounds
infix d o m a i n operator, them,
e.g.
(A ~
serves
tree d o m a i n
I (B-set
to indicate,
w i t h no
separating
construction;
otherwise
(...)
as in :
C)) ~,
i.e.
delimit,
the scope
scope rules
of infix or suffix d o m a i n
are the c o n v e n t i o n a l
ones.
C~_mm_u~a~ivi~[ and A s s o c i a t i v ! ~ y
infix o p e r a t o r s
tivity
~
M
The c o r r e s p o n d i n g
Infix O p e r a t o r
With
expressions
operator,
C),
(...) d e n o t e s
operators.
two or m o r e d o m a i n
than the c a r t e s i a n
as in: (A ~ B - s e t
then
other
operator.
the q u e s t i o n
of their c o m m u t a t i v i t y
and a s s o c i a -
arises: I , U
are c o m m u t a t i v e
, ~ , ~ The c a r t e s i a n
associates
product
operator,
to the right.
x, does not associate~
Ex_am_Rles 44-45-46: (i) The d o m a i n s
A
denoted
i B
by:
and
are i d e n t i c a l l y
the same,
(A ~
B)
U
B i A
and so are:
D)
,
and :
(C ~ D))
,
and :
(C ~
(2) The domains: A ~ A
(B ~
~ B ~
are i d e n t i c a l l y
C ~ D
the same.
Writing
the former
is a c l a r i f i c a t i o n
of the
135
latter,
should you have forgotten
the rules of associativity.
Thus the
domain:
((A
is distinct
~
B)
~
C)
~ D
from the domain denoted by the former expressions.
(3) The tree domains:
(A
x B
are all distinct was
x CJj
((A
x BJ
and
x C),
(in fact, disjoint).
(A
x
(B
x CJ)
Only in this,
the 3rd example,
(°..) used for tree domain construction.
Semantics
of the
I Operatqr
Of the new domain expression
operators
section 7 only the m e a n i n g of
I remains
Let A and B be d o m a i n expressions,
A
([...]j
(...),
I) introduced
in
to be explained.
denoting
A, r e s p e c t i v e l y
B. Then:
I B
denotes: AUB where
U is the
A
I B
(potentially
~
infinite
{ o
! oE
A
set) union operator;
vo£
B
i.e. :
}
Comment:
Thus
f does not denote the discriminated
In Scott 76 the disjoint union operator A
+B
~
{
(A__.,aJ
or disjoint is represented
I a £ A }
{ (B, bJ I
6B}
U
union operation. by +, and:
136
The "tagging" of the A + B the o r i g i n a t i n g domain, lap, and an A + B
domain elements, w i t h a "label" indicating is useful w h e n e v e r
(2) the need arises for testing,
(i) domains A and B oversay in some function, w h e t h e r
object comes from A or from B.
Since the
I o p e r a t o r does not separate the operand domains it is the
task of the definer to see to it that
J o p e r a n d domains are d i s j o i n t
w h e n e v e r some functions a p p l i c a b l e to the union d o m a i n need a s c e r t a i n o r i g i n a t i n g domain.
Constructin~ ~!~2!~
Domains
Let us assume that a union domain,
D1
is required.
I D2
l ...
r o u g h l y of the type:
I Dn
Let us further assume that for some, or all, i # j :
D° is not d i s j o i n t from D.
Since D i and D j
o v e r l a p there is no d i r e c t way of s e p a r a t i n g
(some) D i
objects from D.. J I n t r o d u c i n g the a b s t r a c t syntax tree d o m a i n c o n s t r u c t i n g rules:
A I :: D 1 A 2 :: D 2 w , ,
A
n
:: D
n
and :
A1 J A2
(in lieu of D I marking
(mk-A1,
I ...
i D2
I An
J ...
mk-A 2 ....
in the u n i o n d o m a i n A 1
I Dn), , mk-An)
I A2
I ~..
by d i s t i n c t n e s s of l e f t - h a n d side Thus we introduce desired.
:: a b s t r a c t
e f f e c t i v e l y c o r r e s p o n d s to a d i s t i n c t of r e s p e c t i v e DI, I A n . Distinctness (Ai,
Aj
D 2,
....
D n objects
is solely a c h i e v e d
) names.
syntax rules w h e n e v e r d i s j o i n t n e s s is
137
7.2 A b s t r a c t Syntaxes & Rules
Abstract Syntaxes
Abstract-Syntax
::=
Rule i Rule 2 Rule
is an informal
r
"extended" BNF, or BNF-like,
syntactical d e s c r i p t i o n
d e f i n i n g an a b s t r a c t syntax as c o n s i s t i n g of a number o f rules. Each rule:
Rule
::=
Identifier = D o m a i n - E x p r e s s i o n
::=
Identifier:: Domain-Expression
b a s i c a l l y c o n s i s t s of two parts: a left-hand side definiendum, w h i c h is an identifier; expression.
and a r i g h t - h a n d side definiens, w h i c h is a d o m a i n
The two rule parts are separated either by an e q u a l i t y
o p e r a t o r or by the s o - c a l l e d tree d o m a i n c o n s t r u c t o r Both the or
d~f
=
and the
)" The latter,
A
::
B1
in addition,
B2
.
,
.
'constructs'
operator.
trees.
(like:
Its use in:
Bn
could be taken as an a b b r e v i a t i o n for the ::
(::)
o p e r a t o r s are d e f i n i t i o n symbols
::
(=)
(intended, reflexive)
use of
in: A
=
::(B 1
B2
.~.
Bn).
Context Constraint
In a c o m p l e t e m e t a - l a n g u a g e p r o g r a m there m u s t be no two rules of any one or pair of a b s t r a c t syntaxes w i t h identical definienda,
i.e. lhs
identifiers.
/s-Function:
Any a b s t r a c t syntax rule
!~!!S!~!£
cate f u n c t i o n /s-Identifier:
introduces,
i.e. defines,
a predi-
138
type:
OBJ ~ BOOL
is-Identifier:
w h i c h applies to any object and yields true if it is an o b j e c t in the d o m a i n d e n o t e d by Identifier, o t h e r w i s e false.
Note:
We could have c h o s e n to write:
obj 6 Identifier instead of:
i8-Identifier(obj) but, except for a few cases, we reserve the former form for set m e m b e r ship tests where t h e
set is not one d e f i n e d as a D o m a i n as d e f i n e d by
some a b s t r a c t syntax. The exceptions are those i l l u s t r a t e d by the following descriptor
and quantified expressions
(see sections 1.5 & 1.4.1):
(Ax £ !dentifier)(P(x)) (VX 6 Identifier)(F(x)) (Hx £ Identifier)(F(x)) (B!x £ Identifier)(F(x))
Exam~!~ ~Z: Given the i n t r o d u c t o r y a b s t r a c t syntax example, and given:
i8-ID(id),
is-Scalar Type(st),
is-Stmt(sl),
i8-Stmt(s2),
is-Named-Stmt(nsl),
and is-Expr(e)
is-Stmt(s),
is-Named-Stmt(ns2),
we are able to construct:
m k-Program (8) ink-Block ( [id-~mk-Type (st, nil) ], { }~
pr
ink-Named-Strut (nil, s)
ns
mk-IfCe, 81,82)
if
etc.. Let us call these four objects pr, bl, nB and if. Now:
bl
139
N is-Program(hi)
is-Program(pr) is-Stmt(pr)
is-Stmt(bl)
is-Block(pr)
is-Block(hi)
i8-Named-Stmt(pr)
is-Named-Stmt(bl)
is-If(pr)
is-If(bl) N is-Program(if)
is-Program(he) is-Stmt(ns)
is-Stmt(if)
is-Block(he)
is-Block(if)
is-Named-Stmt(ns)
is-Named-Stmt(if) is-If(if)
N is-If(he) etc..
Further Context Constraint A z-rule, when expressible in the form:
Identifier
=
D 1 D 2 ... D n
(n~2)
D I D 2 ... D n
(n~2)
is identical to the rule:
Identifier
::
Semantics of Abstract Syntaxes The prescription for computing most of the domains designated by compound domain expressions has
already been given. Allowing now for do-
main definitions,
in fact for several such, and, in addi-
i.e. rules,
tion, for potentially mutually recursive rules, we require a more comprehensive prescription for computing the domains given an arbitrary abstract syntax. We shall only do that informally here, relying in general on the formal foundations laid by Scott. An abstract syntax can, speaking rather formally,
[Scott 1976]. be viewed syntacti-
cally as an equation set. Its meaning is a family of named sets of mathematical objects being the minimal,
fix-point solution to the equa-
tion set. That is: to each lhs there corresponds a potentially infinite class of finite objects,
the domain. These domains are the smallest
such classes which, when substituted in lieu of their identifying names
I40
in the equation lhs and rhs's will,
satisfy the equations.
The bit
about the fix-point ~omes into the picture since our equations may be mutually recursive.
The equation:
D
=
D-~D m
has the following solution:
D:
{[],[[]~[]],[[]~[[]~[]]],[[[1~[]]~[]]
with : D
=
(DMD)
J A
"adding":
{[a I
*
[]] ....
[a 1 ~ a 1 ] . [a I
~
. . .
al,a 2
to the above solution.
~
a2,...,a
n
~
a n ]....
.... };
141
7.3 A b s t r a c t S y n t a x o r i e n t e d C o m b i n a t o r s
The m e t a - l a n g u a g e
(structured-)
s p e c i f i c a l l y c o m p l e m e n t i n g the t e r n a t i v e operator,
expression
and s t a t e m e n t c o m b i n a t o r s
(abstract syntax)
d o m a i n e x p r e s s i o n al-
i, are:
The M c C a r t h £ C o n d i t i o n a l Clause:
(pe I ~
e 1,
pe 2 ~
a 2,
o , ,
pe n ~
o n)
The Cases C o n d i t i o n a l Clause:
da8e8
~0:
(e I -~ cl, e I -~ a2, o ° o
e
Here p e i stand statement, expression.
n
-~ d
n
)
for p r e d i c a t e
e x p r e s s i o n , cj
and e k for expressions.
for either e x p r e s s i o ~
or
A clause is either a s t a t e m e n t or an
If either of the above c o n d i t i o n a l clauses is
(intended to
be) of the e x p r e s s i o n type,
then all c. are (to be) expressions. SimiJ larly they are all to be statements if the above clauses are to be
c o n d i t i o n a l statements.
We refer to the e k e x p r e s s i o n s as follows:
as the root expression and e k ,
for 1~k<__n,
e0
as the branch expressions.
G i v e n the a b s t r a c t syntax for e x p r e s s i o n s of some source language:
142
1
Expr
=
Infix
I Rhs-ref
2
Infix
::
Expr Op Expr
3
Rhs-ref
::
Var-ref Id
4
Con-var-ref
::
5
Conet
=
INTG
6
Var-ref
::
Id
7
Op
=
Int-Op
We can define
a function,
I BOOL I Bool-Op
ex-tp,-which
given
I PROC
DICT
=
Id ~ (Type
9
Type
::
Scalar-type
10
Scalar-type
=
~Z
t h e Scalar-type
~ Const
[Expr +]
8
computes
f Con-var-ref
I Rel-Op a dictionary:
I ...)
[(Expr
! ~)+]
I BOOL
of an e x p r e s s i o n ,
e:
ex-tpCe, dict)=
ii.0
case8
.I
e
(mk-Infix(
.2
,opj
)
.3
(is-Int-Op(op )
~
.4
is-Bool-Op(op)
~
~NT, B00~,
.5
ie-Rel-Op(op)
~
BOOL),
mk-Rhs-ref(mk-Var-ref(id,
.6
))
8-Scalar-type(dict(id)),
.7
mk-Con-var-ref(
.8
)
.9 .i0
i8-B00L(e)
.ii
type:
Observe
how,
structs.
in t h i s
Relate
function,
Expr DICT
the
case,
and observe
how they
in t h e c a s e s
name
arguments
branch
BOOL))
Scalar-type
we nested
structures
constructs those
~
~
the
Cases
of the abstract "match".
Observe
expressions.
of t h e mk-
functions
and the McCarthy syntax
con-
t h e ex-tp
n e x t t h e u s e o f mk-
Observe
which
and
finally
that we only
we explicitly
require.
-- a n n o t a t i o n s : An expression rence,
is e i t h e r
a controlled
an infix
variable
expression,
reference
a right-hand-side
or a constant.
refe-
~43
An infix e x p r e s s i o n
has three parts:
two o p e r a n d
expressions
and an
operator. A right-hand-side A controlled
variable
variable
reference
reference
is a v a r i a b l e
is an identifier.
A constant
is e i t h e r
an integer
A variable
reference
has an i d e n t i f i e r
an ar r a y length
location,
An o p e r a t o r rator,
or a boolean.
then an index
expression
list,
is e i t h e r
list,
and,
if this
which
identifier
is a non-zero,
denotes
finite
else nil.
an integer
or a r e l a t i o n a l
reference.
(arithmetic)
operator,
a boolean
ope-
operator.
-- comments: An e x p r e s s i o n
either
an e x p r e s s i o n
is
an e x p r e s s i o n
-- w h i c h
certained.
denotes
(said)
Given
an integer
either
(to be)
is o t h e r w i s e
or a boolean. ~NT or
well-formed
that the type w i t h w h i c h
(to be)
Hence
the type of
BOOL. The type of
-- can be s t a t i c a l l y
a variable
as-
or formal p a r a m e -
ter is declared: 12
Block ::
(Id ~ Type) Proc-set Named-Stmt
13
Proc
::
Id Parm
14
Parm
::
Id (Type t PROC_)
is r e c o r d e d vironment,
in some
Stmt
(compile-time)
the f u n c t i o n
dictionary,
ex-tp computes
also
called
(at compile-time)
static
en-
the type of
any expression.
-- annotations,
continued:
ex-tpis g i v e n an expression, If e
(.i)
et and a dictionary,
is an infix e x p r e s s i o n
as some mk-Infix(el,op, e2), w h e r e
(.2),
i.e.
dict.
if e can be e x p r e s s e d
el,op and e2 b e c o m e the names of those
Expr, Op, r e s p e c t i v e l y Expr o b j e c t s of w h i c h e is m a d e up, then the type of e is a s c e r t a i n a b l e .3) an integer either
(.4)
from the kind of o p e r a t o r
operator,
a b o o l e a n or
that op is.
then the type of e is ~NT; (.5) a r e l a t i o n a l
If op is
if op instead
(or comparison)
is
operator,
then the type of e is BO0~. If e
(.I)
expressed
is a r i g h t - h a n d
side r e f e r e n c e
as some mk-Rhs-ref(vr),
(meta-)expressible
(.6),
i.e.
if e can be
vr is a v a r i a b l e r e f e r e n c e
as some mk-Var-ref(id, el), w h e r e
the names of the Id, r e s p e c t i v e l y m a d e up,
where
id and el b e c o m e
[Expr +] o b j e c t s of w h i c h e can be
then the type of e can be looked up in the d i c t i o n a r y
as that
144
of the Scalar-type component of the Type object with which id is associated.
PART
III
COMBINATORS
In part II, i.e. in sections 2-7 inclusive, of constructing domains of objects, ing primitive,
we dealt with all aspects
constructing objects and perform-
i.e. language-defined operations on objects.
Certain desired transformations on objects are, however,
of a complexi-
ty which cannot easily be described by some such operator/operand expression,
regardless of its composition.
customary in programming,
To that end, and as is quite
the meta-language provides a number of con-
structs which facilitate the gradual composition of transformations and processes on objects. We call these constructs for combinators.
They
are: Variables:
Declarations,
Assignment & the State
Structured Clauses Blocks: Let & Return Exits So far we have officially dealt only with the applicative aspects of the meta-language. constructs, ever,
Introducing variables implies introducing imperative
i.e. statements.
The applicative part of the language,
how-
includes the let constructs of, and hence also, blocks, as well
as most of the structured clauses. We say, in general,
that the appli-
cative constructs of the language permit the expression of composite transformations on objects. The imperative constructs correspondingly enable the decomposed,
stepwise statement of processes on objects.
145
8. VARIABLES
Exam~!~
~:
The following four function definitions all define ~
to denote the fac
torial function:
1
fo(n)
=
if n=O then i else n*fo(n-1)
2
fl(n)
=
(dcl Z := I t~pe N1; ~0 r i=I t__oon do
,i
.2 .3
3
Z :: ( ~ ) * i ; return(c v))
f2(n)
=
.i .2
~ := (S~)*i;
.3
4
(dc l ~ := 1 type N1; [or all i E {l:n} d~o return(c u))
f3(n)
=
.2 .3
(dcl Z := 1 type N1, while
.4
(ci % O) do (Z :: ( £ i ) * ( ~ ) ; ~ := (c£)
.5
- 1);
return(c u))
The first defines ~ applicatively;
the remaining three,
We say that the parenthesized constructs: blocks.
imperatively.
(dcl ... return(...))
~ and, only in the last definition,
~ are
(assignable) variab-
les. They form part or all of the state current in these blocks. other
(externally declared)
variables
fo:
NO ~ NI
If no
'exist', then they form all of
the state. The logical type of the four f's are:
type:
are
146
type: where
Z denotes
the blocks,
the
the state
to this space
z where
fl,f2,f3:
....
N O ~ (~ ~ (Z NI)) space.
... e l l i p s i s
refers
to p o s s i b l y
state t r a n s f o r m a t i o n
'equivalent'
8.1 D e c l a r a t i o n s
change.
Thus
declared
variables.
state,
and h e n c e
it
that
by:
the four f u n c t i o n s a global
can indeed be
state.
& The State
the e x a m p l e s
normally
not f i n d a need for other
of h i g h e r - l e v e l
The m e a n i n g
any global
indicated
even w h e n c o n s i d e r i n g
Although
models
externally
f2 nor f3 a s s i g n to any such g l o b a l v a r i a b l e s
is in fact the i d e n t i t y shown
~, inside
k ~#.~o)
is easy to see that they do not alter the p o t e n t i a l
of ~ and
is:
k cL # ~ )
Since none of the f1"
The c o n t r i b u t i o n s
above
featured
b l o ck
local d e c l a r a t i o n s
than global v a r i a b l e s
we shall
in a b s t r a c t
software.
of a declaration:
dol V~r := ... type D -- in w h i c h we m a y omit the type state,
D clause -- is that of joining to our
s, a contribution:
U [~ It is u n d e r s t o o d In general,
~ obj] that V a ~ is not a l r e a d y
the state
space,
Z, g i v e n a c o l l e c t i o n
tions:
dcl ~I := ... type DI, ~2 := ... type D2, ~Vn
declared,
:= ... type Dn;
i.e. of
that
Va~ ~6dom ~.
(global)
declara-
147
can be d e f i n e d as:
= (~I ~ D1) ~ (~2 ~ D2) k "'" ~ (~n ~ Dn) The d o m a i n expressions:
(V-i ~ D i) are d e g e n e r a t e in that the d e n o t e d map d o m a i n s are singular, sist of just one element,
the
(quotation-like)
i.e. con-
o b j e c t ~i w h i c h can be
r e g a r d e d as d e n o t i n g itself.
Our source language example features the a b i l i t y to input data from an (one) e x t e r n a l device,
to o u t p u t data to an
d i s t i n c t from the input device,
(one) external device --
and to declare v a r i a b l e s in any
block. The r e l e v a n t s y n t a c t i c domains,
Block
::
(Id ~ Type)
Stmt
=
In
In
::
Var-ref
... Stmt
Out
::
Expr
Assign
::
Var-ref Expr
I Assign
I Out
(nested)
c o n t i n u i n g example 31, are:
I ...
The semantic functions a s c r i b i n g m e a n i n g to these source c o n s t r u c t s w i l l be based on the f o l l o w i n g three
dcl ~
ST~
(global)
variables:
:=
<...> t~pe
(INTGIBOOL)
,
:=
<>
type
(INTGIBOOL) ~,
:=
[]
~
sTa;
w h e r e STG was d e f i n e d in the last e x a m p l e of section 4.4.
The state space,
Z, of the e l a b o r a t i o n functions,
= ( ~
~
(INTGIBOOL)~)
is:
148
8.2 V a r i a b l e
References
Prelude
Recall
the i n t r o d u c t o r y
(~) o c c u r r e d
The
left-hand
(state)
tion.
of section
side o c c u r r e n c e
denotes
The r i g h t - h a n d
The m e t a - l a n g u a g e
breaks w i t h
then you are r e q u i r e d
itself,
i.e.
side o c c u r r e n c e
~ But here we t r a d i t i o n a l l y
content,
8. V a r i a b l e
identifiers
in two contexts:
location.
itself
examples
expect this
of
the m e t a - s t o r a g e V likewise
the v a l u e k e p t tradition.
to p e r f o r m
denotes
in the
V loca ~
If you need the
the c o p e r a t i o n
to V.
end-of-Prelude
If
V is the name of a d e c l a r e d
de___ll NV
then
:=
...
type
V is said to d e n o t e
variable:
D
itself,
or if need arises
for m o r e precision,
N
to d e n o t e
a re~D
object,
To get at the v a l u e
i.e.
'stored'
a reference
in ~ a p p l y
to an o b j e c t of type D.
the c o n t e n t s - o f
operation
de-
noted by c:
cV V and c V
~
are m e t a - l a n g u a g e
is e x p l a i n e d
expressions.
Given
the state,
~:
as :
oc£). If V is of type r e f D
, then c V
N
m
ces ~. Thus ~ d e n o t e s objects; states
a function
w h i c h we g e n e r a l i z e
to states
'paired'
is of type D. That
is:
N
c de-referen--
from
state
to a f u n c t i o n
with objects:
variables
and
states
from s t a t e - v a r i a b l e
to
and
149
c
~
Xu.hs.(s,s(v))
c
6
(V ~
(x X
(z o s J ) ) )
8.3 A s s i g n m e n t
A s s i g n m e n t is a m e t a - l a n g u a g e statement:
:= expr If ~ is of type r e f D
then expr m u s t be of a type D' , included in D,
i.e. D'qD, e.g. D~D'
The m e a n i n g of a s s i g n m e n t is as you think it. Formally,
i.e. :
:=
N
Xu. Xobj.ha. (~+[v~obj])
:=
6
(V ~ (OBJ ~ (X ~ Z)))
We now c o n c l u d e the e x a m p l e s of sections
however:
4.4, 6.3 and 8.1. Recall in
p a r t i c u l a r the last example of section 4.4.
The e l a b o r a t i o n f u n c t i o n s a s c r i b i n g m e a n i n g to the source language In,
Out and Assign s t a t e m e n t s will themselves e m p l o y , b u t now, m e t a - l a n g u a g e assignments.
Since the b a s i c source language means of r e f e r r i n g to a
v a r i a b l e is t h r o u g h :
Var-ref
::
Id [Expr +]
we define a set of a u x i l i a r y functions:
type: eval-Var-ref:
eval-Var-ref
Var-ref ~ (ENV ~ (Z ~ (Z Scalar-loc))
contents:
Scalar-lot
~ (~ ~ (~ (INTGIBOOL)))
assign:
Scalar-loc
(INTGIBOOL)
takes a v a r i a b l e reference,
~ (~ ~ ~)
an e n v i r o n m e n t and a state,
and p r o d u c e s the same state and the scalar l o c a t i o n d e n o t e d by the v a r i a b l e reference.
The need for a c c e s s i n g the state arises as a result
150
of potentially evaluating array variable subscripts. Whereas
eval-Var-ref
applies to a syntactic object
the environment;
eontents
(Var-ref),
and hence needs
and assign apply only to semantic objects,
and hence do not require the environment.
Finally:
objects assigned
to storage locations must have their type match the type of the location. Recall that the storage model of the last example of section 4.4 distinguished between integer- and boolean locations:
v-tp-match(v,
0 .i .2
sloc)=
(is-INTG(v)
~ is-Intg-loc(sloc),
is-BOOL(V)
~ is-Bool-loc(sloc))
type:
(INTGIBOOL)
(Intg-locLBool-loc)
Now:
i. int-In(mk-In(vr)} (p)=
.2
then error
.3
else
(let s l o c :
.4
eval-Var-ref(vr)(p),
iv
.S
if
.6
v-~p-match(iv, sloc) then
.7
: hd c ~ ;
(In k
:= tl c ~ ;
assign(sloe, iv))
.8
else error) type: In ~ (ENV ~ (E ~ E))
2. int-Out(mk-Out(e))(p) =
.1
(let ov : eval-Expr(e)(p);
type:
Out ~ (ENV ~ (~ ~ E))
3. int-Assign(mk-Assign(vr, e))(O) = .! .2 .3
(let s l o c : val
eval-Var-ref(vr)(o), : eval-Expr(e)(o);
assign(sloc,val)) type: Assign ~ (ENV ~ (E ~ Z))
~ BOOL
151
The a u x i l i a r y functions:
4. e v a l - V a r - r e f ( m k - V a r - r e f ( i d , s s l ) ) ( p ) = .i
if ssl=nil
.2
then r e t u r n ( o ( i d ) )
.3 ~
else
(let arrloc = p(id)
.4
let il
.5
if
in
: < eval-Expr(ssl[i])(O)
il
l 1 < i < l e n s s l >;
N6 dom arrloc
.6
then error
.7
else r e t u r n ( a r r l o c ~ l ) ) )
5. c o n t e n t s ( 1 ) = .i •2
6. oi
(let V : ( s S l ~ ) ( 1 ) ; i_~ v = u n d e f i n e d
•3
then error
.4
else return(V))
assign(l,V)= STG
:= a S T G
+ [l~v]
-- a n n o t a t i o n s
io I n t e r p r e t i n g an I n p u t s t a t e m e n t p r o c e e d s as follows: is no m o r e ~nput, then we evaluate
(.2) i n t e r p r e t a t i o n halts,
(.1) If there
otherwise
(.3-.8)
(.3) the scalar location denoted by the variable refe-
rence c o n s t i t u t i n g the Input s t a t e m e n t and input stream value.
If
(.4) retrieve the front
(.5) the type of this Calue matches that of
the scalar l o c a t i o n then
(.6-.7) we p r o c e e d to
(.6)
~nput stream by the element value just retrieved,
'shorten'
and
the
(.7) to assign
this value to the scalar storage location; o t h e r w i s e i n t e r p r e t a t i o n halts.
2. I n t e r p r e t i n g an
Output s t a t e m e n t consists,
rather m o r e simply, of
(.I) e v a l u a t i n g the e x p r e s s i o n it is c o m p o s e d of and ing the r e s u l t i n g output value to the Output stream.
(.2) of append-
152
Etc. for 3., int-Assign.
4.
Evaluating a variable reference which consists of a possibly void array subccript lows:
list and the variable
(.i) If the subscript
fier is shown,
guaranteed,
by well-formedness
to denote a scalar variable,
from the environment directly. list is present,
identifier proceeds as fol-
list is absent,
then
then
(.2) the identi-
context conditions
not
whose location can be obtained
(.3-.7)
If instead the subscript
(.3) the identifier
denotes an array variable
location is kept in the environment. The subscript list is guaranteed to consist of proper expressions all yielding integer
whose
values.
Well-formedness
context conditions
but see
[Jones 1978a]. We therefore
expressions to obtain an not one of the array, the denoted
index
then
for this are not shown,
(.4) evaluate all the subscript
list.
(.5) If this index
(.6) interpretation
scalar location
fails,
is obtained by applying
list is
otherwise
the array
location, which is a map from index lists to scalar locations, the computed index
to
list.
Comments In the above definitions "parallel":
1.3-1.4,
certain
3.1-3.2.
proceed sequentially,
'pairs'
of evaluations
In [Jones 1978a]
in the order listed.
proceeded
in
the same evaluations
This gives rise to two dis-
tinct semantics!
8.4 Derived References Section 8.2 dealt only with simple variable ences denoting use, ware,
the location of an
'entire'
since 1973, of the meta-language, has not been registered
references. variable.
That is: refer-
In the design and
a need, when abstracting
for easily denoting references
soft-
to proper
components of store composite objects. When applying
the m e t a - l a n g u a g e
to lower-level
rather more implementation-biased
abstractions,
specifications,
The following notation is therefore offered.
i.e. to
such a need may arise.
153
to TUPLE Elements
Sub-References Given:
(0)
d,c,,1Tu~l~ :=
<.'..>
type D*
Retrieving
the i'th component
of ~ T u ~
(i)
l~)Ci]
is basically
expressible
with the selective update of that tuple position basically as:
~
(2)
:: ~ T U ~
It is now suggested
(3)
~{~"
to the i'th position of ~
,
permitting
(I)
[i])
(2) as:
Tu~!£" [i] :: d
Sub-References
t__ooMAp Range Elements
The forms corresponding type map:
(0)
+ [i~d];
Tu!%,p./~'[i]
(i')
(2')
expressible
to let:
denote the reference to be rewritten:
and
as:
dcl ~
to (i,2,3,1',2')
:= [... ] type A ~ D; m
are: {i)
(0 ~ )
(a)
<2)
~
::_o~
(3)
~"
(a)
(i')
s ( ~ " (a))
(2')
~'(a)
:= b
+ [a~bJ
above, but for variables
of
154
-- w h e r e a E d o m c ~ p r i o r
to
(2).
S u b - R e f e r e n c e s to Sub-"TREE"s.
Given:
D
::
s-nm1:D 1 8-nm2:D 2 ... s-nml:D 1
and:
(0)
del Tree
:= mk-D(...)
The forms c o r r e s p o n d i n g to
type D.
(1,2,3,1'~2')
above are now:
(I)
s-rim. (e Tree)
1
(2)
(let mk-D(d I ..... d i .... ,d l) := a_Tr~ze. lae~£ := mk-D(dl,...,d i',...,dl))
w h e r e all d . for j#i are unchanged, @ 8-nm. sub-"tree". Now:
(3)
s-nm,'Tree
(i')
e(s-nm.'Treg)
(2')
e-nm.'Tree
i.e. w h e r e
(2) only
'changes'
the
:= d.'
Discussion The reader m a y v e r i f y that a similar need for v a r i a b l e s c o n t a i n i n g sets does not arise. Also:
the b e n e f i t of the d e r i v e d reference operation,
h i g h e r in forms
Finally:
(2') than
(i') -- cf. forms
(2) and
denoted by " , is
(i), respectively.
the semantics of the d e r i v e d r e f e r e n c e operator, " , is fully
e x p l a i n e d by the e q u i v a l e n c e of forms spectively.
(i) and
(i'), (2)
and
(2'), re-
9 STRUCTURED CLAUSES
As used in this section a clause is either a s t a t e m e n t or an expression.
It turns out that to each s t r u c t u r e d statement, tion,
and block,
there c o r r e s p o n d s a structured expression.
such clauses s y n t a c t i c a l l y looks v e r y m u c h
see next sec-
The c o n d i t i o n a l form of
alike, w h e r e a s this is not
the case for the i t e r a t i v e clauses.
9.1 O v e r v i e w
Let in the f o l l o w i n g 8 and S(...)
stand for statements,
s u i t a b l y d e c o r a t e d e's for expressions, p r e d i c a t e expressions,
E(...) and
suitably d e c o r a t e d p e ' s
and s u i t a b l y d e c o r a t e d c's for clauses.
for It is
f u r t h e r assumed that the c's of a g i v e n c o n d i t i o n a l s t r u c t u r e are either all statements,
or all expressions,
leading to this c o n d i t i o n a l in turn
being a statement, r e s p e c t i v e l y an expression.
The following p r e s e n t s the various s t r u c t u r e d clauses in a schematic way:
C o n d i t i o n a l Clauses
(i)
if
(2)
(pc I ~
c 1,
pe 2 ~
c2,
•
pe
aI
else
c2
and
° °
(2 I)
(pc I ~
01,
Pe 2 ~
c2,
. . .
pe n
(3)
then
~
cases
c n)
T
and
CO:
~
(3') c a s e s
c n)
eo:
(e I ~
c I,
(e I ~
c 1,
e2 ~
c 2,
e2 ~
c 2,
en
cn )
T
c n)
~
156
Iterative Clauses:
(4)
fo r i = m t_~o n d_~o S(i)
(4')
<E(i)
(5')
{E(id)
(5)
for all id6set
(5")
d_oo S(id)
J m
I id 6 set}
lid ~ E(map(id))lid6dommap] f(obj)=
if P(obj) (6)
while pe do s
then
(6')
F(obj)
else G(obj,f(H(obj))) w h e r e in the last schema P being a predicate.
((6'))
P, F, G and H are a p p r o p r i a t e functions,
(4, 5, 6) are statements;
(4', 5' , 5") are expres-
sions, and so is an a p p l i c a t i o n of f.
~5_~_~!~
-- ~ :
I l l u s t r a t i o n s of the d u a l i t y b e t w e e n clauses (5) and
(5'),
(4) and
(4'), r e s p e c t i v e l y
(5"), have a l r e a d y been given -- see sections 3.4, re-
spectively 2.4, 4.4.
The d u a l i t y of the c o n d i t i o n a l statements and conditional e x p r e s s i o n s need not be further discussed.
The f o l l o w i n g examples illustrate the d u a l i t y of forms
TO sum the elements of a tuple,
(6) and
(6').
t, of integers:
Sum(t)= sum
N
~
:= 0 type INTG;
while ' (c ~) ~ <> d_~o (SU~ := ( c _ ~ ) + hdc~;
i_ff t = <>
then else hd t + sum(tl t)
return(c sum) ) S u b s e q u e n t e l a b o r a t i o n functions will i l l u s t r a t e the power and n e a t n e s s of r e c u r s i v e d e f i n i t i o n s c e n t e r e d around a simple ~_~f-then-else
clause.
157
9.2 D e t a i l e d Syntax & S e m a n t i c s 9.2.1 I f - t h e n - e l s e C o n d i t i o n a l
Schema:
i_f expr
predicate-expression
then clause
consequent
else clause
alternative
E l a b o r a t i o n of an if-then-else clause proceeds as follows: premiss-
(or test-)
p r e d i c a t e e x p r e s s i o n is evaluated.
first the
If it does not
y i e l d a truth v a l u e an error has o c c u r r e d -- and the m e t a - l a n g u a g e prog r a m is in error!
If the premiss yields truth then the consequent
clause is elaborated.
O t h e r w i s e the alternative clause. Any e l a b o r a t i o n
of either the c o n s e q u e n t - or the a l t e r n a t i v e clause strictly succeeds the e v a l u a t i o n of the premiss°
E~2~ra_n~_!n~ Notes: i.
Observe that the form :
i_~ expr then stmt
is not provided.
Instead the programmer,
if so forced,
is adviced
to use:
if expr then stmt else I for I see section 1.2. N o t e that the c o n v e r s e is possible:
i_~
Nexpr
and that the
then I else stmt 'similar' p r o b l e m is not r e l e v a n t for if-then-...
expressions~
2.
The premiss
sometimes relates as follows to either the consequent
or a l t e r n a t i v e clause:
158
i_ff ( 3 x . . . ) ( P ( x ) J then
(let x be s.t.
~(x);
cC(xJ) else
...
or, e.g. :
if~(Bsy...)(p(yjj then
...
else
(let
z =
(Ax)(P(x));
~C(z))
W h e r e e v e r the
'connection'
is so obvious,
then we informally,
but
strictly s p e a k i n g erroneously, write:
if
(3x...)(P(x)) then
cC(x)
else
...
respectively:
i_L~(3!x°..)(P(x)) then
...
else
aC(x)
etcetera.
The
'shifts'
in identifier naming is, of course,
rial. Thus the x of the latter two p r e m i s s e s
(informally)
far as the entire c o n s e q u e n t and a l t e r n a t i v e clauses.
9.2.2 M c C a r t h Y C o n d i t i o n a l
Schema:
(e I
~
esl,
e2
-~
es2J
-~
es
,o. e n
and:
) n
n < 2
immatehind
as
159
(e I
~
esl,
e2
~
es2,
~
es
.,.
T
n>2
) n
where
the
McCarthy All e i
We give
T of the latter and Cases
(1
form is a m e t a - l a n g u a g e
constructs
are p r e d i c a t e
the s e m a n t i c s
the i f - t h e n - e l s e
(i_~ e I t h e n
in the e
n
(or propositional)
of the above
keyword
'position',
i.e.
only used
in
in lieu of e . n
expressions.
in terms of their t r a n s c r i p t i o n
into
form:
es 1
else (if e 2 t h e n
es 2
else (
ooo
else (if e n the____~nes n else
error)..°)))
respectively:
(i~ e I t h e n
es 1
else (i_~ e 2 t h e n (
.o.
else
The
same remarks
i~.~-then-else identifier e8
.:
esn...)))
concerning
construct,
defined
informal
apply
in some e i
with (l
name the
binding constraint
restricted
and of
scope the
as for the scope
of
an
to the c o r r e s p o n d i n g
160
(3,.,x...)(P(x))
~
ES(x),
.., ...
...)
9.2.3 The Cases C o n d i t i o n a l
Schema:
ca8~8 ~0: (e I
~
esl,
e2
~
es2,
~n
~
esn)
and:
case8
eO:
(e I
~
e81,
e2
~
e82,
T
~
es n)
w i t h f as d e f i n e d above. The form of e. (l
is either an ordinary
i.e. one all of whose free identifiers are bound by/in the
s u r r o u n d i n g context,
or it is one of the s o - c a l l e d defining e x p r e s s i o n
forms:
{dl,d2,...,d k}
id r e p r e s e n t s
~2~_~'~_~ ~2~: U s u a l l y the dj's of an immediate d e f i n i n g e x p r e s s i o n are identifiers.
161
Some of these may be bound in the containing scope. If all are bound or constants,
then we have an ordinary expression.
We first assume ordinary,
i.e. bound expressions, and explicate through
reduction to earlier understood forms:
(let v 0 : eO; i f VO=e I then
es 1
else (if VO=e 2 then e8 2 else (
,..
else (if VO=e n then es n else e r r o r ) . o . ) ) ) respectively:
(let v 0 : eo; i_~ Vo=e I then es 1 else (if VO=e 2 then
es 2
else (
...
else
es
n
...)))
We explain the free identifier,
defining expression variants by speci-
fically presenting an atypical
combination and then transcribing it to
an if-then-else form combined with let blocks. The example assumes all branch defining expressions identifiers free and rather casually mixes sets, tuples and trees!
162
cases
eo:
({idl,id2,..o,idk}
~ es 1,
~ es 2,
m k - N m ( i d l , . . . , i f k)
~ es 3,
id
~ e84,
~..
e.g.
®,.)
transcribes
into:
(let VO: eo; if is-SET(V O) ^ c a r d v o = k then
(let {idl,id2,...,idk}
= v 0 i__nn
es I ) else (if is-TUPLE(V O) ^ ~ v o = k then
(let
else (if is-Nm(v O) then
(let m k - N m ( i d l , i d 2 , . . . , i d k) = v 0 i__nn
else
es 3 ) (let id = v O i_~n es4))))
This
latter
tively
First
form is now a n n o t a t e d
to the former
object.
elaborate, fically:
Following
in turn,
e 0, is evaluated. the listing
successive
we first ask w h e t h e r
k. If a fit is thus naming
these ~dl,
commented)
branches
v0
until
a match
is a set and,
found we d i s s o l v e
~d2,
in the cases
If v 0 is not a se~ it is then asked w h e t h e r
This
terminates
if so, of length k. If a fit is thus
elaboration
found ....
nor a tree of type N m then v 0 is r e n a m e d
to no e l a b o r a t i o n
as here:
id,
'corresponds'
ever of s u c c e e d i n g
Speci-
the set v 0 into its k e l e m e n t s
clause.
a free name,
is found.
..., idk, w h e r e u p o n the e x p r e s s i o n -
is elaborated.
the
form we now
if so, of c a r d i n a l i t y
esl,
tuple,
alterna-
The name 4 0 i d e n t i f i e s
given
clause,
Thus
referring
form:
the base expression,
evaluated
(i.e.
etc.
it is a tuple,
and
If v 0 is not a set,
id and es 4 is elaborated.
to a T - c l a u s e
branches.
or s t a t e m e n t
of the cases
-- leading
The scope of the free identifiers of the branch-expressions the corresponding expression,
or statement,
is that of
clause.
, o o
And so on: many variations,
combinations and permutations
ings of free- & bound variables).
The above
'schematic'
(e.g. order-
examples have
attempted to convey the general idea of defining expressions,
their
possible mixture of free- & bound variables and even constants. reader should,
from this, be abl~ to extrapolate.
this: since it is an abstraction,
The
The basic point is
i.e. meta-language and since there
is generally ~2~ to be an interpreter for it, anything sensible and context-wise obvious is to be allowed.
Ex_am_ple 54:
We shall use the meta-language conditional expressions and recursion to exemplify simpler versions of the conditional statements.
That is:
we applicatively define imperative constructs!
Abstract Syntax: The syntactic domains:
Cond
=
If
I MeG
I Case
If
::
Expr
Stmt
MaC
::
ExSt +
[Stmt]
Case
::
Expr
ExSt +
ExSt
::
Expr
Stmt
where E x p r
and S t m t
Stmt
[Stmt]
are the meta-language expression and statement do-
mains:
The semantic domains)
0 £ ENV ~ E STG
first the textual,
=
Id
=
LOC
~ m
(LOG
then the temporal:
°..)
~ OBJ m
where Id is the syntactic domain of identifiers, analyzed domain of locations.
LOC
the further un-
|84
Semantic Functions:
Let I and V be names of the generic functions elaborating meta-language statements,
respectively expressions, N
N
i.e.:
N
type:
I:
Stmt ~ (ENV ~ (~ ~ ~))
type:
V:
Expr ~ (ENV ~ (~ ~ ~ OBJJ)
I {8tmtJ (pJ (~)= cases
stmt:
(ink-If(p, c, a) (let
(s',b)
= V(p)(p)(o)
in
~b then I(c)(p)(~') else
I(a)(p)(~')),
mk-McC (es l, t) (let mcc(lesJ (~)= ( (Ise~<>) (let
(~',b)
= V(s-Expr(hlse))(@)(~)
in
if b then I(8-Stmt(h lse))(p)(~') else mce(t lse)(~')), (t~nil)
I(tJ(pJ(~J, T ~ error)
in
mcc (es l) (a J), ink-Cases (e, esl, t) (let (s',v)
= V(e)Cp)(~)
in
let case(lse)(~)= ((lse~<>) (let
(~',v')
= V(s-Expr(hlse))(p)(~)
if V--v ' then I(s-Stmt(h lse))(p)(~') else case(t lse)(~')), (t@nil) I(tJ(~J, T ~ error) in case (es5) (a ')), .°o)
i_~n
185
9.2.4 The Ordered,
Iterative For-To-Do Statement
Schema:
for
i d = e x p r m t_~o e x p r n d_~o stmt
i d m u s t be free in the s u r r o u n d i n g context,
e x p r m and e x p r n m u s t be
integer v a l u e d expressions. All o c c u r r e n c e s of id in 8tmt are free in stmt.
We u s u a l l y c o n s t r a i n e x p r m and e x p r n to be s o - c a l l e d ~ k ~
~P~k2~.
These are e x p r e s s i o n s w h o s e value can be a s c e r t a i n e d statically, without r e f e r e n c e to any c o m p u t a t i o n
(e.g. state). As such,
sions are u s u a l l y either c o n s t a n t s
static expres-
(viz.: e x p r m = I) or simple opera-
t o r / o p e r a n d expressions i n v o l v i n g only textual,
i.e. syntactic domain
objects.
The C o n t r o l l e d V a r i a b l e
i d is c a l l e d a, or t h e , c o n t r o l l e d variable.
sense of d e n o t i n g a R E F e r e n c e ,
It is not a v a r i a b l e in the
and thus it cannot be changed in stmt.
i d d e n o t e s an integer.
The first o c c u r r e n c e of i d in "for id =..." is the d e f i n i n g occurrence° It binds all
(free) o c c u r r e n c e s of i d in stmt.
The scope of this con-
trolled v a r i a b l e is the for statement in w h i c h it is defined.
We first e x p l i c a t e the p r i m a r i l y intended usages of the for statement: namely the ones w h i c h have e x p r m and e x p r n being static e x p r e s s i o n s e v a l u a t i n g to m, r e s p e c t i v e l y n. Let S ( i d ) to stmt.
Then:
fo r i d = m t o n d o S ( i d )
SCm) ;SCm+1} ;. . . ;SCn-1)
;SCn}
be another way of a l l u d i n g
166
Thus if m
then:
"for id = m t_~o n d__~oS(id)
=
"~".
Given S(id),
S(k)
m e a n s the s u b s t i t u t i o n of all id in S by k.
We then e x p l a i n the m e a n i n g of for statement w h o s e from and to expressions,
expr m & expr n are e x p r e s s i o n s of any kind. To this end we apply
the m e t a - l a n g u a g e
itself~
Let the for s%aZement s y n t a c t i c d o m a i n s p e c i f i c a t i o n be:
For
::
Id Expr
where I d c T O K E N ,
and E x p r
Expr
Stmt
& Stmt
denote the class of r e s p e c t i v e l y source-
language e x p r e s s i o n s and statements.
Let the semantic domains p e r t a i n i n g to the i n t e r p r e t a t i o n of F o r Statem e n t s be the temporal store:
q £STG
=
L O C ~ OBJ m
w h i c h maps L O C a t i o n s
p 6ENV
=
to OBjects,
Id ~
and the s i m p l i f i e d textual environment:
(LOCIINTGI...)
w h i c h maps s o u r c e - l a n g u a g e text I d e n t i f i e r s they are names of d e c l a r e d variables,
into either L O C a t i o n s ,
or to I N T e G e r s ,
if
if they are e.g.
c o n t r o l l e d v a r i a b l e names, or . . . .
Let V denote the generic e x p r e s s i o n e v a l u a t i o n f u n c t i o n w h i c h applies to source
- l a n g u a g e expressions,
environments
& states/st6res
state changes & objects -- in this case I N T e G e r s .
and yields
~ denotes the generic
s t a t e m e n t i n t e r p r e t a t i o n w h i c h applies to s o u r c e - l a n g u a g e statements, v i r o n m e n t s & s t a t e s / s t o r e s and yields state changes.
en
I67
(mk-For (id, fe, te, sJ ) (p) (~)= oi .2
(let (~',f) : V(fe)(p)(~), (~",t) = Y(te)(p)(~) in
°3
let ~"'6{~',S"} in
o4
let for (p')(~)=
o5 .6
i_ff P'(id)>t then
o7
else
(let ~' = I(s)(g')(~)
.8 .9
in
for (g '+ [id~(k '(id))+l]) (~ ')); for(pU[id~i]) (c5"' ))
Annotations:
.1-.2
Both s p e c i f i c a t i o n expressions, expression,
the f r o m e x p r e s s i o n and the to
are e ~ a l u a t e d in p a r a l l e l
","
(or in any order),
and b o t h m a y lead to i m p l i c i t state changes a")
.3
(~', r e s p e c t i v e l y
and to the e x p l i c i t l y d e s i r e d from, f, and to, t, values.
This line i l l u s t r a t e s the problem: or ~", to choose.
w h i c h new
(or next)
state,~'
In this case the p r o b l e m has b e e n b r o u g h t
upon us by our insistance on p a r a l l e l e v a l u a t i o n of all specif i c a t i o n expressions.
Had our pragmatics" lead us to choose se-
q u e n t i a l i t y of from- and to e x p r e s s i o n s e v a l u a t i o n there w o u l d have been no need for a n o n - d e t e r m i n i s t i c choice.
.4
A local function,
for, is r e c u r s i v e l y
(.4 vs.
.8) defined w h i c h
if applied:
.5
will test w h e t h e r the c o n t r o l l e d v a r i a b l e value gone b e y o n d the limit
.6
(t),
if so, the final state is the one c u r r e n t w h e n the last invocation
(.8 or
.9) of for was made,
i.e. at the end of last itera-
tion, r e s p e c t i v e l y w h e n for was first c a l l e d
.7
.8
(p'(id)) has
(initialized);
o t h e r w i s e the value of the c o n t r o l l e d v a r i a b l e 'body',
s, of the for statement
bounds,
and the
preted,
leading to a new state,
W i t h this state, and the (textual)
is still w i t h i n shall be Inter-
~'.
Wupdated'
e n v i r o n m e n t w h i c h binds the
name of the c o n t r o l l e d v a r i a b l e to its i n c r e m e n t e d
v a l u e the for loop is invoked
(recursively).
168
This completes the d e f i n i t i o n of the a u x i l i a r y for function,
w h i c h is first a c t i v a t e d w i t h the
.9
'initial'
state, ~', and an
e n v i r o n m e n t w h i c h binds the c o n t r o l l e d v a r i a b l e to its initial value,
i.
Note that the e n v i r o n m e n t s are simply e x t e n d e d v e r s i o n s of the
i0
e n v i r o n m e n t in w h i c h the for statemen% is interpreted.
In summary:
the m e t a - l a n g u a g e
for loop was c o n c e i v e d of as a m e a n s for
tl. Hence the s t a n d a r d
iterating t h r o u g h syntactic tuple structures,
r e q u i r e m e n t that expr m and expr n be static expressions,
the former
u s u a l l y 1, the latter u s u a l l y ~ t l .
E~E~E
Ex_am_ples 56 & 57:
We now illustrate i m p e r a t i v e and a p p l i c a t i v e d e f i n i t i o n s of the Compound
Statement
source language construct:
Cmpd
::
Stmt*
The i m p e r a t i v e v e r s i o n is b a s i c a l l y b a s e d on a state:
Z.
=
(STG~,~~ ST@) _U ...
Int-Cmpd(mk-Cmpd(stl))(p) fo r i=I to l s t l type:
=
d_2 int-Stmt(stl[i])(p)
Cmpd ~ (ENV i ~ (~i ~ ~i ))
The a p p l i c a t i v e v e r s i o n is s i m i l a r l y based on a state:
Z
a
STG ...
::
~-Gmpd(mk-ampd(stl ) ) (p) (0)= /f st/=<>
then else
(let ~' = I-Stmt(hstl)(p)(e)
in
I-Cmpd (mk-Cmpd (t 8 t l ) ) (p ) (~ ')) type:
Cmpd ~ (ENV a ~ (Z a ~ Xa))
169 where correspondingly:
type:
int-Stmt:
Stmt
~
N (ENV i ~
type:
I-Stmt:
Stmt
~
(ENV a ~
(Z i ~ Zij)
N
(Z a ~ Za))
9.2.5 The u n o r d e r e d F o r - A l l & P a r a l l e l S t a t e m e n t s
The For-All S t a t e m e n t
Schema:
fPr
all
def
6 set d__oostmt
where def and stmt p a i r w i s e are of the forms:
id
N S (id)
(cd 1, cd 2, • . ., cd n} S (idl, id2, . . . , idm)
w h e r e a p r o p e r subset of cdl,
ed2,
....
cd n may be constants,
otherwise
of either of the above four listed forms, u s u a l l y identifiers, T h e s e m u s t all be distinct.
And where idl,
id2,
...,
id!
id m are the iden-
tifiers of d e f free in the c o n t a i n i n g context. All such m u s t be free in S. It m u s t be s t a t i c a l l y d e c i d a b l e that eet denotes a set. And if either of the latter three d e f forms are used, ally d e c i d a b l e that set is of a logical type, X-eetj X ~ O r
N m is c o n t a i n e d in Y; viz.:
X-set
then it m u s t be staticY, such that either some c Y, X ~ c Y or: N m c Y~
The C o n t r o l l e d V a r i a b l e s
The i d e n t i f i e r s of d e f free in the c o n t a i n i n g c o n t e x t are the c o n t r o l l e d variables.
Again,
as in section
9.2.4 they are not a s s i g n a b l e but di-
r e c t l y denotes n o n - R E F e r e n c e O B J e c t s .
The i d e n t i f i e r o c c u r r e n c e s d e f i n i n g occurrences.
in d e f free in the c o n t a i n i n g context are
T h e y bind all their
(free) o c c u r r e n c e s
in Stmt
The scope of these c o n t r o l l e d v a r i a b l e s is the for statement in w h i c h they are defined.
(S).
170
In this ment
section we only e x p l i c a t e
for the simple
the semantics
case of static
set e x p r e s s i o n s
fier def's -- this is also the m o s t of k objects,
and name
these
of the for-all and simple
stateidenti-
Let set d e n o t e
common case.
a set
idl,id2, .... id k. T h a t is set N {idl,id2 ,
...,idk}:
~or all idE{idl,id2, .... id k} d_~o S(id)
// {~idl),S(id 2) ..... S(idk)}
The P a r a l l e l
Statement
Schema:
//{stmtl,stmt2,...,stmtn}
n>2
Sea~i~ : Elaboration parallel, clause
of the s t a t e m e n t s
"independently"
terminates
stmtl,
stmt2,
of each other.
as a r e s u l t of all
..., 8tmt n p r o c e e d s
Elaboration
statements
of this
in
collateral
having been e l a b o r a t e d .
E_x~!es _5_8-_S2 We now i l l u s t r a t e to the parallel parallel,
All
::
of a source
Instead
language
of e l a b o r a t i n g
in any,
arbitrary
statement
similar
the s t a t e m e n t s
in
order:
Strut-set
tive
::
statement.
they are just e x e c u t e d
is the syntactic
)-
the s e m a n t i c s
o..
domain
specification.
The d e f i n i t i o n
is kept a p p l i c a -
171
I-All(mk-All(stmts))(O)(~)= if stmts={} then elee (let s £ 8tmts in let a' = I-Stmt(s)(g)(s)
in
I-All(mk-All(stmts~{s} ) ) (p) (a ')) type: All ~ (EN~ ~ (~ ~ ~))
A for-all source language construct could be given the following definition:
ForAll
::
::
Id Expr Stmt
...
I-ForAll(mk-ForAll(id, e, s) ) (g) (~)= (let (s',set) = V-Expr(e)(O)(s)
in
let all(coll)(~)= if coll={} then else (let obj 6 toll in let ~' = I-Stmt(s)(p+[id~obj])(~) all(coll~{obj}) (~ '))
in in
all (set) (s ')) type: ForAll ~ (ENV ~ (Z ~ ~)) where it is assumed that the evaluation function, which elaborates id, finds the meaning of id just by looking up in the environment~
type: I-Stmt:
Stmt ~ (ENV ~ (Z ~ X))
t~pe: V-Expr:
Expr ~ (ENV ~ (Z ~ (Z OBJ)))
9.2.6 The While-Do Statement Schema:
while expr do stmt where it is statically decidable that expr is a truth-valued expression.
172
expr is usually an impure expression,
i.e. one whose value depends on
the current state. The state is, of course, potentially being changed by stmt.~
As you might expect it -- but here is an applicatively expressed forma lization of the imperative while construct.
_~x~!e _6_0: Abstract Syntax: Wh
::
E x p r Stmt
for the syntactic domain. And:
£ STG
=
p £ ENV
=
LOG ~ OBJ m Id ~ (LOCI...)
for the semantic domains.
I (mk-Wh(e, s)) (p) (~)= (let w h ( ~ ) = Clet
(~',b)
= V(e)(p)(~)
i_~n
ifb then
(let 6" = I ( s ) ( p ) ( ~ ' )
in
wh(~")) else
~')
wh(~) ) type: I : Wh ~ type:
(ENV ~
wh: ~ ~ £
(~ ~ ~) )
in
~73
Dijkstra's Guarded,
rg E RepGuard w i t h STG and ENV
Repetitive Construct
::
(Expr
[Di~kstra 75 ]:
Stmt)-set
as above, has the f o l l o w i n g
'informal'
semantics:
Execute rg as long as e v a l u a t i o n of at least one e x p r e s s i o n in the un= o r d e r e d set of pairs of Expression-Statements
zields
true:
~(mk-RepGuard(ese))(p)(a)= .1
(let gwh(ses)(~) =
/_Z se~={}
.2 .3
then
.4
else
(let
(e,s) E see
in
.5
let (~',b) = V ( e ) ( o ) ( ~ )
.6
~b
.7
then
.8
in
else gwh(ses~{(e~s)})(~))
in
gwh(ess)(e)) t,,~Pe: RepGuard
In this definition, i.e.:
(let ~" = I(s)(p)(~') gwh(ess) (~") )
.9 .i0
in
~ (ENV ~ (~ ~ Z))
e v a l u a t i o n of guards
(e) m a y cause side-effects,
~ goes to ~'. Thus r e p e a t e d e v a l u a t i o n s of some
(one) guard,
in =
itially y i e l d i n g falsity, m i g h t e v e n t u a l l y p r o d u c e truth -- had we not p a s s e d the initial state tions
(~, s u b s e q u e n t l y ~) onto a l t e r n a t i v e evalua=
(.9). D o i n g so also secures D i j k s t r a ' s r e q u i r e m e n t that if some
guard is chosen,
then it was
true in the 'initial ~ state
(~, subse=
q u e n t l y ~).
The n o n - d e t e r m i n i s t i c a s p e c t of this c o n s t r u c t is e x h i b i t e d by the ar= b i t r a r y set e l e m e n t s e l e c t i o n of line
.4.
The reader m a y v e r i f y that this c o m m a n d is a (sledge-hammer ?) ization of the while
do c o n s t r u c t above~
general=
174
10. BLOCKS
A c o m p o u n d statement:
(stmtl;
stmt2;
.,. ; stmt n)
is a s e q u e n c e of two or m o r e statements. The semicolon,
";", acts as
the c o m b i n a t o r here.
A block:
(let id = expr d i__nnexpr b )
(let id = expr in stmt)
(let id : exprd;
(~et id : expr;
(dcl vr := exprd;
expr b)
(dcl vr := expr;
expr b)
consists of a (let)
d e f i n i t i o n of a constant,
a (dcl)
(of a variable)
declaration
an expression,
or a statement
stmt) stmt)
non-re_~erence object,
or
-- on one hand --, c o m p o u n d e d w i t h
(-sequence)
b i n a t o r s here are either the semicolon,
-- on the other hand. The com=
";", or the "in" symbol.
This section will not bring very m a n y examples.
Previous
sections abound
w i t h examples of blocks. We leave it to the reader to look these up for re-confirmation:
R e f e r e n c e to block-exam~!e~:
P a r e n t h e s i z e d numerals refer to example numbers, these refer to formulae
(i) and line number
the i.j-k trailing
(j-k) sequences.
A p p l i c a t i v e e x p r e s s i o n blocks: (0)11.3-8, (0)18.8-21,
(0)11.6-8,
(0)16.1-6,
(0) 17.3-7,
(0)18.3-21,
(0) 20.3-11 . . . .
I m p e r a t i v e e x p r e s s i o n blocks: (31) 14.3-6, (52) 5.1-4,
(31)14.12-17,
(50) 2.0-3,
(50) 3.0-3,
...
S t a t e m e n t blocks: (31) 13.1-8,
(52) 1.3-8,
(52)2.1-2,
(52) 3.1-3,
...
(52) 4.3-7,
175
The B l o c k C o n c e p t
The b l o c k
concept
tion of scope.
of the m e t a - l a n g u a g e
Blocks
essentially
d e a l s w i t h the no-
are of the forms:
(let id = expr in clause)
and:
(let id : expr; clause).
We have, duce
however,
in p a s t examples,
also p e r m i t t e d
ourselves
to intro-
local variables:
(del id := expr }Epe D; clause). In all three cases id stands s t a n t quantity. it is defined. first
for a locally,
We say that the Only
two blocks
in this
last case id d e n o t e s
a block,
scope of id is the block:
textual
id d e n o t e s
i.e.
part,
may
(...)
it be r e f e r r e d
the v a l u e of expr upon block
the l o c a t i o n
defined,
of a m e t a - s t o r a g e
cell,
in w h i c h
to.
entry. i.e.
con-
In the In the
an ob-
ject in the d o m a i n of Z:
z
. . . .
u
(zd ~
D)
--
u
[i !-,
obj]
In pa r t i c u l a r :
where
...
i d is the d e n o t a t i o n
of id, and obj is the v a l u e of expr upon
block entry.
The
let
(or dcl) d e f i n i t i o n s
of id in clause.
Thus
of id are said to bind any free o c c u r r e n c e s
the scope of id extends
to inner,
nested
blocks
in w h i c h id is not redefined.
clause m a y be a m e t a - l a n g u a g e statements.
expression
or a s e q u e n c e
of one or m o r e
176
10.1 Let C o n s t r u c t s
O b s e r v e the two d i s t i n c t cases of let constructs:
The § £ n t a ~ ! c ,
let construct:
o~ a ~ ! ! c a t i v e
(let id = expr i__nn clause)
If expr is a ~ e
S~£~!2~,
i.e. an e x p r e s s i o n w h o s e e v a l u a t i o n does
not require access to any state components,
then we use
"=" and "i~n"
as delimiters.
The semantic,
or ~ £ ~ ! Z 2
let construct:
(let id : expr; clause) If, on the other hand,
e v a l u a t i o n of expr requires access to the state,
i.e. if expr is an ! ~ ! Y ~ ,
or ! ~ E S ,
~P~!2~
, then we use ....
and ";" as delimiters.
A s s u m e id to o c c u r free in clause,
i.e. think of clause as C(id). T h e n
the m e a n i n g of the syntactic let clause block is C(expr),
i.e. can be
o b t a i n e d by substituting expr for all free o c c u r r e n c e s of id in clause. Note that the s u b s t i t u t i o n could be done on the syntactic level,
by ~!~S!~S
texts. The meaning,
however,
i.e.
of the semantic let clause
block is C(val), w h e r e val is the value of expr u p o n block entry. That is: the m e a n i n g can be o b t a i n e d by
e~£kik~ki~
free o c c u r r e n c e s of id in clause.
Let C o n s t r u c t V a r i a n t s
A v e r y useful
let v a r i a n t is:
(let obj £ D be s.t. clause)
P(obj);
values of expr for all
177
w h i c h we u n d e r s t a n d
let obj be an o b j e c t
as:
such that it satisfies
the p r e d i c a t e
in the d o m a i n
P. Ot h e r variants,
or set D
which
are simple
cases of the a b o v e are:
(Set obj 6 Set; clause) and:
(let obj be s.t. P(obj); clause) The a b o v e
three v a r i a n t s
construct
from the b l o c k body
lar,
but s y n t a c t i c
were
indicated,
by the
";" s e p a r a t i n g
constructs
would
instead
of the infix
The
O b j e c t Let , D e c o m p o s i t i o n
following
are useful,
so-called
composite
let constructs:
(let m k - D ( d l , d 2 , . ~ , d n) = expr d i__nn clause) (let
let ~dl,d2,...,d n} = expr s i~n clause) Their
respective
meanings
are:
expr d m u s t e v a l u a t e to a D tree object, D
::
D 1 D 2 .o. D n
then the a b o v e "is e q u i v a l e n t
let
";" use an in-
fix "in".
Composite
the
clause, to be of the semantic type. Simi-
to:
with:
178
Cle__~t tree = expr d i_nn
(!~t d I d2
= s-D1(tree), = s-D2(tree) ,
dn = s-D n (tree) clause)).
in
expr t must evaluate to an n-tuple: (let tuple = expr t inn (let d I
= tuple[1],
d2
= tuple[2],
dn
= tuple[n]
__in
clause)). expr s must evaluate to a set of cardinality n. The 'assignment' of set objects to d i is arbitrary:
(let set = expr s in (let d I E set i_~n (~t
d 2 E set~{d I} i__nn
(let d s 6 set~(dl,d 2} i__nn (let d n E 8et~{dl,d 2 .... ,dn_ I} in clause)...))))
Simultaneous & Recursive Let Definitions
The form:
(let d I = el, d 2 = e2, o l .
d n = e n in clause) simultaneously defines the objects tO be the
(nz2)
d l , d 2 , . . . , d n.
They are, in general,
("smallest" such) objects which satisfy the
simultaneous)
equations.
(above set of
This description permits djWs to occur recur-
sively in the equation set. The dj.'s might be composite constructs,
179
introduced
in the p r e v i o u s
subsection,
constituent
(free)
recursively
in the e q u a t i o n
identifiers
For the story on r e c u r s i v e
(ultimately
The
definitions
Conventions
form:
let d I = e I i_nn let d 2 = e 2 i_nn
let d .......
= e ~
in n
--
clause)
is a s h o r t - h a n d
for:
(Zet d I = e I ~n (let d 2 = e~ i~n (o,°
(let d
= e
in
clause)...)))
The
form :
(let m k - A (
,c,
) = ea
in
clause)
where
e.g.:
A
::
is a s h o r t - h a n d
B C D,
for:
(let m k - A ( b , c , d ) clause)
occurring
in dj)
m a y occur
set.
6.2.
Notational
in w h i c h case we m e a n that the
= ea
in
--
of f u n c t i o n s
we refer
to section
180
It is used to alert the reader to the non-use of the B and D components of the A tree d e n o t e d by e .
Similarly for anonymous trees; and:
(let
<x~
,z,
> = e t i__nn
clause)
w h i c h is the same as:
(let let
t = e t i_~n x =
t[1],
z = t[3]
in
clause ) .
10.2 Pure & Impure E x p r e s s i o n s
A ~ure
(or applicative)
S ~ ! 2 ~
is one whose e v a l u a t i o n never re-
quires access to the state.
An !mR~re
(or imperative)
~£S££!2~
is one whose e v a l u a t i o n p o t e n t i a l l y
r e q u i r e s access to the state.
G i v e n that X. denotes the state space of an i m p e r a t i v e
(global v a r i a b l e
only) m o d e l we can say that the type of the d e n o t a t i o n of an impure exp r e s s i o n is either of the form:
xi ~ (£i OBJ) or of the form:
x. ~ oBJ The former type hints that e v a l u a t i o n of the m e t a - l a n g u a g e e x p r e s s i o n p o t e n t i a l l y leads to a (side-effect)
state-change, w h e r e a s the latter
type only expresses that the state is a c c e s s e d in order to c o m p o s e the resulting OBJect
value.
181
The choice of forming an e x p r e s s i o n either as a pure-, expression,
is solely d e t e r m i n e d
by the kind of object to be denoted.
That is: even though some abstract model global
state variables,
or as an impure,
is p r i m a r i l y centered around
some objects may still be denotable by pure
expressions. If at least one target expressions pure,
of a conditional
then all such target expressions
ment is further m o t i v a t e d expression
expression
are to be impure.
in [Jones 1978a].
is im-
This require-
To render an otherwise pure
return.
impure prefix it with the operator
See section 10.6.
10.3 The ";" Combinator The ";" is a combinator. tically,
Its use can be explained
and semantically.
rative clauses:
Syntactically
statements;
from a statement;
semantic
and a statement
(... 8tmtl;
in two ways:
speaking,
let clauses;
syntac-
";" separates a semantic
impe-
l~t clause
from an impure expression:
8tmt 2 ...)
(...
let x I : exprl;
let x2: expr2;
(...
let x: expr; iexpr)
...)
(... 8tmt; iexpr) Semantically
speaking
";" denotes
functional
of the d e n o t a t i o n of a m e t a - l a n g u a g e ment,
semantic
composition.
Since the type
let clause,
let, or state-
stmt, is: let,
stmt: Z. ~ Z.
The construct:
(ci;e2) where
(ci,c2) are either
statements),
(semantic
lets,
statements)
means:
Xs.(e2(cI(s))) where
ai is the m e a n i n g of ei
(i=1,2). Thus:
or
(statements,
182
lal . ha2. hs. (c2 (ci Ca)))
N
;
i.e.
£
10.4 C o m P o u n d
(Z ~ Z) * ((Z ~ Z) * (Z~Z))
Statements
The m e t a - l a n g u a g e
(stmtl; The body of a to as clause
permits
parenthesizing
block,
section
8tmt2;
...;
i.e.
the s y n t a c t i c
10.1, m a y be a s t a t e m e n t
statement:
construct
referred
sequence:
8tmt n
difference
the latter
The formal m e a n i n g
to be a c o m p o u n d
..~ ; stmt n)
(statement-)
is no semantic
Sequences
any s t a t e m e n t
stmt2;
in e.g.
stmtl; There
& Statement
since
between
these two constructs.
it is always
We omit
superfluous.
is:
X~.stmtn(Stmtn_1(...(stmt2(stmt1(~)))...)) where
stmt°
We re f e r
is the m e a n i n g
to
[Jones
of the basic
1978a]
Statement-
a state-change.
is as you w o u l d
& Expression
A statement-block
evaluated,
for a f u r t h e r
l-definition
of the m e a n i n g s
statements.
The i n f o r m a l m e a n i n g
10.5
of stmt..
expect
it to be.
Blocks
is a statement.
The block,
An e x p r e s s i o n - b l o c k
when
interpreted,
is an expression.
m a y e f f e c t a state-change,
but always,
effects
The block,
in addition,
when
delivers
a value: N
A statement
stmt-block:
X. * X.
expr-block:
Zi ~
block consists
(E i OBJ)
of a s e q u e n c e
of one or m o r e
syntactic
and/or
183
semantic
let clauses
f o l l o w e d by a sequence of one or m o r e statements.
An e x p r e s s i o n b l o c k is either a pure- or an impuretive-,
r e s p e c t i v e l y an imperative-)
c o n s i s t s of one or m o r e s y n t a c t i c
expression.
let clauses
(i.e. an applica-
A pure e x p r e s s i o n block
f o l l o w e d by a pure ex-
pression. An impure e x p r e s s i o n block consists of a n o n - z e r o length seq u e n c e of zero, one or m o r e s y n t a c t i c - or s e m a n t i c
let clauses
followed
either by an impure e x p r e s s i o n or a s t a t e m e n t all of w h o s e s y n t a c t i c a l l y p o s s i b l e e x e c u t i o n paths end w i t h an impure expression.
Since only well-
s t r u c t u r e d statements are p e r m i t t e d the test for this latter is quite simple.
10.6 Return
From the e x p l a n a t i o n o f " / " it follows that if a s t a t e m e n t sequence, an e x p r e s s i o n block,
is to be followed by an expression,
of
then the type
of this e x p r e s s i o n m u s t be:
Z -~ (X OBJ)
i.e.
impure.
In general,
if the c o n t e x t d e t e r m i n e s that an e x p r e s s i o n be impure,
the value to be y i e l d e d can be d e n o t e d by a pure expression,
and
e, then we
need to r e n d e r e impure. This is the p u r p o s e of the m o n a d i c e x p r e s s i o n operator return.
return
N
kobj. h<~. (~, o b j )
return
6
(OBJ ~
(~ ~
(~ O B J ) ) )
Ex ~ ! e s See examples:
(31) 14.6,
(31) 14.17,
(50) 2.3,
(50) 3.3,
(50) 4.5.
184
ii. EXITs
Even though the m e t a - l a n g u a g e conventional
GOTO construct.
The exit mechanisms,
has i m p e r a t i v e Hence
in m a n y ways,
say, w i t h o u t b e i n g g r o s s l y wrong, albeit,
in general,
unlabelled,
it lacks
replace
source
Observe
the d i s t i n c t i o n
in p a r t i c u l a r
1
Block
2 3
the GOT0 construct.
determined,
language!
when modeling Therefore:
a structured
::
(Id ~ Type)
Named-Stmt
::
[Lbl] Stmt
Stmt
=
Block
of the same list,
read carefully.
and m e t a - l a n g u a g e
constructs,
... N a m e d - S t m t *
I Gore
whether
been executed,
t ...
through
or out of the c o n t a i n i n g
or w h e t h e r -- as w e r e
of n e s t e d (normal)
Block to a s t a t e m e n t
Block,
in fact it m a y
due to all statements
Goto,
due to a global
in e.g.
the same
example
31,
4 i n t - B l o c k ( m k - B l o c k ( d c l s , p r o c s , n s t l ) ) (p, ca)= .i (let aid 6 AID be s.t. aid ~c ca in J lbl £ Labels(nstl)
.3
+[ v ~ g e t - l o c ( d c l s ( v ) ) ( p )
.4
+[ s-ID(p) ~ eval-Proc(p)(p')
.6
I p 6 procs
always (let loce
.7
= {p'(v)
Set sloes = { ...
.8 .9
i v £ domdcls
S T ~ :=
I v 6 domdcle} see example
31 ... }
c~slo~)
in i n t - N a m e d - S t m t - l i s t ( n s t l ) ( p , caU{aid},aid)) tRpe:
Block ~ ((ENV AID) ~ (X ~ ~))
i_~n i_nn
having
'clean-up' section
first take place:
let p' : p+[ lbl ~ mk-LAB(aid, lbl)
T h a t is:
list to another
Each time a Block a c t i v a t i o n
levels.
epilogue
illustrated
structures.
of a N a m e d - S t a t e m e n t
list of the next e m b r a c i n g
go out of any such n u m b e r
logue actions
the GOTO c o n c e p t of our r u n n i n g
Gotos m a y not go into p h r a s e
language
of the N a m e d - S t a t e m e n t
.5
GOTO,
and -- in any case --
in the f o l l o w i n g
between s0~6e-
Gotos m a y e.g. go from one s t a t e m e n t
.2
You m a y
the block constructs.
In this source
must
the
p r o g r a m point.
example
is left,
it lacks
labels.
that exit p r o v i d e s
to a d y n a m i c a l l y
We use the exit m e c h a n i s m
statement
constructs,
] ];
epi-
4.5 --
185
.4
eval-Proc
is the i m p e r a t i v e
in e x a m p l e
.2
42
(section
The d e n o t a t i o n
.i
serves
to keep
(identifiers
The b l o c k e n v i r o n m e n t list w i t h this
Since p r o c e d u r e s
track of a c t i v e
na m e d
statement
blocks,
source
activation
from w i t h i n
current
language
passed
identifier
not
activations.
of its n a m e d
statement
(identifier).
and -- i n d e p e n d e n t l y a procedure
lists of any of its embracing,
(thus recursively)
.4-.8
an a c t i v a t i o n
by all)
all Labels
m a y be recursive,
the e n v i r o n m e n t
We shall r e t u r n
selects
selected
associates
(unique)
since gotos m a y o c c u r
lines
is in the domain:
a c t i o n of a Block
in the set of
.4
6.3)°
activations.
The p r o l o g u e
o2
V-Pro, as used
40's
:: AID Lbl
The AID c o m p o n e n t block
of e x a m p l e
6, r e s p e c t i v e l y
of a label
LAB
version
thereof
(activation) including
--
to the
defining,
to eval-Proc is the e n v i r o n m e n t
being
defined.
to lines
.5-~9,
& .3 of int-Block
which
-- on the w h o l e
of example
31,
section
-- r e s e m b l e
4.5.
5 int-Named-Stmt-list (nstl) (g, aa, aid)= .i (tixe
[ mk-LAB(aid, 1) ~ cue-int-Named-Stmt-list(ijnstl)(p,
.2 .3
i 1 < i < len nstl ^ 8-Lbl(nstl[i] i_~n cue-int-Named-Stmt-list(1,nstl)(p,
ca))
6 cue-int-Named-Stmt-list(i,nstl)(p, ca))= .i
for j=i to l e n n e t l
d_~oint-stmt(s-Stmt(nstl[j]))(p, ca)
7 int-Stmt(stmt)(p, ca)= .1 .2
case8 stmt: (mk-Goto(lbl)
.3
mk-Block(.°.)
..
°..)
~
exi~(o(lbl)) ,
~ int-Block(stm~J(p, ca),
-- annotations:
5.0
Interpreting
a named
statement
list is the same as:
ca) = l ~ nil ]
186
5.3
interpreting
that list as from its Ist statement.
T h a t is: the tixe is not
'executed'
(exit spelled in Polish) clause of lines 5.1-5.2 by the m e t a - l a n g u a g e e l a b o r a t o r w h e n first en ~
tering the int-Named-Stmt-list 'discover'
6.0
functions. We shall s u b s e q u e n t l y
the p u r p o s e of the tixe clause.
Having cued this function w i t h i, i.e. having given it the startw o r d i, interpretation
of the statements
of the
(named)
statement
list
6.1
p r o c e e d s linearly, -- provided,
as from the cued, ith, s t a t e m e n t until the last
of course, m e t a - e l a b o r a t i o n is not re-directed.
W h e n & how this occurs will p r e s e n t l y be uncovered.
7.1
If the interpreted
statement
7.2
a Goto, then an exit is performed.
is
a r g u m e n t is the LABel denotation,
It is g i v e n an argument.
This
mk-LAB(aid, lbl), by w h i c h this
label is known in the environment. M e t a - e l a b o r a t i o n of an exit d y n a m i c a l l y
'unravels'
the m e t a - l a n -
guage block invocations. That is: we retrace our steps, back to (here) the m o s t recent m e t a - l a n g u a g e block having a tixe clause. We say that the tixe clause stops the exit.
5.1
The tixe clause we b a c k t r a c k to, is the one a s s o c i a t e d w i t h the named s t a t e m e n t
list of w h i c h the
'offending'
Goto was an immediate
statement. The tixe clause is to be u n d e r s t o o d as follows: p a s s e d b a c k w i t h the exit
of the "map" c o m p o n e n t of the tixe clause,
cue-int-Named-Stmt-list,
if the a r g u m e n t
(7.2) is equal to some mk-LAB(aid, l) then the c o r r e s p o n d i n g
w i t h the a p p r o p r i a t e cue p o s i t i o n
(i), is
invoked; o t h e r w i s e the d e s p a t c h i n g exit is not stopped here, but p a s s e d out to the next e m b r a c i n g tixe clause -- i.e. the Goto is to an e m b r a c i n g Block.
6-7
In now
(re-)interpreting
possibly, 5.1
the
as from another,
These are stopped,
(same) named statement
cued, position,
thus recursively,
by the
list, but,
new Gotos m a y occur. 'same'
tixe clause.
187
7.1
If the interpreted statement
is instead,
in c o n t r a s t to a n n o t a t i o n s
7.1-7.3 above,
7.3
a Block, the~ that, nested,
And so on. p a s s e d on
Block is interpreted.
exits are always stopped by an alway8 clause before being (4.5-4.8).
Comments The "maps" of tixe clauses may,
as we have done in the above annotations,
be c o n s i d e r e d ~2~ to be "computed" w h e n the m e t a - l a n g u a g e e l a b o r a t o r enters a m e t a - l a n g u a g e block having a tixe clause.
The domains of such
"maps" are c o n s t r a i n e d to be s t a t i c a l l y determinable, in the cue-int-.., object,
e l a b o r a t i o n function,
and finite.
Since,
nstl is a static (i.e. fixed)
this c o n s t r a i n t is satisfied.
You m a y in fact v i e w the d o m a i n of the "map" of the tixe clause as being 'computed' u p o n entry to the m e t a - l a n g u a g e block of w h i c h it is part. Now,
for this source language,
the test for w h e t h e r the "returned" argu-
m e n t of an exit belongs to such a "map" is likewise
'statically'
deci-
dable since o n l y Gotos w i t h c o n s t a n t Label d e s i g n a t o r s w e r e permitted.
II.i The Exit M e c h a n i s m s
In the f o l l o w i n g the language constructs, d e a l t w i t h and mentioned, those of the meta-language~
and not c o n s t r u c t s of a ~ 0 ~ c z
are
language
being modeled.
V a r i a b l e s p r e s u p p o s e declarations,
and d e c l a r a t i o n s define a state.
S t a t e m e n t s are r e q u e s t s for state changes, mers,
and denote state t r a n s f o r -
i.e. functions from states to states. The serial s t a t e m e n t compo-
sition o p e r a t o r ";"
(semicolon)
thus denotes functional c o m p o s i t i o n .
In c o m p o u n d e x p r e s s i o n s all c o m p o n e n t s u b - e x p r e s s i o n s are
(usually)
c o m p l e t e l y e v a l u a t e d before any result v a l u e is yielded.
In this section we shall d e s c r i b e the o n l y s t a t e m e n t - and e x p r e s s i o n c o n s t r u c t a v a i l a b l e for c h a n g i n g the m e t a - l a n g u a g e s t a t e m e n t interpre-
188
tation-,
respectively
The exit m e c h a n i s m statements
language,
sion
the e x p r e s s i o n
n o w to be e x p l a i n e d
offers
-- in one sense a r e s t r i c t e d
gotos.
conventional
statements
controlling
gotos
to
In particular: (arbitrary
exits p r o v i d e
evaluation-,
-- in the c o n t e x t
form of,
or a l t e r n a t i v e
instead of providing,
or p h r a s e - s t r u c t u r e
such g o t o s
part.
to
in the meta-
constrained)
to s t a t e m e n t - b l o c k
of
labelled
or b l o c k - e x p r e s -
"ends".
In the c o n t e x t
of an a p p l i c a t i v e
language
it is an a l t o g e t h e r
new con-
struct.
The m e t a - l a n g u a g e
provides
exit,
1,2
(alway8
.i
stopping
constructs:
F(...)
in C(...))
(tra£ exit(def)
4.0
.I
with
F(def)
in C(...))
(tixe
5.0
.i Lines
designators:
exit(expr)
and three kinds of exit
3.0
two k i n d s of exit
[ G(def)
~ F(def)
I P(def)
]
in C(...)) 3.0,
4.0 and 5.0 schematize
prefixed
Clauses
1 or 2 can o c c u r w h e r e m e t a - l a n g u a g e
m a y occur. plicative
Thus
by a stopping
the stopping
C(...),
the exit m e c h a n i s m
construct
ping clause,
construct
-- see
[Bj~rner
as will be seen,
clauses.
becomes
statements
is an imperative,
restricted
blocks.
The forms
d e f can be of either of the forms:
{ dl,d2,...,d n } < d l , d 2, . . . ,d n > m k - D ( d l , d 2, • . . ,dn) , id, c~t
or e x p r e s s i o n s
as w e l l
as an ap-
The use of the always
77e].
is, however,
Any clause,
a block.
(d 1,d 2, •.., d n) , or
stop-
to i m p e r a t i v e
189
w h e r e id stand for terals),
(free or bound)
identifiers,
cst for constants
(li-
d i for forms of the above kind, and w h e r e the def form need
not c o n t a i n any free identifiers.
11.2 P r a g m a t i c s & S e m a n t i c s of the E x i t M e c h a n i s m
The exit concept is based on the f o l l o w i n g four principles:
(I)
The first basic p r i n c i p l e of exit is to p e r m i t goto-like of e l a b o r a t i o n evaluation)
(statement interpretation,
transfer
respectively expression
c o n t r o l to block b o u n d a r i e s -- i.e. to just outside
their t e r m i n a t i n g part. In particular:
e l a b o r a t i o n of any exit not d e f i n i t i v e l y stopped
in a block p r o p e r l y c o n t a i n e d in C(...) will result in immediate t e r m i n a t i o n of any further parts of C(...)
, this to be f o l l o w e d
by e l a b o r a t i o n of some F(...).
(if) The second basic p r i n c i p l e of exit is to p e r m i t the u s e r to (implicitly)
specify w h i c h
(dynamically enclosing)
block end the
exits go tO: A block w i t h no stopping clause is said to not d e f i n i t i v e l y stop any exit. A tra P exit unit w h o s e e l a b o r a t i o n m a y result in an exit is likewise said to not d e f i n i t i v e l y stop an a r b i t r a r y exit. nally:
if an e l a b o r a t i o n of P(.°.)
Fi-
is c o m p l e t e d w i t h no exit then
the exit is said to be d e f i n i t i v e l y trapped.
In that case elabo-
ration of the block c o n s i s t s of e l a b o r a t i o n of the part of C(...) up to the exit f o l l o w e d by e l a b o r a t i o n of the P(...). The p o t e n t i a l state t r a n s f o r m a t i o n y i e l d e d by an i m p e r a t i v e block is in this case the serial c o m p o s i t i o n of the two net effects. For the case the block is a b l o c k - e x p r e s s i o n of d e f i n i t i v e entrapment,
P(...) m u s t in this case, namely that
y i e l d a value.
~II) The third basic p r i n c i p l e of exit is to p e r m i t the m e t a - l a n g u a g e p r o g r a m m e r to specify that c e r t a i n actions be taken at any stopping block end. The stop clauses serves this purpose,
exits from m u l t i p l y nested
blocks m a y cause s u c c e s s i v e s t o p p i n g actions, out), block.
one per block
(inside-
and each being t e r m i n a t e d by an exit to the next e n c l o s i n g
190
An exit not d e f i n i t i v e l y stopped by a stop clause of the (outermost)
block of a f u n c t i o n d e f i n i t i o n is d y n a m i c a l l y p a s s e d to the
immediately function,
e m b r a c i n g block in w h i c h the actual r e f e r e n c e to the
i.e.
"to this f u n c t i o n definition",
occurred.
The always stop clause u n c o n d i t i o n a l l y filters any exit, its
F(...) is elaborated, and the exit p a s s e d on to outer blocks. In consequence:
exits of one f u n c t i o n d e f i n i t i o n may, d e p e n d i n g
on dynamic calling patterns,
be trapped by a m u l t i t u d e of stop
clauses of blocks c o n t a i n e d in various
(other)
function defini-
tions. An exit of an a c t i v a t i o n of a r e c u r s i v e l y defined f u n c t i o n m a y thus be stopped by a prior,
temporarily suspended activation
of that "same" function.
(IV) The fourth basic p r i n c i p l e of the exit mechanism,
i.e. the joint
use of exits and stopping clauses is finally to c o m m u n i c a t e inform a t i o n from the
(usually
only d y n a m i c a l l y determinable)
point of
exit to trap exit and tixe stop clauses' F(.o.). The idea being to let the e l a b o r a t i o n of F(...) In particular:
the value,
depend on exit "returned"
v, of the expr of exit(expr)
the proper stop clause is found;
data. is obtained;
and v is s u b s t i t u t e d for all free
o c c u r r e n c e s of that unit's formal p a r a m e t e r def in that unit's
F(...) r e s u l t i n g in F'(...)o Then F'(...) is elaborated.
Scope Rules
A n a l t e r n a t i v e w a y of d e s c r i b i n g some of the linguistic p r o p e r t i e s the exit mechanism)
Two scope aspects are important: A syntactic tic
(of
is now presented.
(or static),
and a seman-
(or dynamic).
The ~ £ ~ ! ~
~2~
~!~
±S c o n c e r n e d w i t h the scope of i d e n t i f i e r s
o c c u r r i n g in the def form of the trap exit clause. free in the e m b r a c i n g context, fiers in the c o r r e s p o n d i n g
bind
Identifiers of def,
free o c c u r r e n c e s of these identi-
F(def). The static scope rules of the tixe
"map" are the same as those of any i m p l i c i t map
(set or tuple)
construc-
tion. The semantic scope rule is c o n c e r n e d w i t h the scope of the alway,s, tra~
exit and tixe clauses.
191
The dynamic scope rules of the always and tra~ exit clauses is the text C(...); w h e r e a s the dynamic scope rule of the tixe clause includes both the tixe
"map" and the text C(...)!
an exit
Thus:
'occurring'
F(def), of 3.0 or
as a r e s u l t of e l a b o r a t i n g
4.0, if not stopped in F(...), is ~2~ stopped by this
(3.0, r e s p e c t i v e l y
4.0) i n s t a n c e of the always, r e s p e c t i v e l y tra P exit clause.
Instead it
is p a s s e d out to p o s s i b l y e m b r a c i n g meta-blocks.
An exit
'occurring'
of a tixe clause
"map",
as a result of e l a b o r a t i n g some F(def) of 5.0, i.eo
if not trapped in F(...), is trapped by this tixe
(5.0). Thus the tixe clause is said to apply
~S~!E~!£!
Some E q u i v a l e n c e T r a n s f o r m a t i o n s
The always stop clause in:
(always F(...) in C(...)) is s e m a n t i c a l l y e q u i v a l e n t to:
(.trap exit(id) with (F(.~.); exit(id)) in C(...))
In g e n e r a l a b l o c k w i t h no stopping clause:
(let x : E(...); C(...)) is identical to a block w i t h the simple gate:
(tra~ exit(id) with exit(id) in (let : E(...); C(...))). W h e n no block t e r m i n a t i o n actions are n e e d e d in an i m p e r a t i v e block, then we write:
(trap exit with I in C(...))
192
Correspondingly,
w h e n the v a l u e p a s s e d back
(by the exit) u n c o n d i t i o -
nally is to become the result of the block, we write:
(trap exit(id) with id in C(...)) or:
(trap exit(id) with return(id) in C(...)) d e p e n d e n t on w h e t h e r the block
Finally:
(-expression)
is pure or impure.
'mixed', nested uses of exit(e) and exit, and thus e.g.
(trap exit with V(.o.) i_~nC(...)) and (traP exit(id) with F(id) i__nnC(...)) do
not m a k e sense:
(tra~ exit(id) with
F1(id)
in (...) (trap exit with F2(...) in (... exit(expr) ...))
Etcetera~
C o n t i n u i n g our d i r e c t o r y example,
DIR
=
Rid ~ RES
RES
=
VAL i DIR
from e x a m p l e s
19 & 29, we recall:
m
with:
retrieve-res(dir, ridl)= ((ridl = <>) ~ dir, T
~ (let rid = hdridl
in
if rid E dora dir then retrieve-res(dir(rid),t_klridl) else undefined)) N
t~pe: DIR Rid ~
RES
193
Users of the s y s t e m d i r e c t o r y each have their q u a l i f i e d name, uid in
Rid*, o t h e r w i s e g u a r a n t e e d to d e s i g n a t e a DIR object: is-DIR (re trieve-res (Di r , ui d) ) Users issue r e s o u r c e names, rid in Rid + , d e s i g n a t i n g values in the gio= bal directory, by uid
Dir, as follo~s:
let dir
be the d i r e c t o r y d e s i g n a t e d
:
let dir = retrieve-res(Dir, uid) If rid is some
then either rid names an entry in dir,
the r e s u l t is dir(rid).
through,
and we are
Or rid does not name an entry in dir.
We now chop off the last Rid e l e m e n t of uid-- to resume the search as from the d i r e c t o r y d e s i g n a t e d by the r e s u l t i n g If rid is some
DIR
e n t r y in di~,
resQurce name: we
('remaining')
uid,.
then rid I either names a
and we search as from the d e s i g n a t e d directory, w i t h
<~id2,...,ridn>,
or rid I
'back' up the d i r e c t o r y hierarchy,
the root,
forn>l,
does not name a DIR entry, and
to a level one higher,
i.e. nearer
than that at w h i c h we o r i g i n a l l y started , or at w h i c h the
search w h i c h just failed took place.
We c o m p l e t e the above i n c o m p l e t e
d e s c r i p t i o n by giving the formal d e f i n i t i o n of the p r o p e r search algo= rithm:
search(uid, vid)(updown)(Dir)= .i 2 3
(let dir = retrieve-res(Dir, uid) in (trap exit with if updown =
DOW~
4
then exit
5
else if u i d = <>
6
then undefined
7
else search(fst(uid),vid)(UP)(Dir)
.9
then if h d v i d
6domdir
.10
then dir(hdvid)
.ll
else exit
.12
i_~n
else if h_ddvid~6 dom dir
.13
then exit
.14
else search(uid~
~ (DIR ~ RES))
Ig4
where:
fst(ridl)
=
I I < i < (lenridl) - 1 >
Given the global directory, and a 'relative'
Dir, w h i c h we could omit as a parameter,
resource name,
rid, we initially invoke the above
search function with the users identification
and the updown
marker
set to UP. We may tie up any loose ends in your understanding rithm, by the following, a node,
alternative
towards the leaves,
Then rid designates path
characterization:
N, in the directory hierarchy
There are now three possibilities path,
of the search algo=
(or:
"tree",
uid designates
see example 19).
for rid. Either there is a d~wnward
from N whose sequence of edge labels is rid.
the object
'hanging'
on to the other end of this
(as seen from N). If there is no such path,
starting at N, then
rid might still designate an object in the hierarchy,
but now as from
a node
and N. Search
N', between the root of the overall directory
starts with the node N' immediately
above N.
The purpose of the u~down marker is to guidethe ~ a ~ up beyond already searched The third possibility,
mechanism
in backing
'subtrees'.
for rid, is that there is no resource,
relative
to uid, that is named by it.
The Zahn Event M e c h a n i s m matically
[Zahn 7h, Knu%h 74~ Hal&s
looks like:
lo__~stmtlO u n t i l e i d l do s t m t l l , eid2 do s t m t l 2 , ,
°
,
e i d n do s t m t l n
pool An abstract syntax is:
75, Bj~rner
YTd] sche=
195
Zahn
::
Stmt +
(Eid ~ Stmt +) m
No s t a t e m e n t in any stmtl i
(1
may name any event:
event eid on any eidj
(1<_j
Event
::
Eid
as a statement,
Stmt
=
i.e. with:
Event
i Zahn
i o..
the static w e l l - f o r m e d n e s s c r i t e r i a can be c o m p l e t e l y specified:
is-wf-Stmt(8 ) (eids )= .i
cases 8:
•2
(mk-Event(eid)
.3
~ s i d e eids,
mk-Zahn(stlO, esm) ~ (¥c E elem8 stlO) is-wf-Stmt(c) (eids U dom esm)
.4 .5
^(reid E dom esm)
.6
(Vc E elem8 (esm(eid) ) )
.7
is-wf-Stmt (c) (eids~dom esm),
.8
.
The informal,
. .
~
.
.
.)
i n c o m p l e t e s e m a n t i c s is: ~tmtlO
If an e v e n t is i n t e r p r e t e d in $tmtlO terminated.
stmtl k
then i n t e r p r e t a t i o n of stmtlO
If the e v e n t names some eid~
is interpreted.
is r e p e a t e d l y interpreted.
This terminates i n t e r p r e t a t i o n of the mechanism.
If the e v e n t names some p r o p e r l y c o n t a i n i n g mechanisms'
Stmtl£ is obeyed,
Zidl,
then its
..., etc. Formally, we can capture things m u c h m o r e
succinctly:
Assuming :
Z = (STG ~ STG)U( . . . . . . . we get an i m p e r a t i v e formulation:
t~pe:
is
(15~k< n), then the c o r r e s p o n d i n g
int-stmt:
strut ~ (ENV ~ (Z
~
Z))
196
int-Stmt(s) (env)= ~8e8
8 :
(ink-Event (ei d) exit(eid) , mk-Zahn (8 t l, esm) (tixe
[eid ~ int-Stmt-list(esm(eid))(env)
I eid 6 dom esm]
in while
true do int-Stmt-list(stl)(env)),
int-Stmt-list(stl)(env.)= for i=I to lenstl
do int-Stmt(stl[i])(env)
It is thus we o b s e r v e that the tixe c o n s t r u c t closely p a r a l l e l s the Zahn e v e n t mechanism.
The reader is,however, w e l l - a d v i c e d to study
[Jones 78a,ySb] in order to d i s c o v e r the neatness of the h-calculus semantics g i v e n there for this m e t a - l a n g u a g e combinator.
197
PART IV ABSTRACT MODELS
Part I exemplified a complete,
abstract model.
Its components were:
abstract syntaxes for both syntactic & semantic domains; dynamic]
(1)
(2) [static and
consistency constraints on objects of these domains -- called
is-wf-..,
functions;
(3) semantic elaboration-
, and
(4) auxiliary func-
tion definitions. In part II, sections 2.1, 3.1, 4.1, 5.1, 6.1 and 7 taught the notation for, and techniques of, defining domains.
Sections 2.2, 3.2, 4.2, 5.2
and 6.2 taught the notation for representing objects of these domains. Sections 2.3, 3.3, 4.3, 5.3 and 6.3 finally taught the notation for, and techniques of, expressing transformations on objects.
Part III generally taught the notation for, and techniques of, stating processes,
respectively composite transformations,
on objects.
Part IV finally closes the story on the meta-language. pieces of the meta-language introduced formally, plified in parts II & I I I , function
definitions.
and also heavily exem-
we can now formally introduce the notion of
Function definitions have, however,
extensively exemplified. on the meta-language.
With the bits and
already been
Section 12 will therefore wrap-up our tutorial
The section can best be understood if you fre-
quently compare the formal information and schematized "examples" with examples 0-63~ That is: we do n ~
present comprehensive,
dels involving function definitions, jects!
abstract mo-
although those are its prime sub-
198
12 F u n c t i o n
In section
Definitions
Abstract
&
5 we introduced
objects,
for r e p r e s e n t i n g
FunCTion
objects.
Recall
the a b s t r a c t m o d e l s
on the other w e gave
The
of e.g.
O n one hand we gave
of a syntactic i.e.
an o b j e c t
an A R G ~ ( X ~ )
abstract
examples
in Prc
syntaxes
for semantic
40),
we call a semantic
This
tion 5, is d e s c r i b e d
function,
for s y n t a c t i c domains.
is an o b j e c t
domains, The m e a n i n g
of a Proce-
in A R G ~ ( Z ~ ) .
its denotation,
elaboration
function
like all the FunCTion
by the m e t a - l a n g u a g e
on
the story we started
The m e a n i n g
takes a Pro o b j e c t and yields
object,
It is a function.
(example
of FunCTion
0,19,29,42,51-52,54-55,58-
syntaxes
object.
domains
and for o p e r a t i o n s
abstract
object was a semantic
"thing" w h i c h
for d e n o t i n g
FunCTion objects,
there.
dure,
the n o t a t i o n
In a sense we are here c o n t i n u i n g
giving
59-60,61.
Models
i.e.
(V-Prc).
objects
of sec-
c o n s t r u c t we call a f u n c t i o n
definition.
12.1 The S y n t a x of F u n c t i o n
A function definition
consists
a body:
The body
C(...) clause:
1
these
in d.'s,
identifiers
Observe
type:
is any s t a t e m e n t
occurring
formal
D 1 D 2 ... D k or e x p r e s s i o n
parameter
and the f u n c t i o n in C(...).
the f o l l o w i n g
~
(Dk+ I ~ (... -~ (P n
clause you choose.
identifiers. name,
They,
The d i for
or any i d e n t i f i e r s
lid, bind free o c c u r r e n c e s
between
the d °'s of the formal
fier,
and is then either syntax rule:
of
parameter
clause.
If d i is of the form
abstract
~ D')...)
The D.'s and D are d o m a i n expressions.
relations
list and the D .'s of the ~ F $
(i)
of three parts:
f i d ( d l , d 2 , . . . , d k ) ( d k + 1 ) . . . ( d n )=
a header:
a type
Definitions
an identi-
the name of a d o m a i n d e f i n e d by some
199
D.
=
D*,
D.
=
D+
or
D. c D*; or D i is
(directly)
either D* or D + -- for some D.
(2) If d i is of the form { d i l , d i 2 , . . . , d i m }
D.
=
then:
D-set
etcetera.
(3) If d i is of the form m k - ~ ( d i l , d i 2 , . . . , d i m ) ,
then there is an ab-
stract syntax rule:
Di
::
Dil Di2
... Dim
(4) If d i is of the form ( d i l , d i 2 , . . . , d i m ) , r e s p e c t i v e l y
mk(di2, di2 .... ,dim), (Dil Di2
then D i is of the form :
... Dim)
We do not p r e s e n t l y see a need for w r i t i n g di's
in forms other than
the above, w h e r e u l t i m a t e l y d ..'s j end up as identifiers, the di's be identifiers.
In the latter case Di's m a y be any appro-
priate d o m a i n expression, forms
or letting
not just an identifier.
E x p e r i e n c e shows
(1)-(2) to r a r e l y Occur.
This c o n t i n u e s example 40. Now,
PROC
=
ARG ~ ~ (Z ~ Z)
Prc
::
Id ~ Block
let:
and:
ENV
=
Id ~ DEN
DEN
=
LOCI
PROC
W i t h these p r e r e q u i s i t e s we could also w r i t e the V-Prc f u n c t i o n d e f i n i t i o n in this way:
elaboration
200
V-Pro(p) (p)= (let mk-Pro(idl, bl) = p
in
let fct(al)(~)=
• •
. )
in
fat) ) type:
Pro ~ (ENV ~ PROC)
type:
Prc ~ ((Id ~ DEN) ~ (ARG* ~ (Z ~ Z)))
or
Relating the last type
clause to the formal p a r a m e t e r list
we observe that p is of type Pro,
((p)(p))
p of type (Id~DEN), and the result
y i e l d e d by V-Pro is w h a t e v e r remains to the right of the arrow after the ENV specificationl
The form of D remains to be constrained.
(5)
If the body,
C(...), of the function d e f i n i t i o n is a s t a t e m e n t
(-block), then D is of the form: Z ~ Z, or:
I ~ Z
w h e r e Z is the state resulting from global v a r i a b l e declarations.
(6)
If the body,
C(...), is instead an impure e x p r e s s i o n
(-block),
then D is of the form:
Z ~ (Z D'), or:
X ~ (Z D')
where D' denotes the domain of results y i e l d e d by C(...) w i t h Z as in (7)
(5).
If finally C(...) is a pure expression,
D is any d o m a i n e x p r e s s i o n
(etcetera -- c o n c e r n i n g r e l a t i o n to C(...))°
(applicative) I-Block, I-Stmt-list, and I-Stmt, d e f i n i t i o n s of example 42, w e r e all Z. But £hen the X was not
O b s e r v e that D of e.g. the pure
201
that of any global v a r i a b l e state space -- since there was none --, but e x p l i c i t l y d e f i n e d in example 42 formula 2!
end-of-example
Sch~nfinckeling/Currying
The "back-to-back"
("dos-~-dos")
parentheses,
")(", of the formal para-
m e t e r list, e.g. to the left of di, m a y be replaced, i=k+l
, by commas
"," -- p r o v i d e d we s i m u l t a n e o u r s l y delete the "~ ("
in the type clause, (matching)
starting w i t h
to the left of the c o r r e s p o n d i n g Di, and delete a
right p a r e n t h e s e s
(")").
F o r m a l Ex_am_~!es
f(a)(b)(e)(d)
= C(...)
type:
= C(..,)
type: A B - (C-(D~E))
f(a, b, c) (d)
=
~ :
A S C .
f(a,b,c,d)
= C(...)
type:
A B C D
A--(B--(C~(D--E)))
is one way, f(a, b) (c) (d) is another way, C(...)
(D-E)
and: -
E
is a final way of f o l l o w i n g the s o - c a l l e d d e - S c h ~ n f i n c k e ! i n g or deC u r r y i n g rule g i v e n above.
The form: f'(a)(b,e)(d) is, however,
= C(...)
type
A-((B
C)-(D--E))
not a curryi'ng of f's d e f i n i t i o n above. D e - C u r r y i n g f'
w o u l d lead to: f'(a,(b,e),d)
= C(...)
type
A
(B C) D
-
E
The c o n c l u s i o n to be d r a w n from the last example is that the type clause: type:
g':
(D 1 D 2 ... D n)
--
is a l t o g e t h e r d i s t i n c t from: t_~:
g":
D 1 D 2 ... D n
"
D
D
202
A l t h o u g h we m i g h t
(sloppily) write:
g'(dl,d2,...,d n) where, m o r e correctly, we should write:
g'((dl,d ~ .... ,dn)) to d i s t i n g u i s h it from the
(correct):
g"(dl,d2,...,d n) end-of-formal-examples
The rule for removing covered in section 6.2
")("s etc. can be used in reverse -- and this was (see s u b s e c t i o n on l-Expressions).
In 6.2 we
"Curry", whereas here we "de-Curry". As implied by the last,
formal,
example above, we m u s t observe the dual role of parentheses:
delimiting
and a n o n y m o u s tree d o m a i n & tree o b j e c t constructionl has an extra pair of b r a c k e t / b r a c e / p a r e n t h e s i s our {}, <>,
(),
If your k e y b o a r d
delimiters
(other than
[], then use them to distinguish!
The C u r r y i n g / d e - C u r r y i n g Rule is one form of s y n t a c t i c t r a n s f o r m a t i o n on function definitions.
It involved the header~type-clause
'pair'. Se-
mantics r e m a i n e d invariant!
Formal P a r a m e t e r S y n t a c t i c T r a n s f o r m a t i o n s
A n o t h e r kind of syntactic t r a n s f o r m a t i o n rule involves the h e a d e r / b o d y 'pair'.
It can m o s t simply be dealt w i t h by listing the f o l l o w i n g se-
mantic identities:
f(
(i) f(d) = Clet
=_
f(d) = (let mk-Di(dil,di2,...,dim) etc..
= d i_~n C(...))
It is here assumed that d is not free in C(...).
20S
12.2 The S e m a n t i c s of F u n c t i o n D e f i n i t i o n s & A b s t r a c t M o d e l s
The i d e n t i f i e r s o c c u r r i n g in the h e a d e r of a f u n c t i o n d e f i n i t i o n bind all their
(free) o c c u r r e n c e s
in the body~ U s u a l l y there is no need to
r e - d e f i n e i d e n t i f i e r s in any block.
General
An a b s t r a c t m o d e l c o n s i s t s of a set of f u n c t i o n definitions, a b s t r a c t syntaxes,
a set of
and p o s s i b l y also a set of v a r i a b l e declarations.
All names of d e f i n e d functions,
d o m a i n s and v a r i a b l e s are g l o b a l l y known.
The f u n c t i o n d e n o t e d by any such, g l o b a l f u n c t i o n d e f i n i t i o n headers' first identifier,
i.e. by the f u n c t i o n identifier,
w o u l d expect. Formally:
~d,
is the one you
it is the least f i x - p o i n t s o l u t i o n to the equa-
tion set that the f u n c t i o n d e f i n i t i o n s
form.
I n f o r m a l l y we o b s e r v e that an a b s t r a c t m o d e l is all d e f i n i t i o n s -- and no real "action"~ N o b o d y really invokes any of the s p e c i f i e d functions.
A n a b s t r a c t m o d e l d e f i n e s a class of systems.
E x a m p l e 0 d e f i n e d the s t r u c t u r e and p o s s i b l e b e h a v i o r a l p a t t e r n s of a class of grocery stores.
E x a m p l e s 3-8, 12-13,
17-18,
20-25,
27-28 & 35 d e f i n e d f r a g m e n t s of
classes and m a n i p u l a t i o n s of file systems.
E x a m p l e s 19,29&62 d e f i n e d the s t r u c t u r e and o p e r a t i o n s on a class of o p e r a t i n g s y s t e m directories.
E x a m p l e s 30-34, 3 6 - 3 8 , 4 0 , 4 2 - 4 3 , 4 7 , 4 9 , 6 1 , 6 3 , 7 0 defined f r a g m e n t s of structures and m e a n i n g of some class of programs,
i.e. a source language.
If you come w i t h a p a r t i c u l a r g r o c e r y store, or a p a r t i c u l a r file system, or a p a r t i c u l a r d i r e c t o r y and a c o r r e s p o n d i n g a c t i o n
(e.g. put-
204
chase, read, respectively catalog), then the definitions, dels,
tell you what to expect happening.
state c o n f i g u r a t i o n
i.e.
the mo-
If you come with a particular
and a program then the model will compute you a re-
sult. However,
you need not come with a semantic and a syntactic
object.
Come
just with a syntactic object. And the model will produce the answer: this syntactic object denotes
such-and-such
a function from semantic
objects to semantic objects. If you are asking for the meaning of say a Purchase, "stick" your mk-Purchase(...) function.
example
object into the Elab-Purchase
0, then semantic
That is: ~2~ decide which part of your model to concentrate
on. T h e r e f o r e we, the model builders, tic function is the most important,
do not tell you w h i c h one seman-
i.e. which one should always be in-
voked first when "starting up" a model! end-of-exam~! 2
A Note on Input/Output Based on the d i s c u s s i o n
(of example 69) it should n o w be easy to under-
stand why the m e t a - l a n g u a g e
has no input~output
A program in the m e t a - l a n g u a g e
defines
constructs.
a function.
from syntactic objects to semantic objects.
The m e a n i n g
The prime means for expres-
sing this function is the set of function definitions. taxes describe
the domain and range of this meaning
of syntactic objects,
function
The abstract
function:
and the class of semantic objects.
PART V: MISCELLANEAE
There remains only to formally in examples
throughout
introduce
this tutorial.
the elementary
syn
the class
domains used
205
13 E L E M e n t a r y
Data Types
U s u a l l y a p r o g r a m m i n g language comes ready-made,
e q u i p p e d w i t h a set of
basic data types.
A number of such have been e m p l o y e d in the e x a m p l e s g i v e n so far. These are:
.i
R a t i o n a l NUMbers, --with tion,
INTeGers
the operations: ceil~
.2
BOOLeans
.3
QUOTations
.4
TOKENs
(...,-2,-I,0,1,2,...),
+, -, ~, ~,
Natural numbers
<, <, =, ~j >, >, e x p o n e n t i a -
f l o o r ~ etc.
(true,
false)
(8, ~ ,
~
-- w i t h the operations: ~, v, ^, D, m.
. . . . ) -- w i t h the operations:
=, #.
(-- for w h i c h no r e p r e s e n t a t i o n is r e q u i r e d --) -- w i t h
the operations:
=, #.
Other e l e m e n t a r y data types could be considered.
(A data type is a set of objects and a set of operations.
For a data
type to be e l e m e n t a r y its objects m u s t all be c o n s i d e r e d elementary,
i.e.
h a v i n g no structure.
The data types so far f o r m a l l y i n t r o d u c e d were:
SET;
TUPLE;
They w e r e all C O M P o s i t e .
MAP,
FCT;
TREE
Thus the 0BJects of the m e t a - l a n g u a g e satisfy:
OBJ
=
ELEM
COMP
=
SET
j COMP I TUPLE
I MAP
I FCT
I TREE
where the five s u b - d o m a i n s of C O M P are all c o n s i d e r e d disjoint.
In this t u t o r i a l we take
ELEM
=
E L E M to be:
NUM
The f o l l o w i n g r e l a t i o n s apply:
i BOOL
I QUOT
J TOKEN
2~
N 1 c N O c INTG
O t h e r w i s e the E L E M
c NUM
sub-domains are c o n s i d e r e d disjoint.)
If you need to introduce further objects or domains of objects -- by almost all means~ At least as long as they are in k e e p i n g w i t h the principles of a b s t r a c t i o n s
(exemplified),
and thus of the m e t a - l a n g u a g e °
13.1 Rational N U M b e r s
Useful domains are:
NUM
R a t i o n a l numbers,
i.e. the numbers that arise as the
result of integer
(non-zero)
INTG
Integers
NO
N a t u r a l numbers,
divisions.
in p a r t i c u l a r the p o s i t i v e integers
including 0.
NI
N a t u r a l numbers larger than or equal to i.
We only find a need to r e p r e s e n t the integers: ...,
-3,
-2,
-1,
O, 1, 2, 3, ...
Useful o p e r a t o r s / o p e r a t i o n s are: +
addition
-
subtraction multiplication
/
division:
integer d i v i s i o n leaving q u o t i e n t v o i d i n g remainder,
if I N T G
(No,
or N I) r e s u l t is
expected. etc.
If you would like to use:
ceil r
smallest integer larger than or equal to its only operand,
floor r
largest integer smaller than or equal to its only operand,
ij
the e x p o n e n t i a t i o n of i by j
207
etc.s
then we see no p r o b l e m in you doing so. E t c e t e r a -- for the intro-
d u c t i o n and proper e x p l a n a t i o n of your own o p e r a t o r s sgn ....
(mod,
ln, rmd,
).
Programming Note
We a b s t r a c t numerals by the numbers they denote. stants of e x p r e s s i o n s are INTeGers
13.2 BOOLeans
Thus in example 49 con-
(and B00Leans).
& Logic E x p r e s s i o n s
We name the d o m a i n in question:
B00L
Booleans values
In this tutorial we c o u n t on it having just two objects w h i c h we represent:
Useful o p e r a t o r s / o p e r a t i o n s are:
N
negation~
v
or,
^, &
and
=, ~
implication
(two forms provided),
and
(two forms provided).
In order to c o m p a c t formulae we take the ^, v, m o p e r a t o r s as non-commutative!
Thus if in blAbZ bl is false,
if bl in blvb2
b~ is never evaluated. L i k e w i s e
is true.
Predicate Expressions
Besides the p r o p o s i t i o n a l e x p r e s s i o n s w h i c h can be formed using expressions d e n o t i n g b o o l e a n s and the above, c o n v e n t i o n a l operators,
proper
use of the m e t a - l a n g u a g e h e a v i l y relies on the p o s s i b i l i t y of forming q u a n t i f i e d expressions:
208
We
(VxJ(P(xJ)
(Wx £ Set)(P(x))
(3x)CP(xJ)
(3x 6 Set)(P(x))
(3!xJ(P(xJ)
(B'x E Set)(P(x))
'read'
the above expressions:
"for all x in the x for which
set Set the p r e d i c a t e
the predicate
P(x) is true",
P(x) is true",
Set for w h i c h the p r e d i c a t e which
"for all x the p r e d i c a t e
"there
P(x) is true",
exists
"there
P(x) holds".
exists
In your r e a d i n g
the f o r m u l a e
'aloud'
exists
a unique
you can e.g.
'object x', etc.
We refer
to e x a m p l e s
0, 9, i0,
ii,
31
(i0), etc.
Comments:
For the case w h e r e
Set = {Ol,O2,...,On} the q u a n t i f i e d
expressions
can be simply
transliterated:
(Vx £ SetJ(P(x)) P(o I) ^ P(o 2) ^ .,.
^ P(o n)
(Bx E Set)(P(x)) P(o I) v P(o 2) v ...
v P(o n)
(3!x E Set)(P(x)) if (3x 6 Set)(P(x)) then (let o£Set be s.t. P(o) in (¥x 6 Set~{o})(~P(x))) else false,
Also:
"there
an x in the
an
set x for
P(x) holds", and "there exists a unique x in the set Set for which
we did in the last two forms -- and you can i n s t e a d of x' or
P(x) is true",
'x' say
v a r y as 'objects
209
-(3x) (P(x) )
=-
(¥x) (~P(x) )
-(3x 6 Set)(P(x))
=-
{,Vx E Set)(~P(x))
13.3 QUOTations The subject domain is here named:
QUOT Quotations are objects whose representations
can be said to denote them-
selves. They are not to be confused with characters and characterstrings of conventional languages. ably) upper-case letters,
G
~. . . . .
~, ~ ,
We choose under-dashed sequences of and
(prefer-
(rarely) other symbols:
~ .....
~,
~,
~ .....
~ ....
, ~-.-~
....
The only two operations intended are:
=
equality
#
non-equality
(Quotations correspond to the enumerated type objects of PASCAL, but we define no ordering on them.)
If you wish to use quotations
characters then observe that ABC is indivisible; these modeling strings,
to model
and if you wish to use
then make tuples of quotations!
The following formulae may complete the syntax of example 49:
~oo~-Op
=
~E~
Re 1-Op
=
LARG
I o~ I £~Z I LAEQ
I EQ
I NEQ
I SMALI
SMEQ
An evaluation function for the expressions of example 49 might use these quotations:
210
eval-Expr(e)(p)= dace8
e:
(ink-Infix ( le , op , re ) (let Iv : e v a l - E x p r ( l e ) ( p ) , rv o~8e8
: eval-Expr(re)(p); op:
(ADD
~ return(lv+rv),
SUB
~ return(lv-rv),
° . ,
AND
~ return(lvArv),
OR
~ return(lvvrv),
LARG ~ return(lv>rv),
SMEQ ~ return(Iv
Expr ~
(ENV ~
(Z ~
(X VALJJ)
Here it was assumed that IV and rv were of the appropriate type. Suppose the language is statically type checkable,
then:
ie-wf-Expr(e)(dict)=
( m k - I n f i x ( l e , o p , re) (i8-wf-Expr(le)^ is-wf-Expr(re)^ (let
~t = e - t p ( l e ) ( d i c t ) , rt = e - t p ( r e ) ( d i c t ) ;
(is-Bool-Op(op) T
~ It = I N T = rt))),
°..) E x p r ~ (DICT ~ BOOL)
type:
where: DICT
=
Id ~
~ It = BOOL = rt,
(INTIBOOL)
13.4 T O K E N s The subject domain is named:
211
TOKEN
Tokens are objects for which we seek no representation. The only two operations provided are: =
equality in-equality
When modeling the identifiers of software systems system directory,
(e.g. the operating
examples 19 & 29; the file system file identifiers,
examples 20, 24-25, 27-28 & 36; the source language variable procedure and formal parameter identifers,
examples 30-31-32-33,
when modeling labels of a goto language storage addresses, TOKENs.
36 etcetera),
(example 61), or when modeling
or as we call them: Locations
(example 30-31) we use
That is:
Rid
=
TOKEN
(exs. 19!,
Fid
=
TOKEN
(exs. 20),
Id
=
TOKEN
(exs. 30-33,
Lbl
=
TOKEN
(ex. 61),
LOC
=
TOKEN
(ex. 30), and
Scalar-Loc
=
TOKEN
(ex. 31).
36,...),
When in e.g. examples 24-25 & 27 we write suitably decorated f i d ~ s , these are meta-language
identifiers naming otherwise unrepresented F i d
objects.
When in example 31 we need to 'generate' "pull them out of the S c a l a r - L o t
(let
sloc
E Scalar-Loc
be
new S e a l a r - L o c a t i o n s ,
then we
bag":
8.t.
P(sloc)
o..)
81oc
names a T O K E N
object. We need not know "what it looks like":
212
PART VI:
POSTLUDE
This completes
the informal introduction
to the meta-language.
ACKNOWLEDGEMENTS: The author is pleased to acknowledge the IBM Vienna Laboratory,
all of his former colleagues
and Mrs.Jytte
handling of eight IBM "golf ball"
S~llested
type-fonts~
for her expert
of
213
EXAMPLEINDEX:
0.
Grocery Store.
A Complete Model: Abstract Domains,
Objects,
Syntax,
Operations,
Func=
tion Definitions. i.
School-Class
of Students.
Section Introduction: stract Syntax,
Sets, Ab=
Domains,
Objects,
Operations. 2.
Collections
of Classes
Set Domains.
of Integers. 3.
Files: Unordered Collec= tions of Records.
4.
Collections
of Integers.
5.
Records,
6.
-"-
7.
File Manipulations
Explicit Set Constructions.
Files.
&
Primitive
Set Operations.
Record Handling.
Imperative 9.
Equivalence
Classes.
Set Operations.
Complete Specification: Syntax,
Function Definitions.
i0.
Coarsest Partitionings.
_._
ll.
Pascal Triangle.
Section Introduction: mains,
Abstract
Objects,
Tuples,
Applicative
Do=
& Im-
perative Function Definitions. 12.
Ordered Fields of Records.
13.
-- | I
Tuple Domains,
Abstract Syntax.
Tuple Enumerations.
214
14.
Fibonacci Numbers
Tuple Enumerations.
15.
Pascal Triangle.
Implicit Tuple Enumeration.
16.
Value Stacks.
Tuple Domain & Primitive Tuple Operations.
17.
Primitive Tuple Operations.
File Handling.
Applicative
18.
& Imperative Tuple
Operations. 19.
Section Introduction:
System Directory.
stract Syntax, Operations, 20.
File System & Files.
21.
Files.
22.
w
Objects,
Map Domains.
I I
File System & Files.
Explicit Map Constructions. Implicit Map Constructions.
25. 26.
Domains,
Function Definitions.
Ilm
23. 24.
Maps, Ab=
Implicit Map Construction:
Conceptual Example.
Scope of Identifiers,
the
Abstract
Syntax.
27.
File System & Files.
Imperative Map Operations.
28. 29.
Primitive Map Operations.
Function Definitions,
System Directory.
Map Opera=
tions. 30.
Progr.Lang.:States ronments
& Envi=
as Models of Var=
iables & Scopes.
Map Domains,
Primitive Operations,
Abstract Syntax.
215
31.
32.
Prgr.Lang. :Model of Block
Abstract Syntax, Map Domains,
Concept & Storage.
Function Definitions.
Prgr.Lang. :Blocks.
Trees, Syntactic Domains. Trees, Abstract Syntax.
33. 34.
Prgr. Lang.: Statements.
35.
System Directory & Direc= tory Update Commands °
36.
Prgr. Lang.: Procedures.
37.
Prgr. Lang.: Statements.
Selector Functions,
Abstract
Syntax. mT~
38. 39.
Factorial Function.
Section Introduction:
Functions,
Function Definitions,
Block Ex =
pressions. 40.
Prgr.Lang.:Procedures.
Function Denotations,
Semantic
Domains, Syntactic Domains, Ab= stract Syntax, Elaboration Func= tions. 41.
Meta-Language:
Type of
Function Types.
Primitive Operations. 42.
Prgr.Lang.:Blocks
& Sta=
tements.
Abstract Syntax, Elaboration Function Definitions,
Function
Application. 43.
Prgr.Lang.
Section Introduction: Syntax.
44-46.
Conceptual Examples.
Abstract Syntax.
47.
Prgr.Lang.:Syntax
~8-functions.
Abstract
216
48.
Reflexive Domains.
Abstract Syntax,
Map Domains,
Map Objects. 49.
Prgr.Lang.:Expressions.
Abstract Syntax, McCarthy Condi= tional Clause,
50.
Factorial Function.
Function Definition.
Section Introduction: Applicative
Variables,
& Imperative Function
Definitions,
Expression Blocks,
The State. 51.
Prgr.Lang.:Modeling Variables,
52.
Global Variables,
The State.
Input, Output.
Prgr.Lang.:Assignment,
Elaboration-
& Auxiliary Function
Input, Output.
Definitions,
Variables,
Assign=
men,. 53.
Conceptual
Example.
Imperative
& Applicative
Combi=
nators. 54.
Prgr.Lang.:Structured
Abstract Syntax,
Statements.
Structured Applicative
Semantic Domains,
Clauses:
cases, if,
Definitions
of Impe=
rative Features.
55.
56.
Prgr.Lang.:For-To-Do
Abstract Syntax,
Statement.
Elaboration Function Definitions.
Prgr.Lang.:Compound
-"- &: for-to-do• Imperative
Statement.
finition. -"-
57. 58.
Prgr.Lang.:Arbitrary
Semantic Domains•
but Applicative
De=
Definition.
Ifm
Ordering. 59.
-"-
For-All Statement
60.
Prgr.Lang.:
While-Do
lib
Recursive
("sledge-hammer")
nition of ("egg")
while.
Defi =
217
61.
Prgr.Lang.:Guarded
Repe=
titive Command.
62.
Prgr.Lang.:GOTO
Elaboration Function Definition, Applicative Definition.
& Block
exit and tixe
Concept Model. 63.
System Directory:
Hierar=
exit and trap
chical Entry Access. 64.
Prgr.Lang.:Zahn's
Event
exit and t~xe
Mechanism. 65.
Prgr.Lang.:Procedures.
Abstract Syntax, Syntactic & Se = mantic Domains,
Elaboration Func=
tion Definitions. 66.
Prgr. Lang. :States.
Imperative & Applicative
67.
Prgr.Lang.:Expressions.
Quotations.
68.
Prgr.Lang.:Names
Tokens.
dresses.
& Ad=
'States'.
THE META-LANGUAGE:A REFERENCEMANUAL
Cliff B.Jones
Abstract: The recent work of the Vienna Laboratory on the sub= ject of semantic definitions has used the "denotational semantics"
approach. Although this is a clear break
with the earlier abstract interpreter approach,
the
newer meta-language has tried to preserve and even improve upon the readability of the earlier "VDL" no = tation. The meta-language described here has been used in the definitions of large programming languages and systems. This paper is not a tutorial;
rather it pro =
vides a reference document for the meta-language.
CONTENTS
0.
Introduction
220
I.
Logic Notation
223
2.
Elementary Objects
224
3.
Composite Objects
225
3.1
Sets
226
3.2
Pairs
228
3.3
Maps
228
3.4
Tuples
230
3.5
Trees
231
3.6
Functions
232
3.7
Implicit Definition
235
4.
Object Description
236
5.
The r61e of "undefined"
239
6.
Defining Semantics
240
6.1
States & State Transitions
241
6.2
A Macro-expansion Process
243
6.3
Simplifying Extended Expressions
251
6.4
Basic Combinators
258
6.5
Other Issues
258
APPENDICES I
Concrete Syntax
261
II
Conventions
265
III
Example definition
266-277
220
0. I N T R O D U C T I O N Q
This paper is intended to p r o v i d e a r e f e r e n c e d o c u m e n t w h i c h d e s c r i b e s the m e t a - l a n g u a g e used t h r o u g h o u t this volume.
It is equally i m p o r t a n t
to a p p r e c i a t e w h i c h o b j e c t i v e s are not b e i n g aimed for here. On the one h a n d this d o c u m e n t is d e f i n i t e l y not a tutorial, neither for den o t a t i o n a l semantics nor for the specific m e t a - l a n g u a g e used. of this paper no m o t i v a t i o n at all is provided,
In m u c h
the reader who is not
familiar w i t h the general ideas is r e c o m m e n d e d to read Bj~rner 78b before a t t e m p t i n g to use this paper. On the other h a n d this d o c u m e n t does not p r o v i d e a formal
"foundation" for the m e t a - l a n g u a g e in the
style of, say, Mosses 75.
The a i m of this
"reference manual"
is to p r o v i d e a d o c u m e n t w h e r e
readers or writers of the m e t a - l a n g u a g e can find a d e s c r i p t i o n of its constructs in terms of some other notation. As such, this d o c u m e n t does not n e c e s s a r i l y i n t r o d u c e all terms and n o t a t i o n in a strict leftt o - r i g h t order.
The n o t a t i o n to be i n t r o d u c e d is p r i m a r i l y intended for the purpose of d e f i n i n g languages or systems using the a p p r o a c h k n o w n as "denotational semantics";
a l t h o u g h it can also be used as a sort of p r o g r a m m i n g lan-
guage this is not its purpose. A general
"denotational" a p p r o a c h can
be expected to yield a d e f i n i t i o n w h i c h can be viewed in four parts:
~)
A b s t r a c t syntax of the language to be studied
~)
Context Conditions
~)
S e m a n t i c Objects
~v)
M e a n i n g function(s)
Before e m b a r k i n g on d e f i n i n g the m e a n i n g of a language it is o b v i o u s l y e s s e n t i a l to fix w h a t
("object")
language is to be studied:
the task of the first two parts of a definition.
this is
The a b s t r a c t syntax
defines a class of objects w h i c h are abstractions of the actual texts of the language. syntax:
(The class of texts w o u l d be d e s c r i b e d by a c o n c r e t e
this subject is w i d e l y d o c u m e n t e d and in c o n s e q u e n c e need not
occupy space here).
The a b s t r a c t s y n t a x of a language is "context free"
and it is thus impossible to r e s t r i c t the class of a b s t r a c t texts to those which are o b v i o u s l y meaningful.
For example,
in a p r o g r a m m i n g
language it is impossible to specify that all valid programs m u s t use only d e c l a r e d identifiers. the m e a n i n g functions,
Rather than leave such c h e c k i n g to cloud
a s e p a r a t e section defines p r e d i c a t e s over the
221
objects of the a b s t r a c t syntax.
Such p r e d i c a t e s define a sub-set of
the objects w h i c h are s p e c i f i e d by the a b s t r a c t syntax;
those objects
w h i c h s a t i s f y the c o n t e x t c o n d i t i o n s are said to be "well-formed". The m e a n i n g functions p r o v i d e d e n o t a t i o n s only for w e l l - f o r m e d objects.
The third p a r t of a d e f i n i t i o n defines sets of semantic objects. the d e n o t a t i o n s c h o s e n for a language states)
Both
(e.g. c o n t i n u o u s functions over
and any a u x i l i a r y objects such as environments are described.
In a sense,
this part of a d e f i n i t i o n is unnecessary~
The a b s t r a c t
syntax is the only way in w h i c h the class of source objects is d e l i m i t ed
(unless a translator f u n c t i o n from c o n c r e t e syntax is written);
the
d e n o t a t i o n s and a u x i l i a r y objects w h i c h can be created by the m e a n i n g f u n c t i o n s could,
in fact, be d e d u c e d from those functions. However,
the s e p a r a t e d e s c r i p t i o n of semantic objects
is both an invaluable aid
to the reader of a d e f i n i t i o n and an i m p o r t a n t tool to be used during the d e v e l o p m e n t of the m e a n i n g functions.
The first three parts of a definition,
then, have defined a class of
w e l l - f o r m e d a b s t r a c t objects and a class of semantic objects: m e a n i n g is d e f i n e d by a f u n c t i o n m a p p i n g the former into the latter. This mapping will be d e f i n e d by a family of
(recursive)
functions. An o b j e c t i v e
of a d e n o t a t i o n a l d e f i n i t i o n is that the m e a n i n g of a c o m p o s i t e o b j e c t should be created from the m e a n i n g s of its components. G i v e n this objective there w i l l n o r m a l l y be one semantic f u n c t i o n for each sub-class of a b s t r a c t objects.
H a v i n g o u t l i n e d the "denotational method"
in general,
a few comments
can now be made on the spefic m e t a - l a n g u a g e used in this volume. n o t a t i o n was r e f e r r e d to w i t h i n the Vienna Lab as "Meta-IV").
(The
It is
i m p o r t a n t to a p p r e c i a t e that the authors do not regard the m e t a - l a n guage as any sort of fixed standard.
Rather,
it is o f f e r r e d as a basis
w h i c h has been shown to be a d e q u a t e for a v a r i e t y of definitions,
and
w h i c h can be e x p e c t e d to be a d e q u a t e for d e f i n i n g other related systems. Even for such systems the e x i s t a n c e of a b o d y of n o t a t i o n does not elim i n a t e the d i f f i c u l t i e s of c h o o s i n g suitable abstractions their definition.
Moreover,
for use in
it m u s t be r e a l i z e d that an a t t e m p t to ap-
ply the ideas of d e n o t a t i o n a l semantics to systems of an e n t i r e l y different nature will require the i n v e n t i o n of suitable extensions to the n o t a t i o n p r e s e n t e d here. T h e r e does, however,
appear to be some virtue
in a d e g r e e of s t a n d a r d i s a t i o n in the b a s i c notation.
222
The n o t a t i o n used by the O x f o r d U n i v e r s i t y group
(cf. Stoy 74)
for de-
n o t a t i o n a l semantics d e f i n i t i o n s is rather d i f f e r e n t in a p p e a r a n c e from that p r e s e n t e d here and it may be useful to s p e c u l a t e as to the cause. The O x f o r d group h a v e b e e n p r i n c i p a l l y c o n c e r n e d w i t h q u e s t i o n s of foundations and have w o r k e d w i t h r e l a t i v e l y small languages. They have,
in fact, chosen languages w h i c h illustrate the key p r o b l e m s with
a m i n i m u m of u n n e c e s s a r y detail.
In contrast,
tended to tackle
languages and systems. Furthermore,
larger
(given)
the languages have u s u a l l y b e e n d e f i n e d
the Vienna group have
"warts and all". For a defi-
nition of a certain size it becomes v i r t u a l l y i m p o s s i b l e to r e m e m b e r enough c o n v e n t i o n s to permit use of single c h a r a c t e r names,
type clauses
given i m p l i c i t l y by Greek letters chosen for p a r a m e t e r s etc. Thus,
for
large languages a d i f f e r e n t style is adopted to provide a readable definition. For example, possible,
(longer)
a syntax is e m p l o y e d w h i c h is as a b s t r a c t as
f u n c t i o n names are u s e d in the hope that they are
s u g g e s t i v e to the reader etc.
It is i n t e r e s t i n g to compare the rela-
tive merits of s u c c i n c t n e s s and r e a d a b i l i t y on Mosses 74 and Henhapl
78. The various topics are d i s t r i b u t e d t h r o u g h o u t this paper as follows. S e c t i o n 4 is c o n c e r n e d with the a b s t r a c t syntax notation. The actual objects
(and their operators)
w h i c h have been found to be of use in
earlier a p p l i c a t i o n s of this m e t a - l a n g u a g e ,
are d e s c r i b e d in sections
2 and 3. S e c t i o n s 1 and 5 b r i e f l y outline the logic n o t a t i o n used. The heart of the m e t a - l a n g u a g e is the means for d e f i n i n g and c o m b i n i n g m e a n i n g functions:
this is d e s c r i b e d in section 6. The subject of ar-
bitrary order or m e r g i n g of o p e r a t i o n s
is c o m p l e t e l y omitted from
this paper for reasons given in section 6.
An outline concrete syntax for the m e t a - l a n g u a g e is given in a p p e n d i x I and a p p e n d i x II lists some c o n v e n t i o n s w h i c h have been used in earlier definitions. A p p e n d i x III contains a d e f i n i t i o n of a small language, close study of w h i c h should provide the reader w i t h a clear u n d e r s t a n d i n g of the use of the notation.
223
i. LOGIC N O T A T I O N
In d e f i n i n g any language s o m e t h i n g has to be taken as a basis. For the d e s c r i p t i o n of the o p e r a t o r s of the m e t a - l a n g u a g e ,
the f i r s t - o r d e r pre-
dicate calculus w i t h e q u a l i t y is chosen. T h e r e are two reasons for this choice. Firstly, provided
a c o n s i s t e n t and c o m p l e t e a x i o m a t i c d e f i n i t i o n can be
(e.g. Kleene
67). Secondly, it is w i d e l y enough u n d e r s t o o d
that the p r e s e n t a t i o n here can be r e s t r i c t e d to p r o v i d i n g
"readings"
for the p a r t i c u l a r symbols chosen.
Fig.
I-! d i s p l a y s the n o t a t i o n a d o p t e d t h r o u g h o u t this paper. The con-
straints on b o u n d e d q u a n t i f i e r s are used in p r e f e r e n c e to implications (Thus:
(Vx£NatO)(lis-prime(4.x)) (Vx)(x6Nat 0 ~ lis-prime(4ox))
, rather than
)
in order to reduce the number of "undefined" operands°
However,
the
p r o b l e m of the m e a n i n g of the logical operators w i t h u n d e f i n e d values m u s t be faced and is d i s c u s s e d in section 5. The c o n s t r a i n t s on quantifiers m a y be o m i t t e d w h e r e the context makes t h e m obvious.
The
(iota) d e s c r i p t i o n o p e r a t o r yields the unique o b j e c t s a t i s f y i n g a
predicate.
It is an error to use the o p e r a t o r if no, or m o r e than one,
v a l u e s a t i s f i e s the predicate.
(B:XoEX)(P(Xo)) Here again, text.
Thus:
~ p((~xEX)(p(x)))
the c o n s t r a i n t may be omitted if it is clear from the con-
224
Symbol
Reading
TRUE FALSE
truth values
&
and
V
or
implies equivalence not V
for all
3
there exists
3"
there exists exactly one the unique object
(¥x£X)(p(x)) (vxlc(x))(p(x))
for all members of set X, p(x) for all x satisfying c, p(x) similarly for other quantifier8
fig. I-1: Logic notation
2. ELEMENTARY OBJECTS
In writing a definition it will normally be necessary to use objects which are structured
(i.e. composite).
together with their operators, will, however,
Some types of composite objects,
are described in section 3. A definition
also have to employ certain basic objects whose struc-
ture is of no interest for the system being defined. For example, many definitions will require natural numbers but will wish to treat them as elementary objects. Two standard objects,
the truth values, have already been introduced:
225
TRUE,
FALSE
A n o t h e r o b j e c t w h i c h w i l l be e x p l a i n e d b e l o w holder for an o m i t t e d b r a n c h in a tree)
(roughly,
it is a place
is:
NIL An a u t h o r may also e n u m e r a t e any other objects r e q u i r e d for his defin i t i o n in a n o t a t i o n e x p l a i n e d in section 4. The only p r o p e r t y which is assumed about e l e m e n t a r y objects is that they are d i s t i n g u i s h a b l e . Thus two m e a n i n g f u l o p e r a t o r s are the e q u a l i t y operators
(=,#). A m o n g
the e l e m e n t a r y objects to be e n u m e r a t e d for a d e f i n i t i o n are "references"
(see s e c t i o n 6.1).
In a d d i t i o n to those objects w h i c h can be enumerated,
a definition
w i l l u s u a l l y also require k n o w n objects like natural numbers,
integers,
reals etc. W i t h such familiar sets one may also w i s h to adopt some of their standard o p e r a t o r s
(e.g. <,~,/). Any d e f i n i t i o n should include
a list of such a s s u m e d objects and their operators.
S e c t i o n 3.1 lists
some s u g g e s t e d names for sets of such objects. All d e f i n i t i o n s w i l l be a s s u m e d to use the s t a n d a r d p r o p o s i t i o n a l c o n n e c t i v e s on the truth values.
3. C O M P O S I T E OBJECTS
A d e f i n i t i o n w i l l have to d e f i n e a number of classes of objects, least the texts of the l a n g u a g e or s y s t e m b e i n g defined.
not
The style of
d e f i n i n g classes of objects is d e s c r i b e d in s e c t i o n 4. This s e c t i o n w i l l i n t r o d u c e a number of classes of objects which, are u s e f u l in b u i l d i n g a b s t r a c t i o n s a p p r o p r i a t e for m o s t systems. The objects g i v e n here,
in d i s t i n c t i o n to those d i s c u s s e d in section 2, have structure.
Thus o p e r a t i o n s will be introduced for m a n i p u l a t i n g
(building), decom-
posing and i n t e r r o g a t i n g the objects of each class. The test for eq u a l i t y is a v a i l a b l e for each class and w i l l be defined.
The objects are d e f i n e d in the first p l a c e in terms of the logic not a t i o n i n t r o d u c e d in section i; there is then a layer by layer cons t r u c t i o n of each m o r e c o m p l e x class of objects. struction,
B e c a u s e of this con-
c e r t a i n objects of d i f f e r e n t classes are formally identical:
226
in fact d e f i n i t i o n s
will
ensure
that the types
are not mixed.
3.1 Sets
Sets are c h a r a c t e r i z e d object
is a m e m b e r
by the m e m b e r s
they contain.
of a set is achieved
Testing whether
by a two p l a c e
an
infix operator:
e£S
This
is a p r o p o s i t i o n a l
Its c o n v e r s e
Fig.
3-I uses
expression
and thus y i e l d s TRUE or FALSE.
is written:
the test for m e m b e r s h i p
tice that the d i s t r i b u t e d
to d e f i n e
union_ is d e f i n e d
the set operators.
only for sets of sets.
Set O p e r a t o r
Definition
S = T
e£S~=~e£T
S UT
{xlxCS v x6T}
unio n S
{eI(Bs6S)(e6s)}
s nT~
{xlx6s & x~T}
s -~
{=Ix£s & xCT}
ScT
e6S ~ e6T
scT
Sc_T & S%T
Fig.
3-I: Set o p e r a t o r s
The basic way of c o n s t r u c t i n g predicate,
those
No-
elements
sets is by i m p l i c i t l y
of some other
set w h i c h
defining,
via a
are to be included:
227
XoE{X£Sip(x)}
~
(Xo6O & p(Xo))
W h e r e some set is clearly implied as the r a n g e by the c o n t e x t in w h i c h a f o r m u l a appears,
the "6S" can be omitted.
It is p o s s i b l e to v i e w the e x p l i c i t e n u m e r a t i o n of the elements of a (finite)
set as an abbreviation:
{Xl~X 2 ..... x n} = {xlx=x I v x = x ~ v . . , In particular,
v x = x n}
for the empty set:
Thus :
"1(Bx o) (Xo6 { }) For two integers a set of integers can be d e f i n e d by the abbreviation:
{i:j} A= {x£intli<x<j } W h e r e context makes clear w h i c h variable(s)
is
(are) to be c o n s i d e r e d
bound:
{f(x) Ip(x)} ~- {zI(3x)(p(x)
& z=f(x))}
The n u m b e r of e l e m e n t s in a finite set can be d e t e r m i n e d by:
card {} = 0 Xo~S ~ card (SU{Xo}) = card S + 1 It is well k n o w n that an u n c o n s t r a i n e d v i e w of sets will p e r m i t the p o s s i b i l i t y of p a r a d o x i c a l sets
(e.g. {SIS(S} ) : s t a r t i n g from non-pa-
r a d o x i c a l sets and u s i n g the o p e r a t o r s g i v e n here this d a n g e r d o e s not exist.
The f o l l o w i n g standard sets w i l l be used:
Bool = {TRUE, FALSE} Nat = {I, 2 . . . . }
228
N a t 0 = {0, Int
I, 3,
= { ....
-1,
o~.} O, 1,
..o}
3.2 Pairs
In b u i l d i n g the s u b s e q u e n t
notion
a n o t a t i o n for ordered pairs:
of M A P
it w i l l be n e c e s s a r y to have
such a n o t a t i o n is introduced in this
section but will not be used other than w i t h i n section 3 (a general tuple n o t a t i o n is d e v e l o p e d in section 3.4.)
The objects c o n s i d e r e d here will be b e s t u n d e r s t o o d as ordered pairs:
pair(el,
e~)
£ PAIR
They, and their operations,
p a i r ( e I, e 2) = {el,
are d e f i n e d via sets:
{e I , e2}}
S e l e c t i o n of elements is achieved by:
first(pr)
=
(lel)(Be2)Cpr
= {e I , {e I, e2}})
second(pr)
=
(~e2)(3el)CPr
= {e 1,
(e I, e2}})
Notice that it is an immediate c o n s e q u e n c e of the d e f i n i t i o n that:
p a i r ( e 1, e 2) = p a i r ( e l ' ,
e 2 ') ~=~ ~e I = e I ' & e 2 = e2')
3.3 Maps The M a p s
to be i n t r o d u c e d here are a r e s t i c t i o n of the general functions
to be covered in section 3.6. The r e s t r i c t i o n is that the d o m a i n of a map is finite and c o n s t r u c t a b l e
(i.e. every way of g e n e r a t i n g a map
also shows how to compute the domain). The u s e f u l n e s s of this restricted class of functions
(along w i t h its separate notation)
comes from
their use in a definition. The basic m o d e l is a set of pairs w h i c h pair a u n i q u e second element w i t h any first element:
229
for m6Map: PI" P2 £m & first(Pl) For some MAP
= first(P2)
~ Pl = P2
m, the O p e r a t i o n s of domain, a p p l i c a t i o n and range are
d e f i n e d in terms of the set model:
domm = {dl(3pEm)(d = first(p))} m(d) = (Ir)(palr(d,r)Em) rn~m = {m(d) IdEdomm} The actual c o m p u t a t i o n of the d o m a i n of a map can be shown for each of the m a p g e n e r a t i n g e x p r e s s i o n s below.
(The range o p e r a t i o n is also re-
cursive b e c a u s e d o m a i n is). N o t i c e that a p p l y i n g a map to an element o u t s i d e its d o m a i n is undefined.
The m a p c o n s t r u c t o r s and o p e r a t o r s are d e f i n e d in fig.
3-2. The b a s i c
way of c o n s t r u c t i n g maps is by i m p l i c i t l y d e f i n i n g the pairs they should comtain.
Strictly,
the set from w h i c h d is chosen should be spe-
cified h~t this w i l l be a s s u m e d to be given by the context. As w i t h sets a finite e n u m e r a t i o n of the elements
in a map is r e g a r d e d as an
abbreviation.
Notation
Meaning
Domain
[c~rIp(d,r) ]
{pair(d,r) Ip(d,r) }
{d I(3r) (p(d,r) ) }
[dF r I..... dn~r n]
[d~*rl (d=d I & r=rl)v... {d=dn & r=r n) ]
{dI ..... dn}
jr m U n
~d°mm U domn
m+n
[c~rldEdomn & r=n(d)v
domm U domn
m}8
d£(domm-domn) & r--re(d)] [~-~(d) Id~(do~nns) ]
do~ a s
m\s
[ d~m (d) [dE (do....~-s) ]
do___~ - s
] ~ [&~m(n(d) ) IdEdomn]
domn
for: dommndomn = {} mUn
for: ~ g ~ _ o ~ rn'n
fig.
3-2: M a p s
230
Notice that the union o p e r a t o r is d e f i n e d b e t w e e n maps w h o s e domains are disjoint. The normal
(set) union symbol will be used b e c a u s e it
is clear that maps are being combined.
3.4 Tuples
The objects d e s c r i b e d here will be familiar as u n b o u n d e d but following Reynolds
(finite)
lists,
76 we yield in the face of the e s t a b l i s h e d use
in c o m p u t i n g of this term.
(Although the term "list" will be used in
informal discussions).
Tuples are m o d e l l e d on maps and are either empty or have a head and a tail component. The tail c o m p o n e n t of a tuple is always a tuple. Tuples are finite,
that is after a finite number of selections of the tail
c o m p o n e n t an empty tuple w i l l be located.
t6TUPLE
~
(domt = {} v domt = {H_DD, T L} & t(T_kL)6TUPLE)
The tuple n o t a t i o n
(including e x p l i c i t enumeration)
is d e f i n e d in fig.
3-3. Unlike sets, tuples provide an ordered access to their elements (by hd or indexing). For this r e a s o n care m u s t be taken in the choice of an i m p l i c i t list notation.
In order to ensure that an order is de-
fined for the c r e a t e d list, g e n e r a t i o n is d e f i n e d only for
(modifica-
tion of) a s u b - l i s t of a given list. Thus:
("cone")
is only d e f i n e d for
231
Notation
Definition
<>
[]
<ela...jen>
[HD~e I, 2L__~[....
Tn~[~D+en,2n+[]]...]]
for tup~<>:
h_!dtup
tup(H~D)
for tup~<>: t ltup
tup (T i)
lentup for 1&i~lentup:tup(i)
(HDEdomtup~O,T~lentltup+l) (i=1~h_ddtup, T~(t_~ltup)(i-1))
tupl^tup2
(I tup)(lentup
= lentupl+lentup2
~ tup(i)=tup1(i))
(l
~ tup(i+lentupl)=tup2(i)))
conc tt
(tt=<> ~ <>, T~h_ddtt^conctltt)
elemstup
{tup(i)II~i
indstup
{1:lentup}
fig.
&
(l
&
3-3: tuple n o t a t i o n
3.5 Trees
In o r d e r to d e f i n e s t r u c t u r e s w h i c h c o r r e s p o n d programs etc., of objects
(abstract forms of)
into new objects and these c o m b i n a t i o n s m u s t be r e c o g n i s -
a b l e and d e c o m p o s a b l e . functions"
to
it will be n e c e s s a r y to have a w a y of c o m b i n i n g instances
Such objects w i l l be b u i l t by " a o n s t r u c t o r
the only e s s e n t i a l p r o p e r t y of w h i c h is their uniqueness.
mk-a(xl,x 2 ..... x n) = mk-a'(x I ~,x 2' ..... Xn') ~=~ (a=a' & Xl=X 1 ' & x2=x 2' & ... & Xn=Xn') (The names of c o n s t r u c t o r
functions are always formed by the prefix
"mk-" and the name of the r e l e v a n t a b s t r a c t s y n t a x rule:
for the re-
232
lation to a b s t r a c t s y n t a x see section 4).
One t e c h n i q u e for d e c o m p o s i n g a c o n s t r u c t e d o b j e c t w i l l be to d e f i n e "selector functions"
mk-a(s-l:x ~-1(a)
I,
in the constructor:
8 - 2 : x 2,
...,
= x I & s-2(a)
s - n : x n) = a = x 2 & ...
& s-n(a)
= xn
N o t i c e that, a l t h o u g h the selector functions do not play a part in the d i s t i n c t i o n b e t w e e n objects,
the rules about o b j e c t d e s c r i p t i o n
(see
section 4) p r e v e n t any confusion. A c o n v e n i e n t intuitive v i e w of the r e s u l t of a c o n s t r u c t o r f u n c t i o n is a labelled tree, thus:
a
•\ xI
x2
Xn
A p a r t from u s i n g selector functions,
an object may be d e c o m p o s e d by
w r i t i n g the constructor in a d e f i n i n g p o s i t i o n l e f t - h a n d - s i d e of a " l e t " ) .
(e.g. p a r a m e t e r name,
This achieves a c o m p l e t e d e c o m p o s i t i o n in
one step. Using the let c o n s t r u c t of section 3.6:
let m k - a ( s - l : n l ,
s-2:n2,
...,
s - m ; n m)
=
a
l let n I = s - 1 ( a ) let n2.
~let
n
m
s-2(a)
s-m(a)
3.6 F u n c t i o n s We shall be interested in d e f i n i n g functions over d e f i n e d domains w h i c h d e l i v e r results in d e f i n e d ranges. This, w i l l be written:
f:D~R
so called type,
information
233
If the d o m a i n is, in fact, a c a r t e s i a n p r o d u c t of sets,
this is w r i t t e n
(without ,,x,, symbols):
f:
D I
D 2
...
Dn
~, R
Similar e x t e n s i o n s hold for the range.
(Strictly all functions take one
a r g u m e n t w h i c h is a tuple, but the actual tupling and d e c o m p o s i t i o n will be s y s t e m a t i c a l l y omitted).
The simpler functions to be d e f i n e d will define a r e s u l t for any v a l u e in their domain:
they are total and the u n d e c o r a t e d arrow will be used
to s e p a r a t e the d o m a i n and range. F u n c t i o n s w h i c h may be u n d e f i n e d for some input values are said to be p a r t i a l and will use the symbol ~, for example:
It is assumed that the reader is f a m i l i a r w i t h the s t a n d a r d w a y s of w r i t i n g and n a m i n g functions even w h e r e r e c u r s i o n is involved,
f(x)
=
o..
x
..o
f
thus:
...
A n o t a t i o n will be r e q u i r e d w h i c h enables the c r e a t i o n of
functions
w i t h o u t h a v i n g to p r o v i d e names. A brief i n t r o d u c t i o n to the lambda n o t a t i o n is g i v e n here,
for further i n f o r m a t i o n c o n s u l t Stoy 74.
Instead of d e f i n i n g f by some e x p r e s s i o n in terms of its arguments (e.g.
f(x)
=
e(x)
),
the lambda n o t a t i o n provides a way of d e f i n i n g instances of functions in the f o r m "~" f o l l o w e d by a r g u m e n t list f o l l o w e d by " " f o l l o w e d by d e f i n i n g expression,
thus:
~x.e(x9
Named functions can be a p p l i e d to arguments and a simple symbol subs t i t u t i o n for the p a r a m e t e r s can be u s e d to d e t e r m i n e the value. simple cases,
In
the same r u l e w i l l p r o v i d e an e v a l u a t i o n m e c h a n i s m for
lambda e x p r e s s i o n application,
thus:
234
(~x.5)(7)
=
5
(hx.x)(7)
=
7
(lx.(~y.x+y))(7)
Notice
that this
now d e f i n e
I=
= ~y.7+y
last a p p l i c a t i o n
the i d e n t i t y
yields
a function
as result.
We can
function:
lx.x
The first o p e r a t o r
to be c o n s i d e r e d
for functions
is f u n c t i o n a l
compo-
sition:
f'g
The
= ~x.f(g(x))
notation
"let"
nal d e v i c e
can then be used
let .
or
.
let e
i.e.
x = .
.
... .
.
x =
the
cursive
in
The p u r p o s e of local
of this n o t a t i o -
abbreviations
which
Thus:
¢(x)
.
...
~
(hx.e(x))(...)
(x)
this basic
use,
if a n e w line is used~
the
let
n o t a t i o n w i l l be used
to introduce
re-
definitions:
let f =
...
...
f
the m e a n i n g
of the d e f i n i n g
Several
introduction
in an expression.
"in" can be d r o p p e d
Beyond
with
can now be introduced.
is to p e r m i t
that f is to name the least fixed p o i n t
(see Park 69)
equation.
notational
w a y s of c o m p u t i n g
devices
will permit
a result.
The b a s i c
the s p e c i f i c a t i o n conditional
of different
expression
form should
be familiar:
if p
then
A multiple
e I else
e2
(two or greater)
split can be a c h i e v e d
by the case construct:
235
Gases
V:
V1 ~
e1
V2 ~
e2
"if
v = v I then
els____e_ei f
else
Vn_ 1 ~ en_ I T ~e n
eI
v = v 2 then
e2
if_ v = V n _ I t h e n
else
en_ 1 e
n
A l t e r n a t i v e l y a m u l t i p l e split can be a c h i e v e d by the "McMarthy conditional expression"
Pl ~
VI"P2
form:
-~ V n _ 1 , T -~ v n ~ V2"''''Pn-1 "i-i~ Pl t h e n v 1 else
i_f P2
then
v2
else if
else
if Pn-1
else
v
then
Vn_ 1
In either the case c o n s t r u c t or c o n d i t i o n a l e x p r e s s i o n s the "T" clause can be omitted if the p r e c e d i n g cases cover all possibilities.
If, how-
ever, none of the tests are s a t i s f i e d the result is undefined.
The s u b j e c t functions,
and their definition,
is r e t u r n e d to in section
6.
3.7 I m p l i c i t D e f i n i t i o n
As has b e e n p o i n t e d out earlier,
the m e t a - l a n g u a g e p r e s e n t e d here
should not be c o n s i d e r e d to be closed in any way. One p a r t i c u l a r way in w h i c h it is "open-ended" is in the ability to use objects w h o s e c h a r a c t e r i s a t i o n is implicit.
Such d e f i n i t i o n s are u s u a l l y d i f f i c u l t
(see Beki6 70b) and in languages
where they can be avoided a c o n s t r u c t i v e
form is p r e f e r r e d
dix III and Henhapl 78). For general a p p r o a c h e s p l i c i t d e f i n i t i o n see Guttag
or L i s k o v 75.
(cf. appen-
to. the p r o b l e m of im-
236
4. O B J E C T D E S C R I P T I O N
If a d e f i n i t i o n c o n s i s t e d solely of functions c r e a t i n g objects,
the
only use for d e s c r i b i n g classes of objects w o u l d be as a comment for the reader. This is, in fact, the case for m a n y objects and,
for exam-
ple, one could deduce from a d e f i n i t i o n the class of p o s s i b l e states w h i c h could be generated. T h e r e is, however,
another use for o b j e c t
d e s c r i p t i o n s w h i c h amounts to a necessity. W h e n a d e f i n i t i o n is to be presented, which
one m u s t h a v e a way of d e f i n i n g the e x a c t class of objects
is to be considered.
Such a d e f i n i t i o n will not n o r m a l l y be prac-
tical via its g e n e r a t i o n f u n c t i o n and it is then a r e q u i r e m e n t to h a v e a n o t a t i o n for d e s c r i b i n g classes of objects.
In a simple language it w o u l d be p o s s i b l e to a s s o c i a t e m e a n i n g directly with c o n c r e t e forms of the o b j e c t language texts. Some languages offer a "rich" choice of r e p r e s e n t a t i o n s w h i c h are s e m a n t i c a l l y equivalent. An a b s t r a c t syntax not only offers a way of d e f i n i n g some "normal form" for such expressions,
it also omits the details w h i c h are
p r e s e n t only to ensure u n a m b i g u o u s parsing. J u d i c i o u s choice of objects used
(e.g. sets of declarations)
can also shorten the s e m a n t i c d e s c r i p -
tions.
Objects will be d e s c r i b e d by an a b s t r a c t syntax.
(cf. c o n c r e t e syntaxes
w h i c h d e f i n e a set of strings). The m e m b e r s of the set of rules comprising an a b s t r a c t syntax will each define and name a set of objects. Each a b s t r a c t syntax class will be d e f i n e d as follows:
flAME {=1::}RULE By c o n v e n t i o n the first c h a r a c t e r of a NAME is an upper case character. The choice b e t w e e n the "::" and "=" d e f i n i t i o n symbols and the form of the RULE dictate the set of objects w h i c h is to be a s s o c i a t e d w i t h NAME. The m a j o r i t y of this section is c o n c e r n e d w i t h d e f i n i n g the sets given by the various possibilities.
Before e m b a r k i n g on this we note that a
p r e d i c a t e w h i c h tests for m e m b e r s h i p of a p a r t i c u l a r class of objects is i m p l i c i t l y defined for each NAME.
is-e(t)
Thus
# tee
w h e r e @ is a NAME d e f i n e d w i t h i n an a b s t r a c t syntax.
237
A R U L E consists of one or m o r e T E R M S
s e p a r a t e d by v e r t i c a l bars
(i.e.
"I", read as "or").
TERMS
are b u i l t up by j u x t a p o s e d ITEMS.
Unless a t e r m c o n t a i n s exactly
one item it is c o n s i d e r e d to be bracketed. dified NAMES,
W i t h i n a TERM,
I T E M S are either NAMEs,
mo-
lists of u n d e r s c o r e d symbols, or b r a c k e t e d TERMs.
the m e a n i n g of a N A M E
is the set of objects d e f i n e d by
its rule; that of a m o d i f i e d N A M E is e x p l a i n e d later; that of a list of u n d e r s c o r e d symbols is the unit set c o n t a i n i n g an e l e m e n t a r y o b j e c t d i s t i n c t from that d e n o t e d by any other string of u n d e r s c o r e d characters; a b r a c k e t e d T E R M denotes a c o n s t r u c t e d
(i.e. tree-like)
object.
This last case r e q u i r e s m o r e explanation. S e c t i o n 3.5 has i n t r o d u c e d c o n s t r u c t o r functions and the p o s s i b i l i t y to v i e w
them as trees. A
b r a c k e t e d term d e n o t e s the set of o b j e c t s o b t a i n e d by a p p l y i n g a cons t r u c t o r to elements of the c a r t e s i a n p r o d u c t of the sets d e n o t e d by the I T E M S w i t h i n the brackets. of a "::" symbol,
If the term occurs alone to the r i g h t
the name of the constructor is the NAME,
found on the
left hand side of the "::" symbol, p r e c e d e d by "mk-". Thus:
N :: N 1 N 2 ... N m defines
N = { m k - n ( n l , n 2 .... ,nm) In16N 1 ~ n 2 6 N 2 & ... & n m E N m } The other contexts are as an o p t i o n w i t h i n a TERM. "mk-a"
in w h i c h a b r a c k e t e d T E R M has b e e n allowed above
(separated by "or" form other TERMS)
(i.e. a is a name not used for any rule). N o t i c e that this can
introduce
(sub-)classes of objects w h i c h are not d i s t i n g u i s h a b l e .
The set of objects d e n o t e d by an "=rule" "or"s)
or as an I T E M
In either of these cases the name of the c o n s t r u c t o r is
(which c o n t a i n s zero or more
is the union of the sets d e n o t e d by the T E R M S
rated by the "or"s). Fig.
(which are sepa-
4-1 p r o v i d e s some examples of rules and the
set of objects s a t i s f y i n g them.
238
Rule
set of objects
A=B A::B A=BIC A=(BC) ID A::CID A=BI(CID)
B {mk-a(b)Ib£B} BUC {mk-~(b,c) Ib6B & c6C} U D not d e f i n e d erroneous
fiE. 4-I: examples of rules
"Modified names" and the sets of objects they denote are given in fig.
4-2.
Modified Name
Set d e n o t e d
N-set N• N+
power N {l£TUPLEll
Is]
BU{NIL} {m6MAPIdomm c B & rngm c C}
B~a B ~ C m
{m£(B~C) Im(dl)=m(d 2) ~ dl=d 2}
B~C B~a
continuous functions
where:
partial functions N, B and C can be TERMS
(bracketed by implication)
fig. 4-2: M e a n i n g of m o d i f i e d names
239
There are o c c a s i o n s w h e r e a class of m a p o b j e c t s terms of other m a p types.
is
to be d e f i n e d in
If the new map is d e f i n e d over the u n i o n of
the d o m a i n s a f r e e d o m is i n t r o d u c e d w h i c h may be unwanted.
This can be
avoided by using:
M = M1
U M2
w h i c h defines M to be a set of maps:
{mEMAPldomm
= domMl
U domM2
&
rngm
= rngM1
U r n~M2
&
(a£domM1
~ m(a)6rngM1)
(aEdQmM2
~ m(a)Ern~M2)}
&
A used c o n s t r u c t o r can be c o m p a r e d with a b s t r a c t syntax rules w h e n the s y n t a x d e s c r i b e d is of i n t e r n a l
(semantic)
objects.
Because c o n s t r u c -
tors can also be u s e d to d e c o m p o s e texts of the o b j e c t language, a c o m p a r i s o n is also p o s s i b l e b e t w e e n the a b s t r a c t syntax of the texts being d e f i n e d and their use in the s e m a n t i c rules.
In all cases w h e r e such a c o m p a r i -
son is p o s s i b l e the used constructors,
their selectors and their argu-
m e n t s m u s t c o n f o r m to the rules d e s c r i b i n g the class of objects.
5. THE ROLE OF "UNDEFINED"
The t r e a t m e n t of logic in s e c t i o n 2 is s o m e w h a t o v e r - s i m p l i f i e d in that (in c o m m o n w i t h m o s t text books)
the p o s s i b i l i t y that e x p r e s s i o n s m i g h t
be u n d e f i n e d has b e e n ignored. A l t h o u g h the f r e q u e n c y has been reduced by the use of b o u n d e d quantifiers, dEdomm
expressions
like:
& m(d)Ee
x = 0 v y/x>10
w i l l be found. For such e x p r e s s i o n s the "conditional expression" (cf. Walk 69) are assumed.
a & b ~ if
a then
b else
forms
For example:
FALSE
This m i n i m i z e s the danger of e x p r e s s i o n s b e i n g m a d e u n d e f i n e d by their operands.
(Notice that Jones ?2 and D i j k s t r a 76 adopt s e p a r a t e symbols
240
for the conditional forms.)
6. D E F I N I N G
SEMANTICS
As explained in the introduction,
the general approach to defining the
semantics of a language is to define a function which maps its formed)
elements to some class of understood denotations.
(well-
For the lan-
guages which are most commonly considered interesting these denotations will have to be functions. Because most computer languages embody some form of assignment operation the functions will normally be state transformations
(functions from states to states).
In languages which have
a procedure concept in its full generality the state transformations will, in fact, have to be very general functions which can be applied to functions
(even themselves)
and yield functions as results.
general functions were permitted without restriction,
If such
it would be pos-
sible to generate the sort of paradoxes which Russell observed in set theory. However,
it has been shown
(cf. Scott 71) that the restriction
to monotone and continuous constructions ensures that a model can be constructed and thus guarantees that inconsistencies are avoided. As this result is both of considerable importance and difficulty, be inappropriate to repeat that work here
it would
(for an excellent tutorial
see Stoy 74). This paper will nOt, then, provide a complete treatment of the foundations of the meta-language. here is to accept
(gratefully)
Rather, the approach taken
that models of the lambda calculus exist
and to define meta-language expressions by specifying the closed larmbda expressions into which an object program is mapped.
In fact, a few
extra combinators are adopted from Stoy 74: these are discussed in section 6.4. The meaning function,
then, is a way of mapping the object language to
lambda expressions which, language
in turn, denote functions.
(i.e. one with a recursive syntax)
ly not be given extensionally.
For an infinite
this function can obvious-
It is, indeed, very important to con-
struct the meaning function in a way which associates
(functional) de-
notations with parts of the constructs of the object language. Furthermore, the meaning of compound constructs of the object language should depend only on the meaning of the components of such compounds.
This
approach provides a natural way of categorising the meta-language constructs used in defining the meaning functions.
Those parts of the
241
m e t a - ! a n g u a g e d i s c u s s e d in section 6.2 can be v i e w e d as a m a c r o - e x p a n sion scheme for
(abstract)
p r o g r a m s of the o b j e c t language. W h a t is
c r e a t e d from this e x p a n s i o n is an e x p r e s s i o n in an e n r i c h e d lambda notation.
("sugared")
S e c t i o n 6.3 e x p l a i n s m o s t of the extra n o t a t i o n w h i c h
is u s e d to aid r e a d a b i l i t y in terms of pure lambda n o t a t i o n plus two c o m b i n a t o r s w h i c h are d i s c u s s e d in s e c t i o n 6.4. The basic ideas of states and state t r a n s i t i o n f u n c t i o n s are r e v i e w e d in the first subs e c t i o n below.
The w h o l e t r e a t m e n t of a r b i t r a r y order has been excised from this volume. This p r o b l e m had b e e n tackled in the framework of a b s t r a c t interpreters
(see Walk 69) and was r e c o g n i s e d in Beki~ 74. The general prob-
lem of how to d e f i n e the m e r g i n g of c o - o p e r a t i n g p r o c e s s e s using a den o t a t i o n a l sematics a p p r o a c h is, however, some extent safe basis
"open".
very c o m p l e x and still to
In v i e w of the aim of this volume to p r e s e n t a
for d e f i n i t i o n w o r k it was decided that the problems
ed in m e r g i n g should be dropped. unordered constructs
involv-
T h e r e is some d i s c u s s i o n of a p p a r e n t l y
in section 6.5.
6.1 States and State T r a n s i t i o n s
Most l a n g u a g e d e f i n i t i o n s use a basic semantic o b j e c t w h i c h is a state. Such a state is a m a p p i n g from some class of names or their surrogates (e.g. locations) provides
to w h a t e v e r values can be manipulated.
Such a state
the v e h i c l e for d e f i n i n g the d e n o t a t i o n s of names. C o n s t r u c t s
w h i c h have an a s s i g n m e n t nature
(nearly all i n t e r e s t i n g languages con-
tain some) w i l l n a t u r a l l y be g r a n t e d d e n o t a t i o n s w h i c h are functions from states to states. Such functions are u s u a l l y called state transitions. Thus for some class of c o n s t r u c t s e:
m-@:
@ -~ T r
Tr=2~2
The n o t a t i o n specific to states and t r a n s i t i o n s can now be introduced.
It w i l l n o r m a l l y be n e c e s s a r y to have some s t r u c t u r e w i t h i n states one c o m p o n e n t for storage,
(e.g.
one for files). This is r e f l e c t e d by intro-
d u c i n g a class of e l e m e n t a r y objects called references. References can be e x p l i c i t l y e n u m e r a t e d by w r i t i n g t h e m as strings of u n d e r l i n e d upper-
242
case characters. The only operators d e f i n e d over r e f e r e n c e s are the tests for
(in)equality. A state will be a m a p p i n g from such references
to any sort of objects,
=
REF
~ m
thus:
OBJECT
The basic way of d e f i n i n g a new state is by s p e c i f y i n g a d i f f e r e n c e from an e x i s t i n g state. A state t r a n s i t i o n is s p e c i f i e d by w r i t i n g a m e t a - l a n g u a g e a s s i g n m e n t s t a t e m e n t w h i c h uses the r e f e r e n c e to have a d i f f e r e n t value)
(which is
on the left and a value on the right. Thus
the m e t a - l a n g u a g e a s s i g n m e n t defines a transition: N
(r
:=
V):
Z ~
and is d e f i n e d as:
r
:=
v
A
=
~cr.c~+[r~v]
Unlike m o s t p r o g r a m m i n g languages, (rather than its value) of an assignment. must be used
a r e f e r e n c e always denotes itself
even if it is w r i t t e n on the r i g h t - h a n d - s i d e
If the v a l u e is r e q u i r e d the contents O p e r a t o r
"~"
(see s e c t i o n 6.3 for further details).
If a semantic f u n c t i o n maps elements of some class @ into transformations, the type w i l l be s p e c i f i e d as:
m-O:
O~
w i t h the meaning:
m-O:
0 ~
( ~ ~ ~)
Further, w i t h value r e t u r n i n g t r a n s f o r m a t i o n s
m-O:O~R
stands for :
m-O:
@ ~
( ~ ~ Z R)
(see below):
243
H a v i n g i n t r o d u c e d the ideas of states and state transitions,
it w o u l d
be p o s s i b l e to build up ways of d e s c r i b i n g i n c r e a s i n g l y more c o m p l e x transitions. This is not the a p p r o a c h taken here. Rather,
transitions
have b e e n i n t r o d u c e d only to p r o v i d e m o t i v a t i o n for the s u c c e e d i n g three sub-sections.
The t r e a t m e n t is now t o p - d o w n in that the means of
c r e a t i n g e x t e n d e d e x p r e s s i o n s p r e c e d e s the d e s c r i p t i o n of the e x t e n d e d expressions
in terms of basic combinators,
so that only in section 6.4
is the t r e a t m e n t back to the level of lambda expressions.
6.2 A M a c r o - e x p a n s i o n Process
The a s s i g n m e n t c o n c e p t in the m e t a - l a n g u a g e together w i t h the combinators to be i n t r o d u c e d in s u b s e q u e n t sub-sections provide ways of writing c o m p l e x tranformations.
G i v e n some o b j e c t l a n g u a g e it is not dif-
ficult to w r i t e for any p a r t i c u l a r p r o g r a m a c o r r e s p o n d i n g m e t a - l a n g u a g e e x p r e s s i o n w h i c h denotes the f u n c t i o n w h i c h captures the m e a n i n g of that p a r t i c u l a r program. guages,
Since the task in hand is d e f i n i n g whole lan-
a way m u s t be p r o v i d e d for g e n e r a t i n g the c o r r e s p o n d i n g meta-
language e x p r e s s i o n s for any
(well-formed)
program. The g e n e r a t i o n it-
self, w h i c h is the s u b j e c t of this sub-section, as a m a c r o - e x p a n s i o n process.
can best be u n d e r s t o o d
By this is m e a n t that the parts of the
m e t a - l a n g u a g e d e s c r i b e d in this section rely on the text and e n v i r o n m e n t alone. This e x p a n s i o n is rather obvious and w i l l be e x p l a i n e d w i t h a m i n i m u m of formalism.
In a d e f i n i t i o n there w i l l be
(notionally)
for each d e f i n e d class of
the a b s t r a c t syntax one semantic rule. This semantic rule maps objects of the class to their d e n o t a t i o n s .
The m o s t basic part of the m a c r o -
e x p a n s i o n process is the a p p l i c a t i o n of the r e l e v a n t rules to the text components. reasons.
The q u a l i f i c a t i o n
Partly,
"notionally" has been added above for two
it w o u l d be u n f o r t u n a t e to apply any rule w h i c h dic-
tated a structure on the semantic functions. Thus v e r y short s e m a n t i c functions may be better conbined w i t h that c o r r e s p o n d i n g to the syntax class w h i c h uses them. More importantly,
syntax rules w h i c h simply list
options w o u l d have c o r r e s p o n d i n g s e m a n t i c rules w h i c h w e r e simply case distinctions
s e l e c t i n g other s e m a n t i c rules. These
"splitting"
(or
,|
routing " structors rules.
rules) (i.e.
are o m i t t e d and only syntax rules w h i c h define con-
"::rules") w i l l n o r m a l l y have c o r r e s p o n d i n g semantic
244
The syntax for an infinite language will be recursive.
In c o n s e q u e n c e
the c o r r e s p o n d i n g semantic rules m u s t also be a family of m u t u a l l y resursive functions. However,
it was pointed out in the d i s c u s s i o n of
objects that v a l i d tree objects w i l l always be finite. This g u a r a n t e e s that the m a c r o - e x p a n s i o n process e n v i s a g e d will terminate.
A trivial language can be used to illustrate this b a s i c expansion. l a n g u a g e to be c o n s i d e r e d is that of b i n a r y numerals.
The
It is, of course,
so simple that the c o r r e s p o n d i n g d e n o t a t i o n s are not t r a n s f o r m a t i o n s but the natural numbers. The syntax of the language is:
Bin-digit
= ~I~
Bin-numeral
=
[Bin-numeral]
Bin-digit
Given the c h o i c e of d e n o t a t i o n s semantic functions are r e q u i r e d of types:
m-d:
Bin-digit
~ Nat 0
m-n:
Bin-numeral
~ Nat 0
Appropriate
m-d(d)
functions m i g h t be:
= i f d=O
then
0 else
m-n(mk-bin-numeral(n,d))
I
= if n=NIL else
then m - d ( d )
2.m-n(n)+m-d(d)
For any e l e m e n t of the o b j e c t language tion will create a finite expression.
(Bin-numeral)
the m e a n i n g func-
In this simple language the ex-
p r e s s i o n will contain only a r i t h m e t i c objects and it can be s i m p l i f i e d by the laws of a r i t h m e t i c to a natural number
(the r e q u i r e d denotation).
A number of points have, however, b e e n illustrated.
It was o b s e r v e d in
section 3.5 that objects can be d e c o m p o s e d by w r i t i n g the c o n s t r u c t o r "on the left of a let":
the use of the c o n s t r u c t o r in the p a r a m e t e r
p o s i t i o n of m - n is a further a p p l i c a t i o n of this idea and is e q u i v a l e n t to: m-n(nm)
=
(let m k - b i n - n u m e r a l ( n , d )
= nm
..o) F u r t h e r m o r e the c o n d i t i o n a l s t a t e m e n t used in the d e f i n i t i o n of m - n is entirely d e p e n d e n t on the text b e i n g a n a l y z e d and is a p a r t o f t h e macroe x p a n s i o n process.
245
Of the three forms of c o n d i t i o n a l
expression
case is always d e p e n d a n t o n the text alone, are always d e p e n d a n t in either way.
The
in s u b - s e c t i o n
6.3.
should be obvious:
on d y n a m i c
tests w h i c h The m e a n i n g either
somewhat
of o m i t t i n g tions°
A
The need
rules
B u t an a r t i f i c i a l
conditionals
else can be used
values
of the t e x t - d e p e n d a n t
by the adoption,
semantic
and /f then
on d y n a m i c
one or the other
ing on the r e s u l t of the test. reduced
values
depend
in the m e t a - l a n g u a g e , "McCarthy"
expansion
are d i s c u s s e d
/_~ then
else
is c h o s e n depend-
for the case c o n s t r u c t
in large d e f i n i t i o n s ,
has b e e n
of the p r a c t i c e
for s y n t a x classes w h i c h are lists of op-
example
can be c o n s t r u c t e d
for the syntax:
= BtcI
B :: X C::XY D :: X Y Z The definition:
fn-a(a)
has
= cases a: mk-b(x)
~ f(x)
mk-c(x,y)
~ g(x,y)
mk-d(x,y,z)
~ h(x,y,z)
the meaning:
fn-a(a)
=
i_~ (3x)(mk-b(x)=a)
then
(let mk-b(x)=a
else i ~ (3x, y)(mk-c(x,y)=a) else i~
(Bx, y,z)(mk-dCx, y,z)=a)
A case c l a u s e w i t h
a final
none of the p r e c e d i n g sent it is an error
A similar
static
If a textual mantic
rule
then
then
"T~" c l a u s e will
predicates
were
in f(x))
(let mk-c(x,y)=a
true.
(let mk-d(x,y,z)=a ~_~nh(x,y,z)) use
object which is likely
this
last o p t i o n
If no such clause
for none of the p r e d i c a t e s
expansion
in g(x,y))
if
is pre-
to be satisfied.
from the text is g i v e n by the for construct. is a list is to be g i v e n
a meaning,
to be formed from a for construct,
i=l t__oou d_~o f(list(i))
thus:
the se-
246
this can be s t a t i c a l l y e x p a n d e d into:
f(list(1));f(list(l+l));...;f(list(u))
w h e r e the ";" c o m b i n a t o r b e t w e e n t r a n s f o r m a t i o n s
is that e x p l a i n e d in
section 6.3. S i m i l a r l y a v a l u e r e t u r n i n g t r a n s f o r m a t i o n can be used to define a list to be c r e a t e d from the list in the text by:
let vl:
w i t h the m e a n i n g
(again expressed
in terms of c o m b i n a t o r s to be defined
in the next sub-section):
let vll
: vt(list(1));
let vlsl
: vt(list(l+IJ);
. . °
let vlu
: vt(list(u));
let vl
=
D e f i n i t i o n s of p r o g r a m m i n g languages have u n i v e r s a l l y adopted the conc e p t of an e n v i r o n m e n t to h a n d l e the problems r e l a t e d to b l o c k structure. C o n s t r u c t i o n of e x p l i c i t e n v i r o n m e n t s use of the m e t a - l a n g u a g e ;
is a c h i e v e d by s t a n d a r d
the rSle of the e x p l i c i t e n v i r o n m e n t in the
m a c r o - e x p a n s i o n process is d i s c u s s e d at the end of this sub-section. There is, however,
a n o t h e r topic to be d i s c u s s e d first and that is the
exit m e c h a n i s m of the m e t a - l a n g u a g e .
The e x i t - m e c h a n i s m is d i s c u s s e d in d e t a i l e l s e w h e r e in this v o l u m e (Jones 78b) and a s t e p - b y - s t e p m o t i v a t i o n of the a p p r o a c h has b e e n presented in Jones 75. Here, only a brief r e v i e w of the idea is given. For a simple language mal termination)
(i.e. one w i t h o u t constructs w h i c h cause abnor-
the t r a n s f o r m a t i o n s
to be used as d e n o t a t i o n s will be:
T = ~ Z The exit a p p r o a c h to languages w h i c h permit abnormal t e r m i n a t i o n
is to
use d e n o t a t i o n s w h i c h are t r a n s f o r m a t i o n s of the type:
E = Z "~ Z [Abn] Here,
just as Z is c h o s e n to fit the p a r t i c u l a r language,
the class
247
Abn
is a set of objects w h i c h can be used for the language in q u e s t i o n
to indicate w h a t sort of a b n o r m a l t e r m i n a t i o n has occured. Of importance for the m e t a - l a n g u a g e is o n l y the d i s t i n c t i o n b e t w e e n NIL omitted)
(Abn
and an actual Abn value. A p a r t i c u l a r element of E w h i c h
takes an e l e m e n t of Z into a pair w h i c h contains a e l e m e n t of Z and NIL
is a "normal" transition.
normal s i t u a t i o n is to be resolved.
(possibly different)
In other words no ab-
On the other hand,
if the second
element of the o u t p u t pair is not NIL , it provides not only the knowledge that an a b n o r m a l s i t u a t i o n is to be resolved, f o r m a t i o n w h i c h aids resolution. ments,
for example,
but also some in-
In a simple language w i t h goto state-
the set Abn m i g h t be identical w i t h label identi-
fiers. A n u n r e s o l v e d goto is then d e n o t e d by an e l e m e n t of E w h i c h yields the label as the second c o m p o n e n t of the result.
tion"
It is "resolu-
which is of concern in this section b e c a u s e it employs a sort
of i m p l i c i t environment. The exit and normal successor b i n a t o r s are d e f i n e d in the next sub-section;
(i.e. ";") com-
the t e c h n i q u e for resolv-
ing exits plays a part in the m a c r o - e x p a n s i o n scheme. Firstly,
however,
the d e f i n i t i o n s are provided.
The basic c o n s t r u c t to be u s e d is written:
tixe
[a~tl(a) Ip(a)]
i_nn t 2
I n t u i t i v e l y this r e q u i r e s that the basic t r a n f o r m a t i o n used is t2;
(in E) to be
if for a p a r t i c u l a r ~£Z this results in a NIL Abn compo-
nent then that element of t 2 is also an element of the overall transformation;
if, however,
an a b n o r m a l c o m p o n e n t is r e t u r n e d w h i c h satis-
fies the p r e d i c a t e p then t r a n s f o r m a t i o n t I is u s e d to a t t e m p t to resolve the a b n o r m a l i t y ;
if an a b n o r m a l r e s u l t is d e l i v e r e d by t2, but
this v a l u e does not satisfy p, then the same a b n o r m a l r e s u l t is d e l i v e r ed by the overall construct. To d e f i n e this f o r m a l l y the types are given first,
suppose:
t I : Abn ~ E t2 : E p : [Abn] E
~ Bool
= ~ ~ ~ [Abn]
then the type of the c o n s t r u c t is:
(tixe
[a~tl(a) Ip(a)]
i_~n t2): E
248
and the d e f i n i t i o n is:
(tixe [a~t1(a) jp(a)] in t 2) (let e = [a~tl(a) Jp(a)] let r(s,a) = (a6dome~r'e(a)(~),T~<~,a>) r t 2) N o t i c e that r in the above e x p a n s i o n is u s e d recursively.
Thus if a-
nother a b n o r m a l s i t u a t i o n results w h i c h still satisfies p, the e f f e c t d e f i n e d in e w i l l again be used. This r e c u r s i v e form fits the p r o b l e m of goto h a n d l i n g
(see the d e f i n i t i o n in a p p e n d i x III) v e r y well.
earlier d e f i n i t i o n s a n o n - r e c u r s i v e
In
"trap" was u s e d w i t h w h i c h it was
then n e c e s s a r y to c o n s t r u c t the r e q u i r e d r e c u r s i o n in the semantic functions.
For:
t I : Abn ~ E t2 : E the type of the trap c o n s t r u c t is:
(trap(a) with tl(a);t2):
E
and the d e f i n i t i o n is:
trap(a) ~,ith tl(a);t ~ (let h(~,a) = (a~NIL~tI(a)(a),T~<~,NIL>) h't 2) R e t u r n i n g to the "tixe" construct, in the m a c r o - e x p a n s i o n .
Firstly,
it is n e c e s s a r y to explain its role
it could be argued that,
w h i c h is u s e d v e r y few times in a d e f i n i t i o n volume),
for a concept
(cf. Henhapl 78 in this
it is not w o r t h p r o v i d i n g a special m e t a - l a n g u a g e construct.
The j u s t i f i c a t i o n for so d o i n g is p r e c i s e l y to provide a f r a m e w o r k for the r e s o l u t i o n of exits w h i c h does fit w i t h a m a c r o - e x p a n s i o n v i e w of the text. The key p o i n t is the use of a m a p p i n g in the The finiteness c r i t e r i a of m a p p i n g s is met because,
tixe construct. for finite texts,
the p r e d i c a t e p m u s t y i e l d a finite number of a b n o r m a l c o n d i t i o n s to be resolved.
In order for the overall tixe c o n s t r u c t to y i e l d a deno-
tation for a text, b o t h the t I and t 2 s e m a n t i c functions should only be used on sub-parts of the overall text being defined. R e f e r r i n g to the semantic function "i-named-stmt-l~st" dix III,
in the d e f i n i t i o n in appen-
it w i l l be seen that the role of the tixe c o n s t r u c t is essen-
249
tially to g e n e r a t e a static e n v i r o n m e n t the elements of w h i c h are mutually d e p e n d a n t on one another.
(The d i s c u s s i o n of this sort of re-
c u r s i o n is g i v e n under the general topic of environments).
The r e m a i n i n g topic to be e x p l a i n e d w i t h regard to the m a c r o - e x p a n s i o n is the r61e of the e n v i r o n m e n t o b j e c t
(Env). In a language w i t h o u t
block s t r u c t u r e it w o u l d be p o s s i b l e to w r i t e semantic functions for each class
m-O:
@ ~
(0) of a b s t r a c t syntax objects.
(2 ~ ~)
In a language w h i c h permits r e d e f i n i t i o n of identifiers at d i f f e r e n t levels of the block structure,
an e n v i r o n m e n t is introduced,
so that
m o s t semantic functions are of type:
m-O: 0 Env -~ (2 ~ 2)
The h i g h e s t
(program)
c o n s t r u c t of the language has a c o r r e s p o n d i n g
semantic rule w h i c h creates an empty e n v i r o n m e n t and this semantic rule is thus still of type:
m-program:
P r o g r a m ~ (2 ~ 2)
If the language to be d e f i n e d p e r m i t s
recursion
(e.g. r e c u r s i v e pro-
cedures in A l g o l 60) the equations for c r e a t i n g e n v i r o n m e n t s will t h e m s e l v e s be recursive.
This r e c u r s i o n must, of course, be u n d e r s t o o d
for the w h o l e d e f i n i t i o n to be sound.
If the d e f i n i t i o n w e r e in fact to be treated as though it w e r e an a b stract interpreter,
it w o u l d be fairly easy to clarify the r e c u r s i v e
equations on e n v i r o n m e n t s by a d o p t i n g an a p p r o p r i a t e mode for param e t e r passing. One w a y of e n s u r i n g that a d e n o t a t i o n a l v i e w was sound w o u l d be to set up an o r d e r i n g over environments.
Such an o r d e r i n g
could be d e f i n e d p o i n t w i s e over the t r a n s f o r m a t i o n s to be held as values in the environments.
Here an a l t e r n a t i v e v i e w is taken. E s s e n t i a l l y
the e n v i r o n m e n t is v i e w e d as a w a y of a v o i d i n g a name c r e a t i o n process for the d e n o t a t i o n s
to be stored therein.
The m o t i v a t i o n for introduc-
ing this "linguistic level '~ can b e s t be given by, initially, r e s t r i c t ing the d i s c u s s i o n to a language w h i c h only has local variables no procedures). For any p a r t i c u l a r p r o g r a m in the language, to w r i t e an a s s o c i a t e d e x t e n d e d lambda expression.
Thus:
(i.e.
it is easy
250
begin integer a,b; .o. end m i g h t h a v e a d e n o t a t i o n like:
(let la:get-loc(a) ; let lb:get-loc(b) ; ...) AS has been stated repeatedly,
the p r o b l e m that m u s t be solved is to
provide a way of g e n e r a t i n g d e n o t a t i o n s for any program. ty of u s i n g an elipses n o t a t i o n was excluded,
The possibili-
but the e n v i r o n m e n t can
be seen p r e c i s e l y as a way of taking away the need for such a n o t a t i o n for the c r e a t i o n of names for the location. Thus for a program:
be~in integer s,d; ... c:=d+e;
... end
the e n v i r o n m e n t m i g h t be such that the d e n o t a t i o n of the b o d y is created by:
i-body((...c:=d+c;..°), The d e f i n i t i o n of i-body
[c~Ic, d~ld]) will be such that this expands to:
° . .
let vd : aontents(Id); let vc : contents(lc); assign (l c,(vd+vc));
In o t h e r words,
the e n v i r o n m e n t itself d i s a p p e a r s e n t i r e l y d u r i n g the
m a c r o - e x p a n s i o n process.
The functions defining
the m e a n i n g of blocks
will create new locations for locally d e c l a r e d identifiers. For block s t r u c t u r e d languages the outer e n v i r o n m e n t is u p d a t e d w i t h a p a i r i n g of the local names w i t h the new locations. This m o d i f i e d e n v i r o n m e n t has two uses:
for local uses of identifiers the location is o b t a i n e d
from the environment;
for nested blocks it is the basis for g e n e r a t i n g
further environments.
In order to exhibit the d e n o t e d expression,
is n e c e s s a r y to create
(arbitrary)
it
names for the locations.
It is now n e c e s s a r y to show how such an e x p l a n a t i o n can be e x t e n d e d to cover the m o r e interesting case of languages w h i c h p e r m i t r e c u r s i v e procedures. For a program:
251
begin
pl:prog
...
p2
...;
p2:~roc
...
pl
...
p2
...;
pl
end
the d e f i n i t i o n will g e n e r a t e a d e n o t a t i o n for the block via:
let
nenv
=
env+[pl~e-proc-den((...pl...),nenv), p2~e-proc-den((,..pl...p2...),nenv)]
i-body((...pl...),nenv)
I n t r o d u c i n g names for the p r o c e d u r e denotations,
let
pdenl
=
...
pden2
...
let
pden2
=
...
pdenl
...
...
pdenl
...
pden2
this expands to:
...
This time the d i s a p p e a r a n c e of n e n v
is d o u b l y welcome: w i t h it has gone
the r e c u r s i o n w h o s e least fixed p o i n t could only be d i s c u s s e d in terms of an ordering. A d i f f e r e n t r e c u r s i o n notations)
(that in terms of p r o c e d u r e de-
has become v i s i b l e but for one thing it was there anyway
and for a n o t h e r it is p r e c i s e l y the r e c u r s i o n over t r a n s f o r m a t i o n s w h i c h has to be e x p l a i n e d below.
This section,
then, has shown how a d e f i n i t i o n can be viewed as a se-
ries of macros w h i c h expand objects of the language to be d e f i n e d into expressions
in an e x t e n d e d lambda notation. At the expense of introduc-
ing the c o n c e p t of names for locations and p r o c e d u r e denotations,
the
e x p l a n a t i o n of these e x t e n d e d e x p r e s s i o n s b e l o w will not be b u r d e n e d w i t h the c o n c e p t of environments.
6,3 S i m p l i f y i n g E x t e n d e d E x p r e s s i o n s
The p r e v i o u s s u b - s e c t i o n has shown how a d e f i n i t i o n of the type given in a p p e n d i x III can be used to create
(by macro-expansion)
an expres-
sion w h i c h is the d e n o t a t i o n of the g i v e n o b j e c t language text. This e x p r e s s i o n itself denotes a transformation.
However,
the e x p r e s s i o n
is not yet in pure lambda n o t a t i o n and the purpose of this s u b - s e c t i o n
252
will be to explain those c o m b i n a t o r s w h i c h can be regarded simply as "synSactic sugar" for m a k i n g the g e n e r a t e d r e s u l t more readable.
It will be easier to c o m p r e h e n d the full combinator d e f i n i t i o n s idea is first e x p l a i n e d w i t h a simplified problem.
if the
Suppose the d e n o t a -
tion of some c o m p o u n d object:
a£A
where
A=BC is sought.
m-b
Given two functions:
: B ~ (~ ~ ~)
there are m a n y p o s s i b l e ways of c o m b i n i n g them to create a t r a n s f o r m a tion. Given the o b j e c t i v e that the d e n o t a t i o n s of c o m p o u n d objects should depend only on the d e n o t a t i o n s of their components, most pleasing combinations
one of the
is a c o m p o s i t i o n of the two created func-
tions. Thus:
m-a(mk-a(b,c)) = m-c(c)'m-b(b) = hs.(m-c(c)(m-b(b)(~))) One o b j e c t i v e of i n t r o d u c i n g c o m b i n a t o r s
(like composition)
void having to w r i t e out many "l"'s and "~"'s.
free"
is to a-
In a d d i t i o n to a "a-
style, a m u c h m o r e natural d e f i n i t i o n can be a c h i e v e d by the
use of well c h o s e n combinators.
In this case we can d e f i n e a "semico-
lon" combinator:
for :
tI
: ~
t2
"E~2
the type is:
(tl;t2)
: ~ ~
and the definition:
tl;t 2
~ t2"t I
and then rewrite the above example:
m-aCmk-a(b,c))
= m-bCb); m-c(c)
253
In a simple l a n g u a g e definition, ments
the m e a n i n g of a sequence of state-
is likely to be the c o m p o s i t i o n of the m e a n i n g s of the single
statements.
Since,
in the c o n c r e t e s y n t a x of such an o b j e c t language,
the e l e m e n t s of the s e q u e n c e are likely to be s e p a r a t e d by ";", a p l e a s i n g symmetry has b e e n created.
Notice, however,
that the m e t a -
l a n g u a g e s e m i c o l o n o p e r a t o r has b e e n f o r m a l l y d e f i n e d and there is no element of c i r c u l a r i t y in such a link b e t w e e n object and m e t a - l ~ n g u a g e . It w o u l d be useful to d e f i n e a few other c o m b i n a t o r s on these simple t r a n s f o r m a t i o n s .
(e.g. ~ ,
while)
This is not done here since the lan-
guages w h i c h are of g e n e r a l i n t e r e s t r e q u i r e s l i g h t l y m o r e c o m p l e x denotations.
S i n c e the c o m b i n a t o r s given b e l o w can be s p e c i a l i z e d v e r y
e a s i l y to those for the simple transformations,
a t t e n t i o n is now turned
to the more general versions.
The object language features w h i c h d e m a n d richer d e n o t a t i o n s are those w h i c h m a n i f e s t an "abnormal exit" behaviour. is "goto",
The a r c h e t y p a l s t a t e m e n t
but also m u c h error h a n d l i n g can b e s t be dealt w i t h in the
same way. One a p p r o a c h to this p r o b l e m is to use t r a n s f o r m a t i o n s w h i c h c r e a t e states and o p t i o n a l a b n o r m a l indications.
The type of a t r a n s f o r m a t i o n now becomes:
E =
~ ~
where Abn
Z [Abn]
is chosen for a p a r t i c u l a r definition.
of such a (partial)
The intuitive m e a n i n g
f u n c t i o n is that it maps state values
w h o s e first element is always a
(possibly different)
the case that the c o m p u t a t i o n was be the e l e m e n t a r y o b j e c t NIL;
into pairs
state value;
in
"normal", the second c o m p o n e n t w i l l
if t e r m i n a t i o n was abnormal,
the second
c o m p o n e n t w i l l be o t h e r than NI___~Land its actual v a l u e w i l l p r o v i d e inf o r m a t i o n about the e n c o u n t e r e d exception.
The n o t a t i o n i n t r o d u c e d for type clauses m u s t now be extended. than write:
m-9:
(9 Env -~ (~ ~ ~ [Abn])
such f u n c t i o n types w i l l be written:
m~8:
8 Env ==~
Rather
2~
and for value r e t u r n i n g transformations:
m-8:
@ Env ~ (Z ~ Z {Abn]
Val)
is written:
m-8:
0 Env =~ Val
It is now n e c e s s a r y to d e f i n e the combinators w h i c h are used to combine t r a n s f o r m a t i o n s of type E. F i r s t l y if a simple t r a n s f o r m a t i o n N
t:Z~Z is w r i t t e n in a context w h e r e a t r a n s f o r m a t i o n of type E is required, it is interpreted as:
t ~ I~.
t:E it is e n s u r e d that it always has a normal termination. ticular
Notice,
in p a r
"I" the identity over E gives:
I ~ I~.<~,NIL> The full s e m i c o l o n c o m b i n a t o r can now be introduced.
I n t u i t i v e l y its
purpose is to avoid a p p l y i n g the second t r a n s f o r m a t i o n if the first results in abnormal termination.
Formally,
types:
tI : E t2 : E then the type of the result is:
(tl;t 2) : E and its definition:
(tl;t 2) ~ (l~,a.a=NIL~t2(~),T~<~,a>)'t
I
given t r a n s f o r m a t i o n s w i t h
255
In order exit
to signal,
is to occur,
(exit(v))
and
combinator
v
(in Abn),
is used,
that an a b n o r m a l
its type
is:
its d e f i n i t i o n :
error
defined tation
~ lo.<s,v>
construct
result
this,
the exit case;
error
tixe
Thus
the v a l u e
applying
result
is used
to i n d i c a t e
of e r r o r
anywhere
for the w h o l e
text.
c a n b e used w i t h the rule that no tixe
that no
in the d e n o To a c h i e v e
covers
the
thus:
A = exit
(ERROR)
combinator,
and the s e m i c o l o n
cation
of the m e t a - l a n g u a g e
is given.
is to show an a b n o r m a l
ERROR
The
some g i v e n v a l u e
: E
(exi~(v))
The
with
the exit
combinator
subsequent
of a s e c o n d
is " a l w a y s " .
w h i c h was
explained
as part of the m a c r o - s c h e m e ,
have p r o v i d e d
transformations. transformation
two ways
A combinator
in both n o r m a l
of c o n d i t i o n a l l y
which
causes
and a b n o r m a l
applicases
Given:
N
e : E
then the type
(always
is:
t in e)
: E
and the d e f i n i t i o n :
(always
t in e) (ls,a.
If t is, component
in fact,
of type E then
functions.
a way analogous semicolon
if a n o n - N I L
second
is ever returned.
(There are o c c a s i o n s w i t h pure
it is an error
where
an exit
to the s e m i c o l o n
is d e f i n e d
or e r r o r
It is s t r a i g h t f o r w a r d
in terms of
construct to r e d e f i n e
combinator.
is r e q u i r e d composition
H a v i n g done
(the revised)
also in
so, of course,
composition).
256
This concludes the combinators w h i c h are e s p e c i a l l y d e s i g n e d for building up e x p r e s s i o n s from
(expressions denoting)
t r a n s f o r m a t i o n s of type
E. A t t e n t i o n is now turned to value r e t u r n i n g t r a n s f o r m a t i o n s of type:
R = Z : Z [Abn]
V
The m o s t basic way of g e n e r a t i n g such a t r a n s f o r m a t i o n is by the r e t u r n combinator. Thus:
for vEV,
(return(v)) : R
is defined:
(return(V)) ~ I ~ . < S , N I L , v >
A t r a n s f o r m a t i o n of type R may be placed after one of type E
(separat-
ed by ";") and make the w h o l e of type R. Thus given:
t:E r : R
then:
(t;r)
: R
is defined:
(t;r) ~ ( l s , a . ( a = N I L ~ r ( ~ ) , T ~ < q , a , ~ > ) )
"t
N o t i c e that as a c o n s e q u e n c e of this d e f i n i t i o n abnormal exit results in r e t u r n i n g an u n d e f i n e d
(here ~) result.
The value g e n e r a t e d by a v a l u e r e t u r n i n g t r a n s f o r m a t i o n can be used in a f o l l o w i n g t r a n s f o r m a t i o n in a way w h i c h is analogous to the simple let shown below. Given:
r:R t : V~E
then: (let v : r ; t ( v ) )
: E
257
is defined:
(let
v:r;t(v)) (le, a , v . ( a = N I L ~ t ( v ) ( s ) , T ~ < e , a > ) ) ' r
To r e d u c e tents
the n u m b e r
operator
of s e p a r a t e
(S) is c o n s i d e r e d
cases
to be d i s t i n g u i s h e d ,
to be a v a l u e r e t u r n i n g
the con-
transformation.
Thus:
c : REF
~ R
and :
c_r = l a . < o , ~ ( r ) >
The contents occur
operator,
in c o n t e x t s
meaning
...
or any o t h e r v a l u e r e t u r n i n g
where
the c o n s t r u c t
r
...
(while
A = (let
r d__oot) ~
The r e c u r s i v e
v:r;
...
items
form
v : el in
The r e c u r s i v e
(let
defines
for values.
The
this rule m u s t be i n t e r p r e t e d
as:
v = el
(let w =
(le__~t v:r;
of s y n t a c t i c
side d e f i n e s
(t;w)
else
I)
in w)
that w should be the
e2(v))
~
are more b a s i c
sorts of t r a n s f o r m a t i o n s . )
an a b b r e v i a t i o n :
(IV.e2Cv))(el)
let:
e2(v))
composition
sugar to be d e f i n e d
to p a r t i c u l a r
let p r o v i d e s
f o r m of
in
if v then
of the equation.
~
(Iv~.e2(v'))(Ylv.el(v))
v to be be the m i n i m a l
Functional
...)
combinator
(i.e. are not s p e c i a l i z e d its s i m p l e s t
v
let on the r i g h t hand
fixed-point
The remaining
(let
only
is:
In the case of the w h i l e
minimal
is d e f i n e d
transformation,can
fixed p o i n t of e x p r e s s i o n
is s t r a i g h t f o r w a r d :
el.
In
258
(f'g) = (~x.f(g(x)))
The d y n a m i c c o n d i t i o n a l is d e f i n e d in terms of a c o m b i n a t o r d i s c u s s e d in the next section:
(if V then t I else t 2) ~ cond(tl,t2)(v)
6.4 Basic C o m b i n a t o r s
A d e f i n i t i o n as v i e w e d in section 6.2 is a way of generating, object text w h o s e m e a n i n g is sought,
for any
an e x p r e s s i o n in an e x t e n d e d lamb-
da notation. The length of such e x p r e s s i o n s
is reduced and the reada-
b i l i t y much increased by the use of various combinators.
S e c t i o n 6.3
has shown how these can be e l i m i n a t e d in a way w h i c h yields a m u c h longer e x p r e s s i o n w h o s e s t r u c t u r e corresponds m u c h less closely to that of the o r i g i n a l text. The a d v a n t a g e of this e x p r e s s i o n is ever,
how-
that it is almost in pure lambda n o t a t i o n and it is now only
n e c e s s a r y to discuss the m e a n i n g of two r e m a i n i n g combinators.
In fact all that is done at this p o i n t is to rely on the w o r k of others. Thus along with the models of the lambda calculus in Stoy 74, the minimal fixed point o p e r a t o r
(Y) and the "doubly strict" c o n d i t i o n a l are
adopted:
cond(tl,t2)(T) cond(tl,t2)(TRUE) cond(tl,t~)(FALSE)
= X = t1 = t 2.
cond(tl,t2)(±)
= ±
The a d e q u a c y of the d o u b l y strict functions comes from the e x p l i c i t t r e a t m e n t of errors in the m e t a - l a n g u a g e .
6.5 O t h e r Issues The q u e s t i o n of how to define a r b i t r a r y order of e v a l u a t i o n in a language has been omitted for reasons explained elsewhere. ever,
There are, how-
some points w h e r e it appears to occur in the d e f i n i t i o n s given
259
in this volume. C o n s i d e r the use of:
let l£Sc-loc be 8.t. R-STG
Clearly,
l~dom a R-STG
:= C R - S T G U [l~?]
this intends to show a f r e e d o m of choice w h i c h w o u l d be lost
by p r e - d e f i n i n g an order over elements of So-lot and always c h o o s i n g the "next" free location. E q u a l l y clearly,
it w o u l d be u n n e c e s s a r i l y
c o m p l e x to use some general t r e a t m e n t for n o n - d e t e r m i n i s m functions are Z~Z-8et) construct.
Essentially,
(e.g. all
in order to p r o v i d e a formal d e f i n i t i o n of this it is clear that the p a r t i c u l a r choice makes
no d i f f e r e n c e and it is no m o r e w o r t h w h i l e to prove this c l a i m than it is to o v e r - d e f i n e
(see Jones 77c) and then prove w h a t p r o p e r t i e s
of the d e f i n i t i o n are irrelevant.
It must, however,
be clear that the "let be s.t." c o n s t r u c t could be
used u n w i s e l y and each use should really be a c c o m p a n i e d by its own arg u m e n t of w e l l - f o u n d e d n e s s .
Similarly,
the simple rule that v a l u e r e t u r n i n g t r a n s f o r m a t i o n s can
be w r i t t e n in p o s i t i o n s w h e r e values are r e q u i r e d presents a danger. The e x p a n s i o n g i v e n in s e c t i o n 6.3 that they should be e x t r a c t e d and formed into a p r e c e d i n g
let is only clear if either there is only
one such value r e t u r n i n g t r a n s f o r m a t i o n or if their order will have no e f f e c t on the result. This latter is the case in:
l#t nenv
: env+([gdoe-type(dclm(id),env)lid£do_~mdclm ] U ...)
F i n a l l y the topic of errors in the d e f i n i t i o n should be mentioned. A t a n u m b e r of points it has b e e n i n d i c a t e d that s o m e t h i n g is simply cons i d e r e d to be a w r o n g use of the m e t a - l a n g u a g e case construct).
(~i)(?
In such a case,
or
n o t h i n g is defined.
(e.g. an i n c o m p l e t e
just as with:
J'ABC'
This is in d i s t i n c t i o n to the use of error w h i c h
shows that the o b j e c t text is d e f i n e d by the d e f i n i t i o n to be in error. In this case it is p e r m i t t e d for a any r e s u l t sult:)
(although a d i a g n o s t i c
(valid)
i m p l e m e n t a t i o n to p r o d u c e
is, of course,
the m o s t useful re-
260
ACKNOWLEDGEMENTS The basis of the work on formal definition was laid in the Vienna Laboratory during the 1960's; Bekic 70a already showed a dissatisfaction with the "abstract interpreter" approach;
the actual meta-language d e s
cribed in this paper was developed at that Laboratory during the period 1973/75.
This author would like to acknowledge the stimulus and enjoy-
ment he has derived from his years in Vienna.
In particular the co-
operation with Hans Beki~ both in writing the notation section of Beki~ 74 and in discussing a draft of this paper, have been invaluable.
261
APPEND IX ~: C o n c r e t e S £ n t a x of the M e t a - l a n ~ u a g e The rules given b e l o w are an outline of a c o n c r e t e syntax in the notation of Walk 69. Basically,
the rules are context-free,
but sub-classes
of e x p r e s s i o n s are u s e d in order to indicate the types of p e r m i t t e d arguments to operators.
W r i t t e n d e f i n i t i o n s use a number of r e l a x a t i o n s on this syntax w h i c h are not f o r m a l l y defined.
a) B r a c k e t s around blocks and cond-stmts
as w e l l as commas and "in" are
o m i t t e d w h e r e i n d e n t a t i o n or line breaks m a k e the r e s u l t unambiguous.
b) Comments,
enclosed in " / ~ / "
may be used freely.
c) W h e r e an e x p r e s s i o n occurs at the end of an expr-ld,
"result is"
can be used.
d) The order of p r e c e d e n c e of operators
(standard)
is m o d i f i e d by use
of blanks and line-breaks in order to avoid e x c e s s i v e bracketing.
defn tr-defn tr-id
::= {.{fn-defnltr-defn}...} :: tr-id{(defs)} . . . . block
defs
::=
def construcor
::= v-idlconstructor
u s u a l l y begins w i t h
"i-" or "e-"
[,.def...]
"mk-" followed by name of a b s t r a c t syntax class (possibly followed by defs in parenthesis)
block
::= ([exit-spec][let-cl]{;.stmt..,})
exit-spec
::= tixe map-expr in
let-el
::= let def:expr;
expr-block
strut
as block but is value r e t u r n i n g
:~= stmt ~b lock Icond-stmtliter-stmtI~Tat-ldlassign-stmtl int-stmtlreturn-stmtll lexit-stmtlerror
262
cond-stmt
::= i_ff expr then stmt [else stmt] I ({,.{expr~stmt}...}[,T~stmt]I (cases expr:
iter-stmt
{,.{expr~stmt}...}[,T~stmt])
::= for v-id=expr
to expr do stmt
I
while expr do stmt 8tmt-ld assign-stmt int-stmt return-stmt
::= (Idl;stmt) ::= v-id:=expr ::= tr-id~(args)}o.. ::= return(expr)
exit-stmt
::= exit(args)
fn-defn
::= fn-id(defs)
expr
::= prefix-exprlinfix-exprlquant-exprlconstlfn-refleval-stmt
= pure-expr
var-refl(expr)Icond-exprlexpr-blocklexpr-ld fn-ref
::= fn-id(args)
eval-stmt
::= eval-id{(args)}...
args
::= [,.expr...]
var-ref cond-expr
::= [£] v-id[~args !] ::= if expr then expr else expr
I
({,.{expr~expr}...}E,T~expr])I (cases expr:{,.~expr~expr}...}[,T~expr]) expr- ld
::= (ldl;expr)
Idl
::= {;.ld...}
ld
::= let {deflfn-id(defs)} as expr but does not
pure-expr
expr-block,
= expr i__nn (directly)
contain:
~, eval-stmt
@eneral e x p r e s s i o n s
prefix-expr
::= h_!d tuple-expr
dessr-expr
::
(ideffEset-expr])(log-expr)
see also selectors and c o n s t r u c t o r s of a b s t r a c t syntax.
263
arith-ex~r
prefix-expr ::= len tuple-exprlcard set-expr see also o p e r a t o r s
on any s t a n d a r d
sets.
log-expr
prefix-expr ::= llog-expr infix-expr ::= log-expr {&Ivl~l~}log-exprl expr68et-expr 1 set-expr {clc}8et-expr expr {=l#}expr quant-expr
::= ({VIBIBf}def[6set-expr])(log-expr)
const
::= TRUEIFALSE
see also o p e r a t o r s fixed to a b s t r a c t
(e.g. syntax
relational) class
on s t a n d a r d
names.
set-expr
prefix-expr ::= {unionLRower}set-expr 1 {domlrn~}map-expr I {~ndslelems}tuple-expr infix-expr
::= 8et-expr{UInl-}set-expr
const
::= ~[,.expr..~]~ I ~exprllog-expr~l iarith-expr:arith-expr~
see also s t a n d a r d
set names:
Bool, Nat, Nat', Int
sets
and
"is-" pre-
284
tuple-expr
prefix-expr
::= {tllconc}tuple-expr
infix-expr
::= tuple-expr^tuple-expr
const
::= <[,.expr...]> I
map-expr
infix-expr
::= map-expr{+IUl'}map-expr map-expr{\I~}set-expr
const
::= k~,.{expr~expr}...}~I kexpr~expr~log-expr~
285
A P P E N D I X If: C o n v e n t i o n s
A p a r t from n o t a t i o n w h i c h guage,
is strictly part of the d e s c r i b e d m e t a - l a n -
a number of c o n v e n t i o n s have d e v e l o p e d in its use. k ~ i l e changes
to the n o t a t i o n should be r e f l e c t e d in a r e v i s e d d e f i n i t i o n of the meta-language,
the c o n v e n t i o n s can be ignored w i t h impunity.
This a p p e n d i x liSts some p o s s i b l e naming conventions:
usage
example
keyword
ofo_r
underlined sequence
operators
dom
of lower case
variables
val
sequence of 1.c.
of list type
intl
last letter "l"
of set type
cas
last letter "8"
of map type
dclm
last .letter "m"
class names
Program
first u.c., rest 1.c.
e l e m e n t a r y objects
INT
u n d e r l i n e d sequence of u.c.
references
R-STG
first letter "R"
context conditions
is-wf-expr
selector names
s-bdl
convention
(1.c.)
p r e d i c a t e names begins
"is-w f-"
begins
"s-"
266
A P P E N D I X III: E~ample D e f i n i t i o n
This a p p e n d i x p r e s e n t s an example w h o s e study will c o n s i d e r a b l y increase the reader's u n d e r s t a n d i n g of the m e t a v l a n g u a g e .
The d e f i n i t i o n
itself is d i v i d e d into a b s t r a c t syntax, c o n t e x t conditions,
semantic
objects and semantic function parts. Before these are p r e s e n t e d a few points of e x p l a n a t i o n will be offered.
(In a d d i t i o n Bj~rner 78b has
taken examples from this d e f i n i t i o n and thus p r o v i d e d a useful introduction).
The a b s t r a c t syntax should p r e s e n t no difficulties.
The c o n t e x t c o n d i t i o n s are also straightforward,
but note that in ad-
d i t i o n to the c o n v e n t i o n for d r o p p i n g formulae c o r r e s p o n d i n g to "splitting rules",
an obvious e x t e n s i o n permits equations
for rules of the
form:
A :: B C D to be omitted if they are of exactly the form:
is-wf-a(mk-a(b,c,d),env) = is-wf-b(bjenv) & is-wf-c(c, env) & is-wf-d(djenv) Notice that the context c o n d i t i o n is-wf-block
shows that r e c u r s i v e
calls of procedures are allowed w h i l e references identifiers w i t h i n the d e f i n i t i o n s of v a r i a b l e s prohibited.
to locally d e c l a r e d (i.e. b o u n d lists)
are
It can also be o b s e r v e d that is-wf-for shows that the con-
trol v a r i a b l e of a for c o n s t r u c t is strictly local to the body of the
for. The d e s c r i p t i o n of the semantic objects yields m o s t insight into the language. The state is divided into three components of w h i c h the m o s t important is storage; of mapping.
this is d e f i n e d as a d i s j o i n t u n i o n of two types
The e n v i r o n m e n t a u x i l i a r y object p r o v i d e s d e n o t a t i o n s
the identifiers. are locations}
In the simple case for variables,
for
these d e n o t a t i o n s
for arrays the locations are themselves
(one-one) map-
pings. For control v a r i a b l e identifiers the d e n o t a t i o n is simply an (cf. i-for, e-con-var-ref). P r o c e d u r e d e n o t a t i o n s are functions from a r g u m e n t lists
integer because no a s s i g n m e n t to such v a r i a b l e is allowed (and Aid-set)
to t r a n s f o r m a t i o n s
(cf. e-proc-den, w h i c h is a function
267
rather than a transformation,
and i-call).
The basic model for goto
definition is discussed in Jones 78b. Here, because procedures can be passed as arguments,
there is an additional problem of locating the
proper generation of a label. This problem is handled by activation identifiers. For a more detailed description of this approach see Jones 75. Given an understanding of the semantic objects an examination of the "type" clauses of the semantic functions should give an overview of the whole definition. Notice that i-program does not create a (value returning)
is the only function which
transformation.
The function i-
block defines nenv recursively to create the appropriate procedure denotations
(see section 6.2). The handling of exits is simplified in
this language
(cf. i-named-stmt-list)
since no compound
statement is
available.
ABSTRACT
SYNTAX
Program
:: Stmt
Stmt
=
Block
:: s-dcls:(Id~Type)
BlocklIflForlCalllGotoIAssignIInIOutINULL Proc-set Named-stmt •
Type
:: 8-sc-type:
Proc
:: 8-nm: Id Parm • Stmt
Parm
:: s-id:
Named-stmt
:: s-nm:[Id]
Scalar-type
s-bds:[(Exprl~) +]
Id s-attr:(TypelPROC) s-stmt:
Stmt
If
:: s-b: Expr s-th:
For
:: s-con-var:Ids-init:
Call
:: s-pn: Id s-args:(Var-refIId)~
Goto
:: Id
Assign
:: s-lhs:
Stmt s-el: Stmt Expr s-step: Expr s-limit: Expr Stmt
Var-ref s-rhs: Expr
In
:: Var-ref
Out
:: Expr
Expr
=
Infix-expr
:: Expr Op Expr
Rhs-ref
:: Var-ref
Var-ref
:: Id s-sscs:[Expr +]
Infix-exprlRhs-reflCo~-var-reflConst
C o n - v a r - r e f :: Id Const
=
Int-constIBool-const
disjoint
Op
=
Int-opIBool-opIComp-o p
disjoint
Scalar-type
= INTIBOOL
268
CONTEXT CONDITIONS
Env-static
= Id ~ (Type
I PROC, I LABEL
is-wf-program(mk-program(t))
I CON-VAR)
= is-wf-stmt(t,[])
i8-wf-block(mk-block(dclm,procs,nsl),env) let II = <s-nm(nsl(i)) let pnm8 = {8-nm(p) is-unique-id8(ll) (plEproc8
aet
I l
[ pEproc8}
&
& p26procs
is-disjoint(<dom
=
& p1~p2 ~ s-nm(pl)~s-nm(p2))
dclm, pnms,
elems
&
ll>) &
renv = env \ (dom dclm U pnm8 U elemsll)
let nenv = renv U [id ~ star(dclm(id)) [id ~ PROC [id ~ LABEL
Iid
Iid
£ pnms]
6 dom dclm]
I i d E elems
ll]
(dcl£rng dclm ~ is-wf-type-dcl(dcl,renv)) (prEprocs ~ i8-wf-proc(pr,nenv))
U
U &
&
(l
is-wf-type-del(mk-type(sctp, bdl),env) is-wf-type(mk-type(sctp,bdl),env) (bdl=NIL
= &
v
is-expr-list(bdl)
& (l
is-wf-proc(mk-proc(nm,parml, st), env) = is-unique-ids(<8-id(parml(i))
I l
&
(let nenv = env + [s-id(parml(i)) ~ s-attr(parml(i)) is-wf-stmt(st,nenv)
)
I i£[1:len parml}]
289
i s - w f - p a r m ( m k - p a r m ( i d , attr),env) attr=PROC v s-bds(attr)=NIL
i8-wf-if(mk-if(b,
= v i8-~-list(s-bda(attr))
, ),env) = e x - t p ( b , e n v ) = B O O L
i a - w f - f o r ~ m k - f o r ( i d , init,atep, limit, st),env) = let nenv = env + [id ~ CON-VAR] ex-tp(init, env) = ex-tp(step, env) = ex-tp(limit, env) = I N T is-wf-stmt(st,nenv)
i s - w f - c a l l ( m k - c a l l ( p n , al),env) = pn E dom env & e n v ( p n ) = P R O C
&
(l
is-wf-goto(mk-goto(id),env)
= idEdom env & e n v ( i d ) = L A B E L
ia-wf-assign(mk-assign(lhs,rhs),env) is-acalar(lhs,env) ex-tp(rha,env)
v env(al(iJ)=PROC)
=
&
= var-ref-tp(lhs,env)
is-wf-in(mk-in(vr),env)
= is-scalar(vr, env)
i a - w f - i n f i x - e x p r ( m k - i n f i x - e x p r ( e l , o p , e2),env) = is-int-op(op)
& e x - t p ( e l , e n v ) = e x - t p ( e 2 , env)=IN T v
ia-bool-op(op)
& ex-tp(el,env)=ex-tp(e2,env)=BOOL
is-eomp-op(op)
& e x - t p ( e l , e n v ) = e x - t p ( e 2 , env)=INT
is-wf-rhs-ref(mk-rhs-ref(r),env)
= is-scalar(r, env)
v
&
270
is-wf-var-ref(mk-var-ref(id, el),env) idEdom
env & i s - t y p e ( e n v ( i d ) )
(el=NIL
=
&
v (s-bds(env(id))~NI k & fen el = len s - b d s ( e n v ( i d ) ) (1
&
el ~ e x - t p ( e i ( i ) , e n v ) = I N T ) ) )
is-scalar(mk-var-ref(id, sscl),env)
=
sscl=NIL ~ s-bds(env(id))=NIL
is-wf-con-var-ref(mk-con-var-ref(id),env) idEdom
ex-tp(e,env) cases
=
env & e n v ( i d ) = C O N - V A R
=
e:
m k - i n f i x - e x p r ( e l , o p , e2) (is-int-op(op)
~ INT
is-bool-op(op)
~ BOOL
is-comp-op(op)
~ BOOL)
mk-rhs-ref(vr)
~ var-ref-tp(vr,env)
mk-con-var-ref(id) T
~ INT.
~ (is-int-const(e)
~ INT
is-bool-const(e)
Car-ref-tp(mk-var-ref(id,
is-unique-ids(idl) type:
),env)
~ BOOL)
= s-sc-type(envCid))
= /~ true i f f no d u p l i c a t e s
*/
Id ~ ~ Hool
star(t)
= /~ all b o u n d s
changed
to ~ ~/
type: T y p e ~ Type
is-disjoint(el)
= /~ teste
type: Set ~ ~ Bool
set8 p a i r w i s e
disjoint
~/
271
is-scalar-type(t)
is-array-type(t)
SEMANTIC
= is-type(t)
= id-type(t)
& s-bds(t)=NIL
& s-bds(t)#NIL
OBJECTS
State
(R-STG~Storage)
Storage
(Bool-loc ~ (Bool
U ( R - I N ~ Value ~) U
Value
=
Int
Env
=
Id ~ (Loc
i Con-var-den
Array-loc
I Scalar-lot
Loc Array-lot
:
(Int + ~ Bool-loc)
Scalar-loc
=
Bool-loc
Con-var-den
=
Int
Label-den
:: Aid Id
I Label-den
Proc-den)
I (Int+ ~ Int-loc)
l£Array-loc ~ ( 3 i l 6 N a t + ) ( d o m
I Int-loc
is an i n f i n i t e set
Proc-den
:: ((Loc I Proc-den)~
Tr
=
State ~ State Abn
Abn
=
[Label-den]
Int-loc
}
Aid-set ~ Tr)
N
infinite
sets s.t.
Bool-loc N Int-loc ={}
Bool-loc
FUNCTIONS
i-program(mk-program(t)J(inl)
=
(let in-state = [R-STG~[], let fln-state
R-IN~inl,
R-OUT~<>]
= i-stmt(t,[],{})(in-state)
fin-state(R-OUT) ) type: Program ~ (Value • ~ Value ~)
i-stmt:
I k ))
I Bool
constraint:
Aid
( R - O U T ~ Value ~)
I k )) ~ (Int-loc ~ (Int
Stmt Env Aid-set
-~
1 =rect(il))
272
i-block(mk-blockCdclm, procs~nsl),env, cas) = (let aidEAid be s.t. aidEcas let nenv: env + ([id ~ mk-label-den(aid, id) lid ~ e-type(delm(id),env) [s-nm(p) ~ e-proc(p,neno)
I is-cont(id, nsl)] U I idEdomdclm]
U
I pEprocs]);
always (let l o c s =
{nenv(id)
I idEdomdclm~
let sclocs = {lElocs
I is-scalar-loc(1)}
uni°n{rgnl R-STG
U
I 1Elocs & lis-scalar-loc(1)}
:= ~ R - S T G ~ s c l o c s
) i__nni-named-stmt-list(nsl,nenv, aasU{aid},aid) )
e-type(mk-type(sctp~bdl),env)
=
i_~ bdl=NIL then (let 1EScalar-loc be s.t. is-tp-scalar-loc(sctp, 1) & 1Edom c R-STG R-STG
:= c R-STG U [1 ~ ~];
return(1) ) else (let ebdl: <e-expr(bdl(i),env) i_~ (3iE~l:lenbdl~)(ebdl(i)
I l
let 1EArray-loc be s.t. sclErng
1 ~ is-tp-scalar-loc(sctp, s c l ) &
dom 1 = rect(ebdl) rng 1 n d o m c R-STG
return(l)
type: Type Env
R-STG = ~}
:= ~ R__-STGU[scl~~
) ~ Loc
& I sclErn~ 1];
273
e-proc(mk-proc(,parml,st),env)
=
let f(denl, cas) = (if lendenl~lenparml
v
(3iE{l:lenparml~J(~is-pmatch(denl(i),s-attr(parml(i))) then error; let lenv = env + [8-id(parml(i))
~ denl(i)
I i E {l:len parml}]
i-etmt(st, lenv, cas)
) mk-proc-den(f) type:
Proc Env ~ Proc-den
i-named-stmt-list(nsl, tixe
env, cas,a~d)
=
[mk-label-den(a~d, tid)~it-named-stmt-list(tno, I 1~tno~lennsl
i__nnit-named-stmt-list(1,nsl, type:
Named-stmt • Env Aid-set
it-named-stmt-liet(i,nsl,env,
nsl, env, aas.
& s-nm(nsl(tno))=tid#NIL]
env, cas)
Aid
cas) =
for j = i to fen nsl do i-stmt(s-stmt(nsl(j)),env~cae) type:
Nat Named-stmt~
Env Aid-set
i-if(mk-~f(be, th, elJ,env, cas) = (let by:
e-expr(be, env);
if by then i-stmt(th,env, cas) else
i-etmt(el,env, cae)
274
i-for(mk-for(cv, ie,se, le,st),env,cas)
=
(let i: e-expr(ie, env); let s: e-expr(se, env); let l: e-expr(le, env); l_~et f(x) = if (s>O ~ x~l,
s
s=O ~ TRUE)
then (i-etmt(et, env+[cv~x],cae);f(x+s))
f(i) )
i-aall(mk-call(pldjal),envjcas) (let mk-proc-den(f)
=
= env(pid)
let dl:
~ e-var-ref(al(i),env),
T
~ env(al(i))
f(dl, cas) )
i-goto(mk-goto(id),env)
=
exit(env(id))
i-assign(mk-assign(vr,
e),env)
=
(let l: e-var-ref(vr, env); let v: e-expr(e,env); assign(1,vJ
i-in(mk-in(vr)jenv) (if c R-IN
=
= <> then error;
let l: e-var-ref(vr, env); let v: hd e R-IN; i f lie-vmatch(v,var-ref-tp(vr)) else (R-IN
:= tl c R-IN;
assign(1,v)
then error
i 1<~
al>;
275
i-out(mk-out(e),env)
=
(let v: e-expr(e,env); R-OUT )
e-expr:
:= c R-OUT ^
Expr Env
~
Value •
e-infix-expr(mk-infix-expr(el,op, e2),env)
x
(let v1: e-expr(el,env); let v2: e-expr(e2, env); let v: apply-op(vl,op, v2); return(v) )
e-rhs-ref(mk-rhs-ref(vr),env)
=
(let l: e-var-ref(vr, env); content,(l) )
e-var-ref(mk-var-ref(id, sscl),env) if sscl=NIL
=
then return(~nv(id))
else (let a l o c =
env(id)
let esscl:
<e-expr(sscl(i),envJ
i f esecIEdom
I 1
aloc then error;
return(aloc(esscl))) type:
Var-ref Env
~
Loc
e-con-var-ref(mk-con-var-ref(id),env)
e-aonst(e,)
= return(env(id))
= /~ return a Value corresponding
to the Constant
~/
276
apply-op(vl,op,v2) type:
Value Op Value
assign(l,vJ R-STG
~
Value */
Value
=
:= c R-STG + [l ~ v~
type: Scalar-Ice pre:
= /* Returns an appropriate
Value
ICdo~ c R-STG,
is-lmatch(l,v)
contents(l) = let v: c R-ST@(IJ; if V=? then error; else return(v)
type: S c a l a r - l o c pre:
~
Value
IEdom c R-STG
rect(il)
= /* generates a dense rectangle of integers
*/
type: Int + ~ (Int+)-set pre:
1
fen il ~ il(i)~l
is-lmatch(1,v)
= /* ,checks location and value are of same scalar type */
type: S c a l a r - l o c Value ~ Bool
is-vmatch(v, tJ = /* checks value is of scalar type */ type:
Value S c a l a r - t y p e ~ Bool
is-pmatch(d,s) type:
(Loc
= /*
checks the argument matchs parameter specification *~
i Proc-den)
(Type
i PROa) ~ Bool
277
i s - t p - s c a l a r - l o c ( t p , l) = tp=BOOL ~ is-bool-loc(1) tp=INT ~ is-int-loc(1)
type:
Scalar-type
i s - c o n t ( i d , nsl) type:
Scalar-lot
~ Bool
= (3iE{l:~ennsl~)(~d=s-nm(nsl(i))
Id N a m e d - s t m t ~ ~ Bool
DENOTATIONALSEMANTICSOF GOTO: AN EXIT FORMULATION AND ITS RELATION TO CONTINUATIONS
Cliff B.Jones
Abstract: This paper discusses the problem of providing a defini= tion for the "GOTO" statement within the framework of denotational
semantics.
The accepted approach to the
problem is to use "Continuations".
An alternative "Exit
Formulation" is described in this paper. A small language is introduced which illustrates the difficulties caused by statements which terminate abnormally.
For this lan=
guage definitions based on both approaches are provided. A proof of equivalence of the two definitions is then given. In a closing discussion it is pointed out that continuations can define a wider class of languages than exits, although the latter have been shown to be adequate to define languages as complex as PL/I.
CONTENTS
l°
Introduction
Z80
2.
Notation
281
3.
A Small Language
282
4.
Definition By Exit
285
5.
Definition By Continuations
289
6.
Equivalence of the Two Definitions
292
7.
Discussion
302-304
Fig.l:
The Language
Fig.2:
Definition Using Exit Combinators
Fig.3:
Definition by Exit M e c h a n i s m w i t h Combinators
Fig.4:
Definition
Using Continuations
Fig.5:
Definition
Using Continuations
to be Defined
283 286
Definition Using Continuations Recomputed
Fig.7:
-293 --
at Each C o m p o u n d Statement
Definition Using
(E) Continuations
W i t h o u t Environments
289 291
with Merge of c - c and c - l Fig.6:
Expanded
296
-300
280
i. I N T R O D U C T I O N
There exists by now a c o n s i d e r a b l e body of w o r k on the formal definition of p r o g r a m m i n g languages
(see Lucas 78, in this volume,
for a hi-
storical review). M o s t of the w o r k can be c a t e g o r i s e d as either "abstract interpreters",
"denotational semantics" or "axiomatic"~ This
p a p e r attempts to make a c o n t r i b u t i o n to the u n d e r s t a n d i n g of denotational semantics. This a p p r o a c h is p a r t i c u l a r l y
a s s o c i a t e d w i t h the
P r o g r a m m i n g R e s e a r c h G r o u p at Oxford University.
E v o l v i n g from the
earlier work on abstract interpreters
(see Lucas 69) the m o r e recent
w o r k of the V i e n n a L a b o r a t o r y has also u s e d the d e n o t a t i o n a l style (see Beki6 74).
A l a n g u a g e can be given by the set of its texts. To define the semantics of a l a n g u a g e one m u s t a s s o c i a t e a m e a n i n g or d e n o t a t i o n w i t h each text in the set. Since the set of texts will, languages, be of i n f i n i t e cardinality,
for i n t e r e s t i n g
this link w i l l be shown by de-
fining a function from the set of textstto a set of d e n o t a t i o n s . such a d e f i n i t i o n of a large language to be comprehensible,
For
it is re-
q u i r e d that the d e n o t a t i o n of a c o m p o u n d text should d e p e n d solely on the d e n o t a t i o n s of its c o m p o n e n t parts. (Clearly, this rule m u s t be applied ohly to a sensible level: a s c r i b i n g m e a n i n g to single characters and then t r y i n g to c o n s t r u c t the m e a n i n g of identifiers and k e y w o r d s is u n l i k e l y to prove illuminating.
The limit of sensible d e c o m p o s i t i o n
is u s u a l l y indicated by the a b s t r a c t s y n t ~
of a language.)
In order
for a f u n c t i o n from texts to d e n o t a t i o n s to define the semantics of the texts,
it is o b v i o u s l y a p r e - r e q u i s i t e that the d e n o t a t i o n s
themselves
should be objects w i t h known meanings. One c h a r a c t e r i s t i c of d e n o t a t i o nal semantics is the use of m a t h e m a t i c a l objects
(especially functions)
as the denotations.
This accounts
m a t i c a l semantics".
In fact the functions chosen as d e n o t a t i o n s are
for the a l t e r n a t i v e name of "mathe-
of a very general form and it has b e e n a c o n s i d e r a b l e task to show that such functions do indeed h a v e a c o n s i s t e n t m e a n i n g
(see Scott 71).
T h e r e is, w i t h i n the " d e n o t a t i o n a l school", a g r e e m e n t as to the concepts r e q u i r e d to p r o v i d e d e f i n i t i o n s of simple languages. a number of notatiQnal d i f f e r e n c e s
lead to d i f f e r e n c e s
of c o n c e p t u a l l y similar definitions,
see next section).
(However,
in the a p p e a r a n c e Reme~nbering the
"denotational rule" that d e n o t a t i o n s of c o m p o s i t e objects should be b u i l t from the d e n o t a t i o n s of their components,
the following o b s e r v a -
tions can be made. For a p u r e l y functional l a n g u a g e it is easy to agree a definition;
for a language w h i c h includes a n assignment c o n s t r u c t
281
the c o n c e p t of a store
(i.e. a m a p p i n g from identifiers to values)
per-
mits d e n o t a t i o n s to be d e f i n e d w h i c h are functions from stores to stores;
the g e n e r a l l y a c c e p t e d a p p r o a c h to block s t r u c t u r e d languages
is to i n t r o d u c e locations and e n v i r o n m e n t s . W h i l s t refs Mosses 74 and Beki~ 74 build from this basic list of a g r e e m e n t s and tackle similar large languages, a n i m p o r t a n t d i f f e r e n c e can be found.
The i m p o r t a n t d i f f e r e n c e b e t w e e n the Oxford and V i e n n a groups can be f o u n d in their a p p r o a c h to p r o b l e m s of abnormal termination. The arc h e t y p a l p r o b l e m in this c a t e g o r y is the "goto" statement. A d e f i n i tion c o n f o r m i n g to the d e n o t a t i o n a l rule is d i f f i c u l t to c o n s t r u c t for languages w h i c h include goto statements p r e c i s e l y b e c a u s e their effect is to t r a n s f e r control across the s t r u c t u r e over w h i c h the d e n o t a t i o n s are b e i n g constructed.
(This p o w e r of goto statements has led to a
m o v e m e n t for their elimination. here.
This c o n t r o v e r s y is not e n t e r e d into
Rather, models are e x p l a i n e d w h i c h are general enough to model
goto. On such m o d e l s one can then compare a l t e r n a t i v e language constructs w h i c h m i g h t offer the d e s i r a b l e features, w i t h o u t the danger, of goto statements. Of course,
a language feature may e v e n t u a l l y be
s e l e c t e d for w h i c h simpler models are possible. W h a t the m o d e l s here offer is a basis from w h i c h to work.) tions"
The O x f o r d group use "continua-
(see Strachey 74) to d e f i n e g o t o - l i k e constructs:
tion in section 5 b e l o w is in this guage is d e f i n e d u s i n g the V i e n n a
the d e f i n i -
style. The same small example lan"exit" a p p r o a c h in section 4. The
language itself is introduced i n f o r m a l l y in section 3 after some comments on notation. G i v e n two d e f i n i t i o n s of the same language, q u e s t i o n of their r e l a t i o n s h i p can be posed:
the
e q u i v a l e n c e is p r o v e d in
section 6. W h i l s t both c o n t i n u a t i o n s and exits h a v e been shown to be p o w e r f u l enough to d e f i n e c o m m o n l y used p r o g r a m m i n g languages, two a p p r o a c h e s are not of e q u i v a l e n t power,
the
section 7 contains some
c o n c l u d i n g c o m m e n t s on this point.
2. N O T A T I O N
The basis of the n o t a t i o n to be u s e d in this p a p e r is taken from logic and lambda calculus and will p r o b a b l y be familiar from the literature. The items of special i n t e r e s t w i t h i n this p a p e r are i n t r o d u c e d b e l o w as required. A m o r e c o m p l e t e e x p l a n a t i o n is a v a i l a b l e elsewhere in this v o l u m e
(Jones 78a); Jones 75 p r o v i d e s a s t e p w i s e d e v e l o p m e n t of
the exit concept.
282
One of the m o s t d a n g e r o u s traps
when
c o m p a r i n g two languages is to
let the superficial syntactic d i f f e r e n c e s confuse the real issue w h i c h is that of meaning. The d i f f e r e n c e in a p p e a r a n c e b e t w e e n the O x f o r d and V i e n n a d e f i n i t i o n s is very striking. The former group
has achiev-
ed s u c c i n c t n e s s in o r d e r to f a c i l i t a t e formal r e a s o n i n g about smaller definitions, w h i l s t the tasks tackled by the V i e n n a group have led them to strive for readability.
This paper, b e i n g b a s e d on a very small
language, c o m p r o m i s e s a little for the sake of compactness. Thus short names are u s e d for the syntactic classes and "<>" is used instead of a named
(tree) c o n s t r u c t o r w h e r e c o n t e x t makes the choice clear
(the con-
vention for d r o p p i n g semantic rules for syntax classes d e f i n e d to be a list of a l t e r n a t i v e s is also followed). O t h e r than this the d e f i n i tions, even that by continuations,
are given in a V i e n n a - s t y l e .
The
issue to be r e v i e w e d is the d i f f e r e n c e s b e t w e e n the d o m a i n s and function types. Choices like the use of d i f f e r e n t b r a c k e t symbols,
expli-
cit versus i m p l i c i t typing of functions and the d e g r e e of a b s t r a c t n e s s for the syntax m i g h t influence the number of c h a r a c t e r s in a d e f i n i t i o n but would,
if u s e d on one of the definitions,
serve only to cloud the
m a i n distinction.
3. A SMALL L A N G U A G E
This section introduces the language w h i c h will be used as the basis for the r e m a i n d e r of the paper. The basic statements of the language are "goto" and an u n a n a l y z e d class of e l e m e n t a r y statements. A b o u t these latter all n e c e s s a r y k n o w l e d g e is g i v e n by the f u n c t i o n "el-sem" which associates a state-transformation class Z) w i t h each m e m b e r of El-stmt.
(i.e. a function over the
Statements can be o p t i o n a l l y
named and lists thereof can be formed into c o m p o m n d statements.
Such
compound statements are also statements and thus can be named and used as elements of other lists. The a b s t r a c t syntax of the language is given,
along w i t h a full name for each class of objects to aid compre-
hension,
in f~g.
I. The s t r u c t u r e of the classes Id and E l - s t m t is not
further defined.
~:
In this paper a s u p e r s c r i p t 0 is to be read as the functional c o m p o s i t i o n operator. It is e l s e w h e r e r e p r e s e n t e d by the fat dot: ,.
283
P
Program
::
C
Compound statement
C
::
s-b:Ns ~
Named s t a t e m e n t
N8
::
s-n:[Id]
statement
s
:
cI
Goto s t a t e m e n t
G
::
Id
Elementary statement
E1
::
El-stmt
Identifiers
Id
IE
A b s t r a c t syntax
Full name
Fig.
s-b:S
I: The L a n g u a g e to be D e f i n e d
In o r d e r to f a c i l i t a t e d i s c u s s i o n of the i d e n t i f i e r p r e f i x e s of statements,
two p r e d i c a t e s w h i c h check for the
(direct and indirect)
con-
t a i n m e n t of identifiers and a f u n c t i o n y i e l d i n g the index of that s t a t e m e n t w h i c h c o n t a i n s an identifier (under the a s s u m p t i o n that it is c o n t a i n e d somewhere)
is~doontCid, nsI)~=> type:
Id Ns*
~
are introduced:
(Bi6{1 -lenr~sl}) Cs-nOnsl(i) = id)
Bool
is-cont(id, ns l) ~
(is-dcont (id, nsl) v (Bi£~l:,,lennsl})(s-bO-nsl(i) E C & is-cont(id, s-bOs-bOnsl(i))))
type:
Id Ns • ~
Bool
ind( id, ns I)= is-doont(id, nsl) T
~-
~
(li) (s-nOnsl(i)=id)
(li)(s-bOnsl(iJ £ C
type:
Id N8~
pre:
i8-eont(id, nsl)
~
Nat
& is-cont(id, s-bOs-bOnsl(i)))
284
It is assumed that w e l l - f o r m e d programs satisfy the context condition that all label identifiers used in goto statements are c o n t a i n e d exactly once w i t h i n the program. With respect to the statement list w i t h i n w h i c h the goto is placed,
the target s t a t e m e n t may be w i t h i n the same
list, w i t h i n a c o n t a i n i n g list or w i t h i n a c o m p o u n d statement w h i c h is a member of the same list~ The local "hop" and the abnormal exit from a list should require no comment. The ability to jump into a p h r a s e s t r u c t u r e is allowed, b e c a u s e it is included in m a n y p r o g r a m m i n g languages
(cf. Algol
60 "goto" into b r a n c h e s of c o n d i t i o n a l state-
ments.)
The choice of features in this language has b e e n m a d e w i t h some care in order to exhibit m o s t of the c o m p l e x i t y of large languages in a framework of reasonable size. Thus the ability to hop b e t w e e n elements of a list has been s u p p l e m e n t e d by p e r m i t t i n g goto statements to enter and leave syntactic units. In fact if the reader compares this language to Algol 60 (see Henhapl 78 in this volume)
only the ability to pass
labels and p r o c e d u r e s as p a r a m e t e r s forces an e x t e n s i o n of the ideas used here. A b n o r m a l t e r m i n a t i o n of a block via a goto s t a t e m e n t is a s t r a i g h t f o r w a r d e x t e n s i o n and the problems a s s o c i a t e d w i t h r e d e f i n i tion of names in a b l o c k - s t r u c t u r e d language can be solved in a uniform way for v a r i a b l e and label identifiers
(see Beki~ 74 for a dis-
c u s s i o n of label variables).
The e l e m e n t a r y statements of the language are a s s u m e d to cause changes to a class of states
el-sem:
Were
(Z):
El-stmt ~
(Z ~ Z)
it not for the inclusion of the "goto" construct,
it w o u l d be
s t r a i g h t f o r w a r d to p r o v i d e a d e f i n i t i o n w h i c h a s s o c i a t e d a t r a n s f o r m a t i o n w i t h any elements of S.
(The d e n o t a t i o n of a list of statements
b e i n g the c o m p o s i t i o n of the d e n o t a t i o n s of the e l e m e n t s of the list.) W h i l s t as a result of the c o n t e x t c o n d i t i o n given above, the d e n o t a t i o n of a w h o l e p r o g r a m w i l l be such a transformation,
it is not p o s s i b l e
to ~scribe such a simple d e n o t a t i o n to "goto" statements. sections offer d i f f e r e n t solutions to this problem.
The next two
285
4. D E F I N I T I O N BY E X I T
The d i f f i c u l t y of finding a suitable d e f i n i t i o n for a language w h i c h includes goto s t a t e m e n t s is that its a b i l i t y to cut across syntactic units forces changes on the semantics of all such units. A m o t i v a t i o n of the exit a p p r o a c h to be defined in this section was to m i n i m i z e the e f f e c t Of these changes on the overall a p p e a r a n c e of a definition.
The
key to a c h i e v i n g the d e s i r e d e f f e c t w i t h o u t w r i t i n g it into all of the semantic equations is to d e f i n e a p p r o p r i a t e combinators. simple language
(i.e. one w i t h o u t goto statements)
Thus in a
a c o m b i n a t o r denot-
ing f u n c t i o n a l c o m p o s i t i o n m i g h t be w r i t t e n ";". If this same symbol is r e i n t e r p r e t e d as the more c o m p l e x c o m b i n a t o r used below,
a defini-
tion for a language w i t h goto statements can p r e s e r v e a simpler app e a r a n c e except, of course,
for those semantic e q u a t i o n s w h i c h deal
s p e c i f i c a l l y w i t h goto statements.
The basic idea of d e f i n i t i o n by exit is to associate a d e n o t a t i o n with e a c h statement w h i c h is a function of type:
E
=
Z~ZA
=
Idl
where:
A
N~L
Thus the d e n o t a t i o n of a s t a t e m e n t is a f u n c t i o n from states to pairs: the first e l e m e n t is a state and the second is either an i d e n t i f i e r or
NIL. In the case that a p p l y i n g the d e n o t a t i o n of a s t a t e m e n t to a state results in no "goto", the r e s p e c t i v e range e l e m e n t will be the result state p a i r e d w i t h NIL. If, however,
a "goto" is e n c o u n t e r e d to a label
not c o n t a i n e d w i t h i n the statement,
the range e l e m e n t w i l l pair the
state r e f l e c t i n g state t r a n s i t i o n up to the time of the "goto" w i t h the target label.
The definition,
using c o m b i n a t o r s w h o s e m e a n i n g is m a d e p r e c i s e belowr
is given in fig 2. The f u n c t i o n names all b e g i n w i t h that they are
part
"x-" to signify
of the exit-style definition. It is not d i f f i c u l t
to p r o v i d e an i n t u i t i v e u n d e r s t a n d i n g of this definition.
The func-
tion x-g w h i c h d e f i n e s the s e m a n t i c s of goto statements uses the "exit" combinator (identifier)
w h i c h simply pairs the a r g u m e n t state w i t h the given value. W h e r e v e r
a simple
(Z~Z) f u n c t i o n is shown it is
i n t e r p r e t e d as y i e l d i n g NIL p a i r e d w i t h w h a t e v e r the o u t p u t state
286
x-p(
x-e(ep)
=
=
x-c(cp)
x-cp(NIL, cp)
x-cp(ido,<nsl>)
=
tixe [ id~x-l(id, nsl) in
I ia-cont(id, nsl)
]
x-l(ido, nsl)
x-l(ido, nsl) = ido=NIL
x-nsl(nsl, i)
i8-deont(ido, nsl)~
x-nsl(nsl, ind(ido,nsl))
T
(let i = ind(ido, nsl) x-cp (ido, s-b (nsl (i) ) ); x-nsl(nsl, i+l) )
x-nsl(nsl, i) = i
(x-s (s-b (nsl(i) ) ) ;x-nsl(nsl,i+l) ) I
T
x-g(
=
x-el(<el>)
exit(id)
=
el-sem(el)
fig 2: D e f i n i t i o n u s i n g exit c o m b i n a t o r s
w o u l d have been. is the i d e n t i t y of the excised nother
This
explains
x-el and the second case of x-nsl
on E). The fact that these denotations,
and thus
(I that
x-s, are of type E force their c o m b i n a t i o n w i t h one a-
to be more complex°
The
";" c o m b i n a t o r
applies
the s e c o n d E
287
t r a n s f o r m a t i o n o n l y if the second c o m p o n e n t of the first result is NIL, o t h e r w i s e the result of the two c o m p o s e d t r a n s f o r m a t i o n s is e x a c t l y that of the first. It remains only to explain x - c p . tor " t i x e "
(spell back-to-front~)
";". If a normal p a i r in
(i.e. NIL
H e r e the combina-
is for the c o n v e r s e situation from
second component)
t r a n s f o r m a t i o n n o t h i n g m o r e is done;
some r e s t r i c t e d set of exit values, t r a n s f o r m a t i o n re£urns a n o n - N I L
is the r e s u l t of the
the first m a p p i n g defines,
for
the a c t i o n to be taken if the i__nn
result. It is i m p o r t a n t to realize
that this m a p p i n g covers a finite number of cases w h i c h can be d e t e r m i n e d from the text b e i n g defined.
The types of the semantic functions can be given:
x-p:
P ~ E
x-c:
C ~ E
x-cp:
[Id]
C
x-l:
lid]
Ns*
x-nsl:
Ns ~ N a t
x-s:
S~
x-g:
G ~ E
x-el:
E1 ~ E
E E E (assumed)
E
The formal m e a n i n g s of the c o m b i n a t o r s is now given. The format used for these d e f i n i t i o n s
is first to list any assumptions,
type of the c o m b i n a t o r e x p r e s s i o n the d e f i n i t i o n
then show the
(after a ":") and finally to p r o v i d e
(after "~").
F i r s t l y the e x i t
combinator:
for i d E I d exit(id)
: E
exit(id)
A ~a.<~,id> =
The p r o m o t i o n of a simple t r a n s f o r m a t i o n to one of type E is g o v e r n e d by context:
for t : Z~Z in a c o n t e x t r e q u i r i n g E t : E
In particular:
288
I ~- I~.<s, NIL> The s e m i c o l o n combinator is defined as:
for t I and t 2 : E
(tl;t 2) : E (tl;t ~) ~ (l~,ido.(ido=NIL~t2(s),T~
for t I : Id ~ E,
t 2 : E,
ido>))Ot I
is "tix~":
p : [Id] ~ Bool
(tixe [a~tl[a) Ip[a)] i__nnt 2) : E (tixe
[a~t1(a) Ip(a)] i__nnt 2) (let e = [a~t1(a) Ip(a)] 0 let r(e, ido) = (ido6dome ~ r e(ido)(s),T~<~,~do>) rot2 )
N o t i c e that r is used recursively,
thus the effort to resolve an ab-
normal exit w i t h t I continues until p is not satisfied.
Fig 3 p r o v i d e s a r e w r i t i n g of the exit d e f i n i t i o n with the above combinator d e f i n i t i o n s applied to provide a d e f i n i t i o n in almost-pure lambda notation. A l t h o u g h this is more c o n v e n i e n t for the proofs of section 6, the c o m b i n a t o r s h a v e c o n s i d e r a b l e v a l u e in p r o v i d i n g a shorter and m o r e intuitive d e f i n i t i o n of a large language
(compare
refs Beki6 74 and Allen 72).
N o t i c e that the only labels w h i c h are returned from c o m p o n e n t s of the function) in the text argument.
(non-NIL second
"x-l" are those w h i c h are not c o n t a i n e d
Thus it can be proved:
pre-x-l(ido, nsl) <=> (ido=NIL ¥ is-aont(ido, nsl)) post-x-l(~do, nsl,~,~',ido') <=> (ide'=NIL v ~is-contCido',n~l)) and b e c a u s e of the context c o n d i t i o n it is p o s s i b l e to show that x-p is of type:
~ ~ NIL and from this extract a d e n o t a t i o n of type:
Z ~
289
x-cp(ido,<nsl>)
=
let e = [id ~ x - l ( i d , nsl) lis-cont(id, nsl)] let r(a, ido')
= (ido'£dome
~ rOe(ido')(c),
T ~ <s, ido'>)
fox - 1 (ido, ns l)
x-l(ido,nsl)
=
ido=NIL
~ x-ns I (ns l, 1 )
i 8 - d c o n t ( i d o , nsl) ~ x - n s l ( n s l , ind(ido, nsl)) T
~
(let i = ind(ido, nsl) (la, ido '. (ido '=NIL ~ x-nsl(nsl, i+l) (s) , T ~ <s,ido'>))Ox-cp(ido, s-bOnsl(i))
)
x-nsl(nsl,i) i
= ~
((l~,ido'. ( i d o ' = N I L ~ x - n s l ( n s l , i+l),
T ~ <e, ido'>)) 0
x-s(s-b(nsl(i)))) T
~ h~.<S,NIL>
x-g(
x-el(<el>)
x-p,
x-c
=
la.
=
h~. <el-sere(el) ( ~ ) , N I L >
unchanged
F i g 3: Definition by exit mechanism with combinators expanded
5. D E F I N I T I O N
BY C O N T I N U A T I O N S
This section introduces the more widely used continuation approach for the definition of languages which include goto statements. As with exits, this approach recognises that denotations of type Z~Z will not
290
suffice. W h i l e c o n t i n u a t i o n s themselves are:
T = Z ~ Z
the denotations of s t a t e m e n t - l i k e constructs become:
T~T
The q u e s t i o n of the m e a n i n g of goto s t a t e m e n t s is handled by a s s o c i a t ing c o n t i n u a t i o n s w i t h identifiers.
The d e n o t a t i o n of a goto state:
m e n t for any c o n t i n u a t i o n is then the c o n t i n u a t i o n a s s o c i a t e d w i t h the c o n t a i n e d identifier.
In a c o m p l e x l a n g u a g e definition, b l o c k struc-
ture w o u l d anyway force the use of an e x p l i c i t e n v i r o n m e n t a r g u m e n t to the semantic functions and this can be used to record the a s s o c i a t e d c o n t i n u a t i o n for labels. Thus,
Env
=
Id
Intuitively,
~
in the current case:
T
one can consider statement d e n o t a t i o n s as yielding,
a given s u b s e q u e n t c o m p u t a t i o n
(i.e. continuation),
for
the overall compu-
tation s t a r t i n g at this statement. Notice that this is not simply the c o m p o s i t i o n of two functions of type Z~Z b e c a u s e of the p o s s i b i l i t y of "goto". The label d e n o t a t i o n s are the transitions r e s u l t i n g from starting e x e c u t i o n at that label and e x e c u t i n g to the end of the program. Thus a f u n c t i o n of type Z~Z is a s s o c i a t e d w i t h a text given a particular e n v i r o n m e n t and continuation. A m o r e c o m p l e t e d e s c r i p t i o n of the m e t h o d of c o n t i n u a t i o n s
is given in S t r a c h e y
t i n u a t i o n s is given in f i g w h i c h are c o n t i n u a t i o n s
4.
The d e f i n i t i o n by con-
?4.
(The use of braces to b r a c k e t arguments
is adopted for the b e n e f i t of the reader.)
Since there are no c o m b i n a t o r s to be explained in this definition, i n t u i t i v e e x p l a n a t i o n is offered.
this style of d e f i n i t i o n is, however, carefully
no
The reader w h o is u n f a m i l i a r with advised to study this d e f i n i t i o n
(possibly w i t h the aid of an example)
to be sure he has
grasped the rather b a c k - t o - f r o n t c o n s t r u c t i o n of denotations. types of these semantic functions are:
c-p:
P
~
T
c-c:
C
~
(Env
~
(T ~
T))
a-nsl:
Ns ~ Nat
~
(Env
~
(T ~
T))
c-8:
S
~
(Env
~
(T ~
T))
(assumed)
The
291
c-p(
I is-cont(id, s-b(cp))]
c-c(cp) (enVo){I }
c-c6<nsl>)
=
c-nsl(nsl, 1)
c-nsl(nsl,i) (env) {c}= i
c-g(
=
c-el(<el>) (env){c}
env(id)
=
cOel-sem(el)
e-l(id, nsl)(env){e}= is-dcont(id, nsl) ~ a-nsl(nsl,ind(id, nsl))(env){c} T
~ (l#t i = ind(ido,nsl) c-1 (id, s-bOs-bOns 1 (i)) (env) {c-ns I (nsl,i+1) (env) {c} } )
fig 4: Definition using continuations
292
G
(Env ~
(T ~ T))
a-el:
EL
(Env ~
(T ~ T)J
e-l:
I d N8 •
(Env ~
(T ~ T))
e-g:
6. E Q U I V A L E N C E
OF THE TWO D E F I N I T I O N S
Sections 4 and 5 have both p r o v i d e d mappings
from p r o g r a m s to functions
(Z~Z) : the aim of this section is to show that the d e f i n i t i o n s are eq u i v a l e n t in the sense that they a s s o c i a t e the same t r a n s f o r m a t i o n w i t h any w e l l - f o r m e d program.
It is p o s s i b l e to d i s c e r n three important
d i f f e r e n c e s b e t w e e n the exit and c o n t i n u a t i o n definitions:
(i)
The c o n t i n u a t i o n d e f i n i t i o n associates w i t h each label identifier
a denotation execution
(i.e. continuation)
w h i c h reflects the effect of s t a r t i n g
at that label and c o n t i n u i n g to the end of the entire pro-
gram. On the other hand,
the exit d e f i n i t i o n p r o v i d e s
(see p o i n t
(ii))
d i f f e r e n t d e n o t a t i o n s for label identifiers at each n e s t e d c o m p o u n d statement:
in each case the d e n o t a t i o n c a p t u r e s the m e a n i n g of execu-
tion f r o m any contained label to the end of the current c o m p o u n d statement.
(ii)
W h e r e a s the c o n t i n u a t i o n d e f i n i t i o n passes the d e n o t a t i o n s of
label identifiers to semantic functions e x p l i c i t l y in the environment, the m e a n i n g of labels (an E) in exit d e f i n i t i o n s is used combinator)
(iii)
(by the tixe
at the level of the c o n t a i n i n g c o m p o u n d statement.
The mode of g e n e r a t i o n of the r e s p e c t i v e d e n o t a t i o n s
a p p r o a c h e s differs:
in the two
in the e x i t - s t y l e the d e n o t a t i o n of a label is
d e r i v e d by starting at that label and "composing" s e m i c o l o n combinator);
forwards
(via the
c o n t i n u a t i o n s are b u i l t up from the final trans-
f o r m a t i o n c o m p o s i n g backwards.
The proof style adopted b e l o w is to show a sequence (each with d i f f e r e n t p r e f i x e s
for the f u n c t i o n names)
each is e q u i v a l e n t to its predecessor.
of d e f i n i t i o n s and show that
Since the p o i n t of d e p a r t u r e
is the "c-" d e f i n i t i o n of section 5 and the last step shows the equivalence of the "f-" d e f i n i t i o n to the
(expanded form of the)
"x-" de-
f i n i t i o n of section 4 a c o m p l e t e p r o o f of e q u i v a l e n c e is given. A good o v e r v i e w of the r e a s o n i n g can be o b t a i n e d by u n d e r s t a n d i n g the interm e d i a t e d e f i n i t i o n s w i t h o u t f o l l o w i n g the details of the individual
293
equivalence proofs.
The first step in a sense,
(i.e. the "d-" definition)
is the second
to difference
("e-")
is purely preparatory,
as,
although this relates specifically
(i)° The step to the "f-" definition completes the reso-
lution of differences
(i) and (ii). The final step from the "f-" to
the "x-" functions resolves difference
(iii).
The first step in our equivalence is trivial. Looking at the "c-" functions,
it is obvious that e-c and c-l are both special cases of a
more general function which takes an optional identifier as its first argument.
d-l:
[Id] Ns ~ ~ (Env ~ (T ~ T))
Since a combination of these two tasks has been employed in the "x-" definition the difference must be resolved somewhere and early resolution will shorten some of the inductive arguments to be used below. In fact the definition given in fig 5 could have been presented in section 5: equivalence with that actually given follows from:
is-cont(id, nsl)
~
d-l(NIL, nsl)
c-c( <nsl>)
=
d-l(id, nsl) = c-l(id, nsl)
d-c(<nsl>)=d-l(NIL,nsl)
d-l(ido, nsl)(env){a}= ido=NIL
d-nsl(nsl, 1) (env) {c}
i8-dcont(ido, ns1)~
d-nsl(nsl, ind(ido, nsl) ) (env) {c}
T
(let i = ind(ido, nsl) d- l (ido , s-bOs-b Onsl( i) ) (env) {d-nsl(nsl, i+ l) (env) {c}i )
d-p,d-nsl, d-g~d-el:
models of respective
"c-" functions
fig 5: Definition using continuations with merge of c-c and c-1.
294
The next step in the proof also changes v e r y little. The types of the "e-" functions are the same as those of the "d-" functions. The d i f f e r ence is that some elements of the e n v i r o n m e n t denotations)
(i.e. c o n t a i n e d label
are r e c o m p u t e d at each compound statement level. W h a t has
to be proved is that the r e c o m p u t e d values are exactly the same as those already stored
(the u s e f u l n e s s of
this
step
will b e c o m e appa-
rent later). A good intuitive c o n f i r m a t i o n of this claim can be obtained by v i e w i n g the "e-" functions as a m a c r o - e x p a n s i o n and observing that the c o n t i n u a t i o n a r g u m e n t of e-cp(NIL,<nsl>) w i t h that used to generate the d e n o t a t i o n s
is ~dentical
(in env 0 of d-p)
of all
labels contained in nsl.
P r o c e e d i n g m o r e formally,
from the s u b s t i t u t i v i t y of equal values it
is obvious that:
(is-cont(id, nsl)
~
env(id)=d-l(id,nsl)(env){c))
&
(ido=NIL v is-cont(ido, nsl)) d- l (ido,nsl ) (env+[ id-~-l(id, nsl) (env) { c} lis-cont( id, nsl ) ]){c} =
d-l(ido, nsl)(env){a}
It is now n e c e s s a r y to show that for all
d-l(ido, nsl) (env){a} it is true that:
is-cont(id, nsl)
~
env(id)
= d-l(id, nsl)(env){c}
O b s e r v e that this is true for the r e f e r e n c e to d-1 from d-p.
For re-
c u r s i v e calls of d-1 consider:
id n such that is-cont(idn,nsl)
& li8-dcont(idn, nSZ)
its d e n o t a t i o n is given by:
env(id n)
=
d-l(idn, S-b 0 s-bOnsl(~n))(env){d-nsl(nsl,in+1)(env){c}}
w h e r e i n = ind(idn, nSl) but for r e c u r s i v e r e f e r e n c e s to d-l in d-nsl(nsl,in)(env){c}
295
d-nsl(nsl, i )(env){c} = d-s(s-b nsl(i ))(env){d-nsl(nsl,i +1)(env){c}} _n o n = d-l(NIL, s-bas-b nsl(in))(env){d-nsl(nsl, in+1)(env){c}} sO for:
is-cont(idn, s-bOs-bOnsl(in )) the required p r o p e r t y still
holds since the c o n t i n u a t i o n s match.
This c o n c l u d e s the a r g u m e n t and the d e f i n i t i o n in fig 6 can be seen to be e q u i v a l e n t to the "d-" functions b e c a u s e e-cp is introduced just to "recompute"
some label d e n o t a t i o n s ;
other functions are changed
a c c o r d i n g l y i n c l u d i n g the fact that ~-p need no longer g e n e r a t e an environment:
e-cp
:
[Id] C ~ (Env ~ (T ~ T))
The n e x t stage of the proof is the m o s t interesting.
B e f o r e coming to
the "f-" functions a u s e f u l lemma on c o n t i n u a t i o n s will be given. Int u i t i v e l y this lemma states that in order to achieve the same effect as c o m p o s i n g some f u n c t i o n w i t h the d e n o t a t i o n of a statement,
that
f u n c t i o n m u s t be c o m p o s e d w i t h both the c o n t i n a t i o n and each label den o t a t i o n u s e d in d e r i v i n g the g i v e n denotation.
296
e-p(
e-c(cp)
=
=
e-c(cp) ([ ]) {I}
e-cp(NIL, cp)
e-cp(ido, <nsl>) (env) {c}= le t env' = env+[id~e-l(id, n~l)(env'){c}lis-cont(id, nsl)] e-l(ido,nsl) (env') {c}
e-l(ido,nsl)(env){c}= ido=NIL is-dcont(ido, nsl) T
e-ns
l (ns l, I ) (env) { a }
e-nsICnsl, indCido, nsl) ) (env) {c} (let i = ind(ido, nsl) e-cp(ido,s-bOnsl(i)) (env){e-nsl(nsl,i+l) (env){c}} )
e-nsl, e-g,e-el: models of respective "c-" functions
fig 6: Definition using continuations recomputed at each compound statement
297
Lemma
I
define: show for: that:
me(c, env) = [id~cOenv(~d) lidEdomenv] et is e-s(s),e-nsl(nsl,i),e-iCido,n~l) or e-cp(ido,cp) c20et(env)~el } = et(me(c2, env)){c20Cl }
Proof:
The argument consider
is by i n d u c t i o n
statements
o n the s t r u c t u r e
of the
text,
as a basis
of G and E:
0 0 a 2 e-g(
in the basis
a C, here basis,
consider
a subsidiary
consider
elements
inductive
of
proof
Ns ~ w h e r e no e l e m e n t c o n t a i n s (on lennsl-i) is made. For the
i>lennsl:
c20e-nsl(nsl, i)(env)~01 } = c20c 1 e-nsl(nsl,i)(me(c2, env)){c20Cl } = a20c I for the i n d u c t i v e
step
i
0 c 2 e-nsl(nsl,i)(env){e I} = c20e-s(s-b(nsl(i))) (env){e-nsl(nsl,i+1)(env){Cl}
}
= e-s (s-b (ns l (i)) ) (me (c2, env) ) {c20e-ns 1 (ns l,~+1) (env) { c I } } 0 = e-s (8-b (nsl (~)) ) (me (c2, env) ) .e-ns 1 (ns l,i+1) (me (e2, env) ) {c 2 c I ~ e-nsl(nsl, i)(me(c2, env)){c20cl } } = e-s(s-b(nsl(i)))(me(c2, env)){e-nsl(nsl,i+l)(me( For e l e m e n t s the results
of for
l.H.onS l.H.onN8 •
c 2, envJ{c2Oel}}
N8 ~ w h e r e no e l e m e n t c o n t a i n s a c o m p o u n d statement, e-l(ido, nsl) and e-cp(idojcp) are i m m e d i a t e from the
above.
For the i n d u c t i v e the c o n s t r u c t i o n
step,
the only a d d i t i o n a l
of e l e m e n t s
of C, thus:
case
to be c o n s i d e r e d
is
~8
0 0 c 2 e - c ( c p ) ( e n v ) { c I} = c 2 e - c p C s - b ( c P ) J ( e n v ) { c I} 0 e - c ( c p ) ( m e ( e 2 , e n v ) ) { c 2 c 1} = e-cp ~ - b ( c p ) ) ( m e ( c 2 , e n v ) ) { c 2 0 c l }
w h i c h are equal by i n d u c t i o n hypothesis.
This c o n c l u d e s the proof of Lemma Z.
Lemma I will now be used to justify change from p a s s i n g in label denotations in e n v i r o n m e n t s
to c o m p o s i n g them w i t h the revised m e a n i n g of
the basic statement list. The r e v i s i o n to the m e a n i n g of a statement list changes
it to type E and makes any goto s t a t e m e n t cause a label
to be returned as the second c o m p o n e n t of the result. The c o m p o s i t i o n of the label d e n o t a t i o n s is now
(recursively)
d i c a t i o n of a b n o r m a l exit is present.
applied only if this in-
I n t u i t i v e l y the proof w h i c h fol-
lows shows that any e n v i r o n m e n t is e q u i v a l e n t to a c o m p o s i t i o n of a test and a c o n s t a n t environment, and any c o n t i n u a t i o n is e q u i v a l e n t to a c o m p o s i t i o n of a test and a c o n s t a n t function. Since both of these tests are the same,
lemma I can be used to factor out the test.
P r o c e e d i n g m o r e formally,
it is o b s e r v e d that though the used types
of the "e-" functions are:
e-e:
0 ~
((Id ~ T) ~
(T ~ T))
they are p e r f e c t l y general in that they also fit:
e-Q:
e
~
((Id ~ (S ~ ~)) ~ ((~ ~ ~) ~
(S ~ ~)))
Writing:
xe(nsl)
= [id ~ X ~ . < ~ , i d > J i s - c o n t ( i d , nsl) ]
xt(env, c) : ~ , a . ( a = N I L ~ c ( s ) , T ~ e n v ( a ) ( s ) )
it is immediate that:
d o m e n v = { i d j i s - c o n t ( i d , nsl)} [id~xt(env, c ) O x e ( n s l ) l i d £ d o m e n v ]
and: 0 xt(enV, c) I ~ . < ~ , N I L >
= c
= env
299
But then:
e-l(ido, nsl) (env'){c} = e-l(ido, nsl) ([id~xt(env ',e)Oxe(nsl) lidEdomenv']) {xt (env ',c) Oks. <~, NIL> } = xt(env ~ c)Oe-l(ido, nsl) (xe (nsl)) (ke. <e, NIL>} SO :
e-cp (ido,
e-p:
the w h o l e d e f i n i t i o n
P -~ (Z -~ T [Id] )
(and this was w h y p l a c e d by 7.~). be shown
has now become:
it was n e c e s s a r y
But,
as w i t h
labels
program
level
element
of the r e s u l t m u s t b e NIL.
B u t all env
arguments
cause the d e f i n i t i o n stant f u n c t i o n s Furthermore,
only considers
can be omitted.
This results
in s e c t i o n 4, it can
programs
denotations
well-formed
into the semantic
s i n c e the e n v i r o n m e n t
that T could be re-
can be returned.
for w e l l - f o r m e d
n o w give c o n s t a n t
can be m o v e d
above
the exit d e f i n i t i o n
that o n l y n o n - c o n t a i n e d it can be shown
to o b s e r v e
argument
Thus
at the
that the second
for labels!
programs
these con-
definition
of goto.
is n o w u s e d nowhere,
in the d e f i n i t i o n
Be-
in fig
7.
it
300
f-p(
f-c(cp)
= f-c(cp){la.<~,NIL>}
= f-cp(NIL, c p)
f-cp(ido,<nsl>){c}= let e = [id~f-l(id, n s l ) { l ~ . < ~ , N I L > } l i s - c o n t ( i d , 0 = (aCdome~r e ( a ) ( s ) , T ~ X c . < s , a > )
nsl)]
let r(~,a)
rOf-l(ido,nsl){hs.<s,
NI__kL>}
f-l(ido,nsl){c}= ido=NIL
~ f-nsl(nsl, 1){c}
is-dcont(ido,nsl)
~ f-nsl(nsl, ind(ido, nsl)){c}
T
~
(let i = ind(ido, nsl) f-cp(ido, s-bOnsl(i) ) {f-nsl(nsl, i+l) {c}} J
f-nsl(nslji){c} = i~lennsl
~
f-s(s-bOnsl(i)){f-nsl(nsl,
T
~
e
f-g(
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.
the lemma is
define:
t(c) = la, a . ( a = N I L
show for:
ft(xt) is f - s ( x - s ) , f - n s l ( x - n s l ) t(c)Oxt(s) = ft(s){c}
that:
the proof
(not given here)
~ c ( ~ ) , T ~ <s,a>)
or f - l ( x - 1 )
is by a similar induction to that of Lemma
I.
Using Lemma II:
f-nsl(nsl, i){c}= i<_lennsl ~ t ( f - n s l ( n s l , i + l ) ~ c } ) O x - s ( s - b O n s l ( i ) T
~ c
respectively
)
302
and:
f-l(ido,nsl) {c}= . . .
T ~ (let i = ind(ido,nsl) t(f-nsl(nsl, i+l) {o})Ox-cp(ido, s-bOnsl(i) ) ) r e w r i t i n g the second case of f-nsl as:
Ic.
lq. <el-sere(el) (q ) ,NIL> the c o n t i n u a t i o n a r g u m e n t s to all functions can be d r o p p e d and the "x-" functions remain.
7. D I S C U S S I O N
Two d i f f e r e n t d e f i n i t i o n s of a l a n g u a g e have b e e n g i v e n and proved equivalent.
It is i m p o r t a n t to realize that this is a limited p r o o f in
the sense that n o t h i n g has b e e n e s t a b l i s h e d about the p o w e r of the two mechanisms
in general.
In fact c o n t i n u a t i o n s can b e stored and p a s s e d
in a way w h i c h cannot be simulated by exit. Thus, c o - r o u t i n e s or like features can be defined u s i n g c o n t i n u a t i o n s but not exits
(see Rey-
nolds 74). However, b o t h a p p r o a c h e s have b e e n used to d e f i n e m a j o r prog r a m m i n g languages
(cf. Mosses 74, Beki6 74, Henhapl 78) and there is
e x p e r i e n c e from the w o r k on a b s t r a c t i n t e r p r e t e r d e f i n i t i o n s to argue that w h e r e a m o r e p o w e r f u l c o n s t r u c t is not necessary,
its use should
be avoided. The c h o i c e of
w h i c h t e c h n i q u e is m o s t a p p r o p r i a t e m i g h t well d e p e n d
on the intended use of a definition.
For general c l a r i t y it could be
that the a b i l i t y of the exit c o m b i n a t o r s to hide the effect of a goto in m o s t parts of a l a n g u a g e d e f i n i t i o n is valuable.
On the other hand,
proofs a b o u t the m e a n i n g of p r o g r a m s will anyway have to expose the c o m b i n a t o r s and a c o n t i n u a t i o n d e f i n i t i o n may be m o r e d i r e c t l y usable. E v e n h e r e there is one i m p o r t a n t a d v a n t a g e of the exit a p p r o a c h and
303
that is the ability to localize the effect of goto statements within the syntactic unit containing the goto and the label. Thus in:
begin
begin
begin
9oto l ,
end~
l:
.°.
end
end the second nested block will have a denotation of type:
-~ ~
NIL
This closing-off of the semantic effects of goto cannot be simulated with continuations.
Both the Oxford and Vienna groups have made experiments with using definitions to provide a starting point for systematic piler development
(justified)
com-
(see Milne 76, Jones 76a). It is in this area that
a more meaningful comparison of continuations and exits should be sought.
Hopefully the proof in section 6 has been presented in an intuitively
3O4
clear style. For more interesting approaches to such proofs see Reynolds 74, Reynolds 75.
ACKNOWLEDGEMENTS An earlier draft of this paper was submitted to, and eventually accepted by the IBM Journal of Research and Development.
Two of the referees
provided very valuable comments for which the author would like to express his gratitude.
(The paper was subsequently withdrawn with the ar-
greement of the editor of that journal in order to place it in the current volume.)
A FORMAL DEFINITION OF ALGOL 60 AS DESCRIBED IN THE 1975 MODIFIED REPORT
Wolfgang Henhapl & Cliff B.Jone8
Abs tract: This paper provides a formal definition of a version of the ALGOL 60 programming language.
In particular
the definition uses the denotational approach and the meta-language presented in this volume
(-- known with=
in the Vienna Laboratory as "META-IV"). As well as ex = emplifying the meta-language,
(yet) another definition
of ALGOL 60 is justified by the recent revision of the language which resolved most of the open points in the earlier "Revised Report".
CONTENTS
0.
Introduction
307
i.
Abstract
310
syntax
i.i Definitions 1.2 Translator 2.
310 notes
312
Context Conditions
313
2.1 "is-wf" Rules
314
2.2 "tp" Determining
Rules
318
2.3 Auxiliary Functions
319
3.
Semantic Objects
319
4.
Meaning Functions
320
4.1 Functions
320
from Object Language
4.2 Auxiliary Functions
334-336
307
0. I N T R O D U C T I O N
For many years the official description of ALGOL 60 has been the "Revised Report"
(Naur 65). Not only the language, but also its extreme-
ly precise description have been seen as a reference point. There were, however,
a number of known unresolved problems and most of these have
been eliminated by the recent modifications given in De Morgan 75. A number of formal definitions exist for the language of the revised report: this paper presents a denotational definition of the language as understood from the modified report
(MAR).
Before making some introductory remarks on the definition, will be made about tke language itself
three points
(as in De Morgan 75). Firstly
the modifications have followed the earlier "ECMA subset" by making the language
(almost)
now be specified,
statically typed. Although all parameters must
there is still no way of fixing the dimensions of ar-
ray parameters nor the required parameter types of procedure or function parameters
(cf. ALGOL 68). In connection with this it could be
observed that the parameter matching rules of section 4.7.5.5 are somewhat difficult.
In particular the definition given below assumes
that, for "bE name" passing of arithmetic expressions,
the types must
match exactly~
The third observation is simply one of surprise. The decision to restrict the control variable of a
identifier>
(i.e. not a subscripted variable)
may or may not be wise:
but the argument that
The definition given here would have
had no difficulty treating the more general case because the concept of location has anyway to be introduced for other purposes. TWO of the major points resolved by the modifications are the meaning of "own" variables and the provision of a basic set of input-output functions:
particular attention has been given to these points in the
formal definition below.
In fact, the treatment of own given here is
more detailed than that for PL/I static variables
in Walk
than perform name changes and generate dummy declarations
69. Rather in the outer-
most block, an extra environment component is used here to retain a mapping from (additional)
unique names to their locations. This "Own-
env" is used in generating the denotations for own variables for insertion in the local "Env". The input-output functions are defined to change the "Channel" components of the state (Z).
308
M u c h of the d e f i n i t i o n w h i c h follows should be easy to read after a study of the example given in Jones m i l a r to that g i v e n there
?Sa. The t r e a t m e n t of goto is si-
(for d i s c u s s i o n see Jones ZS) except that
the use of the "tixe" c o m b i n a t o r h a p b e e n h e l d here to a minimum. stead of the use in i-block,
In-
an a r g u m e n t can be m a d e for l o c a l i z i n g
the effects of goto at the level of comp-stmt,
cond-stmt and 8tmt. In
a v e r s i o n w h i c h used "tixe" at all three levels it was found advantageous to m e r g e the "cue" and "i" functions
(cf. Jones 78b).
As has b e e n d i s c u s s e d e l s e w h e r e in this volume,
the d e f i n i t i o n of ar-
b i t r a r y order of e v a l u a t i o n has not b e e n addressed: had it been, one would,
for example, have to show that the elements of an e x p r e s s i o n
can be e v a l u a t e d in any order.
W i t h the aid of the l±st of a b b r e v i a t i o n s given at the end of this introduction,
the a b s t r a c t syntax and c o n t e x t c o n d i t i o n s should be straight
forward. N o t i c e that, a l t h o u g h the a b s t r a c t syntax itself is a "con-
text-free" p r o d u c t i o n system, c o n t e x t d e p e n d a n t typing name)
is used and secured by the context conditions.
v a r i a b l e s are,
(e.g. A r r a y -
(Notice b y - v a l u e
in fact, n o n - b y - n a m e - i.e. b y - v a l u e includes n o n - p a r a -
meters). The semantic objects are the key to the definition. components, location
States c o n t a i n two
one of w h i c h stores scalar values for each c u r r e n t scalar
(the d i v i s i o n to the sub-types of Sc-loc is not necessary,
is only made to fit the i m p l e m e n t a t i o n viewpoint),
it
the other of w h i c h
c o n t a i n s an a b s t r a c t i o n of the objects w h i c h can be a c c e s s e d by the i n p u t - o u t p u t statements.
State t r a n s f o r m a t i o n s are of the type r e q u i r e d
by the "exit treatment" of goto. The c o m p o s i t e objects Stmt-env and Expr-enV are i n t r o d u c e d solely as abbreviations;
Own-env has b e e n m e n t i o n e d above; the real i n t e r e s t
lies in the d e n o t a t i o n s w h i c h can be stored in Env. Type-dens are obv i o u s l y scalar locations.
A f u n c t i o n p r o c e d u r e w h i c h is a c t i v a t e d sets
up a value to be r e t u r n e d by a s s i g n i n g to the Atv-proc-id:
again a
scalar l o c a t i o n is the a p p r o p r i a t e denotation. A r r a y d e n o t a t i o n s the
store
(one-one) m a p p i n g from all p o s s i b l e subscript v a l u e s to scalar lo-
cations;
notice that the c o n s t r a i n t requires that the d o m a i n of an ar-
ray d e n o t a t i o n is "dense". P r o c e d u r e d e n o t a t i o n s are functions which, for given arguments and a c u r r e n t set of activations, y i e l d transformations. N o t i c e that the Act-parm-dene
carry type i n f o r m a t i o n w i t h them
for c h e c k i n g w i t h i n the Proc-den. Switch d e n o t a t i o n s are similar.
SO9
The very general p a r a m e t e r p a s s i n g quires that the By-name-dens
"by name" p e r m i t t e d in A L G O L re-
are rather like p r o c e d u r e denotations.
Because formal p a r a m e t e r names can occur as D e s t i n a t i o n s
for assign-
m e n t s t a t e m e n t s it is also n e c e s s a r y to know w h e t h e r a b y - n a m e param e t e r c a n be e v a l u a t e d to a l o c a t i o n or not
(cf. e-parm-expr,
e-var-
ref, e-vat). F u r t h e r m o r e , the q u e s t i o n w h e t h e r a p a r a m e t e r is to be p a s s e d b y - n a m e or b y - v a l u e is not d e c i d a b l e at the p o i n t of call. Thus all p a r a m e t e r s are passed b y - n a m e and the Proc-den has the task of c r e a t i n g the locations to store b y - v a l u e p a r a m e t e r s
(cf. e-proc-
decl, e-val-parm). The c l a s s e s Loc and Val are a u x i l i a r y and are used only in type clauses.
G i v e n an u n d e r s t a n d i n g of the semantic objects the reader should be able to tackle s e c t i o n 4. R e m e m b e r that for "splitting" rules o n l y a type clause is given.
ACKNOWLEDGEMENT.
R e t u r n i n g the c o m p l i m e n t to Peter Mosses, one of the a u t h o r s w o u l d like to a c k n o w l e d g e that a p a r t of the i n c e n t i v e to w r i t e this defin i t i o n w a s the hope to provide an equally a b s t r a c t but m o r e r e a d a b l e d e f i n i t i o n than that in Mosses 7 ~
ABBREVIATIONS.
Abnormal c o m p o n e n t
constant
operator
actual
declaration
parameter
activation identifier
denotation
procedure
activated arithmetic
designator descriptor
reference
assignment by-name Boolean
destination element
specification statement subscripted
by-value
character compound conditional
environment
scalar
expression function
unlabelled
identifier
value
integer
variable
transformation
310
1. A B S T R A C T
SYNTAX
i.i D e f i n i t i o n s
Program
:: Block
Block
:: 8-dp:Decl-set
Stmt
:: s-lp:Id-set
Unlab-stmt
=
Comp-stmt Dummy-stmt
s-sl:Stmt* 8-sp:Unlab-stmt
I Block I Assign-stmt I Cond-stmt
Comp-stmt
:: Stmt*
Assign-stmt
:: s-lpl:Destin +
Destin
:: s-tg:Left-part
Left-part
=
Atv-proc-id
:: Id
Goto-stmt
:: Expr
s-rp:Expr s-tp:Type
Vat IAtv-proc-id
Dummy-stmt
:: DUMMY
Cond-stmt
:: s-dec:Expr
s-th:Stmt
For-stmt
:: s-cv:Var
s-cvtp:Type
For-list-elem
=
I While-elem
Expr-elem
:: Expr
While-elem
:: s-in:Expr
~-wh:Expr s-st:Expr
Expr-elem
Step-until-elem
:: 8-in:Expr
Proc-stmt
:: (Proc-des I Funct-des)
Proc-des
:: s-pn:Id
Expr
I Goto-stmt 1
I For-stmt I Proc-stmt
s-el:Stmt s-fl:For-list-elem +
s-un:Expr
s-app:Act-parm*
=
Type-const
Type-const
=
Prefix-expr I Infix=expr I Cond-expr Bool-const IArithm-const
Bool-const
:: Bool
Arithm-const
=
Rea.l-const
:: Real
Int-const Var-ref
:: Int :: Vat
Vat
=
Simple-var
Simple-vat
=
Simple-var-bn
Real-const
Simple-var-bn
:: s-nm:Id
Simple-var-bv
:: s-nm:Id
Subset-vat
=
Subscr-var-bn Subscr-var-bv
:: 8-nm:Id :: s-nm:id
s-b:Block
I Step-until-elem
I Var-ref I Label-const
I Int-const
I Subscr-var
Subscr-var-bn
I Simple-var-bv
I Subscr-var-bv
8-88cl:Expr + + s-sscl:Expr
I Switch-des
I Funct-des
311
Label-const
:: Id
Switch-des
:: s-id:Id
Funct-des Act-parm
:: s-nm:Id s-app:Act-parm • :: s-v:Act-parmv s-tp:Specifier
Act-parmv Parm-expr Array-name
= Parm-expr I Array-name I Switch-name I Proc-name I String :: Expr :: Id
Switch-name Proc-name
:: Id :: Id
String
= Char •
Char
= Implementation
Prefix-expr
:: s-opr:Prefix-opr
Prefix-opr
=
8-ssc:Expr
defined set s-op:Expr
REAL,cPLUSIREAL-MINUS
I~-PLus
i INT-~NUS
Infix-expr
:: s-opl:Expr
Infix-opr
=
I
l ~oT
s-opt:Infix-opt
s-op2:Expr
REAL-ADD IREAL-SUB I REAL-MULT I REAL-DIV I I~T-ADD
I INT-SUB I I~-MULT
s-th:Expr
I !~T-DIV
l
Cond-expr
:: s-dec:Expr
Decl Type-decl
= Type-decl I Array-decl I Switch-decl I Proc-decl :: s-id:Id s-oid:[Own-id] s-desc:Type
Array-decl Bound-pair Switch-decl Proc-decl
:: :: :: ::
s-id:Id s-oid:[Own-id] s-lbd:Expr s-ubd:Expr + s-id:Id s-el:Expr s-id:Id
s-el:Expr
s-tp:Type
s-bdl:Bound-pair +
s-tp:(Type I PROC) s-fpl:Id* s-vids:Id-set s-spm:(Id~Specifier) s-body:(Block I Code) Specifier Type-array
= Type I Type-array I Type-proc I PROC I LABEL I STRING I SWITCH :: Type
Type-proc
:: Type
Type Arithm Code
= Arithm I Boon = INT I REAL :: Tr
Tr
see
"semantic objects"
3t2
Own-id Id
infinite set infinite set
Real Int Bool
=
the set of rational numbers w i t h the usual a r i t h m e t i c
=
the set of integers
=
TRUE I FALSE
Standard-proc-name8 Real-funct-names Int-funct-name8 Prod-name8
(embedded in Real)
= Real-funat-names I Int-funct-name8 I Proc-name8 = "ab8" I "sqrt" I ,,sin,, I ,,cos,, I ,,arctan,, I ,,ln. 1 "exp" I "maxreal" I "minreal" I "epsilon" = "iabs"l "sign"J "ent er" I "l ngth"i " ax nt" i = "inchar" I "outchar" I "outstring" I "outterminator"
"stop" i "fault"1 "~nenteger" L "outinteger" I "inreal" I "outreal"
Comment:
The quotes a r o u n d the s t a n d a r d - p r o c e d u r e names indicate the t r a n s l a t e d v e r s i o n of the identifiers.
1.2 T r a n s l a t o r Notes.
A l t h o u g h n e i t h e r the c o n c r e t e syntax of A L G O L 60, nor its t r a n s l a t i o n to objects of the a b s t r a c t form are formally specified,
a number of
points should be b o r n e in mind:
-
C o n c r e t e delimiters,
comments etc. are dropped.
-
W i t h i n expressions, b r a c k e t s and rules of o p e r a t o r p r e c e d e n c e are
used tO c h o o s e the a p p r o p r i a t e tree form of "expr".
-
If the
(concrete)
it in another -
outer
b l o c k was labelled,
the t r a n s l a t o r embeds
(unlabelled) block.
The body of a p r o c e d u r e
(which is not code)
is always a b l o c k in
the a b s t r a c t form; the t r a n s l a t o r generates this b l o c k if it is not p r e s e n t in the c o n c r e t e form. -
The b o d y of a p r o c e d u r e w h i c h is code is t r a n s l a t e d into the appro-
priate state transformation.
313
-
C o n s t a n t s are, similarly,
-
The
outermost
block
t r a n s l a t e d to
(a c r e a t e d one,
(abstract)
if necessary)
values.
contains the
s t a n d a r d functions and procedures: w h e r e these cannot be e x p r e s s e d in A L G O L 60, m e t a - l a n g u a g e d e s c r i p t i o n s of the t r a n s f o r m a t i o n s are given.
-
The b o d y of the a b s t r a c t form of a for s t a t e m e n t is always a block;
if not p r e s e n t in the c o n c r e t e f o r m it is g e n e r a t e d by the translator.
-
The use of one
fiers>
list> to d e f i n e several <array
identi-
is e x p a n d e d by the translator. N o t i c e that this can no t be jus-
tified from MAR and, w i t h s i d e - e f f e c t p r o d u c i n g f u n c t i o n references the b o u n d pair list,
is s t r i c t l y wrong.
2. C O N T E X T CONDITIONS.
A n e n v i r o n m e n t is used to record s t a t i c a l l y k n o w n type information:
Static-env
= Id ~ Specifier
W i t h the e x c e p t i o n of is-wf-program,
all context conditions are,
for
a p h r a s e class 0, of type:
is-wf-@:
%
Static-enV ~ Bool
As well as the s p l i t t i n g
( " r o u t i n g ")
rules, c e r t a i n other obvious
steps have b e e n taken to s h o r t e n the functions given below,
@ :: 81 0 2 ... O n then a rule
(or part thereof)
of the form:
if-wf-g(mk-@(el,g 2 .... ,en),envj is-wf-gl(el,env)
&
i8-wf-g2(@2, env)
& .o.
is-wf-gn(gn, env) w i l l be omitted.
=
e.g.
if
in
314
2.1 is-w f Rules. is-wf-program(mk-program(b ) ) -/* for all type-decl, array-decl '8 within b, their s-¢id is unique */ & (let oads={d]within(d,b)
&
is-array-decl(d) & s-old(d) * NIL}
/* all expressions in 8-bdl of elements of oads are integer constants */) & (let env -- [n~mk-type-proc(INT) In£Int-funct-no~es ] U [~ - t y p e - p r o c ( R E A L ) InEReal-funct-names ] U [n~PROC lnEProc-names ] is-wf-b lock (b,env )) type: Program~Bool
is-wf-b lock (mk-b lock (de Zs,s t l), env) = let labl = /* list of all labels contained in stl without an intervening block */ is-uniquel(labl) & is-disjoint(<elem8 labl, {s-id(d) IdEdcls}>) & (let renv = env\{e-id(d)[d£dcle} let lenv = [s-id(d)~*(cases d: mk-type-decl(,,tp)
~ tp
mk-array-decl(,,tp,)
~ mk-type-array(tp)
mk-swi tch-dec l (, )
~ SWITCH
mk-proc-decl(,PROC,,,,)~ PHOC m k-proc-dec~(, tp,,, ,) ~ mk-type-proc(tp) )
Id£dcls] 0 [lab~LABEL llab6elems labl] let nenv = renv
U lenv
dEdcls ((is-array-decl(d)
~ i8-wf-array-decl(d, renv) ) &
(is-proc-decl(d)
~ is-wf-proc-decl(d, nenv)) &
(is-switch-decl(d) ~ is-wf-switch-decl(d, nenv)) ) & (1
315
i s-w f-as s ign-s tmt (ink-assign-strut (d l, e), env ) = 1
is-wf-goto-stmt(mk-goto-stmt(e) ,env) = expr-tp(e, env) = LABEL
is-wf-cond-stmt(mk-cond-stmt (dec, th, el), env) = expr-tp(dec, env) = BOOL
is-wf-for-stmt (mk-for-stmt( cv , cvtp,fle 1,b ) , env ) = is-simple-vat(or) is-arithm(cvtp)
& is-scalar(cv, env) &
& cvtp=var-tp(cv, env)
is-wf-expr-elem(mk-expr-elem( e ) , env ) = is-ari thm( expr-tp (e, env ) )
is-wf-whi le-elem(mk-whi le-elem( in, wh) , env ) = is-ari thm( expr-tp (in, env )) & is-BOOL (expr-tp (wh, env ) )
is-wf-step-until-elem(mk-step-until-elem(in,
st, un),env) =
is-arithm(expr-tp (in, env) ) & is-arithm(expr-tp(st, env) ) & is-arithm( expr-tp(un, env ))
is-w f-proc-des (mk-proc-des (id, ap l) , env ) -is-PROC(env(id) ) & (l
is-wf-var(v, env)
=
if is-eimple-var(v)
then is-type (env(s-nm(v) ) )
else is-type-array(env(s-nm(v) ) ) & (1<_i<_len s-sscl(v) ~ is-arithm(expr-tp(s-escl(v) (i) ,env) ) )
316
is-wf-simp le-var-bn/bv
former iff refers to by name formal parameter
i
i s-w f -subs cr-var-bn /bv ~
is-wf-label-const(mk-label-const(id),env)
= env(id) = LABEL
is-wf-switch-des (mk-switch-des (id, e), env) = env(id) = SWITCH & i8-ari thm( expr-tp (e , env ) )
is-wf-funct-des(mk-funct-des(id, aplJ,env) = is-type-proc(env(id))
&
(l
is-wf-array-name(mk-array-name(id),env)
= is-type~array(env(id))
i8-wf-switch-neone(mk-switch-name( id) ,env ) = env( id) = SWITCH
is-wf-proc-name(mk-proc-name(id),env)
= is-type-proc(env(id))
is-wf -pre f ix-expr(m~-pref ix-expr( opr , expr) ,enV ) = let tp = expr-tp(expr, env) (cases opt: NOT
~ tp = BOOL
REAL-PLUS, REAL-MINUS ~ tp = REAL INT-PLUS, INT-MINUS
~ tp = INT)
v env(id) = PROC
3t7
is-wf-infix-expr(mk-infix-expr (el, opr , e2) ~ env ) = let tpl = expr-tp(el,env) let tp2 = expr-tp(e2,env) (cases opt: REAL-ADD, REAL-SUB, REAL-MULT ~ (tpl=REAL v tp2=REAL) & is-ari~h( tpl) & is-arith( tp2) REAL-D IV
is-arith(tpl) & is-arith(tp2)
REAL-EXP
is-arith(tpl) & tp2=REAL
REAL-INT-EXP
tpI=REAL & tp2=INT
INT-ADD, INT-SUB, INT-MULT INT-DIV, INT-EXP
tpl=INT & tp2=INT is-arith(tpl) & is-arith(tp2) tpl=BOOL & tp2=BOOL_)
is-wf -cond-expr(mk-cond-exp (b , t, e ), env ) = expr-tp(b, env) = BOOL & (let tpl = expr-tp(t, env) let tp2 = expr-tp(e, env) compat-tps (tpl , tp2) )
is-wf-array-decl(mk-array-decl(,,tp, bdl) ,env) = 1<_i
is-wf-switch-decl(mk-switch-decl.(exIJjenv) 1
=
= LABEL
is-wf-proc-decl(mk-proc-decl(id, tp, fpl,vids, spm, b) ,env) = is-uniquel(fpl)
&
id E elems fpl & vids ~ elem____~sfpl & dom spm = elems fpl & (idEvlds ~ spm( id) E(TypeU {LABEL ~UType-array) ) & is-wf-b lock (b , env+ spm)
318
2~2 tp
Determinin 9 Rules.
expr- tp (expr , env ) = cases expr: BOOL
mk-boo 1-cons t () mk-int-const ()
INT
mk-rea l-const ()
REAL
mk- lab e l-cons t ()
LABEL
mk-var -ref(mk-var (var))
env (s-nm(var) )
mk-funct-des (id, )
s-type (env(id))
mk-swi tch-des ()
LABEL
mk-prefix-expr (opr,) cases opr: INT-PLUS, INT-MINUS
~ INT
REAL-PLUS, REAL-MZNUS
~ REAL
NOT
~ BOOL
mk-in f ix-expr (, opr , ) cases opr" INT-ADD, INT-SUB, INT-MULT, INT-DIV, INT-EXP
~ INT
REAL-ADD, REAL-SUB, REAL-MULT , REAL-DIV, REAL-EXP, REAL-INT-EXP ~ REAL LT, LE, EQ_, NE__,GE_, GT, AND, OR, IMPL., E#U
-" BOOL
mk-cond-expr( , t, e) le__~ttpl : expr-tp(t, env) le_~t tp2 = expr-tp(e, env) tpl = tp2
~ tpl
i8-arith(tpl) & i8-arith(tp2)
~ REAL
var-tp(v, enVs¢ = cases
~:
mk-simple-var(id, )
~ envs (id)
mk-subscr-var( id, , sscl ) ~ s-type (envs (id)
act-parmv-tp
similar to expr-tp
319
2.3 Auxiliary Functions.
compat-tps( tpl , tp2)
=
tpl = tp2 V is-arithm( tpl) & is-arithm( tp2)
type: (Type I LABEL) (Type I LABEL) ~ BOOL
is-scalar(v, env) = ie-type(env(s-nm(v))
v
is-array-type(env(s-nm(v))) & is-subscr-var(¢)
3. S E M A N T I C
OBJECTS. N
Tr
--
=
~ ~ Abn
Storage
=
(R-STG ~ Storage) - - m Sc-loc ~ Sc-val
Sc- lo c
=
Bool-loc I Real-lot I Int-loc
U
(R-CHANS ~ Channels) - - m
are disjoint,
Bool-loc, Real-lot, Int-loc Sc-va I
=
Int I Real I Bool
Channels
=
Int ~ Char s
Abn
=
[Label-den]
Stmt-env
=
(Own-env Env Aid-set)
infinite,
sets
m
Expr-env
=
(Env Aid-set)
Own-env
=
Own-id ~ (Type-den I Array-den)
Env
=
Id ~ Den
Den
=
Type-den IAtv-proc-id-den IArray-den I Proc-den I Label-den
Type-den
=
Se-loc
A tv-proc-id-den
=
Sc-loc
Array-den
=
Int + ~ Sc-lo~
Con~ traint
:
(Bipl6(Int Int)+)(doma loc=rect(ipl))
Pros-den
=
Act-parm-den ~ Aid-set ~ (2 ~ 2 Abn [Sc-val])
Act-parm-den
: : s-v:Den
m m
Switch-den I By-name-den I String
Lab e 1-den
: : Id Aid
Switch-den
=
Aid
8-tp:Specifier
Int Aid-set ~ (2 -~ ~ Abn Label-den)
infinite set
320
By-name-den
=
By-name-loc-den
: : Aid-set -~ (~ -~ ~ Loc)
By-name-loc-den I By-name-ezpr-den
By-name-expr-den :: Aid-set ~ (~ ~ Z Sc-vaZ) Loc
=
Type-den i Array-den
Abn
=
[Label-den]
Val
=
Sc-val i Label-den
Implementation-defined-const
Comment:
= ~4XINT i MINREAL I MAXREAL I EPSILON
The c o n s t a n t s are Sc-vals,
but no c h e c k is m a d e as to w h e t h e r
they are m a c h i n e representable.
4. M E A N I N G F U N C T I O N S
4.1 F u n c t i o n s from O b j e c t L a n g u a g e
i-program(p)(chans)
=
let state s = { R - S T G ~ [ ] , R - C H A N S ~ c h a n s ] let s t a t e f
= i-program1(p)(state
8)
8tatef(R-CHANS) type:
Program
~ (Channels
i-programl (mk-program(b))
~ Channels)
=
le__~town-decls = {dlwithin(d,b) & (i8-type-decl(d)vis-array-decl(d))
&
s-oid(d) • NIL} let oenv: C [8-oid(d)~e-own-type-decl(d) Id£own-decls & is-~jpe-decl(d) ] U [8-oid(d)~e-own-array-decl (d) idEown-decls & i8-array-decl (d) ]); (tixe [RET~I] i__nni-b lock (b,
Program
321
e-own-type-dec~(d) = let l:e-type-deal(d); if s-dese(d)=BOOL then assign(FALSE, l) else assign(O,l); return (5) type:
Type-decl ~ Type-den
e-own-array-decl(d) = let l:e-array-decl(d,<[~,~}>); i_~ s-tp(d)=BO0~ then for all scl6rn~l d_~oassign(FALS____~E,scl) else for all scl£rngl d_~oassign(O, scl); return (1) type:
Array-decl ~ Array-den
Standard Functions and Transput It is assumed that the translation of the standard cedures
are contained
in the
("fictitious")
tation of their proc-decl follows
functions
outer block.
and pro-
The interpre-
the normal i n t e r p r e t a t i o n
rules
(e-
proc-decl) except in the cases w h e r e the body cannot be expressed in Algol.
In these cases the state transition
explicitly Note:
of the non-Algol part is
listed below.
Referencing
the translated
identifiers we use quotes
"inreal" for the translation of the identifier inreal).
I_nn procedur e stop :
"goto ~" ~ exit(RET)
(e.g.
322
In procedure inchar:
let channel
: contents(env("c~&nnel"));
let str
= env("str")
let int
: e-left-part(mk-simple-var-bn("int"),exenv)
if channel~dom c R-CHANS then error else
(let chan:
(cR-CHANS)(channel);
if chan=
<> then error;
let char:
hdchan
let ind = i f (3i6{l:kenstr})(str(i)=char) then
(li£{l:lenstr))(str(i)=char
&
CVk6{l:i-1})(str(k)~char)) else O; R-CHANS
:= c R-CHANS [channel~tlchan];
assign(ind, int))
In procedure outchar:
<statement>
let channel
: contents(env("channel"));
let str
= env("str")
let int
: contents(env("int"));
let char
= 8tr(int)
i f channel~dom c R - C H A N S R-CHANS
then error;
:= c R-CHANS + [channel~(c R - C H A N S ) ( c h a n n e l ) ^ < c h a r >]
l_nn procedure outterminator: let channel
: contents(env("channel"));
if channel~dom c R - C H A N S R-CHANS
then error;
:= (cR-CHANS)
+
[channel~(c R - C H A N S ) ( c h a n n e l ) ^ < i m p l e m e n t a t i o n defined symbol depending
on the current
state of the channel>]
Procedures "maxint",
"minreal",
which return the appropriate
"maxreal"
and "epsilon" have bodies
Implementation-defined-const.
323
i-block(mk-block(dcls, stIJ,
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 =
I
is-contndlCtlab,stl) ] in for i=I to lenstl d_~oi-unlab-stmt(s-spCstl(i)),stenv) ) type:
Block Stmt-env
epilogue(ids,env) = Set sclocs = {env(id) lidEids & is-sc-loc(env(id))~ union{rng(envCid)JlidEids R-STG type:
U
& is-array-den(env(id))}
:= R-STG\sclocs
Id-set Env
oue-i-stmt-llst(lab,stl,stenv)
=
let i = index.(lab,stl) cue-i-stmt(lab,stl(i),stenv); ~or j = i+I to lenstl d__ooi-unlab-stmt(s-sp(stl(i)),stenv) type:
Id Stmt • Stmt-env
pre:
is-contndl(lab,stl)
324
cue-i-stmt(lab,mk-stmt(labs,sp)jstenv)
=
i_~ ~abElabs then i-unlab-etmt(sp,stenv) else cue-i-unlab-stmt(lab,sp, stenv) type:
Id Stmt Stm.t-env
pre:
is-contnd(lab,mk-stmt(labs,sp))
cue-i-unlab-stmt:
Id Unlab-stmt Stmt-env
cue-l-cond-stmt(lab,mk-cond-stmt(,th, el),stenv) = if is-contnd(lab,th)
then cue-i-etmt(lab,th,etenv)
else pre:
cue-~-stmt(lab,el,stenv) is-contnd(lab,th) v is-con.tnd(lab, el)
cue-i-comp-~tmt(lab,mk-comp-stmt(stl),stenv)
=
cue-i-stmt-liet(lab,etl, stenv)
i-unlab-stmt: Unlab-stmt Stmt-env i-comp-stmt(mk-comp-stmt(etl),stenv)
=
~.or i~I to lenstl d_~oi-unlab-stmt(s-sp(stl(i)),stenv)
i-assign-stmt(mk-assign-stmt(dl, e),<,env, cas>) = let dl:<e-left-part(s-tg(dl(i)),<env,cas>)ll
e-expr(e,<env, cae>);
for i=I to lendl d_~o (let vc:conv(v,s-tp(dl(i))); aseiEn(va,dl(i)))
e-left-part: Left-part Expr-env ~ Sc-loc
e-atv-proc-id(mk-atv-proc-id(id),<env,>)
= env(id)
325
i-goto-stmt(mk-goto-stmt(e)j<,env,
cas>)
let ld:e-expr(e,<env,cas>); exit(ld)
i-dummy-stmt(t,stenv)
= I
i-cond-stmt(mk-cond-stmt(dec, th, el),stenv) let <,env, cas> = st-env let b:e-expr(dec,<env, cas>); i_~ b then i-unlab-stmt(s-sp(th),stenv) else
i-unlab-stmt(s-sp(el),stenv)
i-for-stmt(mk-for-stmt(cv, cvtp,flel,b),stenv)
=
~Or i=1 t__oolenflel d__ooi-for-list-elem(flel(i),cv, cvtp,b, stenv)
i-for-list-elem:
For-list-elem
Var Type Block Stmt-env
i-expr-elem(mk-expr-elem(e),cv, cvtp,b,etenv) let <,env, cas> = stenv
=
let v:e-expr(e,<env, cas>)~ let vc:conv(v, cvtp)~ let l:e-var(cv,<env, cas>); assign(re, l); i-block(b,stenv)
i-while-elem(mk-while-elem(in,wh)ocv, let <,env~cas> = stenv while (let v:e-expr(in,<env, cas>); let vc:conc(v, cvtp); let l:e-var(cv,<env, cas>); assign(vc,1); let b:e-expr(wh,<env, cas>); b
) d_~o
i-block(b,stenv)
cvtpjb,stenv)
=
326
i-step-until-elem(mk-step-until-elem(in,8t,un),cv,
cvtp~b,stenv)
let <,env,ca8> = 8tenv let exenv = <env, ca8> let vin:e-exprCin, exenv); le% vinc:conv(vin, cvtp); let l:e-var(c~,exenv); assign(vinc, 1); while
(let vst:e-expr(st, exenv); let b:e-expr(untest, exenv); b ) do (i-block(b,stenv); let vcur:contents(1)+vst; let vcurc:conv(vcur, cvtp); assign(vcurc, l))
note:
"unrest"
is a n Expr c o r r e s p o n d i n g
to
~cV-un)xsignvst~O ~
i-proc-stmt(mk-proc-stmt(desJ,<,env,cas>)
=
c~ses des: mk-proc-des(id, apl) (le__~t denl = <e-act-parm(apl(i),env)II~i~lenapl> let f = envCid) f(denl,cas)) T ~ (let v:e-funct-des(d~s,<env, cas>); i)
e-expr: Expr Expr-env ~ Val
e-bool-const(mk-bool-const(b),)
= return(b)
e-real-const(mk-real-const(r),)
= represent(r)
e-int-aonst(mk-int-eonst(i)j)
= test{i)
=
327
e-var-ref(mk-var-ref(v),<envjcas>)
=
i_~ is-simple-var-bv(v) vis-subscr-var-bv(v)vis-by-name-loc-den(env(s-nm(v)) then
(let l:e-var(v,<env,cas>);
else
(let bned = env(s-nm(v))
contents(1)) bned(cas))
e-var:
Var Expr-env
~ Sc-loc
e-simple-var-bn(mk-simple-var-bn(id),<env,
cas>)
=
let bnd = env(id) i_~ is-by-name-loc-den(bnd)
then bnd(cas)
else error
e-simple-var-bv(mk-simple-var-bv(id),<env,>)
e-subscr-var-bn(mk-subscr-var-bn(id, let, esscl:e-subscrl(sscl,<env,
= env(id)
sscl),<env,cas>)
=
cas>);
let bnd = env(id) i_f is-by-name-loc-den(bnd)
then
(let aloc:bnd(cas); i_~ essclEdomaloc
then return
(aloc(esscl)J
else error) else error
e-subscr-var-bv(mk-subscr-var-bv(id, 1,#,t esscl:e-subscrl(s~cl,<env, let a l o c =
env(id)
i_~ esscl£dRmaloc else error
sscl),<env, cas>)
cas>);
then return
(aloc(esscl))
=
328
~-subscrl(sscl, exenv) let esscl:<(let
=
essc:e-expr(sscl(i),exenv);
let i:conv(essc,~NT); i return type:
)11
(esscl)
Expr • Expr-env ~ Int ~
e-label-const(mk-label-const(id),<env,>)
= return(env(id~
e-switch-des(mk-switch-des(id, ssc),<env, cas>) = let ess:e-expr(ssc,<env, cas>); let i:conv(ess,INT); let f = env(id) let ld:f(i,cas); return
(ld)
e-funct-de~(mk-funct-des(id, apl)~<env, cas>) = let denl = < e - a c t - p a r m ( a p l ( i ) , e n v ) I I < i < l e n a p l > let f
= env(id)
let v:f(denl,cas); return
(v)
e-act-parm(mk-act-parm(e,tp),env) let d = e-act-parmv(e,env) mk-act-parm-den(d,tp) type: A c t - p a r m Env ~ A c t - p a r m - d e n
e-act-parmV:
Act-parmv
Env ~ Den
=
329
e-parm-expr(mk-parm-expr(e),env) is-var-ref(e)
=
then
(let f(dcasJ = e-var-ref(e,<env,dcas>) mk-by-name-loc-den(fJ J else (let f(dcas) = e-expr(e,<env,dcas>) mk-by-name-expr-den(f) )
e-array-name(mk-array-name(id),envJ
= env(id)
e-switch-name(mk-switch-name(id),env)
e-proc-name(mk-proc-name(id),env)
= env(id)
= env(id)
e-string(s, env) = s
e-prefix-expr(mk-prefix-expr(opr, eJ,exenv) = le__~tv:e-expr(e, exenv); apply-prefix-opr(opr, v)
e-infix-expr(mk-infix-expr(el,opr, e2),exenv) = let vl:e-expr(el,exenv); let v2:e-expr(e2, exenvJ; apply-infix-opr(opr, vl,v2)
e-cond-expr(mk-cond-expr(b,t,e),exenv) i_~ e-expr(b, exenv) then e-expr(t, exenv) else e-expr(e, exenv)
=
330
Comment:
The evaluation of infix expressions
is from left to right.
Since IntcReal no explicit conversion from integer to real is necessary in infix and conditional expressions.
represent(r)
=
if -MAXREAL
v
M I N R E A L < r < MAXREAL
v
r=O then return
(an i m p l e m e n t a t i o n defined a p p r o x i m a t i o n of r)
el8e error
type:
Real ~ Real
test(i) = if -MAXINT
type:
Int ~ Int
a p p l y - p r e f i x - o p r ( o p r , v) = OpT:
dase8
NOT REAL~PLUS, REAL-MINUS)
type:
~ returnC~v) INT-PLUS
~ ~,eturn(v)
I N T - M I N U S ~ return(-v)
P r e f i x - o p r Sc-val ~ Sc-val
331
apply-infim-oprCopr, v,w) = cases opr: REAL-ADD
represent(v+w)
REAL-SUB
represent(v-w)
REAL-MULT
represent(v~w)
REAL-DIV
~i_~wcO then fault1 else represent(v~represent(1/w))
REAL-EXP
if v>O then value of the standard function applied on represent(v'value
exp
of the
standard function In applied on w) else fault2 REAL-INT-EXP
~ i~ v=O & w=O then fault$ else (let expn(n) = i_~ n=O then I else represent(expn(n-1)~n.
i_L w~o then expn(w) else represent(1/expn(-w)) INT-ADD
test(v+w)
INT-SUB
test(v-w)
INT-MULT
test(v~w)
INT-DIV
i_f w=O then fault1 else test(v/w)
INT-EXP
~if
w
v w=O
then fault4 else
(let expi(n)
= if n=O then 1 else test(expi(n-1)~v)
return(ezpi(w)) LT
return(v<w)
LE
return(v<w)
E_QQ
return(v=wJ
NE
return(v#w)
GE
re~urn(v>w)
GT
return(v>w)
IMPL
return(v~w)
332
type:
Comment:
EQU
~ return(V~w)
AND
~ return(v&w)
OR
~ return(vvw) Infix-opr Sc-val Sc-val ~ Sc-val
fault1 r e p r e s e n t s
the s t a t e
to the call:
faults N fault('expr
which
corresponds
fault('div by zero'~v) undefined',v)
fault3 ~ fault('expn
undefined',v)
fault4 ~ fault('expi
undefined',w)
e-type-decl(mk-type-decl(,,tp)) type:
transition,
= gen-sc-den(tp)
Type-decl ~ Sc-loc
e-array-decl(mk-array-decl(,,tp, bdl),exenv)
=
let ebds:<(let v:e-expr(s-lbd(bdl(i)),exenv); let lbd:conv(v,INT); let w:e-exprCs-ubd(bdl(i)),exenv); let ubd:conv(w,INT); i~ v>w then error;
Comment:
It is a s s u m e d ments
that the g e n e r a t i o n
is erroueous,
rather
of an array w i t h o u t
than the access
ele-
to such an array.
883
e-switch-decl(mk-swgtch-decl(,exl),env)
=
let f(~nd, cas) = (i_~ 1 ~ i n d ~ l e n e x l
then e - e x p r ( e x l ( i ) , < e n v , oas>)
else error )
f type:
Switch-decl
Env ~ S w i t c h - d e n
e-proc-decl(mk-proc-decl(id, let f(denl,cas)
tp,fpl,vids, spm, b),oenv, env) :
=
(if lendenl
# lenfpl
v
(3i£{l: ~enfpl} ) (~is-parm-ok(denl(i) ,spm(fpl(i) ),fpl(i)Evids) ) then error else
(let nenv:env+ ([fpl(i)~s-v(denl(i) ) [l
then
[]
[id~gen-sc-den(tp)]));
cases b: mk-code(tr)
~ tr
T
~ i-block(b,
cas>)
epilogue ({fpl (i) 11
f type:
Proa-decl
Own-shy
Env ~ P r o c - d e n
334
is-parm-ok(
iZ
bv then
(spa=spfv is-arithm(spf) & i8-arithm(spa) v is-type-array (spf) & is-type-array (spa) & is-arithm(s-type (spa)) & i8-arithm (s-type (spf))) else ( spa=spry spf=PROC & is-type-proc(spa) v is-type-proc (spf) & is-type-proc (spa) & is-arithm(s-type (spa)) & is-aritk~(s-type(spf) )) type:
Act-parm-den
Specifier
Bool ~ Book
e-val-parm(den, sp, cas) = cases sp: mk-type-array(tp) (let aloc:gen-array-den(domden,
tp);
for essck£domden d__oo (let v:contents(den(essck)); assign(v,aloc(esscl))); return(aloc)) LABEL ~ den(cas) T (let v:(if is-by-name-expr-den(den)
then den(cas)
else (let l:den(cas); contents(1))); let vc:conv(v, sp); let l:gen-sc-den(sp); assign(vc, k); return(k)) type:
Den Specifier Aid-set ~ Den
4.2 A u x i l i a r y F u n c t i o n s
is-contnd: is-contndl: Comment:
Id Stmt ~ Book Id Stmt ~ ~ Bool
Two obvious functions for c h e c k i n g w h e t h e r the g i v e n identifier is c o n t a i n e d in the label part of a
(contained)
w h i c h is not c o n t a i n e d in an intervening block.
statement
335
index:
Id Stmt ~ ~ Nat
Comment:
For
identifiers
finds ment
list also
within(so,o) /~
Comment:
True
True
rect(ipl)
Object
disjoint
= & (l
(Int2) + ~ (Int+)-set l
~ ipl(i)(1)
a s s i g n ( v , lJ = := c R - S T G + [ l ~ v ]
Sc-val
contents(l)
So-lot
=
if c R - S T G ( 1 )
type:
o f o ~/
( O b j e c t - s e t ) • ~ Bool
type :
else
the identifier.
iff sets are p a i r w i s e
= ? then
c R-STG(1)
Sc-loc
~ Sc-val
error
~ ipl(i)(2J
function
of the state,
~ Bool
pre:
type:
this
element
iff no d u p l i c a t e s
~illlenil=lenipl
R-STG
"is-contndl"
O b j e c t • ~ Bool
is-disjoint:
Comment:
contains
i f so is a s u b - p a r t
Object
is-uniquel:
satisfy
such that the i n d e x e d
=
checks
type:
which
the index
33G
conv(v,tp) = if tp=INT then test(rounded value of v) else return(v)
pre:
is-hoof(v) ~ tp=BOOL is-real(v) ~ is-arith(tp)
gen-array-den(indls,tp)
=
let d e n : C i n d l ~ g ~ n - s c - d e n ( t p ) lindlEindls ~ return(den)
type:
Int+-set Type ~ A r r a y - d e n
gen-sc-den(tp)
=
let locE(cases
tp:
BOOL ~ Bool-loc REAL ~ R e a l - l o c INT R-STG
:= c R-STG
~ Int-loc) U [loc~];
return(loc)
type:
Type ~ Sc-loc
be s.t.
locEdom a R-STG
337
SOFTWARE ABSTRACTION PRINCIPLES: TUTORIAL EXAMPLES OF AN OPERATING SYSTEM COMMAND
LANGUAGE SPECIFICATION AND A PL/I-LIKE ON-CONDI= TION LANGUAGE DEFINITION
Dines Bj@rner
Abstract: Four groups of two, either complementing or contrasting abstraction principles are isolated: OPERATIONAL abstraction; CHICAL abstraction; TRANSPARENT,
REPRESENTATIONAL
and
CONFIGURATIONAL versus HIERAR=
STATE-MACHINE- versus REFERENTIALLY
FUNCTIONAL- abstraction;
versus MECHANICAL specification.
and DENOTATIONAL
Tools,
techniques and
examples are presented for, respectively of, each of the eight principles.
CONTENTS i.
2.
Introduction
339
-- On Abstraction Techniques
339
Example I: An Abstract Processor for an Interactive, Operating System Command Language
3.
344
A. Syntactic Domains
344
B. Semantic Domains
346
C. Semantic Domain Consistency Constraints
349
D. Dynamic Command / State Consistency Constraints
350
E. Elaboration Function Types
353
F. Elaboration Function Definitions
354
G. Auxiliary Function Types
357
H. Auxiliary Function Definitions
358
Example II: A PL/I-like On-Condition Language
360
A. Syntactic Domains
360
B. Static Context Condition Function Types
361
C. Auxiliary Text Function Types
361
D. Static
361
(Compile-time)
Domains
E. Static Context Conditions
361
F. Auxiliary Text Functions
364
G. Semantic Domains
364
H. Global State Initialization
365
I. Elaboration Function Types
365
J. Auxiliary Function Types
365
K. Semantic Function Definitions
366
Comment
372
Discussion
372
Acknowledgements
374
339
1. INTRODUCTION
The problem to be solved by the methods outlined in this paper is ultimately the construction of correctly functioning, well-understood, pleasing,
yet complex software.
It is our thesis that one way of achiev-
ing this is to use a systematic software development method which provides a formalized structure for stepwise,
increasingly more detail-
ed arguments of correctness -- a method based on systematically deriving abstractions
into concrete realizations;
i.e. on a-priori,
tic, constructive proofs rather than a-posteriori,
synthe-
analytic proofs.
Thus we see our methodology as starting with an abstract specification of the desired software item. This paper then is concerned with some of the techniques used in achieving such definitions. we cover the problems of mapping abstractions
In [Bj~rner 77c]
into concretizations.
We are there in particular concerned with the systematic derivationand proof techniques.
The objectives of an abstract software specification are basically twofold: that the resulting document serve as the basis from which an implementation take place formally,
and with respect to which correctness
criteria be stated, and a proof given. Hence we require that the specification
(or: meta-)
language be formal. Also:
that the document,
and
it alone, be the specification from which we develop user's reference (and other) manuals~
The objectives of the abstraction principles explicitly expounded in this paper are several: dictory and complete;
That the specifications be precise, non-contra-
that they be short, well-organized and comprehen-
sible; that the described systems be well-conceived, ceptions,
conceptually clean,
relevant notions;
free from mis-con-
lean and with an optimum of semantically
that their properties be well understood,
possesing
desirable properties and with a minimum of ad-hoc ideas. We find [Liskov 75] to give a fine discussion of the above points.
O nnAbstraction Techniques Before going on to exemplify uses of the meta-language
let us first
also summarize the principles used in applying constructs of this language. One thing is the notation:
its syntax & semantics. Another thing is
the intent with which it was to be applied;
its pragmatics. Any notation
can be used against its will, even a good one.
340
If you consider META-IV as an ultra-high-level
programming language,
i.e. one which although it is intended only to specify software actually results in programs which can be considered implementations, beit on a very abstract,
and in most cases not mechanizable,
al-
level, then
which are the programming disciplines around which the meta-language evolved,
and whose application exploits its capabilities
to the fullest?
We consider these to be the pre-dominant abstraction techniques: sentational- & operational- abstraction; cal abstraction; modeling;
repre-
configurational vs. hierarchi-
referential transparency vs. abstract state machine
and mechanical- vs. denotational abstraction.
At each design step and at each specification stage we carefully review the appropriateness
of each abstraction choice:
ing e.g. representationaltional abstractions;
& operational;
its level when consider-
and mechanical- vs. denota-
its mixture or blend of configuration and hierac-
chy, i.e. bottom-up synthetic vs. top-down analytic features; respectively of referential transparency or applicativeness vs. abstract state machine imperativeness;
and finally also its balance of explicitness
vs. implicitness. Before going into a brief characterization of each of the eight abstraction principles,
an outline is first given of the basic parts that make
up our specification document. A rationale is given for their inclusion. The software outputs,
'function'
to be modelled normally accepts inputs, emits
achieves the desired transformations of inputs into outputs
by means of internal data structures, terms of function definitions
and specifies transformations
(procedures, process descriptions,
in
opera-
tions). Our model hence consists of two basically distinct parts: one containing the descriptions of the input/output and internal domains -- subsequently referred to as syntactic-,
respectively semantic domains.
Another part containing a number of elaboration-
(and auxiliary-)
func-
tion definitions which to combinations of input- and semantic- domain objects ascribes their meaning,
in terms of either semantic domain ob-
ject transformations or these latter combined with output domain objects. In the next paragraphs we now treat the abstraction principles individually.
341
By REPRESENTATIONAL ABSTRACTION we understand the specification of objects irrespective of their implementation,
and such that the chosen
abstractions as closely as possible only r e f l e c t
relevant and intrin-
sic properties. Representational
abstraction of classes of objects is here expressed
in terms of so-called abstract
syntax.
Individual
instances of objects
can be abstracted by corresponding expressions of the meta-language. Representational
abstraction is applie d in the definition of both syn-
tactic- and semantic- domains and domain objects.
By OPERATIONAL ABSTRACTION we understand the specification of functions in extension.
That is: we are primarily interested in the properties of
the functions we define,
notably in the properties of that which our
defined functions define
(be they functions themselves),
they Compute; puted,
i.e. in what
less -- if at all -- interested in how results are com-
i.e. not in functions
in extension.
Operational abstrection is here expressed primarily in the form of function definitions. We express these either by a pair of pre- and postconditions on the functions sought, or by a constructive function definition. The former kind are thus usually more implicit, than the latter kind
(of more explicit definitions).
is normally still abstract,
i.e. abstract,
This latter form
in that it usually internally employs ope-
rational abstraction on representationally
abstract objects. Operational
abstraction is used in the definition of the elaboration functions,
as
well as functions of our model auxiliary to these, and to (~8-w~-O) well-~ormednessdicates
context,
'narrowing'
static condition and dynamic constraint-,
pre-
the (~-) domains otherwise defined by abstract syn-
taxes.
By CONFIGURATIONAL ABSTRACTION we understand the step-wise definition and realization of a model, or major model components, which proceeds in a synthetic manner in conceiving and documenting the desired system -- from the bottom-up -- by building layers of abstraction upon more concrete bases. From 'virtual machines':
'physical machines' we create changing raw capabilities
(the illusion of)
into sophisticated con-
cepts. Configurational abstraction composes low-level abstractions rather
'mechanizations')
Configurational
(or
into higher-level abstractions.
abstraction,
in its inner, foundational steps,
ally expresse d in rather concrete representational-
is usu-
and operational
842
forms. In its outer,
so-called
'abstract'
layers, expressional means
are normally tied to those of the procedure, module-, 'abstractions'. nique
and class- like
Configurational abstraction -- as a specification tech-
-- is brought into play whereever uncertainties concerning either
desired functions,
and/or efficient realizability dominate our under-
standing of what system we are in fact aiming at. The resulting design:
its abstraction & implementation can usually,
and
to great advantage however, be hierarchically documented. By HIERARCHICAL ABSTRACTIO N we understand the stepwlse definition of a model which proceeds in conceiving and documenting, fashion -- from the top down -- the desired system
in an analytical (components)
by
decomposing basic overall dominating concepts and transformations
into
constituent ones. Hierarchical abstraction techniques can fully exploit the representational and operational abstraction techniques descussed and elsewhere illustrated in this paper. And hierarchical abstraction is applied where a sufficiently deep understanding of our system has eventually transpired. Configurational abstraction have been used extensively in operating systems designs
[Dijkstra 68; Hansen 73] - Hierarchical abstraction
mostly in e.g. programming language semantics 78] and relational data base
[e.g. Beki{ 74~ Henhapl
(system and query language)
formalization
[Hansal 76, Nilsson 76]. Any one abstraction,
and almost any actual, conventional program al-
gorithm, usually exhibits some mixture of both. Only when the choice between configurational- and hierarchical abstraction has been made as the consequence of a careful study, and only when the resulting documentation
(respectively program code)
appear transparent. down abstract,
is clear, does the specification
The subject of choosing a bottom-up versus a top-
and/or algorithmic design idea programming strategy is,
however, a seriously undeveloped one and we shall unfortunately not contribute much to a clarification in this paper. It is our hope, to return later to a study of their
duality. Step-wise refinement,
though, i.e.
top-down, hierarchical abstraction in program algorithm and data structure design is extensively convered in [Wirth 71,75,76].
343
By a DENOTATIONAL
SPECIFICATION [Scott 71,72; Tennent 75,76; Mosses
75; Milne 76] we understand a definition which ascribes meaning to (composite)
syntactic domain objects by
functionally composing mean-
ings of proper constituent parts. Thus denotational abstraction almost invariably calls for
'homomorphic'
programming
[Burstall 69, Morris 73~
Reynolds 74, ADJ 77], i.e. referential transparency together with syntactic object
'driven' function specifications.
And denotational defi-
nitions achieve their characteristics by employing semantic domain objects of high, struct)
functional order. Thus the meaning of a program
is generally seen as a state transformation function,
transformer,
independent of program
By a MECHANICAL ABSTRACTION
(cona state
(input) data.
(which may hardly be an abstraction at ail~)
we understand a description which assigns meaning to a program struct) by explicitly prescribing computation
(i.e. state-)
(con-
sequences
given input data, thus computing result values. The meaning then becomes the state transition sequence, not the function from begin states to end states. A mechanical definition is said to be so rational)
since its direct realization is immediate
(or to be ope-
(and programmable
in most languages).
Examples We now illustrate some of the abstraction techniques through two examples. The software item to be specified in section 2 is a command language for an operating system -- naturally: strative nature. non-trivial
of hypothetical, illu-
In section 3 we give the denotational
language with PL/I-like On-Conditions.
principles examplified are these: representationalabstraction;
functional,
semantics of a
The abstraction and operational
referentially transparent abstraction in sec-
tion 2, and abstract machine/state programming featuring both local and global states, and local semantic domain objects and almost exclusively:
denotational semantics, whereby the model is
almost invariably forced to be hierarchically
It is, however,
in section 3. Finally,
specified.
an alltogether not un-important aim also to convince
you of the utility of abstractly specifying software in general, -- to take the first choice as an example, professional paper proposals
and
to suggest that future,
for e.g. command- and data base query lan-
guages be formally, hence precisely stated.
344
The p r e s e n t a t i o n s are b o t h a c c o r d i n g to our basic principle: first, and then their n a t i o n a l / n a t u r a l
formulae
language e x p l i c a t i o n i m m e d i a t e -
ly subsequent. No i n t r o d u c t i o n s m o o t h l y
'tricking' you into a subse-
q u e n t f o r m a l i s m -- as if to excuse this latter!
2. EXAMPLE I: A n A b s t r a c t Processor
for an Interactive,
O p e r a t i n g S~ste m C o m m a n d L a n g u a g e
A. S y n t a c t i c D o m a i n s
1
Cmd
=
~n I c~g I Dl
2
In
::
(InputlSourceILink)
3
Id
:
c l cL I cLc i L J
4
C
::
Cid
5
CL
::
6
CLG
::
l
(SoureeIId)
[Id]
Cid
(SourceIId)
[Id]
(LinkIId)
[Id]
aid
(SourceIId)
[Id]
(LinklId)
[Id] [Id]
7
L
::
Id
(LinkIId)
8
LG
::
Id
(LinklId
9
@
::
i0
Dl
::
(InputlId)
[Id]
(InputlId)
Id
(InputlId)
Id
Annotation
1
A job control Command is either a file Input d a t a command, a (partial or complete)
C o m p i l e - l i n k - g o command,
or
(I)
or it is a D e l e t e
file command.
2
An Input command has two parts:
Input,
Source
the d a t a p a r t c o n t a i n i n g either
or Link d a t a itself,
and the part w h i c h I d e n t i f i e s
the file name to ~e given to this data.
3
A C o m p i l e - l i n k - g o command is either a COMPILE,
COMPILE-LINK-GO, 4
a LINK,
a COMPILE-LINK,
a
a LINK-GO or just a GO command.
A COMPILE con~nand has three parts: one part I d e n t i f i e s a Compiler, another either d i r e c t l y c o n t a i n s the Source a text nal
(in the FILE
state component,
text or I d e n t i f i e s such
see below),
and a third, optio-
([]) p a r t I d e n t i f i e s the name to be given to the o b j e c t
(module)
r e s ~ i t i n g from c o m p i l a t i o n and to be o p t i o n a l l y stored in the FILE.
345
A CL@ command a d d i t i o n a l l y has a c o m p o n e n t w h i c h is either the Link d a t a itself or I d e n t i f i e s such a link d a t a file, a c o m p o n e n t w h i c h o p t i o n a l l y I d e n t i f i e s a file name for the linked load
(module) r and
a c o m p o n e n t w h i c h either is the Input d a t a for the e x e c u t i n g load module,
or I d e n t i f i e s such an input d a t a file.
Comments concerning Abstraction Principles
O b s e r v e that we h a v e attempted only to d e s c r i b e s y n t a c t i c a l l y essential c o m p o n e n t s of c o m m a n d s -- and then o n l y abstractly,
i r r e s p e c t i v e of
their p o s s i b l e w r i t t e n forms:
"ALGOL" c o m P i l e "SID" w i t h
link
["FID" ~ "PRINT"]
and e x e c u t e
with
"DID"
Thus we h a v e as far as p o s s i b l e avoided any m e n t i o n of w h a t the c o m m a n d s effect,
i.e. their m e a n i n g . Of course, your p r e v i o u s technical know-
ledge may a l r e a d y h a v e initiated some p e r s o n a l
'feel' for w h a t they
m i g h t stand for. This is b e c a u s e I h a v e chosen s u g g e s t i v e mnemonics. I could as w e l l h a v e c h o s e n x's, y's and z's, and still o b t a i n e d e x a c t l y the same d o m a i n s of m a t h e m a t i c a l objects. O n l y w h e n I deal w i t h concepts for w h i c h there either is no previous
f a m i l i a r i t y or w h i c h may
be a m b i g u o u s l y u n d e r s t o o d w h e n a p p l y i n g only an i n t u i t i v e u n d e r s t a n d ing, i.e. w h e n not r e a d i n g the entire model, o r d i n a r y care in my annotations,
shall I h a v e to take extra-
and in j u d i c i o u s l y k e e p i n g these and
the d i s c u s s i o n w i t h i n p u r e l y syntactic domain,
purely s e m a n t i c domain,
r e s p e c t i v e l y p u r e l y semantic Elaboration f u n c t i o n subject boundaries.
The commands h a v e b e e n r e p r e s e n t a t i o n a l l y abstracted. here about p o s i t i o n a l parameters,
no talk of d e l i m i t e r s or o t h e r syntactic by this a b s t r a c t syntax and Link,
see below)
'sugar'. The objects denoted
(for a d e f i n i t i o n of Id, Cid, Input,
are in fact m a t h e m a t i c a l ,
Source
not c h a r a c t e r s t r i n g s .
We use the same kind of a b s t r a c t syntax d e f i n i t i o n a l c i f y i n g both syntactic and semantic d o m a i n objects, definiens
There is no word
m n e m o n i c k e y w o r d s nor of d e f a u l t such,
f a c i l i t y for speas well as their
logical type e x p r e s s i o n s are used in type d e f i n i t i o n s
Elaboration- and A u x i l i a r y functions.
for
348
The p r e s e n t a t i o n a l structure of this abstract syntax is b a s i c a l l y hierarchical.
B. S e m a n t i c Domains
1
~
::
FILE
2
FILE
=
Id
3
SYS
=
Cid
~
Comp
4
UTIL
=
Uid
~
(Data
Input
5
Data
=
6
Input
=
7
Source
=
SYS ~
UTIL
Data
I QUOT~)
I Source
I Object
Link
I Load
~d~
i ''~
. ° .
8
Object
=
Link
9
Link
=
Id
~
Input ~ (~ ~ (~
~
Load (Id
I Con~t)
i0
Load
=
ii
Output
=
12
Comp
=
Source ~ (Object
13
Cid
=
FORTRA~
Output)
o , .
14
Uid
=
15
Text
=
...
16
Id
=
TOKEN
I ALOOL
I Text)
I COBOL
Annotations
In order to explain the m e a n i n g of our o p e r a t i n g system job c o m m a n d and c o n t r o l language we i n t r o d u c e an a b s t r a c t state space Z. A state, ~£Z, has three components:
a FILE-,
a S Y S t e m programs-,
and a UTILity
object.
2
A FILE o b j e c t is a finite d o m a i n file names)
to Data
(= ...) map from I d e n t i f i e r s
(i.e.
(-sets).
The S Y S t e m object is a ... map from names to the C o m p i l e r s themselves.
(here only:)
Compiler identifier
(Subsequently we m i g h t contem-
plate adding other systems programs to SYS: sort-, copy-, merge-, etc..) T h e UTILity c o m p o n e n t is a ..o map from i d e n t i f i c a t i o n s of Utilities to either Data or lists
(~) of QUOTations
w i s h to think of as c h a r a c t e r s t r i n g s ) .
(objects w h i c h you may
347
5
Besides Input-,
Source- and Link- Da~a (which can be d i r e c t l y in-
serted into the FILE by the c o m m a n d l a n g u a g e user) Object- and
Load c a n be filed
(as the r e s u l t of s u c c e s s f u l l y e x e c u t i n g one of
the C o m m a n d s C, CL, CLG r e s p e c t i v e l y CL, CLG, L, LG).
An Object
(module)
is a map from Link to Load.
(That is: the result
of a c o m p i l a t i o n is to be a n o b j e c t of type Object. The free identifiers of the
(compiled)
Source text h a v e not yet b e e n b o u n d to their
m e a n i n g -- w h i c h a r e to be those of I d e n t i f i e d
filed Data
(names of)
or Constants.)
9
Link is a ... m a p from (free) I d e n t i f i e r s Identifiers
I0 A Load
(of filed Data)
(module)
(of (compiler)
texts)
to
or Constants.
is a f u n c t i o n from Input to
s t a t e transforming func-
t i o n s y i e l d i n g Output.
12 A(ny)
Compiler is a (pure, i.e. not state, ~6Z, dependent)
from Source to the u n i o n
(I) d o m a i n of Object and Text
are to be the result of s u c c e s s f u l tactically,
and o t h e r w i s e erroneous,
function
(-- the former
c o m p i l a t i o n the latter of a syntext
(instead y i e l d i n g diagnos-
tics Text)). 13 S u g g e s t s p o s s i b l e compilers~
14 The UTILity c o m p o n e n t s are h e r e p r i m a r i l y intended to porary r e s u l t s i n / b e t w e e n the C-L-G steps;
clg, compile a n d bind f u n c t i o n d e f i n i t i o n s below.
16 I d e n t i f i e r s are further u n s p e c i f i e d TOKENs.
'store' tem-
for d e t a i l s see the Elab-
348
Comme n t s
on A b s t r a c t i o n
Suggests
or relies
primitive
on a c o n f i g u r a t i v e
components
conjecture
is b u i l t a more
Suggests
goes,
sophisticated.
from the m o r e The user -- we
as far as c o n c e p t u a l
not need to k n o w of its decomposition.
not o n l y a h i e r a r c h i c a l
Comp and Load objects as primitives. highly
abstraction:
-- need t h i n k only of ~, and does,
understanding
8-10,12
Principles
decomposition,
but relies
on
T h e s e are r e p r e s e n t a t i o n a l l y
abstracted.
Discussion
of A b s t r a c t i o n
Choices
Comp and Object. That of Load -Link -- we c o n s i d e r almost trivial. A n t i c i p a t i n g s u b s e q u e n t s e m a n t i c Elaboration f u n c t i o n d e s c r i p t i o n s -The c r u c i a l
abstractions
and to an even
which,
of course,
semantic
are
lesser degree
these:
that of
r e a l l y were d e v e l o p e d
domain definitions
in
'parallel'
-- we h i n g e our m o d e l
with
the above
on the ability
of the
Compiler to produce e x a c t l y a f u n c t i o n of the logical type Object (disr e g a r d i n g here d i a g n o s t i c Texts). W i t h the types we have a s c r i b e d to Object, and in p a r t i c u l a r to Load, it can be shown that the Compiler in fact
is the f u n c t i o n
notational
semantics
denoted
definition,
by an a p p r o p r i a t e ~, of the
mathematical-
Source language.
or de-
~ is to
Sburce text and p r o d u c e a f u n c t i o n w h i c h permits an act of binding. Binding is a f u n c t i o n w h i c h takes an Object m o d u l e and some Link Data and p r o d u c e s some Load module. ~ creates this f u n c t i o n by letting the free I d e n t i f i e r s of the Source text be m a p p a b l e to a v a r i e ty of Constants or FILE Data Identifiers: take the
Example:
fid-i l~ fid-i2 1
Lp.::kn i
I
load-i
fid-inJ
obj-k load-i pid... fid...
6 Object 6 Load 6 Id 6 Id
I
~
idl idl
fid-j l7
LPi "dn
rid-SnJ
lid-j21
load-j end example.
s4g
In fact, we can impose v a r y i n g degrees of easily formalizable, tersely e x p r e s s i b l e c o n s t r a i n t s on Object's
hence
and Link's:
C. S e m a n t i c Doma~in C o n s i s t e n c y c o n s t r a i n t s
Simple, Lax Version:
1.0
.i
is-wf-~(mk-~(f,s,u))= (Yo£rn~ f)
.2
(is-Object(o)
= (Vl1~12
£ dom o)(dom
D (¥11,12
£ dom o)
ll = dom 12))
R e s t r i c t i v e Version:
2.0
.i
is-wf-Z(mk-Z(f,s,u))=
(vo£rn~ f)
.2
(is-Object(o)
.3
((dom
11 = dom l~)
.4
^Crng
ll~Const c dom f)))
.5
^(V16rn~
.6
f)
(is-Link(1)
D
(rn~ l~Const c dom f))
Annotations:
(1.0-1.2 ~ 2.0-2.3)
2.1-2.4
For each Object, o, in fILE
domain
it m u s t be the case that all of its
links have the same domain of
tifiers -- since, naturally,
(free Source
that object,
just one c o m p i l a t i o n of e x a c t l y one Source these free I d e n t i f i e r s to d i f f e r e n t fiLEd
text)
Iden-
o, is the result of text.
(But: b i n d i n g
Data and Constants
should c e r t a i n l y create d i s t i n c t Load modules,
cf. example
above.)
2.4
-- A n d range I d e n t i f i e r s of Object r e s t r i c t i v e version)
Data. 2.5-2.6
-- Similar for fiLEd
m o d u l e Link's
already have b e e n d e f i n e d
Data.
must
(in this
(i.e. fiLEd
350
Comments on Abstraction Principles The domain consistency
(inspection)
functions are operationally ab-
stracted in terms of applicative, referentially transparent expressions exploying quantified predicates,
i.e. staying aloof of order of inspec-
tion~
D. Dynamic Command-State Cpnsistency/Cpnstraint Relations 1 0 1 2
pre- Elab-cmd(
=.~
i__nn
cases cmd:
3
(mk-In(,id)
-~ id N6 d o m f ,
4
mk-Dl(id)
-~ id 6 dom f ,
5
T
-~ p r e - E l a b - c l g ( < c m d , s>))
351
2.0 .I .2 .3
pre- Elab-c lg(
.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)"
•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.
