Strongtalk: Typ echecking Smalltalk in a Pro duction Environment

Gilad Bracha David Griswold

[email protected] [email protected]

Horizon Technologies of New York, Inc.

38 W. 32nd St., Suite 402,

New York, NY 10001

Abstract tion. Understanding of e ectiveways to adapt such

typing techniques to p olymorphic languages with

subtyping has matured only slowly over the last

TM

Strongtalk is a typechecker for a downward-

decade, b eginning with [Car84]. For this reason

compatible Smal ltalk dialect. It is designed for

among others, languages suchasLISP, Smal ltalk,

large-scale production software development, and

and Self that strive for extreme co de reusability

incorporates a strong, modern structural type sys-

through various forms of p olymorphism have tra-

tem. It not only separates the notions of type and

ditionally foregone the b ene ts of static typing in

class, but also deals with the more dicult issue

favor of the more arbitrary exibility of dynamic

of separating inheritance and subtyping using the

typing where all typ es are veri ed on-the- y dur-

notion of inherited types [CHC90, Bru93a ] to pre-

ing execution.

serve encapsulation. Strongtalk integrates inherited

types, metaclasses, blocks and polymorphic methods

Anumb er of attempts [Suz81, BI82, GJ90] have

into a highly usable, ful l-scale language.

b een made to retro t a static typ e system to

Smal ltalk. Most of these e orts have b een signif-

icantly complicated by the extraordinary require-

1 Intro duction

ment that they typ echeck large b o dies of existing

Smal ltalk co de that were written without any no-

It is widely accepted that a strong, static typ e sys-

tion of static typ e safety in mind.

tem for a programming language has imp ortant

This pap er describ es a new typ echecker for

b ene ts, including increased reliability, readability,

Smal ltalk, called Strongtalk, that has b een designed

and p otentially p erformance. However, an inad-

with a quite di erent set of goals in mind. It is the

equate typ e system can constrain the exibilityof

b elief of the authors that the challenge of the next

a language, and thus its expressiveness.

decade will b e to adapt the high-pro ductivity pro-

Static typing allows the typ e safety of source

gramming styles of languages like Smal ltalk to the

co de to b e completely determined b efore execu-

very di erent rigors of very-large-scale software de-

velopment, where issues such as encapsulation b e-

0 TM

Strongtalk is a trademark of Horizon Technologies

come more critical.

of New York, Inc.

App eared in pro ceedings of the ACM Conference on

Accordingly, Strongtalk is an attempt to take ad-

Ob ject-Oriented Programming: Systems, Languages,

vantage of recenttyping advances by de ning a

and Applications OOPSLA 1993.

new highly-encapsulated, pro duction-oriented di-

c

1993 ACM. Copied by p ermission.

alect within the Smal ltalk language framework.

Smal ltalk has b een chosen as the base language  preserves the subtyp e relationships b etween

not only b ecause of its widespread acceptance and classes de ned by the Smal ltalk metaclass hi-

erarchy, and relates them to the typ es of their the availability of mature incremental develop-

instances. mentenvironments, but b ecause it p ossesses sev-

eral crucial features: extreme simplicity, garbage-

 provides facilities for dynamic typing.

collection, and literal rst-class functions, in the

form of blo cks.

The following sections include a discussion of some

3 Design Issues

of the imp ortant issues addressed by the Strongtalk

design, followed by an exploration of the typ e sys-

tem itself. After the typ e system has b een in-

The language designer should be familiar

tro duced, our exp eriences with it are presented,

with many alternative features designedby

followed by a section relating Strongtalk to other

others, and should have excel lent judge-

work. Finally,we present our conclusions.

ment in choosing the best and rejecting

any that are mutual ly inconsistent.... One

thing he should not do is to include un-

2 Typ e System Overview

tried ideas of his own. His task is consol-

idation, not innovation.

C.A.R. Hoare

Before b eginning our discussion of the design is-

sues that have shap ed Strongtalk,we present a brief

list of its ma jor attributes for those who wish an

Typ e systems have a deserved reputation for b e-

overview. The Strongtalk typ e system

ing notoriously dicult things to design and reason

ab out. One of the motivations for the development

 has a purely structural rather than name-

of Strongtalk was a feeling of dissatisfaction with

based form, which provides for exible and

the usability of widely available statically-typ ed

complete separation of the subtyp e and sub-

ob ject-oriented languages. When coming from a

class lattices, while using the concept of

dynamically-typ ed background, one can easily end

brands [Nel91] to provide a notion of typ e

up feeling that the \devil is in the details."

identity.

Although \checking" typ es may sound to the unini-

 includes parameterized typ es and classes

tiated like a straightforward task, a straightforward

b ounded and unb ounded quanti cation.

typ e system can enormously complicate such seem-

ingly mundane tasks as passing an array of strings

 supp orts p olymorphic messages messages

to a metho d that needs a read-only arrayofany

whose typ e signatures are parameterized bya

typ e of ob ject. Whenever you place strict limits

typ e argument, with a exible programmer-

on programmers who are accustomed to none at

controlled mechanism for automatically infer-

all, you must b e very careful indeed that you have

ring values for the typ e parameter.

anticipated and provided for e ectiveways of ex-

 distinguishes inheritance from subtyping,

pressing solutions to a great and subtle varietyof

which is imp ortantforanumb er of forms

common programming problems.

of co de sharing, by incorp orating a tractable

form of the recent notion of inherited typ es In this section we will lay the groundwork for a

[Bru93a, CHC90, CCHO89], which are esp e- presentation of the Strongtalk typ e system by dis-

cially useful for describing abstract data typ e cussing our ma jor design goals, and by drawing

ADT hierarchies. attention to a numb er of the not-so-obvious issues

classes that supp ort the proto col of another class, that can profoundly a ect the expressiveness of an

without inheriting from it, and this can b e dicult ob ject-oriented typ e system.

