Below is the general format for each question's marks, with codes
representing each subsection.

   correctness:
        _O_ output:  marked automatically
        _I_ inspection:  code looks reasonable

    efficiency:
        _A_ asymptotic:  correct overall runtime
        _D_ detailed:  reasonable effort to avoid
            duplicated/unnecessary computation

    style:  appropriate use of
        _P_ patterns
        _L_ local declarations
        _C_ comments
        _W_ whitespace and indentation
        _N_ identifier names

Some deduction are self-exlplanatory, such as losing comment marks for not
having comments, or losing pattern matching marks for not using pattern
matching.
For all other deductions, there is a note stating the code for the section
in question, and why the deduction was taken.  Note that if a submission
was significantly wrong (e.g., used the wrong basic pattern of recursion)
in a question where efficiency was important, some efficiency marks were
deducted as well.  Additionally, some codes were used to represent common
deductions.  The complete list of codes is:

NS - No submission

Deduction affecting output mark:
O1 - Does not compile.
O2 - Functions have types other than what was specified in the handout.

Deduction affecting inspection:
I1 - Generally bad style such as [x] @ xs (instead of x :: xs).

Deductions involving detailed runtime:
D1 - Checks if n < 0 (or similar) at each recursive call
     Typical deduction: -1 (-3 for question 2, as this was
     explicitly forbidden)
D2 - Helper function redefined at every recursive call
     Typical deduction: -1

Deduction involving comments:
C1 - No description of what the function does or how to use it.
     This deduction was waived if the submission had otherwise
     exceptional comments.

Deductions affecting local definitions:
L1 - Unnecessary local definition.
     Contains a local declaration that doesn't really serve any purpose.
     Example: fun f x =
                let fun g 0 = 1
                  | fun g y = 2 * (g (y - 1))
                in g x
              (instead of simply defining f directly)
     Typical deduction: -1
L2 - Redundant code/cases in definitions.
     This mostly applies to trib.sml, and was applied to submissions that
     included identical code for base cases in several helper functions.
     Typical deduction: -1
L3 - Exception defined in local definition.
     This applies to compose.sml, and was applied to submissions that
     defined the Negative exception in a local definition (where it will
     not be available outside).
     Typical deduction: -1
L4 - Helper functions defined globally.
     All helper functions were defined globally instead of locally.
     Typical deduction: All L marks for question.

Deduction affecting patterns:
P1 - Some redundant patterns.
     Code contains several patterns that could be combined into a single
     one, as in the example below, or redundant patterns checking for Nil
     in multapply.sml when only one check is needed for each LL.
     Example:
        ...
          | standardize (Var (x)) = (Var (x))
          | standardize (True) = True
          | standardize (False) = False
        ...
     Typical deduction: -1

Deduction involving identifier names:
N1 - Poor helper function names.
     For each question, I allowed one meaningless helper function name,
     such as: "mapply", "squeezeHelper", "squeeze_h", etc.  After that, if
     there were additional helper functions with poor names, a deduction of
     0.5-1.0 marks was taken, depending on the severity of the problem.
     Typical deduction: -0.5 or -1