Problem Set 8 (Part 2): Typed Aazda

Collaboration Policy - Read Carefully

For this assignment, you may work alone or with a partner of your choice. If you work with a partner, both partners should contribute equally to the assignment and both partners must fully understand everything you submit. Remember to follow the pledge you read and signed at the beginning of the semester. For this assignment, you may consult any outside resources, including books, papers, web sites and people. If you use resources other than the class materials, lectures and course staff, explain what you used in a comment at the top of your submission or next to the relevant question.

If you haven't figured out to start early and take advantage of the scheduled help hours and office hours by now, probably it won't do any good to remind you to do so again on this assignment.

Purpose

The main purpose of this assignment is to understand static typing and how to implement type checking in an interpreter, and to provide additional experience using Java to be well prepared to take cs2110 in the Spring.

Static Type Checking

As introduced in Chapter 5, a type defines a possibly infinite set of values and the operations that can be performed on them. For example, Number is a type. Addition, multiplication, and comparisons can be performed on Numbers.

In Scheme (and in Charme and the current Aazda interpreter before you modify it), types are latent: they are not explicitly denoted in the program text. Nevertheless, they are very important for the correct execution of a Scheme program. If the value passed as an operand is not of the correct type, an error will result. For example, evaluating (+ 1 true) produces a type error in Scheme and Aazda.

