Catalog — Related Work

PFCL language reference · composure.systems

The PFCL catalog specification (/catalog) describes what the catalog is. This page, and the pages it links to, describe how it relates to prior systems that share part of its design — content addressing, immutable artifacts, dependency-conflict avoidance. Each comparison gets its own page so that the specification pages stay free of comparative claims, and so each comparison can be as thorough and as carefully cited as it needs to be, independent of the others.

Unison

The closest prior art. Both systems identify code by content hash rather than name or version. The two diverge concretely on two points: Unison's hash function folds in alpha-equivalence (two definitions differing only in a bound variable's name hash identically); PFCL's does not. Unison automatically propagates an updated definition to its type-compatible dependents; PFCL rebinds a name and leaves dependents to resolve it on next load. → /catalog/related-work/unison

Nix

Not yet written. Nix identifies build artifacts by a hash derived from their build inputs, achieving reproducibility at the level of an entire build closure rather than an individual function or definition. The comparison worth drawing out: what Nix hashes (a build's inputs and process) versus what PFCL hashes (a function's own canonical source), and what each buys and costs at that different grain.

Git

Not yet written. Git's object store is content-addressed (blobs, trees, commits, all identified by hash), which makes it the most familiar content-addressing system to most programmers, but Git addresses whole files and trees, not individual functions, and has no admission-time structural rules of the kind /catalog §3 specifies. Worth drawing out precisely where the analogy holds and where treating a catalog like "git for functions" undersells or oversells what either system does.

Package managers and module systems

Not yet written. The systems the catalog model replaces rather than resembles — npm, Cargo, pip, and module/import systems generally. The comparison here is less "how are these similar" and more "which specific pathology (diamond dependencies, transitive version conflicts, supply-chain trust in a registry) does content addressing structurally prevent, versus merely mitigate with tooling."

Reproducible builds

Not yet written. The reproducible-builds movement (Debian, and others) targets bit-for-bit reproducibility of build outputs from source — a related but distinct goal from PFCL's identity model, which makes source itself, not a build output, the hashed artifact. Worth situating PFCL's "verifiable with sha256sum alone" claim against what the reproducible-builds literature means by verifiability, since the terms overlap but aren't identical.