or imp ossible to do in name-based typ e systems if

you do not control the source co de for that class,

3.1 Compatibility or if you are working in a single-inheritance lan-

guage. A third shortcoming of all widely available

statically-typ ed OO languages is extremely awk-

Although Strongtalk is not designed to typ echeck

ward supp ort for higher-order messages suchasit-

existing Smal ltalk co de without mo di cation, nei-

erators and other user-de ned control structures.

ther is it intended as an incompatible language

extension. Our goal has b een to eliminate the

Strongtalk is designed to circumvent these sorts of

risk that develop ers have traditionally had to as-

awkward situations. In the rst and third situa-

sume when switching to a new, untried language.

tions describ ed ab ove, we take advantage of the

Weachieve this through `downward compatibility',

simple but p owerful combination of strongly-typ ed

which means that Strongtalk co de can always b e

blo cks, and p olymorphic signatures for the higher-

trivially converted to Smal ltalk, but not necessarily

order metho ds that take them as arguments. Ex-

vice-versa. Using downward compatibility as our

amples of this technique will b e presented in the

b enchmark has the b ene ts of giving us some lee-

exp erience section.

way to de ne a very clean typ e system, while guar-

To deal with the second problem describ ed ab ove,

anteeing adopters of Strongtalk that at any p oint

they can switch backtoSmal ltalk if they so desire, Strongtalk has a structural typ e system. In

without reco ding. Other than three trivial transla- Strongtalk, an ob ject can b e passed anywhere as

long as its static typ e is known to supp ort the nec-

tions for manipulating uninitialized variables and

essary proto col, regardless of its class. A way of ex-

dynamic typ echecking, no co de transformation is

plicitly de ning proto cols, and enforcing class sup-

p erformed.

p ort of them, is also provided.

The Strongtalk prepro cessor pro duces typ esafe

Smal ltalk-80 co de that preserves indentation, com-

ments, and typ e annotations.

3.3 Typ e Inference

Some recent languages, suchasTS [GJ90], and

3.2 Expressiveness

ML [MTH90] include features to automatically in-

fer variable and return typ es. Such features would

Smal ltalk is an unusually exible and expressive b e convenientinatyp e system for a language like

language. Anytyp e system for Smal ltalk should Smal ltalk, which lacks any sort of typ e annotations.

place a high priority on preserving its essential a- However, Strongtalk do es not p erform general typ e

vor. inference.

Several of our design goals for Strongtalk involve There are numb er of reasons for this. In a lan-

providing b etter typing solutions for situations we guage like ML, which has no concept of subtyp-

have found awkward in other languages. One of ing, typ e inference can b e well-de ned for any ex-

these situations has to do with the fact that stati- pression. However, for ob ject-oriented languages

cally typ ed languages often have diculty express- typ e inference is considerably more complicated.

ing useful return typ es for metho ds that may re- Awell-de ned language sp eci cation that includes

turn values of variable typ e, or when several re- typ e inference should b e able to either guaran-

turn values are necessary. A second such situation tee that all typ es can b e correctly inferred, or

stems from the fact that often one needs to design provide a clear statement of what expressions

hierarchies. can have their typ es inferred, and which cannot.

State-of-the-art ob ject-oriented typ e inference al-

Although from an encapsulation p ersp ective this is

gorithms that meet these criteria either require

obviously desirable, all dynamically-typ ed ob ject-

non-lo cal co de analysis to do complete typ e infer-

oriented languages, and many statically-typ ed

ence [PS91a, PS91b], or are not capable of dealing

ones, either cannot detect such encapsulation vi-

with realistic programs [Hen91].

olations, or intentionally allow them.

Another consideration a ecting our decision to

The reason why such co de is allowed in some

avoid typ e inference is that at b est typ e inference

statically-typ ed languages is that there is an imp or-

is little more than a convenience when writing a

tant and fundamental tradeo b etween encapsula-

program, and at worst a program for which many

tion and certain forms of co de reuse via inheritance.

typ es are inferred can b e harder to read, since typ e

Non-lo cal co de analysis can determine that some

annotations clarify the source text. Programs are

kinds of dangerous interface changes during inher-

more often read than written.

itance such as removing supp ort for a message,

or arbitrarily changing the typ e of a message ar- A browser that can infer typ es and then insert them

gument are valid as long as the current pattern of into the source text would solve this problem, but

instance usage indicates that suchinterface changes in general for structurally-typ ed languages the in-

will not create typ e-safety lo opholes. ferred typ es can b e complex, anonymous interface

signatures that are not suitable for human con-

There are a numb er of problems with such non-

sumption [Cur90].

lo cal typ e analysis from an encapsulation p ersp ec-

tive. First of all, it means that changes in the bodies

of metho ds outside of a class de nition can cause

3.4 Encapsulation

it to b ecome invalid. It also means that in general

the source co de for the entire system must b e avail-

One of the ma jor reasons wehave adopted a

able. This can b e a ma jor problem in commercial

requirement of `downward' rather than `upward'

environments, where it is imp ortant to b e able to

compatibility is that it allows us to enforce a much

determine the typ esafetyofchanges to a class that

stronger notion of encapsulation in our typ e sys-

is used across many organizations, b efore release.

tem. As mentioned in the intro duction, it is likely

that encapsulation issues will b ecome much more

In addition, non-lo cal typ e analysis intro duces sig-

imp ortantasSmal ltalk continues its move from the

ni cant engineering diculties into the typ echecker

research to the pro duction world.

design. For example, changing the b o dy of a

metho d in a sup erclass requires re-typ echecking the

By encapsulation we mean that mo di cations to

metho d in the context of every sub class that in-

the implementation of a class that do not a ect its

herits the metho d. Such requirements complicate

public or sub class-visible b ehavior should not cause

the task of pro ducing an implementation resp on-

co de elsewhere to break where b ehavior includes

sive enough for interactive, incremental develop-

