CS 536 Homework 8: Type Checker Option

This option has you do a couple of type constraint problems by hand, followed by an implementation of a type checker.

Problem 1

Consider the program
(+ 1 (first (cons true empty)))
which has a type error.

Generate constraints for this program. Isolate the smallest set of these constraints that, solved together, identify the type error.

Feel free to label the sub-expressions with superscripts for use when writing and solving constraints.

Problem 2

Consider the following typed expression:

{fun {f : B1 } : B2
  {fun {x : B3 } : B4
    {fun {y : B5 } : B6
      {cons x {f {f y}}}}}}

The type inference process infers the unspecified types (Bn). Derive type constraints from the above program. Then solve these constraints. From these solutions, fill in the values of the boxes. Be sure to show all the steps specified by the algorithms (i.e., writing the answer based on intuition or knowledge is insufficient). Use type variables where necessary. To save writing, you can annotate each expression with an appropriate type variable, and present the rest of the algorithm in terms of these type variables alone (to avoid having to copy the corresponding expressions). If you do this, be sure to annotate every sub-expression with a type variable. Be sure the annotations are clearly readable!

Problem 3

Consider the type judgments discussed in the textbook. These rules are for an eager language. Consider the lazy version of the language instead. Pay special attention to the typing rules for

• function definition
• function application

For each one, provide a new rule or, if you believe the existing rule does not change, explain why not. (If you believe neither rule changes, you can answer both parts together.) If you believe any other type judgements should change, mention those as well.

Problem 4 (has two parts)

Consider the following typed language that includes numbers, booleans, conditionals, functions, and numeric lists. The concrete syntax for the language is given by the following BNF grammars:

   <expr> ::= <num>
            | true
            | false
            | {+ <expr> <expr>}
            | {iszero <expr>}
            | {bif <expr> <expr> <expr>}

            | <id>
            | {with {<id> : <type> <expr>} <expr>}
            | {fun {<id> : <type>} : <type> <expr>}
	    | {rec {<id> : <type> <expr>}  <expr>}
            | {<expr> <expr>}

            | nempty
            | {ncons <expr> <expr>}
            | {nempty? <expr>}
            | {nfirst <expr>}
            | {nrest <expr>}

   <type> ::= number
            | boolean
            | nlist
            | (<type> -> <type>)
  

This language includes some primitives and constructs beyond those discussed in the lecture on types:

• iszero consumes a number, and returns true if it is 0, false otherwise
• bif is a general-purpose boolean if-expression; the test expression must evaluate to true or false
• ncons consumes a number and a numeric list, and produces a numeric list
• The remaining list primitives work on numeric lists

Problem 4a

Write the type judgments for the five numeric list constructs: nempty, ncons, nempty?, nfirst, and nrest. (You can write these by hand -- they do not need to be included in the file you submit via turnin).

Problem 4b

Implement the function type-of, which consumes an abstract representation of the program (i.e., the output of the parser). If the program has no type errors, type-of returns the type of the program, using the external representation of types given above. If the program does have a type error, type-of raises an error with a descriptive error message (such as "number is not a function").

As always, I will examine your test cases when grading.