The Smalltalk-76 Programming System
Design and Implementation

Daniel H. H. Ingalls
XEROX Palo Alto Research Center
Palo Alto, California

Conference Record of the
FIFTH ANNUAL ACM SYMPOSIUM ON
PRINCIPLES OF PROGRAMMING LANGUAGES
Tucson, Arizona
January 23-25, 1978
© Copyright 199x ACM, Inc., Included here by permission

Abstract
This paper describes a programming system based on the metaphor of communicating objects. Experience with a running system shows that this model provides flexibility, modularity and compactness. A compiled representation for the language is presented, along with an interpreter suitable for microcoding. The object-oriented model provides naturally efficient addressing; a corresponding virtual memory is described which offers dense utilization of resident space.
INTRODUCTION
The purpose of the Smalltalk project is to support children of all ages in the world of information. The challenge is to identify and harness metaphors of sufficient simplicity and power to allow a single person to have access to, and creative control over, information which ranges from numbers and text through sounds and images. In our experience, the SIMULA notion of class and instance is an outstanding metaphor for information structure. To describe processing, we have found the concept of message-sending to be correspondingly simple and general. Rather than provide this organization as a "feature" in an existing system, we have taken these two metaphors as the point of departure for the Smalltalk programming language. The result is a lively interactive system which provides its own text editing, debugging, file handling and graphics display on a personal computer.

The Smalltalk language is object oriented rather than function oriented, and this often confuses people with previous experience in computer science. For example, to evaluate <some object>+4 means to present +4 as a message to the object. The fundamental difference is that the object is in control, not +. If <some object> is the integer 3, then the result will be the integer 7. However, if <some object> were the string 'Meta', the result might be 'Meta4'. In this way, meaning rides with the objects of the system, and code remains an abstract form, merely directing the flow of communication. As we shall see, this separation is a key factor in the ability of a system to handle complexity.

THE PRINCIPLE OF MODULARITY
No part of a complex system should depend on the internal details of any other part. The design of the Smalltalk language supports this principle through uniform reference to objects, sending messages to obtain results, and through organization of object descriptions and computational methods into classes. Factoring of information structure and behavior is provided by the implementation of subclassing.

All references in the Smalltalk language are to objects, which may be atomic, or may consist of several named fields which refer in turn to other objects. Though the only truly atomic datum is the bit, it is often appropriate for such simple objects as names and numbers to be considered atomic. For example, in a piece of code which reads the y-coordinate of a point in two dimensions, nowhere should there be instructions such as: "load the second word relative to point p". Such an instruction would not perform properly if it encountered a point represented in polar coordinates.

Communication is the metaphor for processing in the Smalltalk language. Objects are created and manipulated by sending messages. The same model describes activities ranging from ordinary arithmetic to communicating processes in separate machines. The response to a message is implemented by a method, which reads or writes some data field, or sends further messages to achieve the desired response. The communication metaphor supports the principle of modularity, since any attempt to examine or alter the state of an object is sent as a message to that object, and the sender need never know about internal representation. For example, points represented in polar coordinates r and theta would have a method which responds to the message, y, by returning r*theta cos.

The examples in this paper use a syntax which gives higher precedence to messages of fewer arguments. Therefore theta first receives the message cos (remember, cosine is a property of angles, not a function!), and then r receives the message * with one argument, theta's cosine.
Every object in Smalltalk is created as an instance of some class. The class holds the detailed representation of its instances, the messages to which they can respond, and methods for computing the appropriate responses. The only information remaining to be stored in an instance is the set of values for its named fields. The class is the natural unit of modularity, as it describes all the external messages understood by its instances, as well as all the internal details about methods for computing responses to messages and representation of data in the instances.

In the Smalltalk language,