Programming D.

Gries
Languages Editor

Protection in
Programming
Languages
James H. Morris Jr.
University of California

Linguistic mechanisms which can be used to protect 1. Introduction

one subprogram from another's malfunctioning are
described. Function-producing functions and various The ability of a programming language or system to
type-tagging schemes are considered. An attempt is protect and isolate program modules is vital. As a set
made to distinguish between access limitation and of coexisting and perhaps cooperating programs grows,
authentication. the proper functioning of any particular program should
Key Words and Phrases: protection, types, not be endangered.
environments, trademarks, seals, access keys, access This paper explores a few protection mechanisms as
control, authentication, secrecy they exist or might exist in a programming language.
CR Categories: 4.2, 4.3 In doing so we hope to illuminate certain devices
found in operating systems (e.g. capabilities and access
control) as well as programming languages (e.g. func-
tion-producing functions, programmer-defined data
types).
Who is to be protected from what? Although the
need for protection is usually inspired by situations in-
volving hostility (e.g. competing government agencies
sharing a computer system), experienced programmers
will attest that hostility is not a necessary precondition
for catastrophic interference between programs. An un-
debugged program, coexisting with other programs,
might as well be regarded as having been written by a
malicious e n e m y - - e v e n if all the programs have the same
author! The protection problem to be dealt with here is:
how does one allow programs to cooperate and com-
municate and yet minimize the confusion attendant upon
a program's malfunctioning? There are other kinds of
protection problems of a less microscopic nature (e.g.
proprietary programs) that will not be dealt with here.
Copyright 1973, Association lbr Computing Machinery, Inc. We offer the following as a desideratum for a
General permission to republish, but not for profit, all or part
of this material is granted, provided that reference is made to this programming system: A programmer should be able to
publication, to its date of issue, and to the fact that reprinting prove that his programs have various properties and do
privileges were granted by permission of the Association for Com- not malfunction, solely on the basis of what he can see
puting Machinery.
Author's address: Department of Computer Science, University from his private bailiwick. To make "his bailiwick"
of California, Berkeley, CA 94720. more precise we simply equate it with a single textual
region of a larger program. While we realize that logis-
tical problems prevent a large system of programs from

15 Communications January 1973

