Improving Scala's Safe Type-Level Abstraction

Seminar: Program Analysis and Transformation University of Applied Sciences Rapperswil Improving Scala's Safe Type-Level Abstraction Stefan Oberholzer, soberhol@hsr.ch Dez 2010 Abstract Scala cannot nd all type errors at the code line they are made. In case of methods taking an abstract function, it is possible to rene the function type in a sub-class in a way that is not allowed. This error can only be detected at the place where a class implements this abstract method. In this document I will introduce the Scalina calculus that denes un-members, which allow that types can only be rened in a contravariant way. Scalina's solution has only a few implicit declarations because of this it requires about twice as much code as it would require in Scala. Nevertheless I beliefe that this could be a real gain for Scala's type system. 1 Introduction Scala is a purely object oriented programmining language, supporting also functional features. Scala has many useful features. Some of them still have minor problems not yet solved. One of this problems is that its type system is not able to identify all errors in type denitions in the class where they are made. A solution for this is proposed in the paper Safe type-level abstraction in Scala [MPO08] is presented in this document. An example where the problem in Scala occures can be seen in section 2.1. This introduction will give a short overview about Scala, variance, type systems and abstraction types. In section 2 I will provide a short overview about the type-level abstraction in Scala followed by an example illustrating a weakness of Scala. Section 3 will introduce Scalina, a purely object-oriented calculus used to prove that the explained type-level abstraction works. Afterwards in section 4 I will explain the type-levels used by Scalina to implement its type soundness. I will also explain how this object-oriented calculus can provide functional programming aspects. At the end in section 6 I will make a short conclusion about the abstraction mechanism introduced in Scalina. 1.1 Used type hierarchy for explenations In this document I will use the type hierarchy in Figure 1 for the example UML diagrams. Please be aware that this class hierarchy does not match the one of Scala or Scalina. I use this because it is easy imaginable. 1.2 Terms, types and kinds Terms, types and kinds are the basic constructs of programming languages. Some 1