b oth the typ ed message interface and external se-

ment.

mantics of the class. When di erent organizations

dep end heavily on one another's class libraries,

From the time the encapsulation/unrestricted-

this is obviously a desirable prop erty. While se-

inheritance tradeo was rst recognized until fairly

mantic sp eci cation techniques are not nearly ma-

recently it has b een considered an unavoidable re-

ture enough to enforce full semantic encapsulation,

sult of the subtle distinction b etween sub class and

an appropriate typ e system can prevent imp ortant

subtyp e relationships, b ecause it seems to o ccur in

kinds of encapsulation violation, at the cost of im-

situations where it is handy to de ne a sub class p osing a more discipline d structure on inheritance

whose instances are not `substitutable' for sup er-

class instances.

+

However, recentwork b eginning with [CCH 89]

has shown that there are forms of non-subtyp e-

compatible inheritance that do not violate encap-

sulation. Strongtalk supp orts a form of such in-

heritance, F-b ounded quanti cation, through the

mechanism of inherited typ es. Future work in sp ec-

i cations may pro duce other such forms of inher-

itance. The architecture of the Strongtalk typ e-

checker, b ecause it do es not assume subtyp e com-

patibilitybetween a class and its sup erclass, should

be well-p ositioned to supp ort such extensions.

To put this into p ersp ective, Figure 1 shows where

various ob ject-oriented languages fall on the sp ec-

trum of inheritance exibilityby inheritance ex-

ibilitywe are referring sp eci cally to the kinds of

changes allowed to message signatures during in-

heritance. At the top of the table are languages

that allow metho ds to b e added and overridden in

sub classes, but which allownochanges of any sort

to a metho d interface in a sub class. At the b ottom

of the table are dynamically-typ ed OO languages,

which allowany sort of interface change, including

removal of messages. Languages in all categories

except for the b ottom one are typ esafe languages.

The b oundary ab ove the second category from the

b ottom represents a conceptual divide b elow which

atyp esafe language cannot go without violating en-

capsulation. Our goal has b een to place Strongtalk

at a p ointaslow in this table as p ossible, without

crossing that divide.

Although the ab ove design issues must inevitably

b e assessed di erently for di erent development

needs, we feel that a typ e system with Strongtalk's

characteristics will b e well-suited to a very large class of pro duction applications.

Message signature changes allowed during Inheritance Language

No changes are allowed C++, Mo dula-3

Changes that are subtyp e compatible are allowed Trellis

Changes that are inherited typ e compatible are allowed Strongtalk

Future typ e systems ?

Changes that can b e shown to b e typ esafe with non-lo cal typ e analysis are allowed TS, Ei el

All changes are allowed Smalltalk, Lisp

Figure 1: Languages categorized by inheritance exibility

4 The Typ e System

proto col PlanarPoint

4.1 Proto cols

x^.

x: ^.

y^. In Strongtalk, the typ e of an ob ject is known as a

y: ^.

protocol. This term is often used informally, within

+ ^.

the Smal ltalk community, to denote the set of mes-

class BasicPlanarPoint

sages to which an ob ject resp onds.

instance var x .

A Strongtalk proto col re nes this traditional no-

instance var y .

tion in several ways. In addition to the names

class metho ds

of the messages, the typ es of their arguments and

new ^

the typ es of the ob jects they return are included,

^sup er new init.

by means of typ e annotations, given b etween an-

instance metho ds

gle brackets. We shall use the term interface to

init

describ e this collection of messages and typ e infor-

x := y:= 0.

mation. A proto col has additional structure, which

x^

we discuss in section 4.3. However, the interface

^x.

of an ob ject is always determined by its proto col.

x: xval

x := xval. When the distinction b etween interface and proto-

y^

col is not essential to the exp osition, we will use

^y.

the general term type.

y: yval

Figure 2 shows PlanarPoint, a proto col for p oints

y := yval.

in the plane. To simplify exp osition, we use a

+p ^

form of pseudo-co de, not the concrete syntax of

^self class new x: self x + p x

Strongtalk. The proto col supp orts ve messages;

y:self y + p y.

four for instance variable access, and one to take

Figure 2: Points in the plane

the sum of two PlanarPoints. The caret ^ is used

to distinguish the declaration of the message return

typ e. The sp ecial typ e identi er Self is interpreted

as meaning the proto col of the receiver.

class SpatialPoint Figure 2 also shows a class, BasicPlanarPoint, that

sub classOf:BasicPlanarPoint

implements the PlanarPoint proto col. In fact, we

instance var z .

did not have to de ne the PlanarPoint proto col ex-

instance metho ds

plicitly.For every class, Strongtalk also implicitl y

z^

de nes a proto col which describ es the instances of

^z.

the class. The full name whichmay b e shortened

z: zval

of this implicit proto col is the name of the class,

z := zval.

followed by the word proto col; in this case Basic-

+p ^

PlanarPoint proto col.

^ sup er + p z:self z + p z.

Figure 3: Points in space

4.2 Subtyping and Typ e Inheritance

Having intro duced some basic terminology and the interfaces of instances and their classes must

conventions, wenowmove on to a short review of also b e mutually recursive.

the notions of subtyping and type inheritance. An

The metho d new in gure 2 illustrates the treat-

example will help make this clear.

ment of class metho ds in Strongtalk. The metho d's

Figure 3 shows SpatialPoint, a sub class of Basic- return typ e is the sp ecial typ e identi er Instance.

PlanarPoint. SpatialPoint adds a z co ordinate, and Within a class metho d or message, Instance refers

mo di es its metho ds to re ect the semantics of ad- to the interface of instances of the receiver. This is

dition for spatial p oints. distinct from Self, which always refers to the inter-

face of the receiver itself; in a class metho d, Self is

The typ e SpatialPoint proto col is not a subtyp e of

the interface of the class, not of its instances. Sim-

BasicPlanarPoint proto col. Subtyping means that

ilarly, in the context of instance metho ds, the typ e

memb ers of a subtyp e can always b e substituted

Self refers to the interface of the receiver, while the

where memb ers of a sup ertyp e are exp ected. If

typ e Self class refers to the interface of the receiver's

one invokes + on a BasicPlanarPoint, one can pass

class.

in another BasicPlanarPoint as the argument. By

The b o dy of the metho d invokes the new metho d contrast, + on a SpatialPoint demands a Spatial-

inherited from the sup erclass, using the standard Point, so that the metho d can access the z co or-

Smal ltalk sup er construct. Since this metho d also dinate of the incoming parameter. Therefore, one

returns Instance,we know that in fact, the returned cannot use a SpatialPoint where a BasicPlanarPoint

ob ject is an instance of the receiver. Instances of is exp ected. Nevertheless, the two proto cols share

the receiver are always inherited typ es of BasicPla- a similar recursive structure. This relationship is

narPoint. It is therefore safe to send the init mes- known as type inheritance, and wesay that Spatial-

sage, which is supp orted by BasicPlanarPoint. The Point proto col is an inherited typ e of BasicPlanar-

init metho d returns an ob ject of typ e Self. Since Point proto col.We refer the reader to the literature

+

this is an instance metho d, Self is the interface of [Bru92, Bru93a, CHC90, CCH 89, CCHO89] for a

the instance, which is an instance of the receiver, deep er discussion of the meaning of typ e inheri-

and therefore has typ e Instance. As a result, the tance.

entire metho d is well-typ ed.

During inheritance, the interface of b oth instance

4.3 Instance, Self class and the Nature of

and class maychange. Notice that changing the

Proto cols

interface of one automatically induces a change in

the interface of the other. This means that for pur-

Smal ltalk is a re ective system. One consequence

p oses of inheritance, the interfaces of instance and

of this is that classes are themselves ob jects, which

class cannot b e separated, but must b e packaged

can send and receive messages. Furthermore, users

together.

can de ne metho ds not only for the instances of

A proto col is in fact such a package. It represents

classes, but for classes themselves.

a pair of mutually recursive interfaces, one for

The de nitions of instances and their classes are

instances, and one for the class. One of these in-

always mutually recursiveinSmal ltalk. A class

terfaces is distinguished as the primary interface.

always supp orts at least one metho d for creating

An ob ject whose typ e is a proto col, resp onds to the

new instances. Conversely, all instances supp ort

messages given by the proto col's primary interface.

1

the metho d class which returns their class . Hence,

In the proto col of a class' instances, the interface

of instances is considered primary. In the proto col

1

We will ignore the p ossibil ityofoverriding this metho d

of the class itself, the class interface is primary.

to do something completely di erent.

proto col. Mathematically, a proto col is a generator for a pair

of interfaces. This generator is then used for typ e

inheritance, in a manner analogous to the use of

generators for value inheritance [CHC90]. When

4.4 The Status of nil

used as the typ e of an instance, weinterpret the

reference to the proto col to mean selecting the rst

In Smal ltalk, nil denotes a reference to an unde ned

primary interface from the xp oint of the proto-

ob ject. The value of an uninitiali zed instance vari-

col. The fact that typ es are interpreted as b oth

able is always nil. Sending a message to nil typically

generators and interfaces, according to context, has

results in a run-time error, and this is a common

b een noted in [BH91].

cause of program failure. Unfortunately, determin-

ing that all instance variables are prop erly initial-

ized requires exp ensive, non-lo cal data ow analy-

4.3.1 The Metaclass Hierarchy and its

sis.

Typing

We consider statically detecting invalid access to

In this section, we brie y review the notion of

nil in a language with p ervasive aliasing suchas

metaclasses in Smal ltalk, and present our treat-

Smal ltalk as b eyond the purview of the typ e sys-

ment of the typing of metaclasses. Before delv-

tem. If desired, a separate data ow analysis to ol

ing into the Smal ltalk metaclass hierarchy, readers

e.g., [PS91b] may b e used for such purp oses.

should b e aware of two facts. First, this section

can b e ignored without loss of continuity. Second,

the topic is recognized as b eing dicult for those

4.5 Brands

new to Smal ltalk [BO87].

In Smal ltalk every ob ject is an instance of some

A disadvantage of structural typing is the risk of se-

class. Since classes are ob jects, it follows that each

mantically incompatible ob jects sharing a syntactic

class must itself b e an instance of a class. Indeed,

typ e, and not b eing distinguished by the typ e sys-

each class is an instance of its own metaclass. For

tem. To rectify this situation, we wish to supp ort

example, Object is an instance of the metaclass

a notion of typ e identity, within the framework of

Object class. Object class is then an instance of

structural typing. This can b e accommo dated us-

Metaclass, which is an instance of Metaclass class,

ing the concept of brands,asintro duced in Modula-

which is an instance of Metaclass. This circularity

3 [Nel91].

prevents an in nite regress of meta-meta-... meta-

Brands are merely tags added to typ es to distin- classes.

guish them from one another. To prevent acciden-

The typ e structure of an instance, its class and

tal matching, brands are supplied only by the sys-

metaclass is as follows. Instances of a class X have

tem unlike Modula-3.

typ e Xproto col. The ob ject representing the class

To create multiple implementations of a branded at run time has a distinct typ e, since it may sup-

proto col users may declare that a class supp orts p ort sp eci c metho ds de ned by the user as class

that particular proto col. This has the e ect of in- metho ds in the de nition of class X. This typ e is X

tro ducing the proto col's brand into the typ e of the class proto col. Sending the class message to an in-

class' instances. In addition, the system will ver- stance of X yields an ob ject of typ e X class proto col.

ify that the class do es indeed provide metho ds that Sending this ob ject the message class, yields the

implement the messages sp eci ed by the proto col, metaclass class of a class X class. All metaclasses

with the correct typ e signatures. are considered to have the same typ e, Metaclass

to tail.

generic proto col List[T]

add:.

Strongtalk provides a typ ecase construct for dy-

head ^.

namic typ echecking. As noted in [ACPP89], the

tail ^.

ability to dynamically determine the typeofan

map: ^

ob ject is essential in many circumstances, but in

where S :: actual arg:1 returnTyp e

a structural typ e system this can b e exp ensive. In

practice, most proto cols are branded, and the han-

Figure 4: A generic class.

dling of these can b e sp eeded up signi cantly.

The message map: utilizes parametric p olymor-

4.6 Blo cks

phism, and is describ ed in section 4.8.

Blo cks are ob jects, likeeverything else in Smal ltalk.

A generic maybeinvoked by passing it actual type

They resp ond to messages suchasvalue, which

parameters, e.g., List[Integer]. The actual parame-

causes a blo ck with no arguments to b e evalu-

ters replace the formal ones T in the example in

ated. The precise proto col for a blo ck dep ends

the b o dy of the generic. An invo cation of a generic

up on the numb er of arguments it takes, their

proto col yields a proto col equivalent to the de ni-

typ es A ;:::;A , and the return typ e, R. In

1 n

tion of the generic, substituting the actual parame-

Strongtalk the typ e of such a blo ck is written

ters for the formal ones. Sp ecial care must b e taken

B l ock [A ;:::;A ;^R].

1 n

to prevent recursive generics from leading to in -

nite expansion. The algorithm used is essentially

Blo cks are used as the basis of all control struc-

the one develop ed for POOL [Ame90].

tures in Smal ltalk. One p eculiarity of blo cks is

that blo cks that take no arguments and return a

Strongtalk also supp orts the de nition of generic

b o olean supp ort a sp ecial proto col. This allows

classes. Many of the key classes in the Smal ltalk

their use as a basis for control structures like while

library, suchasArray, are generic. As noted in

lo ops. TS [GJ90] uses a sp ecial mechanism, spe-

section 4.3 ab ove, classes are ob jects in Smal ltalk.

ci c receivers, to handle such cases. We prefer to

Every ob ject has a typ e, which raises the question

provide a sp ecial typ e rule for such blo cks. This

`what is the typ e of a generic class, suchasArray?'.

