Why ML/OCaml are good for writing compilers (1998)

It's interesting to note that this list applies well to other compiler-oriented toolchains, including ones entirely beyond the ML tradition. In particular, RPython has (1), (3), (5), (6), (7), (8), (9), (11), and (12), as well as techniques to handle (2) and (4). Only (10) and (13), which are about speed of compilation and separate compilation, are beyond RPython. Further, I'd suggest that RPython's string handling, borrowed from Python 2.7, is far nicer than in any flavor of ML.

One missing concept from the list, which is available in RPython and some unmentioned flavors of ML like MetaOCaml, is the ability to stage code and import non-ML data as code. RPython doesn't have a clean stratified way to do more than two stages; instead, there's one really big stage with a live Python 2.7 heap, followed by many minutes of freezing, uncalling, and partial evaluation.

This submission was inspired by Bun's rewrite from Zig to Rust, and Roc's rewrite from Rust to Zig. Why not just rewrite all compilers in OCaml and call it a day? ;-)