of Volume 16
the ACM Number 1
existing as one single program, we accept this artific- For example, the expression Ref(0) in Example 1 is
iality for the sake of precision. Thus we are only in- local to the whole expression. Obviously, an object can-
terested in those properties of a subprogram which are not be local unless it is created by a unique object
invariant over all the possible program texts into which generator like Ref, or is defined in terms of such ob-
the subprogram might be inserted. For example, the jects. For example, neither the number 3 nor the
distinction (in ALGOL 60) between an own variable and function (kXX*3) can be local to any region.
one declared in the outermost block is vital given this The advantage of an object's being local is that one
criterion; a programmer can depend upon the privacy can enumerate all the situations in which it plays a role
of his access to the former, but not the latter. by looking at a single (hopefully small) region of the
program.
Naturally, there can be no complete set of rules for
2. Procedures as Objects proving that an object is local since we can easily con-
The procedure or subroutine has always been a con- struct a subprogram with a subexpression whose value
venient device for one programmer to make his work is local iff some other, arbitrary, computation halts.
available to others. The essence of its power is that the However, consider the following general approach:
user of a procedure need not be concerned with the de- Consider a region R and some expression in R known
tails of its operation, only the effect. If we make this to produce a unique object every time it is evaluated
ignorance mandatory by arranging that users of pro- (e.g. Ref(O) is such an expression). There are three
cedures cannot discover anything about them except ways in which a value Vofthis expression could "escape"
by executing them, we have the basis for a very flexible from R: It can be passed as a parameter to a procedure
protection mechanism. not defined within R, it can be returned as a result of a
Execute-only procedures are, of course, the norm; procedure called from outside R, or it can be assigned to
both FORTRAN and ALGOL 60 enforce that restriction. a reference which is not local to R. Therefore, to prove
However, in order to exploit this device to its fullest that V is local to R we must check each procedure call,
extent it is useful to make procedures full-fledged objects procedure return, and assignment which might involve
in the sense that they can be passed as parameters or V and show that it does not escape.
values of other procedures and be assigned to variables.
Then, to make a particular object accessible to someone
in a restricted way (e.g. read only), we make the object 4. Memory Protection
local to a procedure and pass the procedure to them in
its stead. The first language to allow procedures to be If a m e m o r y reference is local to R then only state-
passed about was LISP, with its FUNARG lists [6]. Later ments in R can assign to it or take its contents. However,
languages, I S W I M [5], PAL [2], and GEDANKEN [7], also any imaginable kind of restricted access (e.g. read-only,
have such procedures and have the execute-only re- write-only, increment-only) can be allowed programs
striction (LISP does not). Our example programs will be outside R by providing them with an appropriate pro-
written in GEDANKEN as its definition is probably the cedure defined inside R.
most readily accessible to the reader. An appendix offers Example 2. Suppose a p r o g r a m m e r wishes to pro-
a brief description of GEDANKEN in terms of ALGOL 60. vide some table-maintaining operations to the general
Example 1. The following GEDANKEN expression community. He writes the program shown in Figure 1
yields a procedure which will return as value the number and publishes the following set of instructions to users :
of times it has been called. The reference Count is in- To acquire a set of table-maintaining procedures, call
accessible to users of the procedure. the (publicly available) procedure Createtable with the
maximum number of table entries you wish to allow.
[Count is Ref(O) ;
X( ){Count := Count+ 1; It will return a three-tuple of procedures
Val(Count) }] [ ]
Item, lndex, Save
ltem(i) will return the ith smallest item in the table.
3. Local Objects Index(x) will return the index of x in the table (i.e.
1tern (Index (x) ) = x) if it is there, otherwise 0. Save (x)
We wish to make precise the notion of an object will put x into the table if it is not already there. Ini-
being local to a particular part of a program; i.e. its tially the table is empty. So much for the external
being inaccessible to other parts. For example the ad- specification.
dress of a variable in a FORTRAN program is local to a Inspection of the program reveals that the references
subroutine if it does not appear in any COMMON dec- created for Table and Count, as well as the procedures
laration or as an actual parameter to a subroutine Locate and Move are local to the procedure body of
call. In general we define it as follows: An object is Createtable. This implies that every assignment to the
local to a textual region R if the only expressions that references is performed by statements inside the region
will ever have it as a value are part of R. and every call of the procedures is also from the region.

16 Communications January 1973

of Volume 16
the A C M Number 1
 Consider all the places marked with an asterisk (*) in
Figure 1. At each we make the assertion
Table(i), . .. ,Table(Count)

is in ascending order. Then we may prove, using what-

