Composability

PFCL language reference · composure.systems

1.Scope

This document specifies the composability property of PFCL at the function level. It is a property of the catalog and the language, not of any individual function.

1. PFCL has one composition surface: functions.
2. Composability is the property that composition on this surface is well-defined, free of accidental interference between artifacts, and does not degrade the guarantees of the composed parts.

2.Function composability

Seven mechanisms of the language and the catalog structure make functions compose freely.

1. Content addressing. Every function is identified by the SHA-256 of its typed source body. Identity is a function of the body, not of the name or the storage location. Two functions with identical bodies have identical hashes; two functions with different bodies have different hashes regardless of name.
2. Names are aliases. A function's name is metadata, not identity. Two authors may use the same name for different bodies; the hashes distinguish them. A caller resolves a name to a hash at reference time. This removes namespace conflict as a reason to write larger functions.
3. Purity composes. A function composed of pure functions is pure. The property closes under composition, and the closure is complete at every depth. See /purity.
4. Totality composes. A function composed of admitted functions is itself admitted. The termination guarantee holds through composition without additional witnesses at the composition site. See /totality.
5. Direct hash reference. A caller may reference a function by its hash directly, bypassing name resolution. A body pinned by hash is stable regardless of any upstream rename, replacement, or supersession. This is what makes a third-party reference to a function durable.
6. No versioning. A semantic change to a function produces a new function at a new hash. There is no version number to increment and no migration path. Existing references continue to resolve to the exact body they were audited against.
7. Effects are values. A function that needs to describe an effect returns a command record; a host reads the record and performs the action. The function itself remains pure and composes the same way any function composes. Composition is uniform across effect-describing and effect-free functions, up to the host boundary. See /effects-as-data.

3.Exclusions

The composability guarantee does not cover the following.

1. Composability is not the mathematical property of function composition alone. That follows from purity. This document specifies the mechanisms that make composition of many small units easier than composition of few large ones, which is a property of the catalog structure in addition to the language.
2. Composability is not automatic. It rests on structural mechanisms of the language — content addressing, purity closure, totality closure, effects as values — and on the design of the function catalog. Removing any of these mechanisms would degrade the property.
3. Catalog governance is out of scope for this page. The mechanisms that push authoring toward small composable units at admission time — complexity limits, composability scoring, layer stratification, forced decomposition, machine granularity as a naming principle, retirement via supersession — are specified at /catalog. This page describes composition of already-authored artifacts; the catalog page describes how the catalog stays well-composed as it grows.