Scheme has fairly strong type checking. If the types of operands do not match the expected types, it reports an error. Python has weaker type checking. Evaluating 1 + True in Python does not produce a type error. (Try guessing what the result will be before evaluating it in the Python interpreter to see what the actual result is.) One advantage of stronger type checking is it is often better to get errors than to get mysterious result. (See Martin Rinard's papers on the acceptability envelope for an alternate view.)

   (define (badtype a b) (+ (> a b) b))

Your goal for the rest of this assignment is to add static type checking to Aazda. Static type checking checks that expressions are well-typed when they are defined, rather than waiting until they are evaluated. Static type checking reduces the expressiveness of our programming language; some expressions that would have values with dynamic type checking are no longer valid expressions. If a correct static type checker deduces the program is well-typed, there is no input on which it could produce a run-time type error. In many cases, it is much better to detect an error early, than to detect it later when a program is running. This is especially true in safety-critical software (such as flight avionics software) where a program failure can have disastrous results (such as a plane crashing).

As with Java (but unlike Scheme and Python), Aazda will use manifest types: every definition and parameter will include explicit type information that describes the expected type of the variable or parameter. This increases the length of the program text and sacrifices expressiveness, but makes it easier to understand and reason about programs. To provide manifest types, we change the language grammar to support explicit type declarations.

/* Modified for Question [N] */
your changed code
/* End Modifications for Question [N]*/

Manifest Types

To provide manifest types, we modify the grammar for Aazda to include type declarations. Two rules need to change: definitions and lambda expressions. We replace the original definition rule,

Definition → (define Name Expression)

Definition → (define Name : Type Expression)

We modify the lambda expression grammar rule similarly to include a type specification for each parameter:

Expression → ProcedureExpression
ProcedureExpression → (lambda (Parameters)Expression)
Parameters → ε
Parameters → Name : Type Parameters

The new nonterminal, Type, is used to describe a type specification. A type specification can specify a primitive type. Like a primitive value, a primitive expression is pre-defined by the language and its meaning cannot be broken into smaller parts. Aazda supports only two primitive types: Number (for representing numbers), and Boolean (for representing the Boolean values true and false). (Adding support for Pair types is not required for this assignment, so the cons, car, cdr, and list primitives are not part of static Aazda.)

We also need constructs for specifying procedure types. The type of a procedure is specified by the type of its inputs (that is, a list of the input types), and the type of its results (an Aazda procedure can only return one value, so the result type is a singleton). The arrow symbol, -> symbol is used to denote a procedure type, with the operand type list on the left side of the arrow and the result type on the right side of the arrow. To avoid ambiguity when specifying procedures that have procedure result types, we use parentheses around the procedure type specification.

The grammar for type specifications is:

Type → PrimitiveType | ProcedureType
PrimitiveType → Number | Boolean
ProcedureType → ( ProductType -> Type)
ProductType → (TypeList)
TypeList → Type TypeList | ε

For example,

(define x : Number 3)

The definition,

(define square : ((Number) -> Number) 
  (lambda ((x : Number)) (* x x)))
  

Here is a definition of a compose procedure that takes two procedures as inputs and produces a procedure as its output:

(define compose : ((((Number) -> Number) ((Number) -> Number))
                   -> ((Number) -> Number)) 
  (lambda ((f : ((Number) -> Number))
           (g : ((Number) -> Number)))
    (lambda ((x : Number)) (g (f x)))))

The compose example reveals two important disadvantages of static, manifest types. The first is that manifest types add a lot to the size of a program. You will notice this in your Java programs also. The second is that static types reduce expressiveness of Aazda compared with Charme. This procedure only works on a small subset of the inputs for which the typeless compose procedure works, namely procedures that take Number inputs and produce a Number output. If we want to compose procedures that operate on Boolean inputs, we would need to define a separate procedure with a different type specification.

To support type definitions without spaces, we also modify the Tokenizer to treat : as a separate token (like ( and ) in the original Tokenizer.

Representing Types

The first step in adding static type checking to our interpreter is to define classes for representing types. We will use inheritance to define the APrimitiveType and AProcedureType classes as subtypes of the AType class (we prefix our names with A for Aazda, to avoid confusion with the other type names).

There are three classes (included in taazda.zip): AType.java, APrimitiveType.java, and AProcedureType.java. AType is the supertype class; all of the types we represent are AType objects. The APrimitiveType and AProcedureType are subclasses that inherit from AType. The APrimitiveType class provides a specialized class for representing primtive types (Boolean and Number); the AProcedureType is for representing procedure types which have a return type and parameter types.

The AType class is an abstract class. This means that it provides no constructors. Hence, there is no way to construct an AType directly, only to create its subtypes. The AType class defines one abstract method:

    public abstract boolean match(AType p_t);

package aazda;

public class APrimitiveType extends AType {
	private String tname;
	
	public APrimitiveType(String p_name) {
		tname = p_name;
	}

	public boolean match(AType t) {
		if (t instanceof APrimitiveType) {
			APrimitiveType pt = (APrimitiveType) t;
			return tname.equals(pt.tname);
		} else {
			return false;
		}
	}

The APrimitiveType class also implements a toString() method that overrides the toString() method provided by the java.lang.Object class (which every Java class inherits from). This will produce a human-readable String that represents the type.

Representing procedure types is more complicated since they have both a return type (an AType) and parameters (an ArrayList<AType>). The AProcedureType class does this using the result and params private instance variables. Look at the provided code in AProcedureType.java to understand how procedure types are represented, and how the match method works for procedure types.

The AType class provide a method AType parseType(SExpr) that converts a type expressed as an s-expression (that is, the result of Parser.parse(String)) into an AType. You should be able to read and understand the code for parseType(SExpr) in AType.java, but will not need to modify this code.

The AType class includes a main method for testing the type implementation. The provided code includes some simple tests. For the next exercise, you should modify this code.

Modifying the Environment

With static typing, each place has an associated type. In Java, a variable declaration introduces a new name and gives that name a type. For example,

    int a; 

To support typed places, we need to modify the Environment type to associate types with places. We do this by defining a Place class that packages a type (AType) and a value (SVal):

class Place {
	// Place has a type and value
	AType type;
	SVal val;
	
	public Place(AType p_type, SVal p_val) {
		type = p_type;
		val = p_val;
	}
}

Type Checking

The main change to the evaluator is adding a method,

   public static AType typeCheck(SExpr expr, Environment env)

	public static SVal meval(SExpr expr, Environment env) throws EvalError, TypeError {
		typeCheck(expr, env);

		if (isPrimitive(expr)) {
			...

	public static AType typeCheck(SExpr expr, Environment env) {
		if (isPrimitive(expr)) {
			return typePrimitive(expr);
		} else if (isName(expr)) {
			return typeName(expr, env);
		} else if (isIf(expr)) {
			return typeIf(expr, env);
		} else if (isCond(expr)) {
			return typeCond(expr, env);
		} else if (isAssignment(expr)) {
			typeAssignment(expr, env);
			return AType.Void;
		} else if (isDefinition(expr)) {
			typeDefinition(expr, env);
			return AType.Void;
		} else if (isLambda(expr)) {
			return typeLambda(expr, env);
		} else if (isBegin(expr)) {
			return typeBegin(expr, env);
		} else if (isApplication(expr)) {
			return typeApplication(expr, env);
		} else {
			throw new TypeError("Unknown expression type: " + expr.toString());
		}
	}

For example, below is the definition of typeIf (with some error checking removed, see the full code in Evaluator.java). It first checks that the type of the predicate expression is a Boolean. This uses typeCheck recursively, similarly to the way evalIf uses meval to evaluate the value of the predicate expression. (Indeed, the typeRule methods were created by starting from a copy of the code for the corresponding evalRule.) The key difference, though, is that the type checker does not actually evaluate any expression, it just determines its type.

	public static AType typeIf(SExpr expr, Environment env) throws EvalError {
		...
		SExpr pred = ifExpr.get(1); // error checking code removed
		SExpr consequent = ifExpr.get(2);
		SExpr alternate = ifExpr.get(3);
		
		// Check the predicate is a Boolean
		AType predType = typeCheck(pred, env);
		if (!predType.isBoolean()) {
			throw new TypeError(
					"Predicate for an in expression must be a Boolean.  Type is: "
							+ predType);
		}

		// Check both clauses have the same type
		AType consequentType = typeCheck(consequent, env);
		AType alternateType = typeCheck(alternate, env);

		if (consequentType.match(alternateType)) {
			return consequentType;
		} else {
			throw new TypeError(
					"Clauses for if must have matching types.  Types are: "
							+ consequentType.toString() + " / "
							+ alternateType.toString());
		}
	}

We have provided a testing class, TestAazda.java, for testing taazda. You can run this by selecting the TestAazda main method for running.

As provided, the Taazda interpreter cannot handle recursive definitions! For example, when we try to define factorial in Taazda (this is TestAazda.testFactorial()) we get an Undefined name factorial error.

This is a serious problem, since without recursive definition we do not have a universal programming language.

Note that meval is not an algorithm. It (hopefully) correctly always produces the value of any Taazda expression, but it is not guaranteed to terminate. Indeed, it is impossible to produce an algorithm for this, since that would require solving the Halting Problem. Since Taazda is a universal programming language, we can implement any mechanical computation in Taazda, including simulating a universal Turing Machine. Hence, we know the Taazda-Value problem described below is noncomputable:

Taazda-Value

Input: A string, expr, that is an expression in the Taazda language.

Output: The value of expr in the standard global environment, or Void if expr has no value.

def halts(s):
   return taazdaValue(rewriteNoValue(s)) != Void

Taazda-Well-Typed

Input: A string, expr, that is an expression in the Taazda language.

Output: If expr is well-typed according to the Taazda type checking rules, output true. Otherwise, output false.

Pairs and Lists

   (define identity : ((E) -> E) (lambda ((x: E)) x))

Supporting Lists also requires a special solution for null (what type should null have?) and if you want to support the list procedure for making arbitrarily long lists, a way to have parameter lists that can be any size.

Print PDF