## Assignment 7, CSC430, Spring 2019

### 1` `Goal

Extend the interpreter (no classes) to include a type system.

### 2` `Guidelines

For this and all remaining assignments, every function you develop must come with the following things:

A commented header line that expresses the result of the function in terms of its inputs, written in English. Be as precise as you can within the space of a line or two.

A type declaration (possibly inline), specifying the input and output types.

Test cases. A function without test cases is incomplete. Write the test cases first, please.

For this assignment, you must develop your solutions using the typed/racket language. If you haven’t seen them, you might be interested in these Hints on Using Typed Racket in CPE 430.

Your test cases must use the check-equal?, check-=, or check-exn forms.

Your solution should take the form of a single file. Solve each problem separately, and make sure that each solution appears in a separate part of the file, with comments separating each problem’s solution.

Hand in your solution using the handin server. For help with the handin server, please see the course web page.

#### 2.1` `Handling Errors

All of your error messages must start with the string "ZNQR: ". Essentially, this allows my test cases to distinguish errors correctly signaled by your implementation from errors in your implementation. To be more specific: any error message that doesn’t contain the string "ZNQR" will be considered to be an error in your implementation.

#### 2.2` `Progress Toward Goal comment

Graders are happier when they know what to expect. Your final submission should start with a short one- or two-line comment indicating how far you got through the project. Ideally, this would just be: “Full project implemented.” But if you only implemented, say, squazz and blotz, and didn’t get to frob or dringo, please indicate this in the comment, so that we don’t spend all our time searching for bits that aren’t there.

### 3` `The Assignment

This assignment will build on the same core as the previous assignment: the Assignment 3 interpeter, with the addition of strings and recursive bindings. If you have a completed submission for Assignment 5, you can simply discard the class desugaring. If not, you can start from Assignment 3.

### 4` `Syntax of ZNQR7

A ZNQR7 program consists of a single expression.

The concrete syntax of the ZNQR7 expressions with these additional features can be captured with the following EBNFs.

expr | = | num | ||

| | string | |||

| | id | |||

| | {if expr expr expr} | |||

| | {id <- expr} | |||

| | {var {id : ty = expr} ... expr} | |||

| | {{[id : ty] ...} -> expr} | |||

| | {rec {id {[id : ty] ...} : ty -> expr} expr} | |||

| | {expr expr ...} |

ty | = | num | ||

| | bool | |||

| | str | |||

| | {ty ... -> ty} |

operator | = | + | ||

| | - | |||

| | * | |||

| | / | |||

| | num-eq? | |||

| | str-eq? | |||

| | <= | |||

| | substring |

... where an id is not var, if, lam, =, <-, ->, :, or rec.

#### 4.1` `Primitives

procedure

(+ a b) → num

a : num b : num

procedure

(- a b) → num

a : num b : num

procedure

(* a b) → num

a : num b : num

procedure

(/ a b) → num

a : num b : num

procedure

(<= a b) → boolean

a : num b : num

procedure

(num-eq? a b) → boolean

a : num b : num

procedure

(str-eq? a b) → boolean

a : str b : str

procedure

(substring str begin end) → string

str : str begin : num end : num

value

true : boolean

value

false : boolean

#### 4.2` `Type Checking

Implement a type checker for your language. Note that since functions must now come annotated with types for arguments, you will need to have a type parser that parses types. For Heaven’s sake, make a separate function for this. Note that the types of functions are extended to handle multiple arguments. So, for instance, the type {num str -> bool} refers to a function that accepts two arguments, a number and a string, and returns a boolean.

All type rules are standard.

##### 4.2.1` `Binops

Type-checking binops is more or less as you might expect. For instance, a + should receive two numbers, and will produce a number. The <= operator will take two numbers, and return a boolean.

The equal? operator is a bit different. Specifically, we don’t have subtyping, and we treat the equality operator as a function in the environment, so it must have a single type. In order to simplify our lives, we split it into two equality operators; one that only works for numbers, called num-eq?, with type {num num -> bool}, and one that only works for strings, called str-eq?, with type {str str -> bool}.

Also, note that begin is not a primitive in this language. Can you see why?

### 5` `Recursion

As in the last assignment, the rec form can be desugared into a binding and a mutation. Since we don’t have the begin primitive any more, you’ll need to desugar into a var binding. Also, since type-checking will prevent you from assigning the string-valued "bogus" to your ultimately function-valued variable, you will need to write a function (you could call it make-bogus-value-of-type, as I did) that accepts a type and returns a bogus value of that type.

Something like this:

{rec {silly {[x : num]} : num -> {- x 1}} {silly 9}}

... might desugar to this:

{var {silly : {num -> num} = {{[a : num]} -> #xdeadbeef}} {var {dontcare : num = {silly <- {{[x : num]} -> {- x 1}}}} {silly 9}}}

Note that the type associated with dontcare will be whatever type your mutation operator returns (it’s unspecified in the assignment).

### 6` `Suggested Implementation Strategy

Here are some of the steps that I followed. I wrote test cases for every step before implementing it.

Add a data definition for Types.

Add a parser for the language of types.

Develop a type checker that only works for constants.

Add a definition for Type Environments, mapping symbols to types.

Extend your type checker to handle variables and if expressions.

Extend your type checker to handle applications. (Since you don’t have types for LamC terms yet, your test cases should just use primitive functions.)

Extend your AST nodes for LamC nodes to include types with the parameters.

Extend your type checker to handle LamC terms.

Extend your parser and type checker to handle the modified var and rec terms.

Add your type checker to top-interp. Type checking should happen after parsing and before interpretation.

### 7` `Interface

Make sure that you include the following functions, and that they match this interface:

procedure

(parse s) → ExprC

s : Sexp

procedure

(parse-typo s) → Ty

s : Sexp

procedure

(type-check e env) → Ty

e : ExprC env : TEnv

value

base-tenv : TEnv

procedure

(interp e env) → Value

e : ExprC env : Environment

procedure

(top-interp s) → string

s : s-expression