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.