The following exercises will be graded on both correctness and style. Each function definition must be preceded by input and output type declarations, and the function's implementation must follow the shape of the input data.
Exercise 3.1, Free and bound variables
EoPL exercise 1.19 (page 31) and EoPL exercise 1.21 (page 31).Express your answer to 1.21 as a function answer-for-1.21; the function takes no arguments and returns an <s-list> representing a lambda-calculus expression.
Exercise 3.2, Lexical addresses
EoPL exercise 1.31 (page 37).
Exercise 3.3, define-datatype
EoPL exercise 2.7 (page 53). Call the new functions free-vars2 and bound-vars2.
Exercise 3.4, Environments as procedures
We have seen that variable names are not strictly necessary if we want to evaluate lambda-calculus-like expressions. Implement a position-based environment that has the following interface:
(empty-env/pos) - Creates an empty environment.
(extend-env/pos valsenv) - Extends env with a new set of vals at countour level 0, and with positions determined by the vals list. Values in env at countour level n are, in the new environment, at countour level n+1 (with the same position within the contour).
(apply-env/pos envcnpn) - Extracts the value at contour level cn and position pn.
For this exercise, implement position-based environments with procedures (as in EoPL section 2.3.2).
Exercise 3.5, Environments as abstract syntax
Implement position-based environments with datatypes (as in EoPL section 2.3.3). Call the functions empty-env/pos2, extend-env/pos2, and apply-env/pos2.
Exercise 3.6, Environments as vector lists
Implement position-based environments with lists of vectors, as in the ribcage reprsentation of EoPL section 2.3.4, but without the pair joining variable names with value vectors. Call the functions empty-env/pos3, extend-env/pos3, and apply-env/pos3.
Last update: Thursday, September 21st, 2000mflatt@cs.utah.edu