Lynton Graetz

Eshkol is the most fully Grothendieckian programming language ever conceived and implemented

have you started using Eshkol yet?

you should take a look at the Eshkol programming language. most of these concepts have already been practically implemented. eshkol.ai

be the change you wish to see in the world

Eshkol v1.3.4-evolve: Exactness is an axis, not a floor. Every numerical stack you have used made the same decision, and made it so long ago that it stopped looking like a decision: exactness ends at float64. Below that line you can buy more precision if you pay for it. Above it, you cannot buy any, at any price, because nothing in the stack can represent the answer you wanted. That is not a law of arithmetic. It is a budget decision from the 1980s that got frozen into every library built since. You can see the seam most clearly at the derivative. Ask JAX, PyTorch or Zygote for d/dx of 7x³ + 3x² + x at x = 1/3 and you get 5.333333333333333. The true answer is 16/3. The frameworks are not wrong so much as unable to say the true thing: their tape carries doubles, so the exact rational was destroyed before the derivative existed. Eshkol answers 16/3. (define (f x) (+ (* 7 x x x) (* 3 x x) x)) (derivative-n f 1/3 1) => 16/3 (derivative-n f 1/3 2) => 20 (exact? (derivative-n f 1/3 1)) => #t This is not a trick and it is not a symbolic differentiator bolted to the side. Automatic differentiation in Eshkol is a compiler primitive, and the compiler carries the whole R7RS numeric tower: rationals, bignums, and their contagion rules. So the Taylor coefficients of a rational function are themselves exact rationals, and the derivative of an exact point is exact. As of v1.3.4-evolve, `rational` is a registered exact type under Number, sibling to Integer and Real, so the thing the runtime always carried is finally spellable in a type. The interesting claim is not that one derivative came out exact. It is that exactness turns out to be an axis you can dial per computation, rather than a floor you hit and stop at. This release is what that looks like when you build it in. Take the hardware axis. Apple Silicon GPUs have no native f64 at all: not slow f64, none. The conventional read is that exact double-precision linear algebra is therefore off the table on that machine. v1.3.4 ships it anyway: forty-nine pairwise coprime moduli decompose each double into residues, an f32 GEMM runs per residue pair, and the Chinese Remainder Theorem reconstructs the result. The exactness is bought with integer throughput nobody was spending on numerics. The same construction runs on NVIDIA INT8 tensor cores, the units built for quantized inference. And it does not approximate what your CPU would have said. It computes the exact product, the one your CPU's own DGEMM is itself only approximating, because BLAS rounds at every accumulation and a CRT reconstruction rounds once. The GPU result is the more trustworthy of the two. Take the domain axis. A derivative at a point tells you about that point. Eshkol's Taylor models return a polynomial plus a rigorous interval remainder, which is a proven enclosure of the function over a whole domain. That is a different kind of statement than a sampled estimate: it is a claim you can put in a proof rather than a plot. Take the accumulation axis, where most silent numerical damage actually happens. v1.3.4 adds a native 128-bit integer type in the numeric tower and a fixed-point exact-accumulation engine, for reductions where the low bits are the answer and float64 quietly eats them. Floats also print shortest-round-trip now, so a printed value reads back as the value that was printed: exactness at the boundary where most people stop paying attention. None of these are available to a library. That is the part worth dwelling on. A tracing autodiff library sits on top of float arrays it did not design and cannot change. It can only be as exact as the container it was handed. Because Eshkol's differentiation lives in the compiler, it inherits the numeric tower for free, and it also gets to choose its own algorithm: nth derivatives come from truncated-Taylor recurrences at O(n²) rather than the 2ⁿ blow-up of nested dual numbers. Arbitrary order is a practical operation here, not a demo. And the same machinery emits for three backends, so a gradient is bit-identical whether it runs as native machine code through LLVM 21, as bytecode on the VM, or in a browser tab. Three unrelated execution engines agreeing to the last bit on floating point is not free; it is most of the engineering. Memory works the same way, for the same reason. Eshkol reclaims by region and has no garbage collector, so nothing pauses, ever. In v1.3.4 a resident loop lowers to a per-loop nursery: write barriers promote whatever escapes at the point of the store, the tail-call back edge resets it, and a hundred thousand ticks later the process is exactly as large as it started—flat at 34MB, byte-identical to the `with-region` a careful programmer would have placed by hand. Where the scope is not lexical you can hold the region as an ordinary value, and a raise, guard or call/cc out of it unwinds correctly. Deterministic exactness in time, next to deterministic exactness in arithmetic. Here is the composition test, which is the only test that matters for a claim like this. Write the STO-3G Born-Oppenheimer energy of H₂ as ordinary Eshkol: your own Boys function, your own Gaussian integrals, a 2×2 full-CI eigenvalue. Nothing in it was written to be differentiable. Now ask the compiler to differentiate it, through the eigenvalue, run Newton's method on the first derivative to find equilibrium, and read the force constant off the second. R* = 1.3887 bohr. E = −1.1373 Ha. d²E/dR² = 0.4771 Ha/bohr². ω = 5003.2 cm⁻¹. Experiment says 4401. That gap is the minimal basis and the harmonic approximation; the physics you asked for, faithfully differentiated. It is not error in the derivative, because there is no finite-difference fallback anywhere in the gradient path for error to enter through. Change the basis and the number moves; the differentiation has nothing to apologise for. A molecular Hessian, out of a Scheme compiler, from a program that never heard the word differentiable. The rest of v1.3.4-evolve follows the same grain. A linear Qubit type makes no-cloning a compile-time type error rather than a runtime discovery. Moonlab is pinned to v1.2.0 for the quantum geometric tensor and smooth potential-energy surfaces, and (gradient vqe-energy) flows through native AD to arbitrary order. The reverse-mode tape is public on JIT and AOT: ad-pow, ad-gradient-of, ad-value-of, ad-tape-length, with new backward rules for embeddings and for the Fréchet mean via implicit differentiation. linear-solve does full-f64 dense with a mixed-precision fast path. There is a portable event loop on kqueue and epoll, and --shared-lib emits a real C-ABI shared library you can link from C. Measured at the tag: ctest 184/184; executable language coverage 1,106/1,106; VM parity differential 184/184; SICP, the full book, 88/88 under both -r and AOT; reference-Scheme differential 34/34 against chibi-scheme; sanitizer fuzz, zero signatures. Eshkol v1.3.4-evolve. MIT. Linux, macOS and Windows on x64 and arm64, in lite, XLA and CUDA builds. github.com/tsotchke/eshkol/r…