solution is p ossible, b ecause, unlike TS, we do not

Formally, the typ e of Array is a universally quan-

need to typ echeck the class that de nes blo cks in

ti ed proto col. We do not presently havetyp e ex-

the Smalltalk library see section 5.4.

pressions for suchatyp e in the language. We feel

our users mayhave diculty grasping suchtyp es.

Instead, we require that all references to a generic

4.7 Generics

class b e invo cations e.g., Array[String]. Suchan

invo cation yields a class. In fact, all invo cations

A generic is an abstraction over typ es, such as the

of Array yield the very same ob ject. However, the

generic proto col shown in gure 4. List is a generic

typ e of a generic class invo cation is an ordinary

protocol. It describ es the typ e of linked lists with

proto col. Cases where this rule is to o restrictive

elements of anytyp e T. The head message is in-

almost never arise in application programming.

tended to return the rst element of a list. If the

list is empty, its rst element is unde ned, and so

the typ e returned is a union of the elementtyp e T

and Nil, the typ e of the unde ned ob ject. This will

force users to test for an unde ned ob ject dynami-

cally, as describ ed b elow. Similar comments apply

itself, and several other sizeable libraries. 4.8 Parametric Polymorphism

The usability of a language or typ e system is always

Ob ject-oriented programming typically relies on

