Advances in Programming Languages: Type accuracy

Transcription

1 Advances in Programming Languages: Type accuracy Stephen Gilmore The University of Edinburgh January 29, 2007 Introduction Strongly typed programming languages catch programmer errors, leading to program code of higher quality. Static type-checking finds type errors at compile-time, which is the ideal time to find them. Dynamic type-checking traps type errors at run-time, preventing erroneous programs from continuing past the first occurrence of an obvious mistake. Most strongly typed languages use a combination of static and dynamic type-checking. The extent to which a strongly-typed programming language is useful depends on the accuracy of its type system, which is a measure of its ability to describe data well. Java s generics have made its type system more accurate because it is now possible to differentiate homogeneous collections from heterogeneous collections and to represent concepts such as generic ordered lists. To further emphasise the difference between strongly typed and accurately typed consider Stringy, a (fictional) programming language with only one type, string. In the Stringy API all functions take strings as arguments and return strings as results. The same is true for all built-in operators of the language. Thus, it is not possible to use a data value in a way not allowed by its type (because the language as only one type). However, the type system of the Stringy language is very inaccurate. We represent integers as strings, booleans as strings, arrays as strings, and so forth, where we would rather have values of these types be separated. Thus every function which would like to receive an integer must be prepared to deal with non-integers, every function on arrays prepared to deal with non-arrays, and similarly. This represents a significant extra burden for developers who must write additional code to check and re-check types. (Experience tells us that they probably will not write additional code for this.) Stringy sounds like a terrible programming language but weakly-typed programming languages are not very different from Stringy. Developers need to write code to check and re-check types or, more likely, they assume that their data is type-correct when in practice it is not. The impetus towards improving the accuracy of type systems is an advance in programming languages. Describing the data more accurately causes developers to have to write fewer routines to validate data. Accuracy and loss of accuracy Object-oriented languages lose accuracy when the type of an object is coerced up the class hierarchy in order to match the type specified for a formal parameter for a method. When the class B is a subclass of A then it is not wrong to describe an object instance of class B as an A but it is less accurate than describing it as an instance of B. This loss of accuracy can cause run-time type errors. Consider the following Java program. 1

