A Type Declaration and Inference System

for Smalltalk

Alan H. Borning
Computer Science Dept., University of Washington

Daniel H. H. Ingalls
Xerox Palo Alto Research Center

Abstract

An experimental system for declaring and inferring type in inappropriate class will only result in a run-time error of the form
Smalltalk is described. (In the current Smalltalk language, the “message not understood”, it is nevertheless advantageous for
programmer supplies no type declarations.) The system provides the programmer to be informed of such a problem when the code
the benefits of type declaration in regard to compile-time checking in question is being compiled, rather than later when it is being
and documentation, while still retaining Smalltalk’s flexibility. A used.
type hierarchy, which is integrated with the existing Smalltalk
class hierarchy, allows one type to inherit the traits of another In this paper we present an experimental system for declaring
type. A type may also have parameters, which are in turn other and inferring ripe in Smalltalk. In adding type declarations to the
types. language, we do not wish to give up its current flexibility. The
principal feature of our scheme that allows it to retain this
flexibility is the hierarchical description of types, and the
1. Introduction integration of this hierarchy with the existing Smalltalk class
Smalltalk is a powerful interactive language based on the idea hierarchy. The type of the actual contents of a variable or field
of objects that communicate by sending and receiving messages may be the same as or any subtype of its declared type. (In
[Ingalls 78, LRG 81, Goldberg 81]. In Smalltalk, the user supplies contrast, in e.g. Pascal the types would have to match exactly.)
no type declarations. This results in greater flexibility than in a For example, one might have a declaration for a message
typed language such as Pascal; however, in almost all cases, the ‘addWlndow:’ that specified that its argument was to be of type
programmer in fact knows what sorts of objects are expected as Window. When actually sending the message ‘addWindow:’, any
the arguments of a message, and what sort of object will be subtype of Window--a code editing window, a debugging window,
returned, Since at present one must glean this information from a painting window, or whatever-would be acceptable as the
comments, external documentation, or by inspecting the code, a actual argument. Correspondingly, in the code that implements
type declaration mechanism would provide a valuable form of the ‘addWindow:’ method, the programmer could only send to that
machine-checkable documentation. While Smalltalk is a “type- argument messages that all windows understand. Analogously,
safe” language in the sense that encountering an object of an one could declare that the argument of some other message was
of type Object. Since every type is a subtype of Object, the
argument could be any object--but in the code for that method, the
*--- ----- ---- .—-— —.. — --- programmer could send it only messages that all objects
This research was funded primarily by the Xerox Corporation, understand.
with additional funding from the National Science Foundation
under Grant No. MCS-80041 I I. In the sections that follow, we describe the notions of type,
subtype, and parameterized type in Smalltalk, along with

Permission to copy without fee all or part of this material is granted techniques for declaration, checking, and infe~ence of type. In
provided that the copies are not made or distributed for direct addition, we present a user interface that allows a programmer to
commercial advantage, the ACM copyright notice and the title of the view and edit type declarations conveniently. The type system is
publication and its date appear, and notice is given that copying is by
permission of the Association for Computing Machinery. To copy written in the Smalltalk-80 version of the language.
otherwise, or to republish, requires a fee and/or specific permission.

@ 1982 ACM 0-89791-065-6/82/001/0133 $00.75