dicult to assess b efore its implementation is com-

inclusion polymorphism. In addition to inclusion

pleted. Following are some of the interesting issues

p olymorphism, Strongtalk supp orts a form of para-

that have emerged from our use of Strongtalk.

metric polymorphism similar to that of [CW85].

Parametric p olymorphism is useful in cases where

5.1 The value of Blo cks

the typ e returned by a message send is dep endent

on the typ e of the actual arguments, a common o c-

currence in Smal ltalk. The map: message in gure 4

Prop onents of functional programming styles have

demonstrates the use of parametric p olymorphism.

long argued that the combination of higher-order

The map: message takes an argument whichisa

functions and literal rst-class functions is enor-

blo ck. The blo ckistobeinvoked successively on

mously expressive. Blo ck ob jects are Smal ltalk's

each element of the list, and a list of the results is

equivalent construct. Blo cks are used for many

to b e returned. The blo ckmust take as input an

things in Smal ltalk: de ning extensible control

element of same typ e as the elements of the list.

structures, callbacks, simple exception handling

The typ e of the elements of the list b eing returned

e.g., Dictionary at:ifAbsent:, etc.

dep ends up on the return typ e of the blo ck. The

Wehave encountered a surprisingly handy in-

typ e declaration for map: sp eci es this dep endency

teraction b etween blo cks and static typing that

in terms of a typ e variable, S. The ordinary mes-

mitigates much of the awkwardness wehave en-

sage declaration is suxed bya where clause that

countered when using other statically-typ ed pure

states that S is to b e derived from the return typ e

ob ject-oriented languages. Blo cks, in conjunction

of actual argumentnumb er 1. A sp ecial syntax is

with Strongtalk's p olymorphic messages, provide a

used, allowing precise sp eci cation of how to in-

numb er of convenient idioms shown in gure 5

fer the typ e arguments from the typ es of the value

that Strongtalk can easily typ e.

arguments. Map: can b e invoked as an ordinary

metho d, and there is no need to pass a typ e argu-

All of these things can b e done easily in Smal ltalk,

ment explicitly at call sites. This syntactic treat-

but can b e dicult to do cleanly or eciently in

ment of explicitly p olymorphic metho ds is some-

statically-typ ed languages without blo cks. The

what novel. Its advantage is that it allows us to

