# Homework 4

## Lambda calculus interpreter

This homework is written in literate Haskell; you can download the raw source to fill in yourself. You’re welcome to submit literate Haskell yourself, or to start fresh in a new file, literate or not.

Please submit homeworks via the DCI submission page.

**NOTE:** This homework will be due on *Friday*, October 2nd, since I didn’t post it until Saturday.

```
module Hw04 where
import Prelude hiding (succ,pred)
import qualified Data.Map as Map
import Data.Map (Map, (!))
import qualified Data.Set as Set
import Data.Set (Set)
```

**Problem 1: pure lambda calculus**

We’ll just have variable names be strings.

`type Id = String`

The pure lambda calculus has three forms: variables, applications, and lambda abstractions.

```
data LCExpr =
LCVar Id
| LCApp LCExpr LCExpr
| LCLam Id LCExpr
deriving (Show,Eq)
```

Write a function `freeVars`

that collects the set of free variables in a given lambda calculus expression.

```
freeVars :: LCExpr -> Set Id
freeVars = undefined
```

Write a function `wellScoped`

that determines whether or not a given lambda calculus is well scoped, i.e., there.

```
wellScoped :: LCExpr -> Bool
wellScoped = undefined
```

Here we’ve defined a simple, environment-based lambda calculus interpreter, just like we’ve looked at in class on Monday.

```
data LCValue = Closure Id LCExpr (Env LCValue) deriving Eq
type Env a = Map Id a
extend :: Env a -> Id -> a -> Env a
extend env x v = Map.insert x v env
evalLC :: Env LCValue -> LCExpr -> LCValue
evalLC env (LCVar x) = env ! x
evalLC env (LCApp e1 e2) =
case evalLC env e1 of
Closure x e env' -> evalLC (extend env' x (evalLC env e2)) e
evalLC env (LCLam x e) = Closure x e env
runLC :: LCExpr -> LCValue
runLC = evalLC Map.empty
```

We’re going to implement some of the Church numeral material we’ve seen in class. Here are the initial definitions:

```
true = LCLam "x" (LCLam "y" (LCVar "x"))
false = LCLam "x" (LCLam "y" (LCVar "y"))
cond = LCLam "p" (LCLam "t" (LCLam "e" (LCApp (LCApp (LCVar "p") (LCVar "t")) (LCVar "f"))))
zero = LCLam "s" (LCLam "z" (LCVar "z"))
succ = LCLam "n" (LCLam "s" (LCLam "z"
(LCApp (LCVar "s") (LCApp (LCApp (LCVar "n") (LCVar "s")) (LCVar "z")))))
```

This is a little annoying. Surely we can make these kinds of definitions easier! Write a function `lam`

that takes a list of variable names and a function body and produces a series of nested lambda expressions around that body. For example `lam ["s","z"] (LCVar "z")`

should yield the value for `zero`

.

If `lam`

is called with an empty `args`

list, it should just return the `body`

.

```
lam :: [Id] -> LCExpr -> LCExpr
lam args body = undefined
```

Write a similar function, `app`

, that takes a list of expressions and produces an appropriately nested application. For example, `lam ["n","s","z"] (app [LCVar "s",app [LCVar "n",LCVar "s",LCVar "z"]])`

should yield the value for `succ`

.

What should `app`

do when called with no arguments? Is there a value that’s generally ‘safe’ to return here?

```
app :: [LCExpr] -> LCExpr
app es = undefined
```

With these helper functions to hand, complete the following definitions for Church numerals. You can of course use any of the foregoing functions.

```
isZero, plus, times :: LCExpr
isZero = undefined
plus = undefined
times = undefined
```

Here is the Church encoding for pairs.

```
pair = lam ["a","b","c"] $ app $ map LCVar ["c","a","b"]
first = lam ["c"] $ app [LCVar "c", true]
second = lam ["c"]$ app [LCVar "c", false]
```

Now define the predecessor function, `pred`

, and subtraction, `sub`

.

```
pred, sub :: LCExpr
pred = undefined
sub = undefined
```

**Problem 2: lambda calculus with primitives**

You may have a headache from debugging your pure lambda calculus code—how do you know what number something is? In this problem, you’ll definie a lambda calculus interpreter that has numbers and booleans, too.

Here’s the new definition of values and expressions. Unfortunately, we can’t reuse the constructor names, so we’ll prefix these values and express with `V`

and `E`

, respectively.

```
data Value =
VClosure Id Expr (Env Value)
| VNumber Int
| VBoolean Bool
data Expr =
EVar Id
| ETrue
| EFalse
| EIf Expr Expr Expr
| ENum Int
| EIncr Expr
| EDecr Expr
| EIsZero Expr
| EApp Expr Expr
| ELam Id Expr
deriving (Show, Eq)
```

Please define an evaluator for this extended language. If the user does something ‘wrong’—like try to apply a number like a function—then you should use the function `error :: String -> a`

to signal an error. Your error message should clearly explain the problem: what type of value did you expect, and what did you get instead? (Soon we’ll define a type system that will rule out these errors entirely.)

```
eval :: Env Value -> Expr -> Value
eval = undefined
```

Write a function `embed`

, that embeds the terms of the pure lambda calculus into our new, extended language.

```
embed :: LCExpr -> Expr
embed = undefined
```

Write functions `toChurch`

and `fromChurch`

*in the* `Expr`

*language* that convert `ENum`

numbers to and from Church numerals. You may want to use the Y combinator (defined below as `y`

) to write a recursive function.

```
y :: Expr
y = ELam "f" $ EApp g g
where g = ELam "x" $ EApp f (EApp x x)
f = EVar "f"
x = EVar "x"
```

For `toChurch`

, you don’t need to worry about negative inputs. (But: given this impoverished language, what would you do if I sadistically required you to worry about them?)

```
toChurch :: Expr
toChurch = undefined
```

```
fromChurch :: Expr
fromChurch = undefined
```

**Problem 3: substitution**

The semantics for the lambda calculus we’ve used in class uses substitution, not environments. Let’s write an interpreter that uses substitution!

*(a) 10 points*

What should the type of the substitution function be? How does using substitution change the type of our evaluation function? Do we need to add new datatypes, drop old ones, or leave everything the same? Why or why not?

Think hard about this question before you do parts *(b)* and *(c)*. Write down your thoughts, and then actually implement the function. Were you right?

fill in here

*(b) 5 points*

Implement the substitution function for the pure lambda calculus (`LCExpr`

). Call it `subst`

. You may assume that `e`

is closed—there is no need to be capture-avoiding.

*(c) 5 points*

Implement a call-by-value interpreter for the pure lambda calculus (`LCExpr`

) using substitution. Call it `evalSubst`

. You can use `error :: String -> a`

to signal an error if you need to.

*(d) 5 points*

What are the pros and cons of the two styles of evaluator we’ve written?

fill in here

*(e) 5 points*

What do you need to do to adapt your definition of `evalSubst`

to use call-by-name evaluation? You may either write code or prose explaining what your code would do.

fill in here