133
2. Definition of Type in Smalltaik The type of an argument maybe specified as the gfobal name of
A type specifies the messages that an object of that type
some type, such as Integer or Window, or by the name of a
understands. Thus, a type is abstract: it describes an object’s
parameter, e.g. as e/ementType for a method defined by
interface with the outside world, but not its internal representation.
Collection. In addition, an argument type specification may be
Each type specifies a set of message declarations. In turn, each
message declaration gives the name of the message, the formal
argument names, the types of the arguments, and the type of the
result. 1For emphseie, in this paper we italicize all expressions designating types.
However, when we simply name a class without using it in its role as a type, we
leavethe namein the normaltypeface.
Types come in hierarchies, so that one type maybe declared as
constructed by giving new parameters to one of the above
being a subtype of another, A subtype inherits the message
expressions, or by getting a parameter from one of them.
declarations of its supertype, and may add additional declarations
of its own. In addition, it may refine an inherited message
The “algebra of types” for specifying the type of a result is
declaration by indicating that the result is some subtype of what
somewhat richer. A result type specification may be any of the
was previously declared, At the top of the hierarchy is type
possibilities for an argument type. In addition, the result type may
Object, which declares messages such as ‘ =‘, ‘copy’, and
be specified as self, meaning the type of the object that is
‘printOn:’ that are understood by all objects.
executing the method, as being the same as the type of one of the
arguments to the method, or as being the nearest common
Types can have parameters. For example, rather than just
supertype of two other result type expressions. (The nearest
saying that something is of type Collection, it may be described as
common supertype of two types is that type which is a supertype
being a collection of some other type of object, e.g. as being of
of each and which is closest to them in the type hierarchy. The
type Co//cc/ion of: Window.
algorithm for finding nearest com’mon supertypes is given in
3. Implementation of Types Section 5).
We define a Smailtalk class Type. This class is abstract: it
declares no instance state, but only serves as a superclass for In addition to the declarations for messages, the programmer

other classes. One subclass of Type is class Class -- a class is a can declare the types of temporary, instance, class, and global
perfectly good specification of a type.l ParameterizedType is variables. The types of temporary variabfea can be inferred by the