rst two examples are easy to typ e in Strongtalk;

infer actual typ e arguments without implementing

the second two require p olymorphic messages for

a sophisticated typ e inference mechanism. While

full typ e safety. Figure 6 shows the signature for

some may nd the syntax awkward, it places the

the at:ifAbsent: message from the Dictionary class.

syntactic burden on the relatively infrequent mes-

The return typ e of the at:ifAbsent: message is a

sage declaration, rather than the more commonly

union typ e , which means that the

used message send construct.

metho d returns either a value from the dictionary,

or a value of typ e which is the return typ e

of whatever blo ck the caller passes in for blk.In

5 Exp erience

this example, the blo ck never yields a value, since

it forces its containing metho d to return; so the

return typ e of the blo ck is the invisible typ e Do es- A Strongtalk implementation has b een completed

ntMatter that Strongtalk gives to expressions that that incorp orates all the features mentioned in this

can never yield a value, which allows our example pap er. A signi cant b o dy of co de has b een written

to typ e correctly. using it, including the Strongtalk implementation

It should b e emphasized that we are not simply

saying that blo cks are nice. The primary p ointis

that having well-typ ed blo cks in a strongly-typ ed

* Alternative or multiple return typ es

language turns out to provide a very convenient

way of expressing solutions to problems that can

dataset computeStats:

otherwise b e complicated byatyp e system. For

[ :median :avg

example, without such a facility, a metho d that

:size j

wants to return either a numb er or an error symb ol,

Transcript

might otherwise require a clumsy and less reliable

show: median printString;

dynamic typ e check.

show: avg printString;

show: size printString;

cr.

5.2 Naming issues with separate typ es

]

and classes

* Blo cks instead of p erform: for callbacks

One of the problems with separate typ e and class

button whenPressedDo:

hierarchies has to do with the p otential for a sig-

[Transcript show: 'Yow!'; cr].

ni cantly larger resulting namespace, b ecause of

separate names for classes and their proto cols. In

* Control structures as value-yielding expressions

practice, the namespace is indeed somewhat larger,

but wehave found that not only is the increase eas-

sky := daytime

ily manageable, it is very desirable, since the new

ifTrue: [light]

names tend to b e for imp ortantinterfaces that are

ifFalse: [dark].

only implicit in dynamically typ ed hierarchies, and

which deserve far more explicit attention during

* Simple exception handling

b oth the design and library browsing pro cesses.

Transcript show: myDictionary

Wehave develop ed a few rules of thumb that seem

at: key

to work well as guidelines for assigning names for

ifAbsent: [^self ] .

those proto cols that need to b e distinct. First of

all, having a pithy name for the proto col is more

Figure 5: Blo ck idioms

imp ortant, since it will b e widely used in declara-

tions, whereas the class name is generally used only

at the instantiation p oint, whichmaywell b e hid-

den b ehind encapsulation barriers from the user of

the instance.

It is p erfectly acceptable to simply use the proto col

at: key

automatically de ned by a class if it seems unlikely

ifAbsent: blk

that the proto col will b e supp orted by other non

^

sub classes. In Strongtalk, this do es not prevent

where X :: actual arg: 2 returnTyp e

other classes from supp orting that proto col, b e-

Figure 6: Dictionary[KEY,VALUE] at:ifAbsent: sig-

cause of structural typing. It can, however, cause

nature

some confusion if the proto col will have many al-

ternative implementations, so if it app ears at all

likely that other implementations will exist, pro-

vision for a separate name for the proto col is en- o ccurs whenever a new library must b e learned.

couraged. This can b e accomplished by declaring

In the authors' p ersonal exp erience with the stan-

a separate proto col, or simply by creating a typ e

dard Smal ltalk class hierarchy, one of the largest

alias for the automatic proto col.

imp ediments to understanding is the dicultyin

nding out exactly what argumentvalues metho ds

allow, and what values they return. Comments are

5.3 Prototyping with typ es

not enough! Typing information provides an in-

valuable form of machine-veri able do cumentation.

A commonly heard ob jection to strongly-typ ed

Browsers that understand the typ e system could

ob ject-oriented languages is that having to worry

also include p owerful features that would allowa

ab out the typ es of things gets in the way during

programmer to p ointatanyvariable or expression

the prototyping pro cess. Most of these opinions

and ask 'Show me what I can do with this ob ject

are based on little or no information, since very few

at this p oint.'

p eople haveever had a chance to use a statically-

typ ed language in an incremental programming en-

An even more imp ortant p oint is that although the

vironment. Although such matters are dicult to

inheritance discipline imp osed by the Strongtalk

analyze precisely, in our exp erience the opp osite

typ e system can b e viewed as restrictive, it is re-

has app eared to b e true.

strictiveinaway that contributes greatly to the

comprehensibility of a class hierarchy. Strict inter-

Even a prototyp e must function in some fashion,

face inheritance relationships are a critical rst step

and this requires design and debugging work just

towards the larger goal of strictly enforced seman-

as with any program. Although some of the er-

tic relationships. Hierarchy designers who adhere

rors a typ echecker will nd are ones that would

to these stronger disciplines will earn the heartfelt

b e encountered during testing, catching even these

thanks of those who must understand and reuse

typ es of errors at compile time can save quite a bit

their co de.

of time. For example, if a metho d is called with

an argument of the wrong typ e, the ob ject is of-

ten passed around to a remote part of the system

5.4 Typing the standard Smal ltalk li-

b efore a message that is inappropriate for its typ e

brary

is actually sent to it. Fixing this during testing

requires a tedious backtracking e ort to nd out

where the original error o ccured. Atyp echecker

Obviously,ifStrongtalk is to b e compatible with

detects these errors at the place they o ccur.

standard Smal ltalk environments, wemust havea

way of dealing with the typ es of ob jects in the

At a higher level, fo cusing on typing issues even at

existing libraries. Because of its strict encapsula-