2 UG4 Advances in Programming Languages 2005/ /* File: programs/java/ooarrays.java */ public class OOArrays { static void assignfirst(object[] a) { a[0] = new Object(); if (args.length == 0) { System.out.println("usage: java OOArrays strings"); System.exit(1); assignfirst(args); System.out.println(args[0]); The above program compiles without warnings. In Java, String is a subclass of Object, meaning that String[] is a subclass of Object[], because of Java s covariant rule for arrays. Unfortunately the preceding Java program will fail at run-time with an ArrayStoreException (which is simply a type error). The command java OOArrays a b c produces this result. Exception in thread "main" java.lang.arraystoreexception: java.lang.object at OOArrays.assignFirst(OOArrays.java:4) at OOArrays.main(OOArrays.java:11) Thus, Java achieves type safety by a combination of static and dynamic type-checking. The benefit is that the language is type-safe, which is a huge gain. The disadvantage is that every array store incurs the cost of a bounds check on the index and a run-time type check on the object being stored. The former penalty is relatively common in strongly-typed languages with arrays but the cost of the second is due only to the loss of accuracy caused by coercing up the class hierarchy. C# arrays are covariant Like Java, C# uses a covariant rule for typing arrays, with the consequence that the following program is passed by the compiler. /* File: programs/cs/ooarrays.cs */ using System; class OOArrays { static void assignfirst(object[] a) { a[0] = new object(); static void Main(string[] args) { if (args.length == 0) { Console.WriteLine("usage: mint OOArrays strings"); Environment.Exit(-1); assignfirst(args);

3 UG4 Advances in Programming Languages 2005/ Console.WriteLine(args[0]); However, it too fails at run-time. Unhandled Exception: System.ArrayTypeMismatchException: Source array type cannot be assigned to destination array type #0: 0x00007 stelem.ref in.ooarrays::assignfirst #1: 0x00019 call in.ooarrays::main Generic types and covariance Generic types were introduced into Java to reduce the number of type-related errors which can occur at run-time. Java 1.5 includes a generic collection class which presents an array as a list, java.util.arraylist<e>. The methods in java.util.arraylist<e> include boolean add(e o); E get(int index); E set(int index, E element); Does this mean that we can reproduce the ArrayStoreException fault with a generic ArrayList? The following program tests this. /* File: programs/java/genericarraylist.java */ import java.util.arraylist; public class GenericArrayList { static void assignfirst(arraylist<object> ao) { ao.set(0, new Object()); ArrayList<String> as = new ArrayList<String>(); as.add("first"); assignfirst(as); System.out.println(as.get(0)); This program is (correctly) rejected by the Java 1.5 compiler. GenericArrayList.java:11: assignfirst(java.util.arraylist<java.lang.object>) in GenericArrayList cannot be applied to (java.util.arraylist<java.lang.string>) assignfirst(as); 1 error

4 UG4 Advances in Programming Languages 2005/ Generic classes are non-variant Generic classes are neither covariant nor contravariant. They are non-variant. There is no implicit super- or sub-type relationship between type parameters. That is, if B is a subclass of A and C<E> is a generic class then neither is C<B> a subclass of C<A> nor is C<A> a subclass of C<B>. Just to indicate that there is nothing special about built-in classes such as java.util.arraylist, we can implement our own simple array list, and show that it too is non-variant. /* File: programs/java/myarraylist.java */ public class MyArrayList<E> { private E[] data; public MyArrayList(int len) { // generates an unchecked cast warning data = (E[]) new Object[len]; public E get(int index) { return data[index]; public void set(int index, E e) { data[index] = e; We now attempt to use our array list class in a context where a covariant typing rule would be needed. /* File: programs/java/myarraylisttest.java */ public class MyArrayListTest { static void assignfirst(myarraylist<object> ao) { ao.set(0, new Object()); MyArrayList<String> as = new MyArrayList<String>(10); as.set(0, "first"); assignfirst(as); /* illegal */ The above program produces the same class of compilation error as we saw previously. Namely, assignfirst(myarraylist<java.lang.object>) in MyArrayListTest cannot be applied to (MyArrayList<java.lang.String>).

5 UG4 Advances in Programming Languages 2005/ Why generic classes are non-variant In an object-oriented language with a class hierarchy (and a concept of subclass) covariant generic classes would bring the complications which multiple inheritance brings to an objectoriented language. (Java has a single inheritance rule for classes.) Consider the class Stack<Integer>. The generic class Stack<T> extends Vector<T> and so inherits its methods. The Integer class extends Number. What would Stack<Integer> inherit from if Java had a covariant rule for generic classes? Would it be Stack<T> (for T above Integer) or Vector<Integer>? Diamond inheritance problems such as this led users of the C++ language to develop applications which had unexpected and unwanted behaviour due to a different method being invoked at runtime from the one which the developer expected. Generic Java classes are nonvariant to prevent problems such as this occurring. Run-time availability of generics Java s generics are not available at run-time (because of erasure). C# s generics are not erased and hence are available at run-time. We can see the difference between these two approaches if we attempt to test the run-time type of an object (using instanceof in Java and is in C#). /* File: programs/java/instancetest.java */ import java.util.stack; class InstanceTest { Stack<String> s1 = new Stack<String>(); Stack<Object> s2 = new Stack<Object>(); System.out.println(s1 instanceof Stack<String>); System.out.println(s1 instanceof Stack<Object>); System.out.println(s2 instanceof Stack<Object>); This Java program is faulted at compile-time because run-time type information on generic parameters is not available in the JVM. [scap]stg: javac InstanceTest.java InstanceTest.java:9: illegal generic type for instanceof System.out.println(s1 instanceof Stack<String>); InstanceTest.java:9: illegal generic type for instanceof System.out.println(s1 instanceof Stack<Object>); InstanceTest.java:10: illegal generic type for instanceof System.out.println(s2 instanceof Stack<Object>); 3 errors

6 UG4 Advances in Programming Languages 2005/ We now consider the C# version of the above program. /* File: programs/cs/instancetest2.cs */ using System; using System.Collections.Generic; class InstanceTest2 { public static void Main(string[] args) { Stack<string> s1 = new Stack<string>(); Stack<object> s2 = new Stack<object>(); Console.WriteLine(s1 is Stack<string>); // True Console.WriteLine(s1 is Stack<object>); // False Console.WriteLine(s2 is Stack<object>); // True I used Visual Studio 2005 to compile this program. The test in Console.WriteLine(s1 is Stack<object>); is not classed as an error but produces a warning of The given expression is never of the provided ( System.Collections.Generic.Stack<object> ) type. Thus showing that C# generics are non-variant also. The program runs without errors and produces the results True, False and True. Loss of accuracy: raw types Raw types are used in Java to achieve backwards compatability with non-generic code where one ArrayList is just like any other ArrayList. Variables can be given raw types and raw objects can be constructed. The following program assigns a raw type to an ArrayList. /* File: programs/java/rawarraylist.java */ import java.util.arraylist; public class RawArrayList { static void assignfirst(arraylist<object> ao) { ao.set(0, new Object()); ArrayList as = new ArrayList<String>(); // raw type as.add("first"); assignfirst(as); System.out.println(as.get(0)); This program compiles with warnings but runs and allows us to store an object in a class intended to hold strings (as with traditional heterogeneous collections in Java 1.4 and earlier). The program produces output similar to java.lang.object@ad3ba4

7 UG4 Advances in Programming Languages 2005/ In general if we mix raw types in with generic types we may compromise the usefulness of generic type descriptions. /* File: programs/java/weakening.java */ import java.util.date; import java.util.arraylist; public class Weakening { ArrayList<String> as = new ArrayList<String>(); ArrayList oo = new ArrayList(); // OO array list oo.add(new Date()); // warning here as = oo; // warning here also System.out.println(as.get(0)); // fail here [scap]stg: javac -Xlint:unchecked Weakening.java Weakening.java:8: warning: [unchecked] unchecked call to add(e) as a member of the raw type java.util.arraylist oo.add(new Date()); // warning here Weakening.java:9: warning: [unchecked] unchecked conversion found : java.util.arraylist required: java.util.arraylist<java.lang.string> as = oo; // warning here also 2 warnings Having generated warnings when compiled, this program fails at run-time with a class cast exception (casts are automatically inserted by the Java compiler in the compilation process). [scap]stg: java Weakening Exception in thread "main" java.lang.classcastexception: java.util.date at Weakening.main(Weakening.java:10)

8 UG4 Advances in Programming Languages 2005/ Accuracy and parametricity: wildcards Under the non-variance discipline it might seem that we have lost the ability to define parametric methods, because (for example) ArrayList<String> and ArrayList<Date> are not subtypes of ArrayList<Object>. We could resort to raw types but then we would lose the benefits of generic definitions, and we would be back in the OO world of heterogeneous collections. Another idiom is needed to have generic classess and parametric definitions co-exist: wildcards, denoted by?. /* File: programs/java/printarraylist.java */ import java.util.*; public class PrintArrayList { // parametric method: array list of something static void printall (ArrayList<?> a) { // enhanced for loop: "foreach" for (Object o : a) System.out.println(o); ArrayList<String> as = new ArrayList<String>(); as.add("first"); as.add("second"); printall(as); ArrayList<Date> ad = new ArrayList<Date>(); ad.add(new Date()); printall(ad); The above program will compile cleanly and print the list of strings followed by the singleton list containing the current date. To see that the unknown type is not just java.lang.object we can attempt to add object instances of random classes to the collection which we are passed.

9 UG4 Advances in Programming Languages 2005/ /* File: programs/java/querytest.java */ import java.util.*; public class QueryTest { // parametric method: array list of something static void printall (ArrayList<?> a) { // enhanced for loop: "foreach" for (Object o : a) System.out.println(o); // now stuff in a GregorianCalendar a.add(new GregorianCalendar()); // now stuff in an HTMLEditorKit a.add(new javax.swing.text.html.htmleditorkit()); // main method same as before ArrayList<String> as = new ArrayList<String>(); as.add("first"); as.add("second"); printall(as); ArrayList<Date> ad = new ArrayList<Date>(); ad.add(new Date()); printall(ad); This program is (correctly) faulted by the Java compiler. QueryTest.java:12: cannot find symbol symbol : method add(java.util.gregoriancalendar) location: class java.util.arraylist<capture of?> a.add(new GregorianCalendar()); QueryTest.java:14: cannot find symbol symbol : method add(javax.swing.text.html.htmleditorkit) location: class java.util.arraylist<capture of?> a.add(new javax.swing.text.html.htmleditorkit()); 2 errors The wildcard class variable is a qualified type. The compiler places restrictions on the use of?. It can appear in a return type position (and is treated as Object) but it cannot appear in a parameter type position. boolean add(e o); /* cannot call this */ E get(int index); /* can call this */ E set(int index, E element); /* cannot call this */

10 UG4 Advances in Programming Languages 2005/ Passing objects by value and by reference We have seen that loss of accuracy in type descriptions can have bad effects such as giving rise to an ArrayStoreException. In object-oriented languages passing objects to methods with more generous type descriptors (further up the class hierarchy) happens very frequently. One reason why this is allowable in practice, and only rarely a problem is that it is applied only when objects are passed by value, not when they are passed by reference. Java always passes object references by value. That is, the local variable of the method is a separate variable from the actual parameter. The local variable is simply initialised by pointer copy. If we update the local variable then the link to the formal parameter is lost. The local variable is destroyed when the method exits, as always. /* File: programs/java/passbyvalue.java */ public class PassByValue { static void passbyvalue(object o) { o = new java.util.date(); Integer i = new Integer(13); passbyvalue(i); System.out.println(i); // still 13 C# has pass-by-value calling but it also supports pass-by-reference. Under the pass-byreference discipline the local variable is the same variable as the actual parameter. If we update the local variable then the formal parameter changes also. However, to ensure type correctness coercions up the class hierarchy are not allowed by the compiler. The class description of the formal parameter used in the method header must match exactly the class description of the actual parameter when pass-by-reference is used. /* File: programs/cs/passbyref.cs */ using System; class PassByRef { static void passstringbyref(ref string s2) { s2 = "the new, updated string"; static void passobjectbyref(ref object o2) { o2 = new DateTime(); static void Main() { string s = "the original string"; object o = s; Console.WriteLine("s is {0", s); Console.WriteLine("o is {0", o); passstringbyref(ref s);

11 UG4 Advances in Programming Languages 2005/ Console.WriteLine("s is {0", s); Console.WriteLine("o is {0", o); passobjectbyref(ref o); Console.WriteLine("s is {0", s); Console.WriteLine("o is {0", o); It would be a compile-time error to attempt to pass the string s to the method passobjectbyvalue. The C# PassByRef class generates the following output. s is the original string o is the original string s is the new, updated string o is the original string s is the new, updated string o is Monday, 01 January :00:00 Improving accuracy with enumerations Type accuracy is improved whenever we can use a less general type to describe our data (because we rule out some values which we would otherwise have included). An example of this in the context of Java 1.5 is the use of enumerations which list only the values of interest. Before enumerations, fixed collections of values were approximated by integer constants. /* File: programs/java/values.java */ public class Values { /* Values declared as integer constants */ public static class DegreeType { public static final int BSc = 0; public static final int BEng = 1; public static class Class { public static final int Hons = 0; public static final int Ord = 1; public static class Degree { public static final int AI = 0; public static final int AICS = 1; public static final int AISE = 2; public static final int CS = 3; public static final int SE = 4; /* others omitted */

12 UG4 Advances in Programming Languages 2005/ This is a version suitable for Java 1.5 and higher. /* File: programs/java/enumerations.java */ public class Enumerations { enum DegreeType { BSc, BEng; enum Class { Hons, Ord; enum Degree { AI, AICS, AISE, CS, SE; /* others omitted */ for(degreetype dt : DegreeType.values()) for (Class c : Class.values()) for (Degree d : Degree.values()) System.out.println("" + dt + "(" + c + ") in " + d); Summary Implicit coercions up the class hierarchy reduce type accuracy when methods are invoked. In the context of arrays, such coercions can give rise to run-time type errors known as array store exceptions. The applied coercion uses a covariant rule for arrays. Generic classes are neither covariant not contravariant. They are non-variant. Generic type information is erased in Java compilation, but not in C# compilation. Java introduces a wild card? to represent an unknown type parameter. The use of this type is restricted to certain contexts. Implicit coercions on method parameters are not allowed when values are passed by reference. Enumerations improve type accuracy by introducing a new type for a new collection of values.