The toolchain this course actually runs on, and how to build and run any week's starter or solution once you have it.

This page is about the toolchain — installing and confirming it. If you haven’t written OCaml before, the OCaml crash course covers the handful of language features this course’s interpreter actually leans on, with real examples pulled from interpreter/ itself.

What you need

An opam switch with dune. Nothing else — the reference interpreter behind every week and checkpoint uses only OCaml’s standard library, no third-party opam packages, so there is no dependency list to chase beyond the switch itself.

The exact versions this course’s own reference implementation was built and verified against:

You do not need these exact versions — any reasonably recent OCaml 5.x toolchain will build every interpreter/ project in this course — but if something doesn’t build and you want to rule out a toolchain mismatch first, this is what to compare against.

Creating a switch

If you don’t already have an opam switch:

opam switch create default 5.2.1
eval $(opam env)

Then confirm the pieces are actually there:

ocaml -version
dune --version
opam --version

If dune isn’t found, opam install dune gets it into the current switch.

Confirming it works

Every week and checkpoint in interpreter/ is a standalone dune project. Pick any one — week 1’s is the smallest — and confirm the whole pipeline before relying on it for real work:

cd interpreter/week-01
dune build
dune exec bin/main.exe -- examples/digits.sno

If that prints token output rather than erroring, your toolchain is fine and you’re ready for the first session. If dune build fails on a completely fresh project like this one, the problem is your toolchain, not this course’s code — fix that first, since (as week 1’s own session page says) every week after it assumes a working build.

The per-week workflow

Each week and checkpoint’s starter is downloadable from its own session page. Once you’ve unzipped one:

cd week-0N          # or checkpoint-N
dune build
dune exec bin/main.exe -- examples/<name>.sno

examples/ holds a handful of small .sno programs written to exercise that week’s new feature set (and, from week 2 onward, to double-check the previous week’s features still work unchanged) — running them is the fastest way to see whether a stub you’ve just filled in actually behaves like the transcript on the session page. interpreter/README.md, in this repository, documents this same mechanic in full, including the two starter-stub shapes (whole-function and partial) you’ll actually encounter while filling one in.

One thing that surprises people

Every lexer in this course — from week 1’s bare integer-literal scanner through to week 11’s — is hand-rolled, not generated by ocamllex. This is deliberate, not an oversight: SNOBOL4’s blank-sensitivity rule for + - * / needs to look at the character immediately before and after an operator at the same time, which is awkward to express in ocamllex’s forward-matching regex rules but easy to express as an explicit scan with “was the previous character a blank” as ordinary mutable state. If you go looking for a .mll file anywhere in interpreter/, you won’t find one — that’s expected.

If something doesn’t build

Check the toolchain versions above first, then check whether the specific project’s own dune-project file names a lang dune version newer than the dune you have installed (opam update && opam upgrade dune fixes that). If it still doesn’t build after that, it’s worth reporting — every starter and solution in this course is a real project that’s been built and run for real, so a build failure on an unmodified starter is a bug in this course’s code, not something to work around.