the earliest stages of development can help enor-

tion, Strongtalk do es not need access to the imple-

mously in clarifying the interfaces and resp onsibil-

mentations of those libraries; we need only declare

ities which drive the design pro cess. The larger the

their proto cols. Co ok has p ointed out [Co o92] that

pro ject, the greater the b ene t.

although there are a numb er of areas where the

Wehave also encountered a somewhat more subtle Smal ltalk class hierarchy do es not have subtyp e re-

b ene t of strong typing and stronger encapsulation lationships, it in fact implicitly contains the incom-

that maywell in the long run turn out to havean plete skeleton of a clean subtyp e lattice. Our origi-

even greater impact. It has b ecome well accepted nal proto cols for the Strongtalk libraries were some-

that one of the most dicult parts of the ob ject- what similar. Subsequently,wehave adopted the

proto cols from Co ok's corrected Collection hierar- oriented learning curve to climb is understanding

chy b ecause of their stronger prop erty of semantic large class libraries. Furthermore, this problem re-

global analysis, however, and is not well suited to substitutibility.

incremental development.

An interesting b ene t of the fact that Strongtalk

can typ echeck based on purely lo cal information

is that it signi cantly eases integration with exist-

6.2 Inherited Typ es

ing Smalltalk classes. A class declaration is sp ec-

i ed, and this supplies all the information needed

The notion of inherited typ es has app eared in var-

by Strongtalk. Typ echeckers based on non-lo cal

ious related forms in several ob ject-oriented lan-

information are faced with a much more dicult

guages. Emerald [BH91] incorp orates a similar no-

task when trying to integrate with non-typ echecked

tion called type matching. Emerald do es not sup-

classes and this is necessary, since no typ echecker

p ort class inheritance however. POOL [Ame90]is

has ever succeeded in typ echecking all the classes

the imp erative language most similar to Strongtalk

in the existing Smalltalk hierarchy. Without the

in its typ e system.

abilitytotyp echeck all sup erclass source co de, non-

lo cal typ echeckers cannot safely allow the very ex-

The theoretical foundations for inherited typ es

+

ibility they were designed to preserve.

were rst given in [CCH 89] and [CHC90]. The

language ABEL [CCHO89] incorp orated these

ideas in a functional framework. Our typ e system

is mainly based on the typ e rules given by Bruce

6 Related Work

for the language TOOPL [Bru93a]. The di erences

between the two systems re ect their di erent pur-

6.1 Typ echecking Smalltalk

p oses. TOOPL is a theoretical language designed

to facilitate fundamental understanding of ob ject-

There have b een several e orts to intro duce static

oriented languages and their typing. Its typ e sys-

typ echecking or typ e inference to Smal ltalk.

tem has b een proven sound and for TOOPLE

These e orts have had di ering ob jectives, result-

[Bru93b], a close relative, typ echecking has b een

ing in di erent approaches to the problem.

proven decidable. Wehave not formally proven

such prop erties for our system. In contrast, we

Early e orts met with limited success [Suz81,

haveintegrated the rules into a realistic, imp era-

BI82]. TS [JGZ88, Gra89, GJ90] is geared toward

tive language TOOPL mo dels instance variables

typ echecking Smal ltalk in its entirety, and toward

functionally. Wehave added supp ort for abstract

optimization. The scop e of Strongtalk is less ambi-

classes, generics, dynamic typ echecking, multiple

tious in this resp ect. Certain Smal ltalk programs

levels of visibility, and explicit p olymorphism.

that are accepted by TS will not b e accepted by

Strongtalk. The advantage of our approachisthe

preservation of encapsulation. In TS, inherited

co de is retyp echecked in the context of the inher-

7 Conclusions

iting class, with all the concommitant advantages

and disadvantages outlined in section 3.4.

Wehave describ ed Strongtalk, a strongly-typ ed di-

alect of Smal ltalk. This dialect is essentially com- Palsb erg and Schwartzbach [PS90, PS91c, PS91a,

patible with the standard Smal ltalk-80 language. PS91b] develop ed a system that infers typ es for

The typ e system di ers from other e orts to typ e- Smal ltalk without relying on typ e annotations at

check Smal ltalk in that it preserves encapsulation. all. The system is useful for analyzing a com-

Encapsulation is crucial in large scale applications, pleted application prior to nal release, to shake

out remaining typ e errors, and can provide useful and also helps the system p erform incremental

information for optimization. The system relies on typ echecking quickly. As a result, the advantages

subtyping. In Proc. of the Joint of the incremental programming environmentmay

ACM Conf. on Object-OrientedPro- b e more easily combined with those of static typ e-

gramming, Systems, Languages and checking.

Applications and the European Confer-

The typ e system demonstrates the practical util-

ence on Object-OrientedProgramming,

ity of recent advances in the typ e theory of ob ject-

