Checkpoint 2
Complete a partially-implemented OCaml starter — the goto field, failure propagation, and DEFINEd functions — matching Movement II's two sessions
Due: 2 April 2027 · Weight: 20%
The brief#
Complete a starter OCaml implementation so it executes labeled statements with a goto field driven by success and failure, and calls user-defined functions declared with
DEFINE— the two things Movement II’s sessions built up over weeks 5–6.
You are starting from Checkpoint 1’s working evaluator, not from a blank
page: the starter is Checkpoint 1’s solution with this movement’s new
material stubbed out as failwith "TODO" — the goto-field dispatch and
DEFINE/call-frame handling are the gaps, everything from Movement I
(literals, arithmetic, variables, string concatenation) already works and
should not need to change. Your job is to fill in exactly the Movement II
gaps, using the starter’s existing statement and evaluator representation
rather than redesigning the pipeline around them. Download the starter at
checkpoint-2-starter.zip; it
includes a sample transcript showing the exact input/output behaviour your
completed evaluator should match once every TODO is filled in.
As with Checkpoint 1, this is a correctness checkpoint with a narrow
brief. A response that reproduces the sample transcript’s behaviour on the
given inputs, and behaves sensibly on inputs of the same shape the
transcript didn’t happen to cover (a goto field with both S and F
present, a function called with too few or too many arguments, a
recursive call at least two levels deep), is a complete response.
Anything from Movement III onward — pattern matching, ./$ assignment,
the pattern primitives — is out of scope here; it belongs to later
checkpoints.
What you submit#
Your completed .ml/.mll source files, in the same project layout the
starter arrived in, building cleanly with the starter’s own dune setup.
Include a short note (a few sentences is enough) naming any place you
departed from the starter’s existing structure and why — this is the
“quality of execution” half of the criteria below, and it’s also where you
declare any assistance you used, per the course’s academic integrity
policy.
The marking: block above renders as a weighted criterion table: the bulk
of the mark is whether your evaluator actually reproduces the sample
transcript’s behaviour; the remainder is whether your completed code reads
as a reasonable continuation of the starter rather than a bolt-on.
The spec
The brief poses the problem and leaves room for a response. The spec is the fixed part: what a marker checks. Some lines can be checked mechanically; the rest call for judgement.
- submitted by the deadline, in the format named below
- the completed evaluator reproduces the sample transcript's output exactly
- the work is yours, with any assistance declared
How it is marked
| Criterion | Weight |
|---|---|
| Correctness against the sample transcript | 70% |
| Code quality and fit with the starter's existing structure | 30% |