The Persistent Dimension

Type systems erase dimensional annotations before code generation. Meters, seconds, kilograms — these labels exist in the source code, where they prevent nonsensical operations like adding a distance to a time. The type checker enforces dimensional consistency. Then the compiler strips the labels away, and the generated code operates on bare numbers. The safety was a compilation-time property, not a runtime one.

Haynes (arXiv:2603.16437) refuses to erase. The dimensional metadata persists through every MLIR lowering phase, from high-level tensor operations down to machine-level memory management. Dimensions are treated as coeffect properties — annotations that travel alongside the computation through every transformation stage.

The unexpected payoff: the dimensional algebra turns out to encode information the compiler needs for entirely unrelated tasks. Cache locality depends on which array dimensions are contiguous in memory — and the physical dimensions (space, time, channel) determine the natural memory layout. Auto-differentiation requires tracking which quantities are differentiated with respect to which — and the dimensional algebra is closed under the chain rule, meaning gradient computation inherits dimensional correctness for free.

The constraint that forbids adding meters to seconds also tells the compiler where to store the result in memory. The prohibition is not just a check; it is structural information about the computation that was being thrown away at the first compilation stage.

This is a general principle about type-level information: constraints that exist for one purpose (preventing errors) often encode information useful for other purposes (optimization, verification, layout). The type checker knows things the optimizer needs. Erasing the types severs this connection. Preserving them reveals that the “restriction” was always also a description — of the computation’s structure, not just its correctness.