pages 161{168, Octob er 1990.

oriented programming languages. The notion of in-

herited typ es has b een integrated into a full- edged

[BH91] Andrew P. Black and Norman Hutchin-

imp erative language, including generics, p olymor-

son. Typ echecking p olymorphism in

phic metho ds, a practical approachtotyping meta-

Emerald. Technical Rep ort CRL91/1

classes, and dynamic typ echecking. This sp ectrum

Revised, DEC Cambridge Research

of language features has not b een combined b efore.

Lab, July 1991.

There is a tradeo b etween encapsulation and the

[BI82] Alan H. Borning and D. H. Ingalls. A

exibility of the typ e system. Strongtalk imp oses

typ e declaration and inference system

a stronger disciplin e than other Smal ltalk typ e sys-

for Smalltalk. In Proc. of the ACM

tems. Nevertheless, Strongtalk supp orts a richstyle

Symp. on Principles of Programming

of programming dicult to obtain in other lan-

Languages, pages 133{141. Asso ciation

guages with signi cant static typ echecking. The

for Computing Machinery, 1982.

tradeo is valuable b ecause it allows, for the rst

[BO87] Alan H. Borning and Tim O'Shea.

time, practical, pro duction use of a strongly-typ ed

Deltatalk: An empirically and aes-

Smal ltalk system.

thetically motivated simpli cation of

the Smalltalk-80 language. In Eu-

ropean Conference on Object-Oriented

Acknowledgements

Programming, pages 1{10, 1987.

[Bru92] Kim Bruce. A paradigmatic ob ject-

Wewould like to thank Pierre America for sharing

oriented programming language: De-

his exp erience with generic typ es in POOL.Peter

sign, static typing and semantics. Tech-

Deutsch o ered valuable comments and encourage-

nical Rep ort CS-92-01, Williams Col-

ment. Finally,we wish to thank Ralph Johnson for

lege, January 1992.

his valuable comments on this work. Of course, the

authors are solely resp onsible for the shortcomings

[Bru93a] Kim Bruce. Safe typ e checking in a

of Strongtalk.

statically typ ed ob ject oriented pro-

gramming language. In Proc. of the

ACM Symp. on Principles of Program-

References

ming Languages, January 1993.

[ACPP89] Martin Abadi, Luca Cardelli, Benjamin

[Bru93b] Kim Bruce. Typ echecking in TOOPLE

Pierce, and Gordon Plotkin. Dynamic

is decidable. In Proc. of the ACM

typing in a statically-typ ed language.

Conf. on Object-Oriented Program-

In Proc. of the ACM Symp. on Princi-

ming, Systems, Languages and Appli-

ples of Programming Languages, pages

cations, Septemb er 1993.

213{227, January 1989.

[Car84] Luca Cardelli. A semantics of mul-

tiple inheritance. In Semantics of [Ame90] Pierre America. A parallel ob ject-

Data Types, volume 173 of Lecture oriented language with inheritance and

of Programming Languages, pages 136{ Notes in Computer Science, pages 51{

150, January 1990. 68. Springer-Verlag, 1984.

+

[Gra89] Justin Owen Graver. Type-Checking

[CCH 89] Peter Canning, William Co ok, Walt

and Type-Inference for Object-Oriented

Hill, John Mitchell, and Walter Oltho .

Programming Languages. PhD the-

F-b ounded p olymorphism for ob ject-

sis, University of Illinois at Urbana-

oriented programming. In Proc. of

Champaign, 1989.

Conf. on Functional Programming Lan-

guages and Computer Architecture,

[Hen91] Andreas V. Hense. Typ e inference for

pages 273{280, 1989.

O'Small. Technical Rep ort A 06/91,

Fachb ereich Informatik, Universitaet

[CCHO89] Peter Canning, William Co ok, Walt

des Saarlandes, Octob er 1991.

Hill, and Walter Oltho . Interfaces

for strongly-typ ed ob ject-oriented pro-

[JGZ88] Ralph E. Johnson, Justin O. Graver,

gramming. In Proc. of the ACM

and Laurance W. Zurawski. TS: An

Conf. on Object-Oriented Program-

optimizing compiler for Smalltalk. In

ming, Systems, Languages and Appli-

Proc. of the ACM Conf. on Object-

cations, pages 457{467, 1989.

OrientedProgramming, Systems, Lan-

guages and Applications, pages 18{25,

[CHC90] William Co ok, Walt Hill, and Peter

Novemb er 1988.

Canning. Inheritance is not subtyping.

In Proc. of the ACM Symp. on Princi-

[MTH90] Robin Milner, Mads Tofte, and Rob ert

ples of Programming Languages, pages

Harp er. The De nition of Standard

125{135, 1990.

ML. MIT Press, 1990.

[Co o92] William R. Co ok. Interfaces and sp ec-

[Nel91] Greg Nelson, editor. Systems Program-

i cations for the Smalltalk-80 collec-

ming with Modula-3. Prentice-Hall,

tion classes. In Proc. of the ACM

1991.

Conf. on Object-Oriented Program-

[PS90] Jens Palsb erg and Michael I.

ming, Systems, Languages and Appli-

Schwartzbach. Typ e substitution for

cations, pages 1{15, Octob er 1992.

ob ject-oriented programming. In Proc.

[Cur90] Pavel Curtis. Constraint Quanti cation

of the Joint ACM Conf. on Object-

in Polymorphic TypeAnalysis. PhD

OrientedProgramming, Systems, Lan-

thesis, Cornell University, Department

guages and Applications and the Eu-

of Computer Science, 1990. Also avail-

ropean Conference on Object-Oriented

able as XeroxPARCTechnical Rep ort

Programming, Octob er 1990.

CSL-90-1.

[PS91a] Jens Palsb erg and Michael I.

[CW85] Luca Cardelli and Peter Wegner. On

Schwartzbach. Ob ject-oriented typ e in-

understanding typ es, data abstraction,

ference. In Proc. of the ACM Conf.

and p olymorphism. Computing Sur-

on Object-OrientedProgramming, Sys-

veys, 174:471{522, 1985.

tems, Languages and Applications, Oc-

tob er 1991.

[GJ90] Justin O. Graver and Ralph E. John-

[PS91b] Jens Palsb erg and son. A typ e system for Smalltalk. In

Michael I. Schwartzbach. Static typing Proc. of the ACM Symp. on Principles

for ob ject-oriented programming. Tech-

nical Rep ort DAIMI PB-355, Aarhus

University, Computer Science Depart-

ment, June 1991.

[PS91c] Jens

Palsb erg and Michael I. Schwartzbach.

What is typ e-safe co de reuse ? In Eu-

ropean Conference on Object-Oriented

Programming, July 1991.

[Suz81] Norihisa Suzuki. Inferring typ es in

Smalltalk. In Proc. of the ACM Symp.

on Principles of Programming Lan-

guages, pages 187{199. Asso ciation for

Computing Machinery, 1981.