ever degree of rigor deemed necessary, that if the asser-
tion is true at each relevant entrance to this textual
Fig. 1. Table maintaining routines.
region (i.e. the entries to Item, Index, and S a v e ) , then
Creatable is ~N it must be true at each exit (i.e. the exits of l t e m , l n d e x ,
[Table is Vector(1 ,N,M Ref(O)) ; //The table Save, and Createtable and the Error exits). Now, because
Count is Ref(O) ; //Number of entries
Table and C o u n t - - t h e only objects the assertion deals
Locate is XX[J is Ref( Count) ; //Returns index of X if present,
Loop: if J= 0 then 0 else //Otherwise negative of next with--are local, we may infer that the assertion really
smallest is true upon each entry to Item, l n d e x , and Save. []
if Table(J) < X then -- J else FORTRAN local variables and ALGOL OWn variables
if Table(J) = X then J else
offer limited versions of memory protection. Indeed,
{J := J - l ; go toLoop}];
Move is X(X,I) [if Count = N then go to Error* else
the programs in Figure 1 could be written as a FORTRAN
//Inserts X after subroutine with multiple entry points if it weren't for
{J is Ref(Count) ; //Position 1 the fact that we may call Createtable many times.
Mloop: if J = l then Table(J+l) := X else
(Table(J+ l) := Table(J);
J : = J--l;gotoM/oop);
Count : = Count+ 1}]; 5. T y p e P r o t e c t i o n
Item is M* if 1< 1< Count then Val(Table(1))*
else go to Error*; One of the fundamental ways in which one pro-
Index is XX[*I is Locate(X) grammer provides services to another is to implement a
if I > 0 then I else 0"];
representation of a new kind of object. For example, a
Save is hX[*I is Locate(X) ;
if 1 > 0 then NIL
system programmer may represent files with disk-tracks
else Move (X, -- 1) *]; and tape records, or a compiler writer may represent
Item, Index, Save*] complex numbers with pairs of reals. Generally speak-
ing, the first programmer writes some subroutines which
create, alter, and otherwise deal with the new kind of
objects. These new objects are represented by some older
kinds.
Suppose we wish to provide a new data type, in-
tervals, to the general public. Among the primitive
Fig. 2. Interval manipulating routines. routines to be provided are Createint ( x , y ) which creates
[Createint is X(X,Y) if X<_ Y then X, Y else Y,X; an interval from x and y, M a x and M i n which yield the
Min is XZ Z(1) ; appropriate endpoints, and S u m which adds two inter-
Max is XZ Z(2) ; vals to produce a new one. We might implement them
Sum is X(X,Y) (X(1) -+- Y(1)),(X(2) -q- Y(2)); as shown in Figure 2.
Createint, Min, Max, Sum]
Now the question arises: how is a user of these primi-
tives to regard the objects that Createint produces--
as intervals or as common, ordinary pairs, which they
obviously are? Most people would agree that he should
do the former and would regard as a type violation any-
thing assuming the latter. Specifically, there are three
kinds of mishap which we might regard as type viola-
tions--i.e, use of an object in a way not intended by its
constructor.
1. Alteration. An object that involves references may
be changed without use of the primitive functions pro-
vided for the purpose.
2. Discovery. The properties of an object might be
explored without using the primitive functions; e.g. we
may select a component of a pair representing an
interval.
3. Impersonation. An object, not intended to represent
anything in particular, may be presented to a primitive
function expecting an object representing something

17 Communications January 1973

of Volume 16
the ACM Number 1
 quite specific; e.g. we might call Max with a pair not in the sense that a running program could generate an
constructed by Createint or Sum. arbitrarily large number of different type tags. The
There are two parties involved in such mishaps: the practical virtues of this generality are not entirely clear.
programmer of the primitive procedures and the user
(misuser, actually) of them. Let us examine the impact
upon them. 6. Seals
If an alteration or impersonation occurs, the primi-
tive functions might malfunction in a drastic way which Define a universally available function of no argu-
would embarrass their programmer, e.g. cause a mys- ments, Createseal. Each time it is called, Createseal
terious run-time error or never halt. For example, if yields a pair
Max were called with something that was not even a
Seal~, Unseal
pair, errors would result. While good programming
practice might dictate that a p r o g r a m m e r make no as- where i is a serial number which changes every time
sumptions about input parameters and always perform Createseal is called. SeaL(x) yields a new object x'
checks, doing so can be difficult. Suppose, for example, such that any operation applied to x' except Unseal~
that we chose to represent sets with sorted vectors. If results in an error (or some other abnormal condition).
the programmer were required to check each set- UnseaL(x') yields x, if x' was produced by Seal~, and
representing parameter for well-formedness (i.e. being results in error otherwise. The object x' may. of course,
sorted), there would be little point in using a fast search- be passed as a parameter or value of a function, but its
ing method such as binary search to locate an item. For properties cannot be examined except by Unseal~ .1
to check that a vector is sorted, we must examine each The interval manipulating functions can now be
element and therefore might as well do the locating at revised as shown in Figure 3.
that time. The p r o g r a m m e r of these functions may depend
F r o m the p r o g r a m m e r ' s point of view, discovery upon the following:
presents no direct threat. If in using programs other I. The value of Unseal(E) had to have been an argu-
than his own, he simply looks at the objects being used ment of Seal at a previous time. Therefore, we have the
as representing something, the proper functioning of inductive rule: to prove p(Unseal(E)) for all E prove
his programs is not impaired. There are more subtle con- that (VE)[o(Unseal(E))] implies p(F) for every F to
siderations, but we won't deal with them here. which Seal is applied. (Proving this is easier if Seal is
N o w let us consider the user of the primitive func- local to a small region.)
tions. First, if his violation of the type rules is genuinely 2. If Unseal is local, applying Seal to an object x does
a mistake, he wishes to be informed of it as soon as not endanger its being local (even if Seal(x) is not local).
possible. If he really thinks of the objects he deals with In this particular case p(X) is " X is a pair of num-
as intervals, there is no reason why he would wish a type bers (X1, X2) and X1 _< )(2 ." By assuming it is true of
violation to occur. However, if he is aware of the repre- P' and Q' in Sum, we can easily prove it is true of Seal's
sentation activity, he may wish to violate the type re- argument, ( ( P ' ( 1 ) ) + ( Q ' ( 1 ) ) ) , ( ( P ' ( 2 ) ) + ( Q ' ( 2 ) ) ) .
strictions for efficiency's sake. Also, a programmer may Furthermore, p is true of the expression if X < Y then
discover entirely unplanned for, yet quite useful, ap- X, Y else Y,X in Createint, so we have established by (1)
plications of the primitive operations; e.g. using Sum that o is true of all objects produced by Unseal.
to add pairs representing complex numbers. While Furthermore, by (2), any user of the primitive func-
recognizing that such activity is not entirely reprehen- tions will not be able to examine the objects except
sible, let us now consider devices for preventing it. through the functions provided.
These devices are basically generalizations of the type The Seal mechanism provides two separable func-
tags familiar to any implementor of a language with tions of protection: authentication and limited access.
dynamic data types. Here they are being made available The first is embodied in (1); the second in (2).
to the general user. Our tagging operations are more
general (and expensive) in two respects. First, they are
"cascadable": a tagged item may be retagged. This 7. Trademarks
feature reflects our belief that representation can be a
multilevel affair. Second, they are completely dynamic If we are not concerned with limiting access to a class
1The use of a function-producing-function here is not essen- of objects, we could make the Unseal operation publicly
tial; Createseal could return a pair Iock~, key, where Iock~and key~ available. The same effect can bc achieved in a more con-
are objects of special types usable by the generally available func-
tions Seal and Unseal, respectively. venient way by use of a new primitive function, Create-
trademark. It is called with no arguments and returns
a pair
Markl , i

18 Communications January 1973

of Volume 16
the ACM Number 1
 where i is an ever-changing serial number as before.
Mark~ (x) yields an object x ' that behaves exactly like x
except that it bears trademark I. Trademarklist(x') is a
publicly available operation which yields a list of the
trademarks borne by x'. (By lists we mean nested pairs.)
Mark~ can be used in place of Seal~ and " i f i E Trade-
m a r k l i s t ( x ) t h e n x else go to Error", in place of Un-
Fig. 3. Protected interval manipulating routines.
seal(x). A suitably rephrased version of the induction
[Seal, Unseal is Createseal ( ) ; rule in (1) still applies.
Createint is ~(X, Y) Seal (if X_< Y then X, Y l f t h e reader doubts the utility of this device, stripped
else Y,X) ;
Min is :kP(Unseal(P)) (1) ; of any access limiting power, we urge him to consider
Max is XP(Unseal(P)) (2) ; how trademarks and other authenticating marks are
Sum is X(P,Q) IP' is Unseal(P) ; used in the commercial/bureaucratic sphere. A m a r k
Q' is Unseal(Q) ; from the Underwriters' Laboratories attests that a par-
Seal ((P'(1) q-Q'(1)),(P'(2) +Q'(2)))]; ticular device may be used without risk, a fact that a
Createint, Min, Max, Sum]
user might discover only by extensive experience. A
letter saying, " Y o u have been drafted," is much more
likely to be believed if it bears the m a r k of a draft
board. In neither case is limited access a consideration.
The fact that marks can be forged in the real world is of
no concern here.
Fig. 4. Simulation of Seals with trademarks. The access-limiting ability of the Seal mechanism
Createseal is ( ) is already present in the local variable conventions of
[Mark l , I1 is Createtrademark ( ); GEDANKEN. W e can use trademarks and function-pro-
Mark2, 12 is Createtrademark( ) ; ducing functions to simulate Seals. Figure 4 displays
Password is Mark2(N1L) ; the programs. When Createseal is called it creates two
Seal is ~,X
trademarks and then the functions Seal and Unseal
Markl (hP if 12 E Trademarklist(P)
then X which use them. A sealed object is represented by a
else go to Error) ; trademarked function which will divulge the original
Unseal is ~ Y object only when called with a password.
if I1 E Trademarklist(Y) It is clear that this simulation provides the authenti-
"then Y(Password) cation of the original Seal primitives, For, Unseal trans-
else go to Error;
Seal, Unseal] fers to Error unless its argument bears trademark 1 ; and
an object can bear trademark 1 only if it was produced
(Note: The expression x E L is true iff x is on list L). by Seal, because M a r k 1 is local.
To show that access to sealed objects is limited to
holders of the Unseal function we argue as follows:
F r o m the argument in the preceding paragraph we know
that any object bearing trademark 1 is a function which
arose from the k-expression in Seal. Therefore every Y
applied to Password in Unseal is an incarnation of that
k-expression. Hence P is the only other expression that
can ever have the same value as Password. (Applying
Trademarklist, a primitive, to P does not endanger this
claim.) Therefore Password is local. N o w suppose
x' = S e a l ( x ) . By inspection of Seal, the only way x
can be recovered from x' is to apply x' to something
marked by trademark 2. Since M a r k 2 is local we see
that Password is the only such object, and it is also local.
Therefore, the only way to get x' applied to an object
bearing trademark 2 is to apply Unseal to x'.
Since seals can be simulated by trademarks without
undue loss of efficiency we are inclined to discard seals
as a basic semantic unit, invoking Occam's razor, or-
thogonality, or some other folk principle.
There is another reason for preferring trademarks to
seals, however; they offer greater flexibility. Suppose we
have some class of objects (e.g. ordered pairs of num-

19 Communications January 1973

of Volume 16
the ACM Number 1
 bers) which are used to represent various other classes
(e.g. intervals, points in the plane), in a variety of ways
(e.g. cartesian versus polar coordinates [3]). These ob-
jects may in turn represent others (e.g. a point in the
p l a n e might represent a complex number or a vertex in a
geometrical figure). We can invent trademarks to at-
test to these various properties and attach them to ob-
jects in any order we like. For example, a complex Fig. 5. Simulation of trademarks with access control.
number represented in the cartesian system might bear [Oblist is Ref(NIL); //List of all Marked Objects, really nested
four marks: pair, point-in-plane, cartesian, complex. //triples.
Programs may examine these marks or not as they Seriahmmber is Ref(O) ;
Findob is XX[E is Ref(Oblist) ;
please; e.g. a routine that prints pairs is unconcerned Loop: if E= NIL then NIL else //E(1) is unique name
with all but the pair tag. If seals were used in this kind of if E(1) = X then E(2) else //E(2) is (TMlist,Object)
situation great complications would result. Every routine {E:=E(3); go to Loop}]; //E(3) is next item
that dealt with pairs would have to be equipped with a Trademarklist is ~X
battery of Unseal operations which it would use to un- [T is Findob(X) ;
if T=NIL then NIL else T(1)];
lock all the nested seals; to make matters worse it would Get is )~X
have to have a way of determining which Unseal was IT is Findob(X) ;
called for at each stage. if T = NIL then X else T(2) ];
Naturally, when we wish to limit access to a class of Createtrademark is ~( )
objects as well as authenticate them, the full facilities of [I is Val(Serialnumber) ;
Mark is ~X//Always add to Oblist
the Seal mechanism are called for. Only in situations ITis (l, Trademarklist( X) ), Get(X);
involving no need for suppressing information is the Oblist := Ref(NIL), T, Val(Oblist);
trademark best. Oblist(1)];
Serialnumber.= SeriahTumber q- 1;
Mark, 1];
Createtrademark, Trademarklist, Get]
8. A c c e s s K e y s

