Remember to include a table in your submission. Anytime a 2 one of problem is hand graded we look for a properly formed and completed 2 one of table.
When creating a table, the column and row headers should be type comment fragments and should match the types found in the signature.
When testing, at minimum there should be one test for each unsimpified cell of the table. Typically there should be additional tests for the lower right cell due to how complicated it tends to be. It is very common for students to forget to test all of the simple cells.
Remember when simplifying the table, you must number the cells and then number the corresponding cond cases. Submissions missing these labels will not get full marks.
The function definition must match your table. If the table is not correct that may effect the grading of the function definition. Make sure that the whole design is correct, do not focus on just the function definition.
The cond questions should be derived from the column and row headers following the ``cond question'' part of the how to design data definitions recipe, with the code from the recipe being combined with and, or, and not.
Remember that any time you design a helper function at top-level you must include all HtDF recipe elements.
Remember that every item in the original template origin tags should be in the combined template origin tag + encapsulated.
Do not leave commented code in the file when refactoring. Leaving a clean file makes it easier to read. Imagine what a twenty-year old program would look like if people who worked on it left their scratch work behind whenever they improved it.
All the encapsulated function definitions should be in the local definitions part of the local expression; then the trampoline should be a simple function call to one of the local definitions. Do not put one of the encapsulated functions entirely in the body of the local expression.
The solution for this problem set is: