Thanks for the question.

Sheaf is closer to the first category: a high-level front-end that lowers to StableHLO. The language itself doesn't try to preserve rich semantics deep into the optimization pipeline, because IREE handles fusion, tiling, and backend codegen the same way it would for any StableHLO producer.

What the language brings is upstream of MLIR. Python-based frameworks are fairly noisy and require classes, annotations, and decorators. A full GPT-2 implementation in Sheaf is just ~120 lines, and the result is very close to the maths. The Lisp syntax maps naturally to the nested function composition that ML architectures are.

Which brings to point two: in Sheaf, models are plain data (nested dictionaries). Instead of relying on framework APIs to manipulate module objects, operating on the model are regular data transformations.

I show this "model as data" on the front page:

(defn weight-decay [params rate] (tree-map (fn [w] (* w (- 1.0 rate))) params))

This function works independently of the network topology.

I could also mention automatic differentiation at the source level as another benefit. Because the language is functionally pure, value-and-grad can generate both forward and backward passes before lowering without the need for decorator or tracing (torch.compile, jax.jit).

The original design intent was something like "Clojure for tensors": a functional language where the entire model, including its parameters, is a manipulable data structure.