N o w let us examine the implications of making the

Seal operation public and leaving Unseal private; e.g.
Seal(i,x) places seal number i on x and Createseal
produces the pair
UnseaL, i.
If one puts such a seal on an object and leaves it in a gram provide authenticated evidence of its access rights.
public place, he is guaranteed that only the restricted It seems clear that access control is a sine qua non of
group of programs holding Unseal~ can access it. Those security; if every program has access to every object
programs, however, cannot depend upon an object thus and operation there is no protection. The case is not so
sealed to have any particular properties since anyone clear for authentication. Given the access control mech-
can seal an object with any number. This mechanism is anisms already present in GEDANKEN, i.e. local ref-
similar to the access key described in [4]; each Unseal~ erences, we can simulate the trademark system if
plays the role of an access key. we require the user to use a function, Get, when
Access keys are symmetric to trademarks in the accessing a marked object. (This is a minor incon-
sense that they allow many unprivileged senders to give venience.) The idea is to hold all objects submitted to
information to one privileged receiver, the holder of the M a r k in a protected list (Oblist), paired with their trade-
Unseal operation. With trademarks the sender of in- mark lists. Each such pair is given a unique name which
formation has the privilege. is used to retrieve the object or its trademark list.
These new Createseal and Seal operations can also GEDANKEN'S R e f operation is an admirable generator of
be simulated using the trademark primitives. unique names. The scheme works because access to the
list is limited. Figure 5 shows an expression which
evaluates to produce the functions Createtrademark,
9. A u t h e n t i c a t i o n vs. A c c e s s C o n t r o l Trademarklist, and Get. The idea behind this program
should be familiar to those who understand how C-lists
There seems to be a chicken-egg relation between [1] are used; basically, we are using memory protection
these two notions that make them hard to disentangle. (rather clumsily) to achieve type bit protection.
Access to the authentication operation, e.g. Mark, must This simulation of trademarks is unsatisfactory in
be controlled if it is to be useful. On the other hand, two respects. First, one can say that we really haven't
gaining access to things sometimes requires that a pro- started without type protection since we use references

20 Communications January 1973

of Volume 16
the ACM Number 1
to s i m u l a t e m a r k e d objects a n d t h e y are p r e s u m a b l y A p p e n d i x . A B r i e f C o m p a r i s o n o f G e n d a n k e n with
m a r k e d in s o m e way. T o a v o i d this c h a r g e we c o u l d h a v e Algol-60
used integers i n s t e a d , k e e p i n g a c o u n t e r to g e n e r a t e n e w
ones. H o w e v e r , this is n o t e n t i r e l y a d e q u a t e since it The basic means of introducing new identifiers is the is-declara-
w o u l d t h e n be i m p o s s i b l e for a t r a d e m a r k e d o b j e c t to be tion which is used in three ways here:
local to a n y region. T h e s e c o n d s h o r t c o m i n g is t h a t it is 1. Count is Ref(O) is like integer Count; Count := 0
wildly inefficient: a list m u s t be s e a r c h e d j u s t to access 2. Locate is ~X[. --] is like integer procedure Locate(X);
begin -.. end
a n object, a n d m a r k e d objects will n e v e r be g a r b a g e
3. I is Locate(X) is like integer I; I := Locate(X)
collected even after all references o u t s i d e the p r o t e c t e d
except subsequent assignments to 1 are forbidden. The types of
r e g i o n have d i s a p p e a r e d . A t p r e s e n t we see n o w a y o f
identifiers are never declared. The declaration and calls of param-
o v e r c o m i n g these p r o b l e m s . eterless procedures employ the null parameter list, written "( )".
W e believe t h a t ' a u t h e n t i c a t i o n is a n o t i o n o r t h o g o n a l References (addresses) are dealt with more explicitly. Ref is a
to l i m i t a t i o n o f access. O u r belief rests u p o n i n t u i t i o n function which returns a new reference, containing its argument.
a n d the fact t h a t the f o r m e r seems difficult to s i m u l a t e If r is a reference, Val(r) is its contents, and r := e changes its
with the latter. contents to e. A set of coercion rules (not given here) serve to insert
applications of VAL so that, if Count is a reference,
Count+ 1 means Val(Count) + 1
I<_Count means 1< Val(Count)
Remarks Ref(Count) means Ref(Val(Count))
and Count(l) means (Val(Count))(l)
T h e ideas p r e s e n t e d here are, in a sense, a r e p a c k a g - Vectors and n-tuples are subsumed under the more general
notion of functions. The expressions
ing of familiar notions from programming languages (2,4,6)
a n d o p e r a t i n g systems : scope rules, capabilities, m e m o r y and (~Xif l < X < 3 then 2*X
p r o t e c t i o n , a n d type bits. W e h a v e c o n s i d e r e d these else go to Error)
devices in e x t r e m e l y g e n e r a l f o r m s , a n d it is e n t i r e l y and Vector(1,3,XX 2*)0
possible t h a t less g e n e r a l devices m a y be sufficient a n d all denote the same thing: a function Fsuch that F(1) = 2, F(2) = 4,
F(3) = 6. If Createseal( ) returns a pair, the declaration
e c o n o m i c a l l y m o r e r e a s o n a b l e . Specifically, the f u n c -
t i o n - p r o d u c i n g f u n c t i o n s , indefinitely c a s c a d a b l e type Seal, Unseal is Createseal( )
tags, a n d r u n - t i m e c r e a t i o n o f types e n t a i l s u b s t a n t i a l serves to decompose it and bind the components to the two iden-
costs b y c u r r e n t s t a n d a r d s . F i n d i n g r e a s o n a b l e c o m - tifiers.
The general form for a (large) GEOANKEN expression is a
p r o m i s e s b e t w e e n these facilities a n d o n e s efficiently im-
sequence of (0 or more) is-declarations followed by (1 or more)
p l e m e n t a b l e t o d a y is a s u b j e c t o f c o n t i n u i n g research. expressions (X := y is an expression).
T h i s w o r k b u i l d s u p o n the ideas o f m a n y people,
[ d l ; ' ' ' ;d,,;el;... ;e,~]
m o s t n o t a b l y , L a m p s o n [4], L a n d i n [5], R e y n o l d s [7],
The declarations and expressions are evaluated from left to right
a n d D e n n i s [1].
and the value of the whole expression is e~. The (textual) scope of
the definitions is limited by the brackets.
Acknowledgments. E a r l i e r v e r s i o n s o f this p a p e r were To make the programs more readable we write key words of
given s y m p a t h e t i c r e a d i n g s b y B u t l e r W. L a m p s o n a n d GEDANKEN in boldface and capitalize the first letter of identifiers.
J a m e s N. G r a y . Also variously-shaped brackets are used. Comments are written to
the right of double slashes (//).

Received June 1971 ; revised January 1972

References

1. Dennis, J. B., and Van Horn, E. Programming semantics for

multiprogrammed computations. Comm. ACM 9, 3 (Mar. 1966),
143-155.
2. Evans, A. PAL--A language designed for teaching program-
ming linguistics. Proc. ACM 23rd Nat. Conf. 1968, Brandon
Systems Press, Princeton, N.J., pp. 395-403.
3. Fischer, A.E., and Jorrand, P. BASEL: The base language
for an extensible language facility. Rept. CA-6806-2811, Computer
Associates, Wakefield, Mass., 1968.
4. Lampson, Butler W. Dynamic protection structures. Proc.
1969 FJCC. The Thompson Book Co. pp. 27-38.
5. Landin, P.J. The next 700 programming languages. Comm.
ACM9, 3 (Mar. 1966), 157-166.
6. McCarthy, J., et al. LISP 1.5 Programmers' Manual, M.I.T.
Press, Cambridge, Mass., 1962.
7. Reynolds, J.C. G E D A N K E N - - A simple typeless language
based on the principle of completeness and the reference concept.
Comm. ,4CM 13, 5 (May 1970), 308-319.

21 Communications January 1973

of Volume 16
the ACM Number 1