Description
In this assignment, you will complete the implementation of two interpreters and a type
inference algorithm for Mini-Haskell. You will make changes to the Eval and Ty modules,
and will submit an additional file, tests5.mhs.
This assignment assumes you have completed the Unify module in Assignment 5 and the
Eval and Ty modules in Assignment 6. You may use either the official solutions provided
for these assignments, or your own solutions (or any combination of the two). In the latter
case, you will need to copy the skeleton code for the ty function from the Ty module provided
for this problem set.
You must retrieve the new versions of Parser, Exp, and Val supplied for this problem set
(you may also want to download tests3.mhs and tests4.mhs to test your code). These are
identical to the versions used in the previous assignment, with the exception of new code and
definitions necessary for handling lambda abstractions:
data Exp = …
| Lam [String] Exp
…
data Val = …
| VLam [String] Exp (Env Val)
…
You are not allowed to modify any of the existing data type definitions unless a problem
states otherwise or explicitly directs you to change a definition.
Note: All function definitions at top level must have explicit type annotations. Unless
otherwise specified, your solutions may utilize functions from the standard prelude as well as
material from the lecture notes and textbook. You may not use any other materials without
explicit citation.
1
Problem 1. (15 pts)
In this problem, you will implement an evaluation algorithm for Mini-Haskell that uses the
call-by-value (CBV) environment model as defined in Chapter 13 of the lecture notes. You
will do so by modifying the existing definitions in the Eval module.
(a) In the Eval module, modify the definition of the appVals::Val -> Val -> Error
Val function so that it can handle the case in which the first argument is an evaluated
lambda abstraction, and the second is an argument for that lambda abstraction. You
only need to handle lambda abstractions with a single variable (that is, cases where
the list of strings under the Lam constructor has exactly one element). You may extend
your code to handle lambda abstractions with tuples for extra credit as part of your
solution to Problem #4 below.
(b) In the Eval module, modify the definition of the ev::Env Val -> Exp -> Error Val
function so that it can evaluate lambda abstractions.
You have now implemented a complete call-by-value interpreter for Mini-Haskell, and should
be able to test it using parseEval from the Main module. The program in tests4.mhs
computes a list of prime numbers using bounded recursion.
Problem 2. (60 pts)
In this problem, you will implement a complete interpreter for Mini-Haskell that uses the
call-by-name (CBN) substitution model, as defined in Chapter 13 of the lecture notes.
As usual, you only need to handle let bindings and lambda abstractions with a single
variable. You may extend your code to handle lambda abstractions and let bindings with
tuples for extra credit in Problem #5 below.
(a) In the Eval module, import the Unify module and add an instance declaration that
makes Exp a member of the Substitutable class. You may assume that all variable
names in a program are unique (for extra credit, you may change your code so that
it works even without this assumption in Problem #6), but you must not substitute
a bound variable under its own corresponding lambda or let binding. Think carefully about the checks that need to be performed when subst encounters a lambda
abstraction or let expression. There are two ways you can approach this problem:
∙ assume that substitutions of type Subst Exp have exactly one element and maintain this property in any substitutions of type Subst Exp you construct (this is
the easier option);
∙ add a function remove::String -> Subst a -> Subst a or remove::[String]
-> Subst a -> Subst a to the Unify module that removes the elements in the
substitution that correspond to the variable name(s) in the argument(s).
2
(b) In the Eval module, implement a function appValExp::Val -> Exp -> Error Val
that evaluates a value applied to an expression. You should not evaluate the second
arguments of the short-circuited boolean binary operators (i.e. ((&&) False) and
((||) True)). Note that for some cases, appValExp will need to build substitutions
and call subst. When you need to perform an evaluation, call ev0, not ev.
You will complete the implementation of ev0 in part (c) below. For convenience, you
may call appVals in some cases, but do this very carefully. You should not evaluate
any subexpression that does not need to be evaluated according to the evaluation rules
of the call-by-name substitution model.
(c) In the Eval module, modify the body of the ev0::Exp -> Error Val function so that
it evaluates all possible expressions (as usual, excepting lambda abstractions and let
bindings with multiple arguments) according to the call-by-name evaluation substitution
model, as defined in Chapter 13 of the lecture notes (Hint: For let bindings, it may be
easier to first convert each one into an equivalent application of a lambda abstraction
to an argument, and then to use appValExp, or even a recursive call to ev0).
(d) Create a file named tests5.mhs, and inside it write a small program on which the
call-by-value interpreter defined by ev diverges (runs forever), but on which the callby-name interpreter ev0 terminates.
Problem 3. (25 pts)
In this problem, you will complete a few parts of the full type inference algorithm for
Mini-Haskell. You will complete the already partially-implemented function ty::Env Ty ->
FreshVars -> Exp -> Error (Ty, Subst Ty, FreshVars), found in the Ty module available on the course website.
The ty function binds fresh type variables to any new variables it encounters in lambda
abstractions or let-bindings. Each time the function processes some node in an expression
tree, it may need to unify the types of the children of that node, and so, it accumulates
these substitutions, returning them to the caller. The cases for variables, let bindings, and
applications have already been completed for you, and you may use them as a guide in
completing the remaining parts of the algorithm.
(a) Add the base cases for expressions (the empty tuple, the empty list, integers, boolean
values, and operators) to the definition of the function ty. You may simply return the
fresh list of variables unchanged, and an empty substitution.
(b) The case for if expressions in the definition of ty is not complete. The function
tys::Env Ty -> FreshVars -> [Exp] -> Error ([Ty], Subst, FreshVars)
is used to obtain the types for all three subexpressions simultaneously. Perform the
remaining checks and unifications in order to complete this part of the definition. Remember that any substitutions you might generate in the process (including the one
3
that has already been generated when type checking the three subexpressions) need to
be considered in every subsequent unification.
(c) The case for tuples in the definition of ty is not complete. Complete this case.
(d) The case for general lambda abstractions in the definition of ty is not complete. Complete this part of the definition. Because a new variable is encountered, you will need
to obtain a fresh type variable, and bind this expression variable to the fresh type variable in the environment. The subexpression should be type-checked under this new
environment.
Remember that the argument type of the abstraction is the same as the type of the
variable over which the abstraction is defined. You may want to look at the part of the
definition of ty for let bindings for guidance.
Problem 4. (
∗10 extra credit pts)
Extend your solution to Problem #1 so that it handles lambda abstractions with multiple
arguments.
Problem 5. (
∗20 extra credit pts)
Extend your solution to Problem #2 so that it handles lambda abstractions and let
bindings with multiple arguments.
(a) Modify subst in the appropriate manner.
(b) Modify appValExp in the appropriate manner. Be certain that you do not evaluate
the argument passed to a lambda abstraction that takes unit (an empty tuple) as an
argument.
(c) Modify ev0 in the appropriate manner.
Problem 6. (
∗20 extra credit pts)
You will implement a transformation on expressions that ensures that the implementation of
subst in Problem #2 works correctly for all programs.
(a) Implement a recursive function unique::[String] -> Env String -> Exp -> (Exp,
[String]) that takes an expression and gives a unique name to every variable in that
expression, ensuring that no two lambda abstractions or let bindings are over a variable
with the same name. You will need to maintain a list of fresh variable names.
This list must also be returned with the result because an expression may have multiple
branches, and variables cannot repeat even across branches. The environment is used
to associate old variable names with new ones. More points can be earned if your
function handles let bindings and lambda abstractions with multiple arguments.
(b) Modify evalExp::Exp -> Error Val so that an expression is evaluated only after
being transformed using unique.
4
