COMP 105 fault graph for type checkers

The graph below shows the results of testing type checkers.
Read the nodes as follows:

• The number or numbers in each node identify a submission or set of submissions. Numbers are chosen to keep students anonymous; you should have received your number by email.
• Each node shows how many tests were passed by submissions in that node. The graph includes only meaningful tests. A test is meaningful if it distinguishes a unique set of outcomes, and if its results are not implied by a combination of other tests. Most outcomes have a set of equivalent tests which produce identical outcomes; we use the smallest such test.
• The bars at the bottom of each node show exactly which tests were passed. A vertical bar represents a pass; a dot represents failure or a catastrophic error.

• If node A points to node B, than node B passed strictly more tests than node A; node B is strictly better. The edge from A to B shows the smallest test case that A fails and B passes.
• If there is a single node at the top, which all the others point to, it contains the submissions that passed all tests.
• If two nodes are not connected by any path, then the submissions in those nodes have distinct, independent bugs.
• If there is a node not at the top which contains more than one submission, it means that as far as we could discover by testing, these submissions have identical faults.

1. Failed to type-check the function 'o' from the initial basis (or gave it the wrong type).
2. Did not process the function != from the initial basis.
3. Gave '() the non-polymorphic type (list 'a).
4. Accepted '(a 1) with type (list sym).
4a. Given '(a 1), failed with uncaught exception ValNotFound
5a. Term ('1 5) triggered uncaught exception ImpossibleHasHappened.
6. Let (+ 1 #t) past the type checker.
7. Instantiated (@ + int) even though + is not polymorphic.
7a. Correctly detected (@ + int) as a faulty instantiation, but did not catch the resulting TypeError exception.
8. Accepted (val-rec int e1 e1).
8a. Let (val-rec int e1 e1) past the type checker, raising uncaught exception BugInTypeChecking
9. Did not check return type in 'define'.
10. On term(val e2 ((@ cdr int) '(1))), expected type(list int), but got this error instead: type error: (forall ('a) (function ((list 'a)) (list 'a)))is not a valid function expression
11. Failed give (type-lambda ('a) 3) its proper type(forall ('a) int).
12. Accepted (int int) as the type of a lambda-bound variable.
12a. Detected (int int) as a bad type, but failed to catch the resulting exception.
13. Failed to bind 'f' in(let* ((f 3) (g f)) ...)).
14. Either got type error or inferred wrong type for (val e1 (let ((f 3)) (let ((g f) (f #t)) (+ g 96)))), which has typeint.
15. Various failures (g not found, type error, function type) on term(val e2 (let ((f 3)) (let ((f #t) (g f)) (+ g 96)))), which has typeint.
16. Did not use 'eqType' to check equality of types in SET expression.
17. Did not use 'eqType' to check equality of polymorphic types.
18. Failed on a term using 'left' and 'either'.
19. Refused to swallow the correct definition (val-rec (forall ('a) (function ((list 'a) int) 'a)) nth-element (type-lambda ('a) (lambda (((list 'a) l) (int n)) (if ((@ = int) n 0) ((@ car 'a) l) ((@ nth-element 'a) ((@ cdr 'a) l) (- n 1)))))).