Incremental Type Inference for Software Engineering Jonathan Aldrich University of Washington [email protected] Abstract The desire to use high-level language constructs while Software engineering focused type inference can enhance preserving a static type-safe guarantee drives programmer productivity in statically typed object- programmers to ask for ever-more powerful type systems. oriented languages. Type inference is a system of However, specifying a type that may be almost as long automatically inferring the argument and return types of and complicated as the function it describes can be a function. It provides considerable programming impractical. convenience, because the programmer can realize the benefits of a statically typed language without manually 1.2. Type Inference in ML entering the type annotations. We study the problem of type inference in object-oriented languages and propose In ML, it is possible for the compiler to analyze the an incremental, programmer-aided approach. Code is body of a function and infer the type of that function. For added one method at a time and missing types are example, a function that squares each of its arguments and inferred if possible. We present a specification and returns the sum of the squares clearly takes several algorithm for inferring simple object-oriented types in arguments of type int and yields an int in return (see this kind of incremental development environment. figure 1). - fun sumsqrs (x, y) = x*x + y*y; 1. Introduction val sumsqrs = fn : int * int -> int Type inference was popularized by the ML language [Milner et al., 1990]. ML is made up of functions and Figure 1. An example of type inference in ML. simple data types such as records, tuples, and lists. Every function in ML has a well-defined type that includes the A more powerful aspect of ML’s type system is required types of its arguments and the type of the result illustrated in figure 2. The append function takes two lists of the function. Because ML is strongly typed and that holds elements of some type ’a, and returns another statically typed, each function must be type-checked to list of the same type which is the two lists’ concatenation. ensure that it calls other functions with arguments of the ML infers that append can take any kind of list, but that correct type. Static typing is desirable because it ensures the two lists and the list returned must contain the same that there will be no run time type errors. type of elements. Thus it infers the type (’a list * ’a list) -> ’a list, indicating that append is a polymorphic function 1.1. Motivation that can take several different kinds of arguments. ML types can be rather complex. It has been shown - fun append(nil, l) = l [Mairson, 1990] that the description of the most general | append(head:tail, l) type of a function can be exponential in the size of the = head :: append(tail, l); function definition. In practice, inferred types are not exponentially long but may be more obscure than one val append = fn : might like. Much of this complexity comes from the (’a list * ’a list) -> ’a list power of the ML typing system—it supports a parameterized type (a list), record and tuple types, Figure 2. A polymorphic function. polymorphic types, and closures. This type complexity allows programmers to use powerful language constructs If the compiler can automatically determine types, like higher-order functions in a statically type-safe way. programming effort is saved because the programmer need not enter the type annotations or even analyze this rule by excluding F-bounded polymorphism and exactly what the type should be. This eliminates a parameterized types only because of the time pressure to potential source of bugs: a function is type-safe, but the complete this project. programmer has annotated it with the wrong type. Thus we are willing to design our inference algorithms Furthermore, the compiler can often infer a more general to work correctly in the common case. In more difficult type than the programmer might have annotated a situations, type inference may require some aid from the function with, making that function potentially more programmer in the form of type annotations. In this way extensible. Because of these benefits of type inference, it type inference is able to support the programmer without would be nice to provide type inference in object-oriented interfering with the important software engineering programming languages. abstractions supported by a powerful type system. If it can be shown that type inference usually deduces the 1.3. Object Oriented Type Systems correct type in practice, it will be successful in lightening the burden of static types. A beneficial side effect may be Types in a statically typed object-oriented language raising programmers’ tolerance for more powerful type fulfill four principal roles. The primary role is to systems, since the additional power will come at a lower statically typecheck a program to guarantee that no type cost due to the convenience of type inference. errors will occur at runtime. Another role is to provide a framework for extensibility within that static type safety 1.5. Environment Issues guarantee. We can extend an object-oriented program by providing a new implementation for any type in the We believe that type inference is most useful in an program. Third, types provide a valuable kind of incremental development environment such as the machine-checkable documentation. They specify what Smalltalk or ML environment. In ML, functions are typed kind of object a method operates on, giving important in one by one, and as each function is compiled, its type is clues to the behavior of that method. Finally, type inferred and reported to the programmer. The declarations can improve the efficiency of code, because programmer can then check the inferred type to make sure the compiler can perform many optimizations of dynamic it describes the intended type. The inferred type may be message sends if it can statically limit the receiver of the incorrect either because a more restricted type was desired message to a small set of implementations. or because the inferred type showed some programming error. In either case, the programmer can edit the function 1.4. A Software Engineering Focus (perhaps adding optional type annotations) before continuing on to the next piece of code. The Smalltalk Our focus is on the software engineering roles of types, development environment (which does not provide type including program safety, future extensibility, inference) shows that support for incremental specification and documentation. Other researchers have development can be of great value in object-oriented made considerable progress automatically inferring types programming languages as well as functional languages for safety and code optimization. This work often hides (see figure 3). the extensibility and documentation benefits of strongly typed languages. Therefore, we propose that code be developed with a type system that supports software engineering. When the code is compiled, a separate type inference pass focused on optimizing code can achieve the performance benefits that other researchers have observed [e.g. Grove 1995]. We see type inference as a tool to enhance programmer productivity when working with existing object-oriented type systems. It is crucial that we do not sacrifice the benefits of a well-designed type system just to make type inference easier. This restriction makes type inference more difficult; but if type inference is an optional productivity-enhancing tool, our algorithms need not be perfect. Following the designers of CLP(R) [Jaffar et al., 1992], we believe it is better to provide an Figure 3. The VisualWorks Smalltalk Class Browser. approximate solution to the type inference problem than to provide a perfect solution to an easier-to-solve approximation of the type inference problem. We break Therefore, we propose that an incremental type meaningful name to encapsulate a set of methods and their inference system be added to an interactive, incremental intended behavior. development environment for object-oriented programs. By separating a signature from the abstract type it is A graphical browser such as the Smalltalk browser (figure part of, structural subtyping can cause subtle bugs. 3) provides a window for editing class, method, and Although the types Bag and Set both have a method add, object definitions. Methods are added to the system one the methods mean very different things. Adding an at a time, and as each method is compiled the element to a Bag always increases the number of development environment infers any types that are left out elements, while adding an element to a Set may not by the programmer. Just as in ML, the programmer could increase its size if the element is already present! A then examine the inferred types and update the code to method that operates on any object with an add method reflect his understanding of the proper types. Ideally, the (using structural subtyping) could be incorrect if it inferred types would correspond to the programmer’s assumes that add always increases the size of the intentions (as is usually the case in ML) and so the collection. programmer gains the software-engineering benefits of Because of these problems with structural subtyping, having static types in the code without much of the usual we model types as abstract specifications of methods and effort required. The programmer specifies only type their behavior. Two types may be distinct even if their definitions, the types that each class conforms to, and the interfaces are identical, because their different names types of global, class, and instance variables. The types correspond to different programming concepts. of local variables, methods, and closures can all be inferred, eliminating up to 90% of all type annotations 2.2.