Machine Problem Evaluation Criteria

• Program correctness. Functions need to satisfy their specification; in particular, your interpreter needs to implement the language under investigation.
• Program design.
  • One task one function. Common tasks should be factored into a function. Functions that deconstruct their input should follow the structure of the data.
  • Each newly created function should be documented with a contract, purpose statement, and some illustrative examples.
• Test coverage. You should add enough tests to check that new features of your interpreter work as expected. You should create simple and complex cases for each feature on its own, and you should also check that combinations of features work properly, both between new features and old features.

We are grading the quality of your whole solution, not just that your interpreter behaves as required. Code is not just meant for execution by a machine; it is also read, analyzed, and extended by human programmers.

What follows is a list of common problems exhibited by solutions in this past.

1. Contracts:
   • should be strict. Schemevalue -> Schemevalue covers any unary function you might write, but tells the client of your function almost nothing. Client code should be able to use your function knowing only its contract and purpose statement.
   • should be honored. Make sure your implementation and your contract are consistent.
     • If your contract specifies that it expects a number as input, then there is no need to check your input is a number, or anything else.
     • If your contract specifies that it produces a number, then you should should only write expressions that evaluate to numbers.
   • require maintenance. If a modification to a function changes what classes of data it consumes or produces, then that function's contract must also be redefined. (This is a simple but often overlooked consequence of the above two requirements.)
2. Examples should illustrate your function's purpose statement via a few concrete inputs and outputs. Examples that are inconsistent with a function's specifiction or implementation indicate you do not fully understand your solution.
3. Code
   • should be simple and clean. Before submitting a machine problem, remove any debugging code you have added.
   • should be indented appropriately.
   • should have only lines of less than 80 characters width. Lines longer than 80 characters will be penalized.
4. Make it clear what your modifications are. Use comments to indicate where you have made changes. When adding tests, keep all of your tests before or after the tests provided in the assignment.
5. Dead code will be penalized. If you have code that never gets called, remove it.
6. In your development diaries, provide totals for Time and Lines of modified/added code.