another subclass of Type, which is used to hold copies of existing compileL for the others, declarations are required.
types with new parameters substituted for the original ones. For
example, the type Collection declares that it has a single We now present some examplea of type declarations. (These

parameter named e/ernen(Type, which is the type of the elements aren’t the complete type definitions for any of the types listed;
in the collection. A type such as Co//ecf(on of: Window is rather, we list only some representative message declarations.)

represented as an instance of ParameterizedType. (The type The type of each argument is declared by writing a type
Co//ection itself declares that its element type is Object.) expression in angle brackets after the argument name, while the
type of the result is decfared by an uparrow folfowed by a type
We leave open the possibility of additional subclasses of Type, expression in angle brackets. Comments are surrounded by

for example, a class Protocol that would describe a collection of double quotes.
related messages independently of any concrete implementations. Object
ssrpertype: none
“AS previously mentioned, Object is the
In the default, the type of an object will be the same as its class,
super type of all other types. ”
but this is not universally the case. For example, the Smalltalk ❑ x <Object> “am I equal to x?”
class Integer has three concrete subclasses: Small Integer, t<Bool can>
copy “return a copy of myself”
Larg@Negativelnteger, and LargePositiveInteger, but the type of
t<self>
instances of any of these is simply /nfeger. On the other hand, if c “Here, the type of the object
is a collection of windows, its type will be Co//ection of: Window, returned is the same as that of
the receiver. The specification
but its class will be Collection.
of the object that is returned is
evaluated in ‘type space’ rather
4. Making Declarations
than ordinary ‘object Spa Ce’ , so
As mentioned above, a message declaration gives the name of
that self here means the receiver’s
the message, the formal argument names, the types of the type. ”
arguments, and the type of the result Here, we will give an printOn: strm <Stream of: Character>
“This is the standard message
informal description of the ways in which the argument and result
asking an object to print itself
types can be specified, followed by some examples. A formal BNF on an output stream. Streams are
description is given in Appendix 1, parametrized by the type of
object in the stream. ”
~<self>

134
 type “return my type” Boolean
t<Type> supertype:Object
class &b<Boolean>
“Every types is regarded as being tzBooleanz
parametrized by its class.” and:aBlock<Block to: Boolean>
tsself class> “This version of ‘and’ evaluates
Number its argument only if necessary,”
supertype:Object t<Boolean>
“A!urnber is a supertype for numbers of ifTrue: t <Block to: Object>
all sorts: integers, fractions, if False: f <Block to: Object>
floating point numbers, etc.” t<t resultType nearestCommonSupertype:
abs “return my absolute value” f resultType>
*<self> ifTrue: t <Block to: Object>
aslnteger “convert to an integer” ?<t, resultTypez
?<Integer> “If the receiver is ‘false’, then
asFloat “convert to a real number” the result is nil. (As described
t<Float.> in Section 5, nil is allowed as an
+ n<Number> instance of any type, and hence it
*<self nearestCommonSupertype: n> satisfies the declaration
“As far as the type system is tresu/tType.)”
concerned, 3+4 yields something of if False: f <Block to: Object>
type Integer, while 3.14+4 yields ?Zf resultType>
something of type Number. (In Type
fact, the result in the latter supertype:Object
case will be of class Float, but “A type is itself an object that can
the type system only knows, that it respond to various messages. ”
will be some subtype of Number.)” parameters
“Return a dictionary of my
Collection
parameters. ”
supertype:Object
r<Dictionary keys: Symbol values: Type>
parameters: ‘elementType’ ‘
supertype “answer with my supertype”
“e/ernentType is the type of the elements
tsType~
of the collection. The elements in a
given instance can be subtypes of Class
e/errrent7’ype; however, users of the supertype:Type
collection can only count on the new “create a new instance”
elements being of type e/ernerrtType. “The type Class is regarded as being
The class Collection responds to the parametrized by the type of
message ‘of:’ by returning a new instance that it creates.”
instance of ParameterizedTypa with the t<self instanceType>
parameter elementType set
appropriately. ”
add: x<elementType>
?<self> 5.TypeChecking andTypelnference
remove: x <elementType> This section describes the type checking and inference
tzselfz mechanism. When the user compiles a method, the system
addAll: c<Collection of:elementType>
tzsel f> checks at compile time that the messages that might be sent
do: b <Block from: elementType to: Object> during execution of the method body would be understood by
“This message takes a block as an their receivers, that the message arguments will be of the correct
argument, and evaluates the block types, that only objects of the correct type will be assigned to
for each element in the
collection. The results of the variables, and that an object of the correct type will be returned.
evaluation are discarded. (A Part ofthisprocess requires type inference aswellaschecking,
block is an object representing a
since the types of expressions must be inferred, and the system
piece of code to be evaluated at
an appropriate time; in this specifications allow the types of temporary variables to be inferred
example the block takes one if the user so desires.
argument. The type Block is
discussed further in Section
A fundamental operation in type checking ismatchinq, that is,
7.1.)”
t<sel f> checking that anactual type matches a declared type, An actual
collect: b< Block from: elementType to: Object> typef matches adeclared typed if t isthesame type asor isa
“This nfessage takes a block as an
subtype of d. Ifdhasparameters, then for each parameter of d,
argument, evaluates the block for
each element in the collection, thecorresponding parameter oftmust match it. Finally, the type
and returns a new collection Ur?defirredObject matches any type. (UndefinedObject istheclass
consisting of tha Pesult$ 6f of nil, to which all variables are initialized in Smalltalk. )
evaluating the block. Lisp fans:
this is similar to ‘mapcar’, ”
?Zself of: b resultType>

135
 Another operation required in type checking is finding the For example, the programmer might declare that a temporary
nearest common supertype of two types t7 and f2. To find this variable t is of type Number, but the type inference mechanism

nearest common supertype, t7 searches upitschain of supertypes could infer that in fact t must be an integer. In such a case, the
until it finds the first supertype s that is also a supertype of t2. type system does not refine the declaration; thus, sending a

(Such a supertype always exists, since all types are subtypes of message to t that is understood by integers, but not numbers in

Object.) Ifshasparameters, thevalues of each parameter of the general, would yield an error during type-checking. If the

nearest common supertype is found by computing the nearest programmer wants to send such messages to t, he or she should

common supertype of the corresponding parameters from f7 and declare t to be of type Integer, or else let the system infer its type.2

?2

Thetype checking and inference mechanism isinvoked by the 2

Th6 way of handllng the mterachon between type inference and declaration for
compiler. The types of the arguments, result, and instance variables IS consistent with the treatment of declarations for message arguments.
variables are obtained from the user’s declarations. Aftera parse In type checking a method, it is the declaration of the formal arg”~ent that is “~ed,
even though when the method is invoked, the actual argument may be some more
tree has been generated, an “executionf ortype” of the parse tree
specifw type.
is performed in the following fashion.
6. The User Interface
Each kind of parse tree node understands the message The user interface to the type system has been constructed by
‘executeForType’. When anode receives this message, it returns simple modifications to the Smalltalk class browser described in
the type of the object that it would return at run time. Some nodes [Tesler 81], The old pane of the browsing window that displays
also perform checks: variable nodes check that the type of any the code for a given method is divided into two parts: a declaration
value assigned to that variable matches the declared type of that pane that contains the keywords, arguments, and declarations;
variable; message nodes check that the receiver can understand and a code pane that contains the code proper, (See Figure 6-1.)
the message, and that the types of the actual arguments match Compilation is done in Smalltalk on a method-by-method basis;
those of the formal arguments. To find the type that is returned type checking is performed whenever a method is compiled. The
when a message is sent, the declaration for that message must be system checks that all the messages sent inside the code body
consulted. The system evaluates the result type expression (using have correct argument types, that the value returned matches the
the types of the actual arguments in the computation), and returns declared type of the result, and that assignments to variables
this result as the value of the message node. match the declarations for that variable, notifying the user of any
violations,
Smalltalk control structures are described as messages to some In our experimental prototype, we hatie added declarations for
object. This is very convenient from the point of view of the type only a small proportion of the methods in the Smalltalk system.
system, in that the algorithms for checking such things as Therefore, in this version, there may be no declaration for some
conditionals and looPs can be described simply by the message used in a body of code being checked. In this case, the
declarations for these control structure messages; no additional system informs the user, and assumes that the result type is
mechanism is needed. (See the declarations for ‘Collection do:’ UndefinedObject (which matches anything).
and ‘Boolean ifTrue: if False:’ in Section 4, and the declarations for
‘Block whileTrue:’ and ‘Block whileFalse:’ in Section 7.1.)
7. More about Type Declarations
Type inference is integrated with the type checking process.
For expressions, the type of the expression is returned when
7.1. Declaring the Type of Blocks
‘executeForType’ is sent to the message node. For a temporary
As previously mentioned, a block is an object representing a
variable whose type has not been declared by the user, the
piece of code to be evaluated at an appropriate time, perhaps with
corresponding variable node will keep track of the types of objects
arguments, To evaluate the block, the programmer sends it the
assigned to that variable. If an object of type /7 is assigned to the
message ‘value’, ‘value:’, ‘value: value:’, or ‘value: value: value:’,
variable, the inferred type will be t7. If an object of a different type
depending on whether the block takes zero, one, two, or three
t2 is subsequently assigned, the new inferred type will be the
arguments respectively.3 In Smalltalk, all blocks are instattces OF
nearest common supertype off 7 and ?2.
the same class. However, it is appropriate to send the message
‘value’ only to a block taking zero arguments, the message ‘value:’
Type inference for parameterized types is handled in an
only to a block taking one argument, and so forth. To allow this to
analogous fashion, For example, when inferring the type of a
be verified during type-checking, we define separate subtypes of
collection, the type of e/emenf7’ype is the nearest common
B/ock for blocks that take zero, one, two, and three arguments. All
supertype of the types of each element inserted into the collection.
these types are parameterized by the types of the arguments to be
supplied to the block and the type of the result. Further, it is
On occasion, type inference may yield more specific
appropriate to send the control-structure messages ‘whileTrue:’
information than is available from the programmer’s declaration.

136
and ‘whileFalse:’ only to a block that takes zero arguments and
Blockl
that also evaluates to a Boolean; to represent this, a subtype supertype: Block
/300/earrB/ock of the type of blocks taking zero arguments is parameters: ’arglType resultType’
“This type of block takes one
defined.
argument. ”
Block value: arg<arglType>
supertype: Object t<resultType>
parameters: ‘resultType’
“The type of any actual block will be Block2
supertype: Block
some subtype of this type. ”
parameters: ’arglType arg2Type resultType’
new Process
“This type of block that take two
“Create a new process. All blocks
arguments. ”
can do this, so this message is
value: argl <arglType>value: arg2<arg2Type>
declared in B/ock.”
tzresultType>
t<Process>
Biock3
supertype: Block
parameters: ’arglType arg2Typearg3Type
3 resuitType’
It would of course be easy todefinefurrher measages for blocks taking four
arguments, and so forth. “This type of block that take three
arguments. ”
BlockO
value: argl <arglType>value: arg2<arg2Type>
supertype: Block
value: arg3<arg3Type>
parameters: ‘resultType’
*<resultType>
“This type of blocks takes no
arguments.”
value In writing type declarations, the programmer makes use of a set
r<resultType>
of messages understood by the class Block.
BooleanBlock
supertype:BlockO to: rType returns a BlockO parameterized by the
parameters: ’resultType’ resultType rType. As a special case, if rrype
“This is a subtype of BlockO with matchesBoo/ear?, this returns a BooleanBlock
‘resultType’ set to Boolean, (B/ockO instead.
just declares that it produces
something of type Object.)”
from: al Type to: rType
whileTrue: anotherBlock <Blockto: Object>
?<self>
returns a Blockl parametrized by the
whileFalse: anotfserBlock <Block to: Object>
rfself> argument type a7Type and the resultType
r Type

137
 Object
from: al Type and: a2Type to: rType supertype:none
returns a Block2 parameterized by the be:aType<Type>
argument types alType and a2Type, and the tzaType>
resultType rType
The corresponding method simply checks if the receiver’s type
from: al Type and: a2Type and: a3Type to: rType matches ‘aType’. If it does, it returns the receiver; otherwise, it
returns a Block3 parameterized by the
notifies the user that atype error has occurred (and then returns
argument types al Type, a2Type, and a3Type,
nil if the user chooses to proceed).
and the resultType rType

The messages whose uses can often not be type-checked at

It would be possible to represent the types of blocks in a more
compile time are’Object perform:’, which sends a message using
general way. Forexample, ParameterizedType could allow tuples
adynamically computed selector4, and ‘instfield: gets:’, a message
of types as parameters, and also allow message de~larations to be
for use by systems hackers that assigns into the ith field of an
associated with particular instances. This would permit the use of
instance. There may beafew others.
a single type /3/ock, with blocks taking zero arguments, blocks
producing booleans, and so forth represented simply as
As an aside, at least for now it wouldn’t be disastrous if the type
parameterizationsof this type. We did not do this in the present
checking system were breached: the worst that will happen is that
system because these capabilities, which would be used only for
there will bea run-time “message not understood” error. In any
blocks, would require making the parameterization mechanism
event, ifdeclarations were added for all methods, the type system
significantly more complex.
would be able to inform the user whenever there was a possibility
that a run-time error of the “message not understood” variety
7.2. An Example Using Blocks could occur.
To illustrate type-checking in the presence of blocks and
collections, consider checking the following method.
exampleMethod I pt setl set2 I 41t maybe worth getting rid of therun.time check for”perform’ by adoptinga
scheme analogous to that employed for blocks, where selectors would have
“create a new point with x=5 and y=l O”
pt + 5@lcl. different types, depending on the number and types of their arguments and the
typeoftheresult.
setl + Set new.
setl add: pt.
“Make a new set tha collects the 8. Relation to Other Work
results of sending each element in One of the principal ancestors of Smalltalk is Simula[Dahl &
‘Setl’ the message ‘asString’ .“
Nygaard 66], which was one of the first systems to use the
set2 + setl collect [:x I x asString].
concepts of classes, subclasses, and instances, The use of
objects and messages for information hiding is closely related to
The type of ‘pt’ is inferred to be ‘oint from the declaration for
the data abstraction mechanisms in languages such as Mesa,
the’@’ message to Number. Next, the type of csetl’ is inferred to
CLU, Alphard, and Ada [Mitchell 79, Liskov 77, Wr.rlf 76, DOD 80],
be Set. (Set isoneof thesubclasses of Collection.) However, its
These languages separate the interface specification of a type
e/errrent Type is not yet known. The following statement
from its internal implementation, just as Smalltalk distinguishes the
(<setl add: pt’) allows the type checker to infer that the
external message protocol of an object from its internal aspects.
e/ernenfType of ’setl’ is Poinf. Inchecking the final statement, the
type checker checks that the actual argument to ‘collect:’ matches
Suzu}i has recently described an algorithm for inferring types in
the declaration
Smalltalk-76 [Suzuki 81], and has used it to infer types in the
<Block from:elementType to: Object>,
Smalltalk subset concerned with numbers. The algorithm is an
which itdoes, andthat itislegal tosendthe message iasString'to
instances of Poirrf. The declaration for ‘asString’ also allows the extensioo of Milner’s algorithm used to determine types for the ML
language of LCFIMilner 78]. Suzuki’s program produces asetof
system to infer that the type of ‘set2’ is Set of: String.
equations and inequalities from a collectionof Smalltalkmethods,
and solves them using unification and a transitive closure
7.3. Run-timeType Checking algorithm, There are a number of important differences in the
At the start of this project, we anticipated the need to perform approaches taken in this system and ours. Suzuki’s system deals
run.time type checking in a number of places, but as the design of with Smalltalk asitis, and isthus concerned with inferring typesin
the system has developed, nearly all of these places have the absence of declarations, whereas we modify the language by
disappeared (and the system has become cleaner in the process). the addition of explicit declarations. One consequence of thisis
that Suzuki’s program must examine code throughout the
If itshould beneeded, itisactuallyquite simpletoinclude arun- Smalltalk system to infer types, since here the types of arguments
time type check by using the message’be:’, The declaration for passed into a method can only be discovered by examining all
this message is: users of that method. Bycontrast, oursystem checks one method

138
 at a time, and need only examine the declarations for the
may aid in the production of faster, more compact code by
messages that it invokes, but not their code. This simplifies our
allowing better factoring of information. Also, the type system may
program considerably, and makes type checking in the presence help in tracing control flow, thus making it possible to produce
of edits to a running system much easier,
A less important
application modules containing just the code needed to run a
difference is that Suzuki’s system uses unions of types, whereas
particular application,
we use a single type, taking the nearest common supertype as
necessary. For example, Suzuki’s system would infer that the type
Acknowledgements
of the expression
x = y ifTrue: [3] ifFalse: [3.1416] We would like to thank all the members of the Learning
was {/rNeger, F/oaf}, whereas ours would infer it to be Number, the
Research Group at Xerox PARC for help and suggestions, in
nearest common supertype of /rrteger and F/oat. particular Peter Deutsch and Phil Klein.

Finally, Howard Cannon has developecf the “flavors system” for

the MIT Lisp Machine Lisp [Cannon 80]. The flavors system adds
to Lisp the capability for making objects that can interact by

sending messages, and has received extensive use in defining

window packages. An important feature of the flavors system is
that it allows an object to be defined using several flavors. In
Smalltalk, this would correspond to allowing a class to have
multiple superclasses (and a type to have multiple supertypes).
While we have experimented with such a capability in Smalltalk
(see e.g. [Borning 81]), we have not included it in the system
described here,

9. Conclusions and Further Work

The type declaration and inference system has been
implemented and tested; however, we have not yet used it during
the implementation of a large project, nor has it been used by
people other than its implementors. The next step is thus to carry
out a significant project within our system.

Further work on the user interface is needed, Also, the current

system does not handle dynamic updating of message
declarations. The obvious thing to do if a declaration is changed
is to check all users of that message to see if they are still using it
correctly, but this would be a very time-consuming operation, and
would disrupt the flow of user interaction. We have designed (but
not implemented) a scheme that spreads this load over a longer
time, and also avoids the problem of needlessly re-checking the
same method when making a series of edits.

We have been encouraged by the results so far. It has been

gratifying to be able to make changes of this sort to a running
Smalltalk system without great difficulty. Most of the work in
building the system has gone into the design of types, type
hierarchies, generic types, and the relation between types and
classes, as opposed to the actual coding of the program. Of this
code, most consists of new classes and methods; the
modifications needed to interface with the existing compiler and
browser are small. No changes to the Smalltalk virtual machine
were required,

It has not been an immediate goal of this research to improve

run-time efficiency. In the longer term, however, the type system

139
1. A BNF Description of Type Declarations
In this appendix we present a formal definition of type declarations in our system, using the “human
engineered variant” of BNF described in [Ledgard 81]. Terminals in the grammar are underlined,
optional items are surrounded by square brackets, and repetition is denoted by ‘.,.’.

type-declaration ::= type-name

suDertv De: type-name
[parameters: -’- parameter -name... ~]
message-declaration. .

message-declaration ::= pattern-part

~result-type>

pattern-part ;:= unary-selector

I binary-part
I keyword-part. .,

binary-part ::= binary-selector argument-name <argument-type2

keyword-part ::= keyword argument-name gargument-typez

argument-type ..=
. . simple-type

result-type ::= simple-type

Iti
I argument-name
I result-type nearestCommonSuDertyPe: result-type

simple-type ::= type-name I parameter-name

I new-parameters I get-parameter

type-name ;:= identifier

parameter-name ::= identifier

new-parameters ::= type-name parametrization. . .

parameterization ::= keyword simple-type

get-parameter ..=
. . simple-type parameter-name

The category names urtary-se/ecfor, binary -selector, and keyword are as in Smalltalk-80; definitions
maybefoundin[LRG 81].

140
 [Liskov 77] Liskov, B., Snyder, A,, Atkinson, R, and Shaffert,
References
c.
Abstraction Mechanisms in CLd.
Communications of the ACM 20(8):564-576,
August, 1977.

[LRG 81 ] The Xerox Learning Research Group.

The Smalltalk-80 System.
[Borning 81 ] Borning, A.H.
Byfe 6(8):36-48, August, 1981.
The Programming Language Aspects of
ThingLab, A ConstraintOriented Simulation
[Milner 78] Milner, R.
Laboratory.
A Theory of Type Polymorphism in
ACM Transactions on Programming Languages
Programming.
and Systems 3(4):353.387, October, 1981.
Journal of Computer and System Sciences
17:346-375, 1978.
[Cmno~ 80] Cannon, HI.
F/avers.
[Mitchell 79] Mitchell, J., Maybury, W., and Sweet, R.
Technical Report, MIT Artificial Intelligence
Mesa Language Manual.
Lab, 1980.
Technical Report CSL-79-3, Xerox Palo Alto
Research Center, April, 1979.
[Dahl & Nygaard 66]
Dahl, O-J, and Nygaard, K.
[Suzuki 81] Suzuki, N.
SIMULA -- An ALGOL. Based Simulation
Inferring Types in Smalltalk.
Language.
In Proceedings of the Eighfh Anrrua/ Principles
Communications of the ACM 9(9):671-678,
of Programming Languages Symposium.
September, 1966.
ACM, 1981.

[DOD 80] United States Department of Defense.

[Tesler 81] Tesler, L.
Reference Manual for the Ada Programming
The Smalltalk Environment.
language
Byte 6(8):90.147, August, 1981.
1980.
[Wulf 76] Wulf, W., London, R., and Shaw, M.
[Goldberg 81] Goldberg, A.J., Robson, D., and Ingalls, D.H,H.
An Introduction to the Construction and
Smalltalk-80: The Language and its
Verification of Alphard Programs.
Implementation.
IEEE Transactions on Software Engineering SE-
1981,
2(4):253-264, December, 1976.
Forthcoming book.

[Ingalls 78] Ingalls, D.H.H.

The Smalltalk-76 Programming System: Design
and Implementation.
In Proceedings of the Fifth Annua/ Principles of
Programming Languages Symposium,
pages 9-16. ACM, January, 1978.

[Ledgard 81 ] Ledgard, H.F.

A Human Engineered Variant of BNF.
S/GPLAN Notices 15(1
0):57-62, October, 1981,

141