Most programming languages do not have an analog of Scheme predicates like empty? because they do not have a universal type that contains all other types. Java is almost identical to Scheme in this regard. All object types are subtypes of the universal type Object. If we ignore the eight primitive types (which all have corresponding container types in the Object type hierarchy), then the data models of Scheme and Java are essentially identical.
To test membership in any object type, Java provides a collection of postfix operators of the form
instanceof Twhere T is any defined object type. Hence, given the preceding program defining type IntList, Java interprets the program expressions below as follows:
new Empty() instanceof Empty trueThe instanceof operator has the same precedence as the relational operators. (Although the second ``argument'' to instanceof must be a type name, the Java parser initially recognizes this argument as an expression.)
new Cons(0, new Empty()) instanceof Empty false
"A" instanceof Empty false
Finger exercise: Load the intList1 sample program into the DrJava Definitions window. Add definitions for isEmpty and isCons. In the Interactions window try evaluating the following sequence of interactive computations:
Perform the equivalent sequence of membership tests as in the previous exercise using instanceof operators instead of the operations isEmpty and isCons.IntList empty = new Empty(); empty IntList oneElt = new Cons(1, empty); oneElt empty.isEmpty() empty.isCons() oneElt.getFirst() oneElt.isEmpty() oneElt.isCons() IntList twoElts = new Cons(0, oneElt); twoElts.getFirst() twoElts.getRest() twoElt.getRest().isCons() empty.getFirst() empty.getRest() "A".isEmpty() "A".isCons()
To accomodate static type checking, Java includes a second form of type predicate not present in Scheme called a cast. You may recall that Java includes operations for casting one primitive type to another. These primitive type casts convert values of one type to ``corresponding'' values of another type. The casting operations for object types have a completely different meaning; casting a value v to an object type T peforms an instanceof check on v! If the check returns false, then Java throws a ClassCastException indicating that the cast failed. If this exception is not caught (see Section ), Java aborts execution and prints an error message indicating which cast failed. In contrast, primitive type casts never fail!
If object type casts can only cause a program to abort execution, what good are they? Since the cast prevents execution from continuing if the instanceof test fails, the compiler knows that the result of object casting expression
( T) ehas type T. Consequently, the static type checker in the compiler assigns the static type T to this casting expression. By inserting object casting operations in a program, you can tell the static type checker that a particular expression has a narrower (more precise) type that the type that would otherwise be assigned by the static type checking rules.
Finger exercise: Load the IntList1 sample program into the DrJava Definitions window. In the Interactions window try evaluating the following sequence of interactive computations:
Perform the equivalent sequence of membership tests as in the previous exercise using instanceof operators instead of the operations isEmpty and isCons.IntList empty = new Empty(); IntList oneElt = new Cons("B", empty); oneElt oneElt.first ((Cons) oneElt).first oneElt.rest ((Cons) oneElt).rest