Strongtalk: Typechecking Smalltalk in a Production Environment

Strongtalk: Typechecking Smalltalk in a Production 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 effective ways to adapt such typing techniques to polymorphic languages with subtyping has matured only slowly over the last StrongtalkTM is a typechecker for a downward- compatible Smalltalk dialect. It is designed for decade, beginning with [Car84]. For this reason large-scale production software development, and (among others), languages such as LISP, Smalltalk, incorporates a strong, modern structural type sys- and Self that strive for extreme code reusability tem. It not only separates the notions of type and through various forms of polymorphism have tra- class, but also deals with the more difficult issue ditionally foregone the benefits of static typing in of separating inheritance and subtyping using the favor of the more arbitrary flexibility of dynamic notion of inherited types [CHC90, Bru93a] to pre- typing (where all types are verified on-the-fly dur- serve encapsulation. Strongtalk integrates inherited ing execution). types, metaclasses, blocks and polymorphic methods A number of attempts [Suz81, BI82, GJ90] have into a highly usable, full-scale language. been made to retrofit a static type system to Smalltalk. Most of these efforts have been signif- icantly complicated by the extraordinary require- 1 Introduction ment that they typecheck large bodies of existing Smalltalk code that were written without any no- It is widely accepted that a strong, static type sys- tion of static type safety in mind. tem for a programming language has important This paper describes a new typechecker for benefits, including increased reliability, readability, Smalltalk, called Strongtalk, that has been designed and (potentially) performance. However, an inad- with a quite different set of goals in mind. It is the equate type system can constrain the flexibility of belief of the authors that the challenge of the next a language, and thus its expressiveness. decade will be to adapt the high-productivity pro- Static typing allows the type safety of source gramming styles of languages like Smalltalk to the code to be completely determined before execu- very different rigors of very-large-scale software development, where issues such as encapsulation be- 0TM Strongtalk is a trademark of Horizon Technologies come more critical. of New York, Inc. Accordingly, Strongtalk is an attempt to take ad- Appeared in proceedings of the ACM Conference on vantage of recent typing advances by defining a Object-Oriented Programming: Systems, Languages, and Applications (OOPSLA) 1993. new highly-encapsulated, production-oriented di- c 1993 ACM. Copied by permission. alect within the Smalltalk language framework. Smalltalk has been chosen as the base language • preserves the subtype relationships between not only because of its widespread acceptance and classes defined by the Smalltalk metaclass hi- the availability of mature incremental develop- erarchy, and relates them to the types of their ment environments, but because it possesses sev- instances. eral crucial features: extreme simplicity, garbage- collection, and literal first-class functions, in the • provides facilities for dynamic typing. form of blocks. The following sections include a discussion of some of the important issues addressed by the Strongtalk 3 Design Issues design, followed by an exploration of the type system itself. After the type system has been in- The language designer should be familiar troduced, our experiences with it are presented, with many alternative features designed by followed by a section relating Strongtalk to other others, and should have excellent judge- work. Finally, we present our conclusions. ment in choosing the best and rejecting any that are mutually inconsistent.... One thing he should not do is to include un- 2 Type System Overview tried ideas of his own. His task is consol- idation, not innovation. Before beginning our discussion of the design is- C.A.R. Hoare sues that have shaped Strongtalk, we present a brief list of its major attributes for those who wish an Type systems have a deserved reputation for be- overview. The Strongtalk type system ing notoriously difficult things to design and reason about. 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 flexible and the usability of widely available statically-typed complete separation of the subtype and sub- object-oriented languages. When coming from a class lattices, while using the concept of dynamically-typed background, one can easily end brands [Nel91] to provide a notion of type up feeling that the \devil is in the details." identity. Although \checking" types may sound to the unini- • includes parameterized types and classes tiated like a straightforward task, a straightforward (bounded and unbounded quantification). type system can enormously complicate such seem- • supports polymorphic messages (messages ingly mundane tasks as passing an array of strings whose type signatures are parameterized by a to a method that needs a read-only array of any type argument), with a flexible programmer- type of object. Whenever you place strict limits controlled mechanism for automatically infer- on programmers who are accustomed to none at ring values for the type parameter. all, you must be very careful indeed that you have anticipated and provided for effective ways of ex- • distinguishes inheritance from subtyping, pressing solutions to a great and subtle variety of which is important for a number of forms common programming problems. of code sharing, by incorporating a tractable form of the recent notion of inherited types In this section we will lay the groundwork for a [Bru93a, CHC90, CCHO89], which are espe- presentation of the Strongtalk type system by dis- cially useful for describing abstract data type cussing our major design goals, and by drawing (ADT) hierarchies. attention to a number of the not-so-obvious issues that can profoundly affect the expressiveness of an classes that support the protocol of another class, object-oriented type system. without inheriting from it, and this can be difficult or impossible to do in name-based type systems if you do not control the source code for that class, 3.1 Compatibility or if you are working in a single-inheritance language. A third shortcoming of all widely available Although Strongtalk is not designed to typecheck statically-typed OO languages is extremely awk- existing Smalltalk code without modification, nei- ward support for higher-order messages such as it- ther is it intended as an incompatible language erators and other user-defined control structures. extension. Our goal has been to eliminate the Strongtalk is designed to circumvent these sorts of risk that developers have traditionally had to as- awkward situations. In the first and third situa- sume when switching to a new, untried language. tions described above, we take advantage of the We achieve this through `downward compatibility', simple but powerful combination of strongly-typed which means that Strongtalk code can always be blocks, and polymorphic signatures for the higher- trivially converted to Smalltalk, but not necessarily order methods that take them as arguments. Ex- vice-versa. Using downward compatibility as our amples of this technique will be presented in the benchmark has the benefits of giving us some lee- experience section. way to define a very clean type system, while guar- anteeing adopters of Strongtalk that at any point To deal with the second problem described above, they can switch back to Smalltalk if they so desire, Strongtalk has a structural type system. In without recoding. Other than three trivial transla- Strongtalk, an object can be passed anywhere as tions (for manipulating uninitialized variables and long as its static type is known to support the nec- dynamic typechecking), no code transformation is essary protocol, regardless of its class. A way of ex- performed. plicitly defining protocols, and enforcing class support of them, is also provided. The Strongtalk preprocessor produces typesafe Smalltalk-80 code that preserves indentation, com- ments, and type annotations. 3.3 Type Inference 3.2 Expressiveness Some recent languages, such as TS [GJ90], and ML [MTH90] include features to automatically in- Smalltalk is an unusually flexible and expressive fer variable and return types. Such features would language. Any type system for Smalltalk should be convenient in a type system for a language like place a high priority on preserving its essential fla- Smalltalk, which lacks any sort of type annotations. vor. However, Strongtalk does not perform general type inference. Several of our design goals for Strongtalk involve providing better typing solutions for situations we There are number of reasons for this. In a lan- have found awkward in other languages. One of guage like ML, which has no concept of subtyp- these situations has to do with the fact that stati- ing, type inference can be well-defined for any ex- cally typed languages often have difficulty express- pression. However, for object-oriented languages ing useful return types for methods that may re- type inference is considerably more complicated. turn values of variable type, or when several re- A well-defined language specification that includes turn

Load more