Terms are components of variables or objects in a programming language. In our example, the HashSet object with the label lst is a term. Each value object in the HashSet is also a term. As you can see the amount of dierent terms in an application can only be determined at runtime. Figure 1: Type hierarchy for UML examples knowledge about terms, types and kinds is essential for the understanding of this paper. In this chapter I will give a short overview about terms, types and kinds using the example code in Listing 10. class MyClass{ def GenerateIntervalList(in : Int): HashSet[Int] ={ val lst : HashSet[Int] = new for { HashSet[Int](); value <- 0 to in{ lst += value; return lst; Listing 1: Term, types and kinds example Types are used to describe the type of a term. Like terms they can also be used like a variable. In our example the GenerateIntervalList method is a type. The classes MyClass and HashSet are also types. As you can see, the number of dierent types is specied at compile time. Kinds are the type of a type. They are the constructs allowed by the programming language. They can not be dened in the program code. A programming language may contain a kind hierarchy, comparable with the ones for types. The class MyClass is a structural kind, as the class construct is a kind. It is also a nominal kind because it has a name. As it does not contain any abstract types, it is a concrete kind too. The used kinds in this document are described in Table 1. The Class MyClass consists of the method GenerateIntervalList. This method takes an Int as argument and returns a HashSet containing all values from 0 to the number given in the parameter. 2

Kind Interval kind Description Interval kinds dene that the dened types have to be between its bounds. An example of this would be [mysubclass, myclass] that denes the possible classes that have to be super types of mysubclass and sub-types of myclass. Structural kind Structural kinds dene the form of a type. This is mostly used in functional programming. For example the function maptostring(input : Integer) : String denes a function of kind Integer -> String. Nominal kind Concrete kind A nominal Kind denes a type identied by its name A concrete kind declares types in which all types and terms are concrete. Table 1: Used Kinds 1.3 Type systems in programming languages Type systems are used in programming languages to dene the range of values a type can have. Modern programming languages have polymorphic type systems. They allow to dene code with the same behaviour for dierent types [Pie02]. Listing 5 shows an example without polymorphism. class NonPolymorphicExample { def mapintegertostring( a : Integer) : String = { a.tostring def mapdoubletostring(a : double) : String = { a.tostring Listing 2: Example without polymorphism The class NonPolymorphicExample contains two methods. Both of them map the parameter value to a String by using the tostring method. This is required because only a polymorphic type system would allow to de- ne a method for multiple types. In this chapter I will describe the most important categories of polymorphic type systems. These categories are not exclusive. Modern programming languages implement a combination of them. Parametric polymorphism Parametric polymorphism allows to write a single piece of code typted by using variables in place of actual types [Pie02]. An example can be seen in Listing 4. ParametricPolymorphismExample{ def map[a](a : A) : String = {a.tostring(); Listing 3: Parametric example polymorphism In this example the class contains only one method. As in the non-polymorphic example the method maps the parameter to a String value by using the tostring method. The dierence to the non-polymorphic class is that only one method is needed. The method takes a parameter of any type and maps it to a String by calling the tostring method. Ad-hoc polymorphism Ad-hoc polymorphism allows a function or method to work with several dierent types that might even behave in an unrelated way [CW85]. Overloading is the most common form of ad-hoc polymorphism. This allows a single function symbol to be associated with multiple implementations, each of it diering in the arguments taken. The compiler or 3

the runtime system decides which method to use, based on the arguments [Pie02]. Listing 6 shows an example of overloading. class OverloadingExample { def maptointeger( a : Double) : Int { a.toint; def maptointeger(a : String) : Int { new Integer(a) Listing 4: Overloading example In this case there are two methods with the same name but dierent parameter types behaving dierently. One method converts the value to an Int by calling the toint method and the other does the same with a String by using the constructor of Integer. So the body of both methods is dierent. As the body can be dierent both methods could also do something completely dierent. 1.5 Variance In the previous chapter I described the dierent types of type systems. Variance is an important topic in polymorphic type systems, as it describes which types are allowed. In this section I will describe the three variance types: covariance, contravariance and invariance. 1.5.1 Covariance Covariance means that the type hierarchy is in direction of the substitution hierarchy. This is the most common kind of variance. A sub-class implements all methods and elds of its super-class. So at every place where a class is required, instances of classes extending this class can be taken. Figure 2 shows an example for a covariant return type. The class ConcreteElement is a sub-type of the class AbstractElement. So are return types, Integer is a sub class of Number. Sub-type polymorphism Sub-type polymorphism means that a method taking a class A as parameter can also take any sub-class of A as parameter [Pie02]. This behaviour is standard in most of the object oriented programming languages. For example if there is a method with the signature map(a : Number) : String, the method can get a Number or an Integer, that is a sub-class of Number, as parameter. 1.4 Abstraction types There are two main systems of abstraction in current programming languages. Functional abstraction and object oriented abstraction. In functional abstraction the abstraction is over values. Parametric polymorphism (see section 1.3) is an example of functional abstraction. Object oriented abstraction uses abstract types and sub-typing to dene the abstraction. An example of this is sub-type polymorphism (see section 1.3). Figure 2: Covariance example 1.5.2 Contravariance Contravariance means that the type hierarchy is against the direction of the substitution hierarchy. Variable types behave contravariant. If a variable is dened as subclass and no methods of the sub-class are required, the type of the super-class could be taken instead to dene the variable. Figure 3 shows an example for a contravariant method parameter. As in the 4

covariance example, ConcreteElement is a sub-class of AbstractElement. The type in this example is contravariant, this means that the parameter type of the method in ConcreteElement is a super-type of the parameter in AbstractElement. Figure 4: Invariance example Scala interacts with code written in Java Figure 3: Contravariance example 1.5.3 Invariant Invariant means that the types in the superclass and the sub-class are equal. An example of this are arrays. The type of an array can not be casted to a super type. If this would be possible a dierent sub-type of the super type could be added into the array. It can also not be casted to a sub-type as it may already contain values of the type it had before. Figure 4 shows another example of this. The type parameter of the map method is the same in AbstractElement and ConcreteElement. 1.6 Scala As already mentioned Scala supports objectoriented and functional programming features. Scala was released by the EPFL 1 in January 2004 with the ability to compile to JVM platform compliant code. The second edition of Scala was released in 2006. Scala has the following key aspects [OAC + 06]: 1 École Polytechnique Fédéral de Lausanne Every value is an object and every operation is a method call Functions are rst-class values The abstraction concept is uniform for both, types and values Flexible modular mixin-composition constructs for composing classes and traits are included Object decomposition by pattern matching is supported Patterns and expressions are generalized to support the treatment of XML documents External extensions of components using views are allowed Scala has no interfaces. Instead it has traits, which behave like interfaces with the dierence that traits can contain implementations of methods. Due to the fact that a trait is like an interface, a class can implement multiple traits. 2 Type-Level Abstraction in Scala Scala supports object-oriented and functional programming features and abstraction 5

Figure 5: Type hierarchy of Scala mechanisms for values and types [OAC + 06]. As a result of this Scala can abstract over methods, parameters and classes. All of them can be passed as parameter to methods. Scala can dene generic types as covariant, contravariant and invariant. The abststract class Any is the root of Scala's type hierarchy. This means that any class is implicit dened as a sub class of Any. The trait Nothing is the bottom of Scala's type hierarchy. This means that any class is a super-class of Nothing. Scala's type hierarchy can be seen in Figure 5 [OAC + 06]. 2.1 Problems of Scala's type-level abstraction Scala does not allow to dene types as contravariant. This leads to the problem described in this section. 2.1.1 Example To show an existing problem in Scala I will take an extraction of the UML diagram of a possible UI Element implementation. The UML can be seen in Figure 6. I will describe a trait hierarchy dening a mapping method. To dene this I will have to de- ne a trait hierarchy. The super-class de- nes a trait that has to be implemented by the classes that can be taken as input and output of the map method. To have some specialications of this map method the trait is extended by two other traits. One of them is correct, while the other contains a failure in the variance of the input type. In the following I will describe each of the classes and explain the error. NumberElement The trait NumberElement denes an element that has something to do with a number. It just denes a generic type that has to be a sub-type of Number. NumberSelectionElement The sub-trait NumberSelectionElement is the most important trait in this diagram. It represents a NumberElement that can be selected. NumberSelectionElement denes a type Container that has to be a sub-type of NumberElement. This type is used as return type for the map method. This method takes a function that converts a variable of type T to type B. As it can be seen in the denition of the generic types, T and B must be of the type NumberElement. IntegerSelectionElement The trait IntegerSelectionElement is a subtrait of NumberSelectionElement. It denes that the map method has to return an IntegerSelectionElement. As IntegerSelectionElement is a sub-type of NumberElement this is no problem. As second binding IntegerSelectionElment denes that T has to be an Integer or a sub-type of 6

Figure 6: Erroneous UML diagram of Example it. This binding should not be allowed, as it strenghenes the restrictions on allowed method accepts. Let's assume an implementation of this method and an instance of this implementation is assigned to a variable of the type NumberSelectionElement. In this case the compiler would allow to pass a function converting a Double value to the type B, even though the implementation does not allow it. Scala is only able to detect this error when an implementation of the trait IntegerSelectionElement is created but not when the trait is implemented. In simple designs like the one of the example this is no real problem. In more complex designs it can happen that a lot of work was done taking this as basic before the error is detected. So solving the error might take a lot of time that would not have been required if the error would have been detected earlier. GenericNumberSelectionElement The trait GenericNumberSelectionElement shows a correct sub-trait of NumberSelectionElement binding the types. As T cannot be dened in a contravariant way, T can only be dened invariant. If contravariants would be allowed, T could also be dened contravariant, because this would allow to loosen the restrictions of the allowed functions. This can be allowed because the denition of the sub-class still allows all functions allowed by the super-class. I will show now the same example with contravariants allowed. Solution In the UML in Figure 7 I will de- ne contravariant types using the :> sign. Figure 7 shows the example UML with contravariants. Using this class hierarchy the compiler is able to detect the error while compiling the trait IntegerSelectionElement. This time the type T in NumberElement is de- ned as contravariant. Because of this a covariant renement as it was made in the trait IntegerSelectionElement is not allowed. Instead of this a binding as made in GenericNumberSelectionElement is now allowed. This is allowed because it loosens the restrictions of the map method. GenericNumberSelectionElement now takes any function converting any input type to another input type. Scalina is able to dene contravariants. So it allows to detect this error in the denition of the trait IntegerSelectionElement. 3 Scalina Scalina is a calculus modelling a core subset of Scala, used to prototype new features for Scala [Sca09]. In the implementation case used in the paper Safe Type-level Abstraction in Scala [MPO08] Scalina is used to show that it is possible to check the type-level abstraction at compile time of a class by introducing contravariants. As Scalina is only used to 7

Figure 7: Correct UML diagram of Example show that the concept introduced in the paper [MPO08] works I will only describe the important constructs used in Scalina. 3.1 Type-level abstraction in Scalina Scalina's type system uses kinds, types and terms. All terms in Scalina are objects. While terms are only used for computation, types are used for classication and computation. Kinds are used for classication only [MPO08]. The prove of the paper [MPO08] is restricted to statically bound members. So the examples in this document will be restricted to statically bound members too. 3.1.1 Members and un-members Scala denes members as types or terms belonging to an other type. Un-members are members with a type not yet specied. That means that the type of an un-member has to be specied later in a contravariant way. The term un-type and un-kind are used for un-members of the type or kind. For example the un-type of Integer, can be rened with Integer or any super type of it. 4 Type-Levels used in Scalina In this section I will describe the type-levels used to introduce contravariant declarations. I will only describe the most important def- Symbol Description T type or un-type S type or un-type R structural type new T instantiation of T p.type singleton type (short form of p.type#l) T R T expands to R at runtime Γ Under the assumptions in Γ Un[T ] Untype T. Table 2: Symbols initions. The full set of denitions is in the paper [MPO08]. Table 2 describes the symbols used for formal denitions. 4.1 Terms A term is an instantiation of a type. To instantiate a type and thus creating a term all un-members have to be rened. Because of this terms do not contain any un-types. Scalina is purely object-oriented, so a term is always an object specied by its path 2 and type. The most important denitions in the paper[mpo08] are: Any term can be expanded to its type at runtime. I will show this by using the 2 A path is the the full identication fo a term or type. For example scala.collection.mutable.hashset is the path for the type HashSet 8

example of a singleton lookup: T R (new T ).type R This means in words: When T expands to R at runtime the type of instance of T also expands to R at runtime. In the singleton case this is easy to understand as the type must be known to instantiate the singleton. So it is easy to get the real type of the singleton term. It can be checked that only un-members can be rened and every un-member is only rened once. 4.2 Types Types are used to dene terms. The abstraction mechanisms for types are similar to the ones used for terms. In addition to this it is possible to dene members, un-members and abstract members for types. Scalina also diers between structural types and nominal types. Un-types are used as classiers of value un-members. Type member selection is only allowed on types that consist only of concrete members. By denition singletons are always type safe because a singleton can only be created when all members are concrete 3. Because of the same reason it is also safe to assume that the self variable 4 does not contain any un-members. For simplicity Scalina does not allow variance for constructors. In the following I will list the most important denitions made in the paper [MPO08]. A type T can be normalized to T'. In a normalized type all member selections have been performed, all renments have been made and all compositions of structural types have also been made concrete. 3 The type contains no abstract members 4 variable that points to the own object. In Scala the implicit variable "this" is the self variable To get all the members in a type it can be expanded to its structural type. Un-types can only be rened with contravariant types. Γ T <: S Un[S] <: Un[T ] This means in words: Under the assumptions in Γ, T is a sub-type of S. So the un-type of S is a sub-type of the un-type of T. In other words: S is de- ned as super type of the type T. As unmembers have to be rened contravariantly the un-member of type S is a subtype of the un-member of type T. This is because all types that can be taken to rene the un-member of S can also be used to rene the un-member of type T. The type hierarchy between S and T can only be used to rene T. A type member becomes invariant as soon as it is made concrete. 4.3 Kinds Kinds describe which members may be selected on the types they classify. Interval (In(S, T)) kinds take over the role of bounds. For example In(S, T) means that type members are supertypes of S and sub-types of T. Types containing at least the member of kind R are described by the structural kind (Struct(R)). Nominal kinds (Nominal(R)) are like structural kinds with the dierence that they mark concrete type bindings. As last, concrete kinds (concrete(r)) are used to mark types that have at least all members in R specied. So types with all members bound must be a sub-type of the self type declared in R. Types may only be instantiated or used as target for type member selection, if all types are bound. As in Scala, Scalina uses Any and Nothing as upper and lower bound for kinds. 9

5 Functional programming with OO Type Systems In this chapter I will explain how functional programming can be implemented with object oriented programming languages by adding syntactic sugar to them. As Scalina is object oriented this can also be done in its case. To do this an interface for functions can be created containing multiple generic types. One for the output and the rest can be used to dene the input. The interface also contains an apply method that will implement the logic of the function. By adding syntactic sugar it can be allowed that the apply method is taken implicit if no other method is written and the class implements the function interface. The full prove for this can be found in the paper [MPO08]. I will take the following definition out of the mapping in the paper to show the behaviour with the apply method. T T {val a : Un[ T ]; val apply : T in the paper [MPO08] the solution requires twice as much code as it would require in a Scala implementation that does a similar thing. From my point of view the gain of nding the error at the place it is made is not worth the eort of twice as much code. In most of the cases it will take more time to write twice as much code than to remove the error that might be in the code. As Scalina is only a core calculus with only a few syntactic sugar and nearto no implicit denitions, it might be possible to reduce the required code to an amount close to the one required by Scala. If this would be possible, it were a great improvement for Scala. The function T-> T' takes an argument of type T and returns a value of type T'. It is mapped as a method taking a value a that is an un-member of the type T and a value apply that has the type T' [MPO08]. 6 Conclusion In this document I have shown how Scalina implements contravariant type denitions. Using this denitions it is possible to identify all type errors at the place they are made. With the current solution in Scala it can happen that a developer implements a complex type hierarchy, only containing abstract types, without having any compile error. When he tries to make an erroneous class concrete afterwards, he will get an error. Finding an error so late can mean that a big eort has to be taken to correct the error. The type-level abstraction of Scalina solves this problem but as it can be seen 10

References [CW85] Luca Cardelli and Peter Wegner. On understanding types, data abstraction, and polymorphism. Computing Surveys, 17(4):471522, December 1985. [MPO08] Adriaan Moors, Frank Piessens, and Martin Odersky. Safe type-level abstraction in scala. ACM, January 2008. [OAC + 06] Martin Odersky, Philippe Altherr, Vincent Crement, Julian Dragos, Gilles Dubochet, Burak Emir, Sean McDirmid, Stéphane Micheloud, Nikolay Mihaylov, Michel Schinz, Erik Stenman, Lex Spoon, and Matthias Zenger. An overview of the scala programming language. Technical Report Second Edition, École Polytechnique Fédéral de Lausanne (EPFL), 1015 Lausanne, Switzerland, 2006. [Pie02] Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002. [Sca09] Scalina. Scalina google code project. http://www.scala-lang.org/node/273, 2009. [Online; read state 06-nov-2009]. 11