◀ THE FOLD0ROOT.AI // WORLD II · CO-OP · THE PULL REQUEST◆ .dlw.fold
THE FOLD / CO-OP / THE PULL REQUEST / THE SMALLER LANGUAGE

THE SMALLER LANGUAGE

13 forms cover fortran better than python
1 WHAT IT IS · WHAT IT DOES · FACT OR FICTION
A 13-symbol budget was designed by looking at Python. The gate that could stop everything asked whether the same thirteen forms cover FORTRAN. Counted from each language’s own parser — gfortran’s tree over 2,159 routines, Python’s ast over the standard library — the answer is that they cover Fortran better.

LIT verified live. Fortran 92.42% over 1,347,927 nodes against Python 86.63% over 528,774 — on 2.55× more nodes, and using 37 distinct kinds where Python uses 100. The thirteen published shares sum to exactly 92.42%, and the first three — names, literals, assignment — are 72.53% of all Fortran. Re-running his own counter on this machine’s Python 3.11 gives 86.60%, 0.03 points from his 3.12 figure.
2 HOW IT WAS WEAVED · AI + HUMAN
David (human) built the gate so it could stop his own project and said so before running it: “if it does not, the answer is not more forms. it is that fortran is a different shape, and THAT is the product.” He also flagged his own comparison honestly — the baked figure was 83.27%, his recount 86.63% on a different snapshot, “close enough to be the same phenomenon, not close enough to call it the same measurement.”

AVAN (AI) ran his pyforms.py unmodified against a third stdlib — Python 3.11 on this machine, 540,832 nodes, 96 distinct forms — and got 86.60%. That settles what his caution left open: snapshot-to-snapshot drift is 0.03 points, so the 3.4-point gap to the baked 83.27% is not snapshot noise. It is a difference of method, and naming it as such is stronger than leaving it as a caveat.
3 ONE DIMENSION
Thirteen forms, and what they cover.
4 TWO DIMENSIONS · INTERACTIVE
Change the budget and watch both curves.
5 THREE DIMENSIONS + AVAN’S INVERSE
The green forward object: a small alphabet covering a large corpus.
AVAN’s addition (the inverse-companion): the forward reading is “thirteen forms are enough for Fortran.” The inverse is that coverage counts nodes and programs are not made of nodes in equal measure. Half of Fortran is REF_VAR — a name — and names are the cheapest thing in any language to handle. The 7.58% left uncovered contains the constructs that carry the difficulty, and a budget scored by frequency is scored by exactly the wrong weight. Read backwards, 92.42% is a real measurement of how much of the text the forms reach, and says nothing about how much of the work.
LIT fortran comes to 92.42% over 1,347,927 nodes against python's 86.63% over 528,774 - on 2.55 times more nodes and using 37 distinct kinds where python uses 100; the thirteen published shares sum to exactly 92.42%, the first three are 72.53% of all fortran, and re-running his own counter on this machine's python 3.11 gives 86.60%, 0.03 points from his 3.12 figure

FIG From David's F3.ascii, dropped 2026-08-05. He built the gate so it could stop his own project and said so before running it: 'if it does not, the answer is not more forms. it is that fortran is a different shape, and THAT is the product.' He also flagged his own comparison honestly - the baked figure was 83.27%, his recount 86.63% on a different snapshot, 'close enough to be the same phenomenon, not close enough to call it the same measurement.' AVAN ran his pyforms.py unmodified against a THIRD stdlib and got 86.60%, which settles what his caution left open: snapshot drift is 0.03 points, so the 3.4-point gap to the baked figure is NOT snapshot noise. It is a difference of method.
◆ sealed .dlw.fold → folded to ROOT_0 · a sphere of THE PULL REQUEST · David Lee Wise (ROOT0), with AVAN