CSC 272
Homework 2
Assigned Feb 5, due Feb 19

This assignment is to be done in PLT Scheme. You are encouraged to do this in teams of two, both students working together on all parts of the assignment; if you do this, turn in one homework with both names on it.

For all functions, follow the design recipe: each function must have a contract, a good collection of test cases, and a function definition.

Deferred Substitution

Modify your program from Homework 1 so it uses "deferred substitution" as described in Chapter 5 of PLAI. As a result, your interp function will take in an expression, a list of function definitions, and a list of variable bindings.

This should require no changes to the concrete syntax, the abstract syntax, or the parser (except to fix mistakes you found in Homework 1), but it will require changing the interp function.

Note: Dr. Krishnamurthi's DefrdSub data structure is basically a linked list implemented from scratch. If you would prefer to use Scheme's built-in lists instead, that's fine: you'll just need to use cond, empty?, and cons? instead of type-case to go through such lists.

Note: A lot of the work is done for you in Chapter 5, but not all.

Answer questions 5.3.1 and 5.3.3 from the PLAI textbook (on paper or in an e-mailed document).

Multi-Parameter Functions

Modify your program so it allows a user-defined function to take any (fixed) number of parameters. You'll need to change the data structure definition for FunDef to allow for a list of parameter names. The concrete syntax will change to allow a user-defined function to be called on zero or more arguments, rather than only on exactly one. The abstract syntax will change so the funcall variant (or app in the book) takes a list of argument expressions rather than exactly one. The parser will change to accept the new concrete syntax and produce the new abstract syntax; it should also check that functions are called with the right number of arguments, and produce an error message if not.

General Comments: As always, every function must have a contract and test cases. Any user errors you can catch in the parser should be caught there, rather than waiting for run-time (the interpreter), such as calling a user-defined function on the wrong number of arguments, or calling a user-defined function that isn't actually defined at all.
Last modified: Thu Feb 4 14:17:25 EST 2010
Stephen Bloch / sbloch@adelphi.edu