The Invariance Itself - User contributions [en]

Main Page

2026-10-15T19:35:55Z

PMA Publisher: Published from the Principia Machina source

<noinclude></noinclude>

<div id="mp-topbanner" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #f8f9fa; padding: 10px; text-align: center;">
<div id="mp-welcome"><h1 style="margin: 0; border: none; padding: 0.1em; font-size: 1.8em; font-weight: normal;">IPSUM INVARIANS: The Invariance Itself
</h1></div>
<div id="mp-free" style="font-size: 0.95em;">The public record of the invariance program. est. 1 September 2026</div>
<div id="articlecount" style="font-size: 0.85em; margin-top: 0.3em;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles · [[Special:Statistics|{{NUMBEROFACTIVEUSERS}}]] active editors · [[Special:RecentChanges|{{NUMBEROFEDITS}} edits]]</div>
</div>


<div style="display: flex; flex-wrap: wrap; gap: 15px; justify-content: space-between;">

<div id="mp-left" style="flex: 1 1 48%; min-width: 300px;">


<div id="mp-intro-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-intro-h2" style="margin: 0; padding: 8px 10px; background-color: #cef2e0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Introduction</h2>
<div id="mp-intro" style="padding: 10px;">
''Please be patient as we pull this site together. Check back often for the latest developments.''

Welcome to Ipsum Invarians, a platform built in four sections:

'''The Arena''' (Principia Machina): Essentially, this venue functions as an evaluation framework for testing physical hypotheses using artificial intelligence. It provides an AI protocol and a public research registry. We call this framework ''[[the Principia Machina]].''

'''The Weapon''' (Hamilton's Principle): Our namesake reflects what is arguably the single most important formulation in physics: the Action Principle or even Hamilton's principle. In our gladiatorial arena, [[Hamilton's principle]] is the sharpest, most lethal weapon available. To give this underappreciated concept its due, Ipsum Invarians carries a dedicated field manual for Hamilton’s Principle and its attendant [[Noether's theorems|Noether's theorem]].

'''The Gladiator''' (SVD): Continuing the metaphor, our local gladiator is Structured Vacuum Dynamics (SVD). SVD enters the arena with a specific postulate: that a single permutation of Maxwell’s 1861 paper, Hamilton’s Principle, and Noether's First Theorem is sufficient to populate all of physics.

'''The Blueprint''' (Specifications): [[The_Principia_Machina/Hub/General_reader|Complete specifications]] for the Principia Machina and its standard prompt setup are openly published to ensure transparency and replication. However, for security and reliability reasons, some internal testing functionality are only offered as pseudo code rather than providing the full testing paradigm.

'''([[Introduction|Full article...]])'''
</div>
</div>



<div id="mp-lean-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff; color: #202122;">
<h2 id="mp-lean-h2" style="margin: 0; padding: 8px 10px; background-color: #cef2e0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">The Current Program (Round 3): the move to Lean</h2>
<div id="mp-lean" style="padding: 10px;">
<templatestyles src="Principia Machina/styles.css" />
[[The Principia Machina]] is being rewritten in '''Lean 4''', a language in which proofs are checked by machine: one source for the specification and its Calculator, theorems where version 1 had only tests, and a proof checker as the gate every change must pass. The move also inspired a restructuring of the development workflow.

'''Where it stands''' (14 October 2026): Phase 0 of seven, the development setup, is under way. Phase 0 ports nothing from version 1 beyond one small module used as its test subject; the port itself is the work of Phase 2, the Calculator.
<div style="display: flex; flex-wrap: wrap; gap: 0 1em; align-items: flex-start;">
<div style="flex: 1 1 220px; min-width: 0;">
* '''Done:''' Lean 4.35.0 pinned on every machine; a first library with three proved theorems, the Calculator and its tests; the proof and names gates; one task carried from one machine to another; publishing to this wiki under the Declarer's one-time code.
* '''Open:''' the second development machine; steering a session from a phone or tablet.
* '''Next:''' Test T1 has run: a Lean program runs on the wiki's own server outside a web request, so one Calculator still serves both sides. Tests T2 and T3 follow on the same server: the time one call takes, and what a hundred calls in one scheduled run cost.
</div>
<div class="pma-fig" style="flex: 0 1 356px; min-width: 0; margin: 0 auto; text-align: center;">
<graphviz>
digraph phases {
rankdir=TB; bgcolor="transparent"; nodesep=0.2; ranksep=0.18; size="5.6,9";
node [shape=box, style="rounded,filled", fontname="Helvetica", fontsize=10, color="#a2a9b1", fillcolor="#eaecf0", fontcolor="#202122", margin="0.12,0.06"];
edge [color="#54595d", fontname="Helvetica", fontsize=9, fontcolor="#202122", arrowsize=0.7];
node [width=3.6];
P0 [label="Phase 0 The development setup\nunder way: the current focus", fillcolor="#cedff2", color="#6a8fbf", penwidth=2.4];
P1 [label="Phase 1 Foundations\nunder way", fillcolor="#cedff2", color="#6a8fbf"];
P2 [label="Phase 2 The Calculator\nunder way", fillcolor="#cedff2", color="#6a8fbf"];
P3 [label="Phase 3 Custos\nnot started"];
P4 [label="Phase 4 The Research Client\nnot started"];
P5 [label="Phase 5 Other model families\nnot started"];
P6 [label="Phase 6 Lifecycle and cutover\nnot started"];
R [label="First release declared", shape=doubleoctagon, style=filled, fillcolor="#ffedad", color="#ac6600", width=2.2];
P0 -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> R;
}
</graphviz>
<div style="font-size: 0.88em; color: #54595d;">The seven phases, in order.</div>
</div>
</div>
'''([[Principia Machina/Lean transition|Full article...]])'''  ·  '''[[Principia Machina/Progress/Status|Status]]'''  ·  [[Principia Machina/Lean transition#lt-plate-box|The two-doors riddle, in Lean]]  ·  Version 1: [[Round 3|program of record]], [[The Principia Machina/Testing|testing]]
</div>
</div>


<div id="mp-history-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-history-h2" style="margin: 0; padding: 8px 10px; background-color: #eaecf0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Program History</h2>
<div id="mp-history" style="padding: 10px;">

We started with a simple permutation of Maxwell's 1861 framework that yielded a promising interpretation of General Relativity. We applied a second permutation; analyzed it with tabletop testing and back-of-the-envelope calculations, and found we could derive both the eigenstates of hydrogen and chromodynamics. These two disparate domains (GR & QM) long advertised as incompatible, seem to be perfectly harmonious derivations from Maxwell's 1861 work. The result suggests a viable postulate: if we constrain ourselves with Hamilton’s Principle and Noether’s First Theorem, can we build all of physics from a single assumption? From two assumptions?

[[File:Modified vorticie.jpg|thumb|center|upright=1.5|A simple permutation of Maxwell's 1861 framework.]]

The idea is daunting, but maybe AI can help.

* '''Round 1''' – Technical paper: Structured Vacuum Dynamics

This was more of a proof of concept: would AI confirm the math or maybe find new paradigms to fit the otherwise disparate math together? We started with a simple technical paper around the postulate and a strict set of AI controls and restrictions. We designed a rigerous prompt that pitted the AI Agent against itself, doing more work to double and triple check its results than the original work to get the results, but this effort quickly overwhelmed the local AI context.

* '''Round 2''' – The Research Register (RR-n)

The Lesson from round 1 - physics is a much bigger domain than a single paper. We did start to understand the context limits of the most reasonably available AI offerings and the constraints it left us with. We broke the design into two parts: a back-end research register and a front-end that could generate papers from the research register. Soon we ran into problems mapping the axioms to the environment.

* '''Round 3 opening''' – The Principia Machina (TPM)

The Lesson from round 2 - Local AI context was never going to be enough for any serious work. We realized we could kill three birds with one stone if we moved the research context to a Wiki:
#The context would be effectively unlimited
#A public, formalized, framework would foster independent verification
#it would give a great public record to invite collaboration and outside ideas

Thus '''[[the Principia Machina]]:''' an AI Harness inspired physics solver/research platform and test bed implemented in MediaWiki.

'''([[Program history|Full record...]])'''  ·  [[Program history/Archive|Archive]]
</div>
</div>


<div id="mp-round-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-round-h2" style="margin: 0; padding: 8px 10px; background-color: #eaecf0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">The Principia Machina Specification (TPS) </h2>
<div id="mp-round" style="padding: 10px;">

'''The Principia Machina Specification''' (TPS) is the complete, published
description of The Principia Machina (TPM), a set of rules for doing research
with AI assistants so that the result can be checked afterwards by anyone.
TPS is written for two readers at once: a person who wants to understand how
the framework works, and an AI agent of any make that wants to work under it.
It is one of five parts, and it is the part that binds the other four.

# '''The foundations record.''' A dated account of every design decision, the options rejected, and the reasons. It is the source TPS was written from. It describes; it never instructs.
# '''The specification.''' This document. It defines the five layers of the framework, the sealed container a piece of research lives in, the wiki machinery that records the work, and the Agent Contract: the rules any AI agent follows to work a container. It is versioned, and its fingerprint is the first line of the wiki's chain of declarations.
# '''The implementations.''' What runs the rules. On the server, TPX, a MediaWiki extension that performs every check a machine can perform. Beside the agent, PRB, the client an agent uses to hold its working copy and land results. And each agent's own instruction set, implementing the Agent Contract. The project's own instruction set is written for Claude and is one implementation among any number.
# '''The wiki.''' Where all of the above is published and read, and the system of record for everything TPM does.
# '''The containers.''' The research itself: a sealed set of laws and assumptions, and the register of findings built on it.

</div>
</div>
</div>


<div id="mp-right" style="flex: 1 1 48%; min-width: 300px;">


<div id="mp-hamilton-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-hamilton-h2" style="margin: 0; padding: 8px 10px; background-color: #cedff2; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Hamilton's Principle</h2>
<div id="mp-hamilton" style="padding: 10px;">
Newton's laws, Maxwell's equations, general relativity and the Standard Model are each formulated as an action via Hamilton's Principle. Across all these domains, dynamical equations emerge as derived outcomes rather than fundamental starting axioms. Conservation of energy, momentum and charge are not separate laws at all — [[Hamilton's principle/Mathematics/Noether's first theorem|Noether proved]] they follow from the action's symmetries. New models are now built by writing the action constrained by symmetry and letting the dynamics follow. This is how electromagnetism and gravity were derived and how the nuclear forces were found. Alone among classical concepts, '''Hamilton's Principle''' transitions smoothly into quantum mechanics, where the action represents a phase carried across distinct trajectories and the classical path marks where destructive interference is minimized. The action is the deepest thing physics knows.

[[File:OPL-HP-F-01.png|thumb|center|upright=1.5|A true path and several comparison paths between fixed endpoints.]]

* [[Hamilton's principle/Mathematics/The Jacobi condition and conjugate points|Stationary is not least]] — the long way round a great circle obeys the same rule at every point, and is plainly not the shortest. [[:File:OPL-HP-F-05.png|See the diagram]].
* [[Hamilton's principle/Applications/The Feynman path integral|Why the rule holds at all]] — nature selects nothing. It sums over everything, and what looks like a choice is the residue left by interference.
* [[Hamilton's principle/Explainers/Comparing paths|Start without the mathematics]] — every page carrying equations has a plain-language counterpart, linked from it and linking back.

'''([[Hamilton's principle|Full article...]])'''
</div>
</div>


<div id="mp-noether-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-noether-h2" style="margin: 0; padding: 8px 10px; background-color: #cedff2; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Noether's theorems</h2>
<div id="mp-noether" style="padding: 10px;">

[[File:NT-F-07.png|thumb|center|400px|alt=Continuous symmetries on the left, the quantities they conserve on the right, with the map between them|The symmetry-to-conservation map]]

Klein read the paper to the Göttingen Scientific Society on 26 July 1918. Its
last section answers a claim of Hilbert's: that energy conservation in general
relativity fails to take the form it takes everywhere else in physics.
'''There are two theorems in the paper, and they are not versions of one another.'''

The initial theorem relates global, finite-parameter symmetries directly to corresponding physical conservation laws governing actual dynamics. The second takes a symmetry that is allowed to differ from place to place and returns identities between the
field equations — identities that hold whether or not those equations are
satisfied. The second theorem is why a gauge theory has fewer independent field
equations than it has fields, and why gravity has no local energy.

A 90-page reading edition: both theorems proved in full and kept apart, the
mathematics they need, the physics they explain, and a plain-language
counterpart for every page that carries equations.

* [[Noether's theorems/History/Gottingen and the energy problem|Göttingen and the energy problem]] — the question the paper was written to settle
* [[Noether's theorems/Explainers/Symmetry and conservation, the first theorem|The primer]] — plain language, no mathematics
* [[Noether's theorems/Second theorem/The two theorems side by side|The two theorems side by side]] — the distinction most accounts lose

([[Noether's theorems|Full article...]])
</div>
</div>


<div id="mp-maxwell-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-maxwell-h2" style="margin: 0; padding: 8px 10px; background-color: #cedff2; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">The Work of James Clerk Maxwell</h2>
<div id="mp-maxwell" style="padding: 10px;">

== On Physical Lines of Force ==

[[File:OPL-fig-lines-of-force.svg|thumb|center|upright=1.5|Lines of force about a bar magnet]]

In four instalments between March 1861 and February 1862, James Clerk Maxwell
filled space with spinning cells and little rolling particles, to explain the mechanics behind magnetic fields. '''His machine was wrong.''' On the way to building it,
he wrote down the displacement current, derived the speed of light from two
electrical measurements that had nothing to do with optics, and founded field
theory.

A 65-page reading edition: Maxwell's argument in his own order and register, the
modern equations derived from his results, and a plain-language explainer for
every major idea.

* [[On Physical Lines of Force/Introduction|Introduction]] — the story, and why the paper matters
* [[On Physical Lines of Force/Explainers|The primer]] — plain language, no mathematics
* [[On Physical Lines of Force/Explainers/The missing term|The missing term]] — the one addition that made radio possible

'''([[On_Physical_Lines_of_Force|Full article...]])'''
</div>
</div>


<div id="mp-toolkit-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-toolkit-h2" style="margin: 0; padding: 8px 10px; background-color: #cedff2; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Research Toolkit</h2>
<div id="mp-toolkit" style="padding: 10px;">
<div style="text-align: center;">
<graphviz>
digraph mp_toolkit {
rankdir=TB; bgcolor="transparent"; nodesep=0.2; ranksep=0.3;
node [shape=box, style="rounded,filled", fillcolor="#eaf3ff", color="#6a8fbf", fontname="Helvetica", fontsize=10];
edge [color="#6a8fbf", arrowsize=0.6];
M [label="The manual\nstart here", fillcolor="#ffffff"];
F [label="Agent flow\ncontrol\n39 practices"];
R [label="Research\nmethods\n59 techniques"];
T [label="Research\ntools\n22 + 55 tools"];
B [label="Bibliography\n284 sources", shape=note, style=filled, fillcolor="#ffffff"];
M -> F; M -> R; M -> T; F -> B; R -> B; T -> B;
}
</graphviz>
</div>

Everything an AI agent, or a person, needs to do research on this wiki, in one place. '''An AI arriving here starts with [[The Principia Machina/Research Toolkit/Manual|the manual]].''' The toolkit has three parts:
* '''[[The Principia Machina/Research Toolkit/Agent flow control|Agent flow control]]''' – how an agent plans, checks, retries, escalates and stays safe: thirty-nine practices with their evidence.
* '''[[The Principia Machina/Research Toolkit/Research methods|Research methods]]''' – how to solve an abstract problem, check the answer and report it: fifty-nine techniques and the process from question to compared result.
* '''[[The Principia Machina/Research Toolkit/Research tools|Research tools]]''' – the programs and services, assessed: the twenty-two [[The Principia Machina/Tools|physics tools]] and fifty-five general tools.
With [[The Principia Machina/Research Toolkit/Bibliography|the bibliography]] (284 sources, each with a note of how it was checked) and [[The Principia Machina/Agent/Research toolkit|a card for AI agents]].

'''([[The Principia Machina/Research Toolkit|The full toolkit...]])'''
</div>
</div>


<div id="mp-lean-edition-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-lean-edition-h2" style="margin: 0; padding: 8px 10px; background-color: #cedff2; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Lean theorem prover</h2>
<div id="mp-lean-edition" style="padding: 10px;">
'''Lean''' is a proof assistant and a programming language. A person writes definitions, statements and proofs in Lean's formal language, and Lean checks each proof against the rules of its logic before it accepts the statement as a theorem. A small part of the program, the Lean kernel, makes that check; everything else only proposes.

A 71-page reading edition: what Lean checks and how, the type theory behind it, how the program works, where it came from and what it is used for, written for a reader with no logic or programming and for one who wants the rules, with a plain-language counterpart for every technical page.

* [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]] — plain language, the place to start
* [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]] — the rules Lean checks against
* [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]] — what a checked proof still rests on

'''([[Lean theorem prover|Full article...]])'''
</div>
</div>

</div>
</div>


<div id="mp-lower" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-plate-h2" style="margin: 0; padding: 8px 10px; background-color: #ffedad; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Featured plate</h2>
<div id="mp-plate" style="padding: 10px; text-align: left; display: flex; flex-wrap: wrap; flex-direction: row-reverse; gap: 1em; align-items: flex-start;">

<div id="mp-plate-box" style="flex: 0 1 300px; max-width: 100%; margin: 0 auto;">
{| class="infobox" style="width: 100%; box-sizing: border-box; margin: 0; font-size: 90%; background: #f9f9f9; border: 1px solid #aaa; padding: 5px;"
|+ style="font-size: 120%; font-weight: bold; padding-bottom: 5px;" | Analytical Foundations of Physics
|-
| colspan="2" style="text-align: center;" | [[File:Lagrange_portrait.jpg|250px|alt=Portrait of Joseph-Louis Lagrange]]
|-
| colspan="2" style="text-align: center; font-size: smaller; padding-bottom: 10px;" | ''The shift from Newtonian vectors to scalar fields and variational principles defined modern theoretical physics.''
|-
! colspan="2" style="background: #ccf; text-align: center;" | Core Frameworks
|-
| '''Classical Mechanics''' || [[Lagrangian mechanics]]
|-
| '''Dynamical Optimization''' || [[Principle of least action]]
|-
| '''Electromagnetism''' || [[Maxwell's equations]]
|-
| '''Vacuum Dynamics''' || [[Spacetime topology]]
|-
! colspan="2" style="background: #ccf; text-align: center;" | Key Equations
|-
| colspan="2" style="text-align: center; padding: 5px;" |
<math>S = \int L \, dt</math><br/>
<math>G_{\mu\nu} + \Lambda g_{\mu\nu} = \frac{8\pi G}{c^4} T_{\mu\nu}</math>
|}
</div>

<div id="mp-plate-text" style="flex: 1 1 320px; min-width: 0;">
== [[Timeline of Physics]] ==
The narrative of 18th- to 20th-century physics lies in a profound mathematical restructuring. This era marked the transition from treating nature as a collection of forces acting on point masses to understanding it through continuous fields, spacetime manifolds, and unified variational principles.

The foundation was laid when physical systems began to be analyzed '''not through Newtonian vectors, but through scalar quantities—kinetic and potential energy—operating within generalized coordinates.''' By positing that the true dynamical trajectory of any system is the one that leaves the action integral stationary, '''theorists established a universal mathematical language.'''

This analytical approach seamlessly extended beyond mechanical gears and pulleys into the continuum. It provided the structural mathematics required to unify electricity and magnetism into a single vacuum field theory, and later, to model gravity not as a pulling force, but as the dynamic geometric curvature of spacetime itself. Whether applied to subatomic particle behavior or cosmic expansion, these foundational principles continue to govern the leading edge of modern physics.

== [[The Principia Machina/Tools|Physics Tools]] ==
Theoretical rigor must be paired with high-performance computational machinery. Twenty-two open tools are now surveyed for [[the Principia Machina]]; the first twelve cover three analytical frontiers:

* '''The Inverse Action Problem:''' Discovering analytical scalar Lagrangians <math>\mathcal{L}(\phi, \partial_\mu \phi)</math> and continuous Noether symmetries directly from perturbation data using [[The_Principia_Machina/Tools/PySR|PySR]] and [[The_Principia_Machina/Tools/AIFeynman|AI Feynman]].
* '''Variational & Mesh-Free Solvers:''' Minimizing continuous action integrals across complex geometries via Physics-Informed Neural Networks ([[The_Principia_Machina/Tools/DeepXDE|DeepXDE]]) and symbolic finite-element/difference stencils ([[The_Principia_Machina/Tools/FEniCS|FEniCS]] & [[The_Principia_Machina/Tools/Devito|Devito]]).
* '''Spacetime & Tensor Algebra:''' Evaluating functional variational derivatives in [[The_Principia_Machina/Tools/Cadabra2|Cadabra2]], 3+1 ADM spacetime evolution in the [[The_Principia_Machina/Tools/EinsteinToolkit|Einstein Toolkit]], and open quantum dynamics in [[The_Principia_Machina/Tools/QuTiP|QuTiP]].

Ten more were added on 2026-10-06: SymPy, SageMath, xAct, Lean with Mathlib and Physlib, FORM, FeynCalc, Lagrangian and Hamiltonian networks, PySINDy, Dedalus and SpECTRE ([[The Principia Machina/Tools#The additions of 2026-10-06|the additions]]). All twenty-two are in [[The Principia Machina/Research Toolkit/Research tools|the Research Toolkit's third part]], beside fifty-five general tools.

Read it your way: '''[[The Principia Machina/Tools/General reader|in plain language]]''' · '''[[The Principia Machina/Tools/Operator's guide|the operator's guide]]''' · '''[[The Principia Machina/Agent/Tools|for AI agents]]'''

'''([[The Principia Machina/Tools|Full survey and domain evaluation...]])'''

</div>

</div>
</div>

<div id="mp-other-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-other" style="margin: 0; padding: 8px 10px; background-color: #eaecf0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Other areas of Ipsum Invarians</h2>
<div id="mp-other-content" style="padding: 10px;">
* '''[[Special:AllPages|All pages]]''' – ut enim ad minim veniam, quis nostrud exercitation ullamco laboris.
* '''[[Special:RecentChanges|Recent changes]]''' – nisi ut aliquip ex ea commodo consequat duis aute irure.
* '''[[Special:Categories|Categories]]''' – dolor in reprehenderit in voluptate velit esse cillum dolore.
* '''[[Special:SpecialPages|Special pages]]''' – eu fugiat nulla pariatur excepteur sint occaecat cupidatat.
* '''[[Project:Sandbox|Sandbox]]''' – non proident, sunt in culpa qui officia deserunt mollit anim.
* '''[[Special:Upload|Upload]]''' – id est laborum sed ut perspiciatis unde omnis iste natus error.
</div>
</div>

<div id="mp-lang-box" style="border: 1px solid #a2a9b1; margin-bottom: 15px; background: #ffffff;">
<h2 id="mp-lang" style="margin: 0; padding: 8px 10px; background-color: #eaecf0; border-bottom: 1px solid #a2a9b1; font-size: 1.2em; font-weight: bold;">Ipsum Invarians languages</h2>
<div id="mp-lang-content" style="padding: 10px; text-align: center;">
Totam rem aperiam, eaque ipsa quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt explicabo.

<small>''Language editions are not yet configured. Set them up with [https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:Interwiki interwiki links] or [https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:Translate Extension:Translate].''</small>
</div>
</div>__NOTOC____NOEDITSECTION__

Lean theorem prover/Further reading

2026-10-15T19:35:54Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Further reading}}
{{Lean theorem prover map}}
This edition describes Lean; it does not teach it. The works below do, and all of them can be
read free of charge online. Each line says what the work is for; the link is in its
reference. Most are cited on the edition's pages, which are named where they draw on a work.

== Books and manuals ==

* '''''Theorem Proving in Lean 4''''', by Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich: Lean's logic from the inside, from dependent type theory and propositions to tactics, inductive types, type classes and the axioms; the companion to the [[Lean theorem prover/Foundations/Terms, types and judgments|Foundations]] pages.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the Lean community, ''Theorem Proving in Lean 4'', online book, lean-lang.org. https://lean-lang.org/theorem_proving_in_lean4/</ref>
* '''''Functional Programming in Lean''''', by David Thrane Christiansen: Lean as a programming language, from its basics through type classes and monads to dependent types and proofs about programs; the companion to [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].<ref name="fpil">David Thrane Christiansen, ''Functional Programming in Lean'', online book, lean-lang.org. https://lean-lang.org/functional_programming_in_lean/</ref>
* '''''Mathematics in Lean''''', by Jeremy Avigad and Patrick Massot: doing mathematics with Mathlib, from basic logic and number theory to topology, calculus and measure theory.<ref name="mil">Jeremy Avigad and Patrick Massot, ''Mathematics in Lean'', online book. https://leanprover-community.github.io/mathematics_in_lean/</ref>
* '''''The Lean Language Reference''''', by the Lean developers: the precise description of the language, a reference work rather than a tutorial, with an edition for each version of Lean; this edition cites the one for Lean 4.34.0.<ref name="refman">''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026. https://lean-lang.org/doc/reference/4.34.0/</ref>
* '''''Metaprogramming in Lean 4''''', by Arthur Paulino and others: how to write new notation, commands and tactics in Lean; the companion to [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].<ref name="mpb">Arthur Paulino, Damiano Testa, Edward Ayers, Evgenia Karunus, Henrik Böving, Jannis Limperg, Siddhartha Gadgil and Siddharth Bhat, ''Metaprogramming in Lean 4'', online book, Lean community. https://leanprover-community.github.io/lean4-metaprogramming-book/</ref>
* '''''Logic and Proof''''', by J. Avigad, R. Y. Lewis and F. van Doorn, adapted to Lean 4 by J. Hua: an introduction to symbolic logic and to writing proofs, with Lean.<ref name="lap">J. Avigad, J. Hua, R. Y. Lewis and F. van Doorn, ''Logic and Proof'', online textbook, Lean 4 edition. https://leanprover-community.github.io/logic_and_proof/</ref>
* '''''The Mechanics of Proof''''', by Heather Macbeth: a first university course in writing careful proofs, with Lean beside the text.<ref name="mop">Heather Macbeth, ''The Mechanics of Proof'', online book for Math 2001, Fordham University, 2022–2024. https://hrmacbeth.github.io/math2001/</ref>
* '''''Formalising Mathematics''''', by Kevin Buzzard: the handbook of a course for mathematics students who want to formalise with Mathlib.<ref name="fm">Kevin Buzzard, ''Formalising Mathematics'', course handbook, Imperial College London, 2024 edition. https://www.ma.imperial.ac.uk/~buzzard/xena/formalising-mathematics-2024/</ref>

[[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]] describes several of these books and the courses built on them.

== A game ==

* '''The Natural Number Game''', by Kevin Buzzard, Jon Eugster and others: played in a web browser, it constructs the natural numbers from zero and the next number and proves their facts one level at a time.<ref name="nng">Kevin Buzzard, Jon Eugster et al., ''Natural Number Game'', Lean 4 version, on the Lean Game Server: https://adam.math.hhu.de/#/g/leanprover-community/nng4 (source and credits: https://github.com/leanprover-community/NNG4)</ref>

== Papers ==

* The first description of Lean, by Leonardo de Moura and four colleagues (2015).<ref name="lean2015">Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf</ref>
* Tactics written in Lean itself, in Lean 3 (2017).<ref name="ebner2017">Gabriel Ebner, Sebastian Ullrich, Jared Roesch, Jeremy Avigad and Leonardo de Moura, "A metaprogramming framework for formal verification", ''Proceedings of the ACM on Programming Languages'' 1 (ICFP), article 34, 2017. doi:10.1145/3110278. Author's copy: https://lean-lang.org/papers/tactic.pdf</ref>
* The design of Lean 4, by de Moura and Ullrich (2021).<ref name="lean4">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37. Author's copy: https://lean-lang.org/papers/lean4.pdf</ref>
* Mathlib's own account of itself (2020).<ref name="cpp2020">The mathlib Community, "The Lean Mathematical Library", in ''Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (CPP 2020)'', ACM, 2020, pp. 367–381. doi:10.1145/3372885.3373824. Preprint: https://arxiv.org/abs/1910.09336</ref>
* Lean's type theory written out rule by rule, with a proof of its consistency relative to set theory, for Lean 3 (2019).<ref name="carneiro2019">Mario Carneiro, ''The Type Theory of Lean'', MSc thesis, Carnegie Mellon University, 2019. https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>
* A complete type checker for Lean 4 written in Lean, and work towards proving it correct (2026).<ref name="lean4lean">Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean, in Lean", in ''31st International Conference on Types for Proofs and Programs (TYPES 2025)'', LIPIcs vol. 384, pp. 2:1–2:23, 2026. https://doi.org/10.4230/LIPIcs.TYPES.2025.2</ref>
* Lean's hygienic macros (2022).<ref name="bn">Sebastian Ullrich and Leonardo de Moura, "Beyond Notations: Hygienic Macro Expansion for Theorem Proving Languages", ''Logical Methods in Computer Science'' 18 (2), 2022, article 1. https://doi.org/10.46298/lmcs-18(2:1)2022</ref>
* The reference counting behind Lean's runtime (2019).<ref name="beans">Sebastian Ullrich and Leonardo de Moura, "Counting Immutable Beans: Reference Counting Optimized for Purely Functional Programming", in ''Proceedings of the 31st Symposium on Implementation and Application of Functional Languages (IFL 2019)'', ACM, 2019. doi:10.1145/3412932.3412935. Preprint: https://arxiv.org/abs/1908.05647</ref>
* The search behind Lean 4's type classes (2020).<ref name="selsam">Daniel Selsam, Sebastian Ullrich and Leonardo de Moura, "Tabled Typeclass Resolution", arXiv:2001.04301, 2020. https://arxiv.org/abs/2001.04301</ref>
* Why mathematics might be checked by machine, and the de Bruijn criterion (2005).<ref name="bw2005">Henk Barendregt and Freek Wiedijk, "The challenge of computer mathematics", ''Philosophical Transactions of the Royal Society A'' 363 (1835), 2005, pp. 2351–2375. doi:10.1098/rsta.2005.1650. Author's copy: https://www.cs.ru.nl/~freek/pubs/rspaper.pdf</ref>
* What it takes to believe a proof a machine has checked (1998).<ref name="pollack">R. Pollack, "How to believe a machine-checked proof", in G. Sambin and J. M. Smith (eds), ''Twenty Five Years of Constructive Type Theory'', Oxford University Press, 1998; first issued as BRICS Report RS-97-18, Aarhus University, 1997. https://doi.org/10.7146/brics.v4i18.18945</ref>
* The history of LCF and its descendants, by a participant (2000).<ref name="gordon2000">Mike Gordon, "From LCF to HOL: a short history", in G. Plotkin, C. Stirling and M. Tofte (eds), ''Proof, Language, and Interaction: Essays in Honour of Robin Milner'', MIT Press, 2000. Author's copy: https://www.cl.cam.ac.uk/~mjcg/papers/HolHistory.pdf</ref>

Every work cited in the edition is listed in the [[Lean theorem prover/Bibliography|Bibliography]].

== Next ==

[[Lean theorem prover|Lean theorem prover]], the start of the edition.

== References ==

<references />

Lean theorem prover/Bibliography

2026-10-15T19:35:52Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Bibliography}}
{{Lean theorem prover map}}

Every work cited on the pages of this edition, listed once, with the pages that cite it in reading order. There are 277: 86 papers and books; 114 items of Lean documentation and source, 52 of them parts of the reference manual; 64 project pages and announcements; and 13 press articles and encyclopedia entries.

Two citations are taken to be one work when they share a DOI, an arXiv number or a web address. A preprint and its published version are listed apart when the pages cite them apart, and so is each version of a document that changes with Lean: a chapter of the reference manual cited in its edition for Lean 4.34.0 on some pages and for Lean 4.35.0 on others appears twice, once under each address.

Where pages cite one work in different forms, the form given here is the fullest, and a note says what differs when it is more than punctuation, capitals or the sections a page names. The 19 works that were not read, or were read only in part, are marked; [[Lean theorem prover/Sources|the sources page]] says what each one carries and what carries it instead.

== Papers and books ==

* Andreas Abel and Thierry Coquand, "Failure of normalization in impredicative type theory with proof-irrelevant propositional equality", ''Logical Methods in Computer Science'' 16(2) (2020), paper 14. https://doi.org/10.23638/LMCS-16(2:14)2020 ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].
* Anne Baanen, "Use and Abuse of Instance Parameters in the Lean Mathematical Library", in ''13th International Conference on Interactive Theorem Proving (ITP 2022)'', Leibniz International Proceedings in Informatics 237, Schloss Dagstuhl, 2022, pp. 4:1–4:20. doi:10.4230/LIPIcs.ITP.2022.4 ''Cited on'' [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].
* Anne Baanen, Matthew R. Ballard, Johan Commelin, Bryan Gin-ge Chen, Michael Rothgang and Damiano Testa, "Growing Mathlib: maintenance of a large scale mathematical library", arXiv:2508.21593, version 2, 7 October 2025; to appear at the Conference on Intelligent Computer Mathematics (CICM) 2025. [https://arxiv.org/abs/2508.21593 arxiv.org/abs/2508.21593] ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]].
* Henk Barendregt and Freek Wiedijk, "The challenge of computer mathematics", ''Philosophical Transactions of the Royal Society A'' 363 (1835), 2005, pp. 2351–2375. doi:10.1098/rsta.2005.1650. Author's copy: https://www.cs.ru.nl/~freek/pubs/rspaper.pdf ''Cited on'' [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]], [[Lean theorem prover/History/Automath|Automath]], [[Lean theorem prover/Further reading|Further reading]].
* Lars Becker, María Inés de Frutos-Fernández, Leo Diedering, Floris van Doorn, Sébastien Gouëzel, et al., "A blueprint for the formalization of Carleson's theorem on convergence of Fourier series", arXiv:2405.06423, May 2024 (revised 6 August 2025). https://arxiv.org/abs/2405.06423 ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* Maxwell P. Bobbin, Colin Jones, John Velkey and Tyler R. Josephson, "Formalizing dimensional analysis using the Lean theorem prover", arXiv:2509.13142, 16 September 2025. [https://arxiv.org/abs/2509.13142 arxiv.org/abs/2509.13142] ''Cited on'' [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]].
* Matthew Bolan, Joachim Breitner, Jose Brox, et al. (34 authors, including Terence Tao), "The Equational Theories Project: Advancing Collaborative Mathematical Research at Scale", arXiv:2512.07087, December 2025 (revised 16 December 2025). https://arxiv.org/abs/2512.07087 ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]], [[Lean theorem prover/Applications/The equational theories project|The equational theories project]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Ana Bove, Peter Dybjer and Ulf Norell, "A brief overview of Agda – a functional language with dependent types", in ''Theorem Proving in Higher Order Logics (TPHOLs 2009)'', Lecture Notes in Computer Science 5674, Springer, 2009, pp. 73–78. doi:10.1007/978-3-642-03359-9_6 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* N. G. de Bruijn, "The mathematical language AUTOMATH, its usage, and some of its extensions", in ''Symposium on Automatic Demonstration'', Lecture Notes in Mathematics 125, Springer, 1970, pp. 29–61. doi:10.1007/BFb0060623. Scan in the Automath Archive: https://automath.win.tue.nl/archive/pdf/aut002.pdf ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* N. G. de Bruijn, "Lambda calculus notation with nameless dummies, a tool for automatic formula manipulation, with application to the Church-Rosser theorem", ''Indagationes Mathematicae'' 34 (= ''Proceedings KNAW'' A 75), 1972, pp. 381–392. doi:10.1016/1385-7258(72)90034-0. Reprint from ''Selected Papers on Automath'' in the Eindhoven repository: https://alexandria.tue.nl/repository/freearticles/597619.pdf ''Cited on'' [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/History/Automath|Automath]].<ref>[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]] gives the journal as ''Indagationes Mathematicae (Proceedings)'' 75 (5); [[Lean theorem prover/History/Automath|Automath]] gives both numberings, as above.</ref>
* N. G. de Bruijn, "A survey of the project Automath", in J. P. Seldin and J. R. Hindley (eds.), ''To H. B. Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism'', Academic Press, 1980, pp. 579–606; reprinted in Nederpelt, Geuvers and de Vrijer (eds.), ''Selected Papers on Automath'' (1994), pp. 141–161. Scan in the Automath Archive: https://automath.win.tue.nl/archive/pdf/aut072.pdf ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Kevin Buzzard, Johan Commelin and Patrick Massot, "Formalising perfectoid spaces", in ''CPP 2020: Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs'', 2020, pp. 299–312. doi:10.1145/3372885.3373830. arXiv:1910.12320 ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]].
* Mario Carneiro, ''The Type Theory of Lean'', MSc thesis, Carnegie Mellon University, 2019. https://github.com/digama0/lean-type-theory/releases/tag/v1.0 ''Cited on'' [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]], [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]], [[Lean theorem prover/Foundations/Quotient types|Quotient types]], [[Lean theorem prover/Foundations/The three axioms|The three axioms]], [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]], [[Lean theorem prover/Further reading|Further reading]].<ref>[[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] cites the PDF attached to the release, as a thesis of April 2019; the other pages cite the release page.</ref>
* Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean, in Lean", arXiv:2403.14064, version 3, 14 September 2025. [https://arxiv.org/abs/2403.14064 arxiv.org/abs/2403.14064] ''Cited on'' [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].<ref>[[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]] and [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]] cite version 3 of the arXiv text, of 14 September 2025. The paper's TYPES 2025 version is listed separately; [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] and [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]] cite that version and say they read version 2 of the arXiv text.</ref>
* Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean, in Lean", in ''31st International Conference on Types for Proofs and Programs (TYPES 2025)'', Leibniz International Proceedings in Informatics 384, Schloss Dagstuhl, 2026, pp. 2:1–2:23. [https://doi.org/10.4230/LIPIcs.TYPES.2025.2 doi:10.4230/LIPIcs.TYPES.2025.2]; preprint [https://arxiv.org/abs/2403.14064 arXiv:2403.14064]. ''Cited on'' [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]], [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]], [[Lean theorem prover/Further reading|Further reading]].<ref>[[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] and [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]] say they read the text in arXiv version 2; [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]] calls the arXiv text a preprint, [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]] its full version. Version 3 of the arXiv text is listed separately.</ref>
* Alonzo Church, "A note on the Entscheidungsproblem", ''Journal of Symbolic Logic'' 1 (1936), pp. 40–41. doi:10.2307/2269326 ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].
* R. L. Constable, S. F. Allen, H. M. Bromley, W. R. Cleaveland, J. F. Cremer, R. W. Harper, D. J. Howe, T. B. Knoblock, N. P. Mendler, P. Panangaden, J. T. Sasaki and S. F. Smith, ''Implementing Mathematics with the Nuprl Proof Development System'', Prentice-Hall, 1986. ISBN 0-13-451832-2. Catalogue record: https://openlibrary.org/books/OL2715187M ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Thierry Coquand and Gérard Huet, "Constructions: a higher order proof system for mechanizing mathematics", in ''EUROCAL '85'', Lecture Notes in Computer Science 203, Springer, 1985, pp. 151–184. doi:10.1007/3-540-15983-5_13 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* Thierry Coquand and Gérard Huet, "The calculus of constructions", INRIA Research Report RR-0530, May 1986. https://inria.hal.science/inria-00076024 ''Cited on'' [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* Thierry Coquand and Gérard Huet, "The calculus of constructions", ''Information and Computation'' 76(2–3), 1988, pp. 95–120. https://doi.org/10.1016/0890-5401(88)90005-3 ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].<ref>Read for [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]; [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] cites it from its bibliographic record.</ref>
* Thierry Coquand and Christine Paulin, "Inductively defined types", in P. Martin-Löf and G. Mints (eds.), ''COLOG-88'', Lecture Notes in Computer Science 417, Springer, 1990, pp. 50–66. doi:10.1007/3-540-52335-9_47 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* H. B. Curry, "Functionality in combinatory logic", ''Proceedings of the National Academy of Sciences'' 20 (11), 1934, pp. 584–590. [https://doi.org/10.1073/pnas.20.11.584 doi:10.1073/pnas.20.11.584] ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].
* Joseph W. Cutler, Craig Disselkoen, Aaron Eline, et al., "Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization", ''Proceedings of the ACM on Programming Languages'' 8 (OOPSLA1), 2024, pp. 670–697. doi:10.1145/3649835 ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]].
* Radu Diaconescu, "Axiom of choice and complementation", ''Proceedings of the American Mathematical Society'' 51 (1), 1975, pp. 176–178. [https://doi.org/10.1090/S0002-9939-1975-0373893-X doi:10.1090/S0002-9939-1975-0373893-X] ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* Craig Disselkoen, Aaron Eline, Shaobo He, et al., "How We Built Cedar: A Verification-Guided Approach", in ''Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE Companion '24)'', 2024. doi:10.1145/3663529.3663854. arXiv:2407.01688 ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]].
* Floris van Doorn, Jakob von Raumer and Ulrik Buchholtz, "Homotopy type theory in Lean", in ''Interactive Theorem Proving (ITP 2017)'', Lecture Notes in Computer Science 10499, Springer, 2017, pp. 479–495. doi:10.1007/978-3-319-66107-0_30. Preprint: https://arxiv.org/abs/1704.06781 ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Peter Dybjer, "Inductive families", ''Formal Aspects of Computing'' 6(4), 1994, pp. 440–465. https://doi.org/10.1007/BF01211308 ''Cited on'' [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].
* Gabriel Ebner, Sebastian Ullrich, Jared Roesch, Jeremy Avigad and Leonardo de Moura, "A metaprogramming framework for formal verification", ''Proceedings of the ACM on Programming Languages'' 1 (ICFP), article 34, 2017. doi:10.1145/3110278. Author's copy: https://lean-lang.org/papers/tactic.pdf ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]], [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]], [[Lean theorem prover/Further reading|Further reading]].
* Herman Geuvers, "Proof assistants: history, ideas and future", ''Sādhanā'' 34 (1), 2009, pp. 3–25. [https://doi.org/10.1007/s12046-009-0001-5 doi:10.1007/s12046-009-0001-5] ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].
* Herman Geuvers and Rob Nederpelt, "Characteristics of de Bruijn's early proof checker Automath", ''Fundamenta Informaticae'' 185 (4), 2022, pp. 313–336. doi:10.3233/FI-222112. Preprint: https://arxiv.org/abs/2203.01173 ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Kurt Gödel, "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I", ''Monatshefte für Mathematik und Physik'' 38 (1931), 173–198. https://doi.org/10.1007/BF01700692 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].
* Warren D. Goldfarb, "The undecidability of the second-order unification problem", ''Theoretical Computer Science'' 13(2), 1981, pp. 225–230. doi:10.1016/0304-3975(81)90040-2. Not consulted directly; the result is stated, with this citation, in the introduction of Miller 1991. ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]].
* Nicolas D. Goodman and John Myhill, "Choice implies excluded middle", ''Zeitschrift für mathematische Logik und Grundlagen der Mathematik'' 24 (1978), 461. https://doi.org/10.1002/malq.19780242514 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* M. Gordon, R. Milner, L. Morris, M. Newey and C. Wadsworth, "A metalanguage for interactive proof in LCF", in ''Proceedings of the 5th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL '78)'', ACM, 1978, pp. 119–130. doi:10.1145/512760.512773 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* Michael J. Gordon, Robin Milner and Christopher P. Wadsworth, ''Edinburgh LCF: A Mechanised Logic of Computation'', Lecture Notes in Computer Science 78, Springer, 1979. doi:10.1007/3-540-09724-4 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* Michael J. C. Gordon, "From LCF to HOL: a short history", in Gordon Plotkin, Colin Stirling and Mads Tofte (eds), ''Proof, Language, and Interaction: Essays in Honour of Robin Milner'', MIT Press, 2000. https://www.cl.cam.ac.uk/~mjcg/papers/HolHistory.html ''Cited on'' [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]], [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]], [[Lean theorem prover/Further reading|Further reading]].<ref>[[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] and [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] cite the author's PDF copy, www.cl.cam.ac.uk/~mjcg/papers/HolHistory.pdf, under the name Mike Gordon; [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]] and [[Lean theorem prover/Explainers/Tactics|Tactics]] cite the HTML copy given here.</ref>
* W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "On a conjecture of Marton", arXiv:2311.05762, 9 November 2023 (revised 12 December 2023). https://arxiv.org/abs/2311.05762 ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "Marton's Conjecture in abelian groups with bounded torsion", arXiv:2404.02244, 2 April 2024. https://arxiv.org/abs/2404.02244 ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "On a conjecture of Marton", ''Annals of Mathematics'' 201 (2025), no. 2, pp. 515–549. doi:10.4007/annals.2025.201.2.5 ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* Thomas C. Hales, "A proof of the Kepler conjecture", ''Annals of Mathematics'' 162 (3), 2005, pp. 1065–1185. [https://doi.org/10.4007/annals.2005.162.1065 doi:10.4007/annals.2005.162.1065] ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].
* Thomas Hales and 21 co-authors, "A formal proof of the Kepler conjecture", ''Forum of Mathematics, Pi'' 5, e2, 2017. [https://doi.org/10.1017/fmp.2017.1 doi:10.1017/fmp.2017.1]; preprint [https://arxiv.org/abs/1501.02155 arXiv:1501.02155]. ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].
* Sidharth Hariharan, Christopher Birkbeck, Seewoo Lee, Ho Kiu Gareth Ma, Bhavik Mehta, Auguste Poiroux and Maryna Viazovska, "Progress in Formalizing Sphere Packing in Dimension 8", arXiv:2604.23468, April 2026 (revised May 2026). https://arxiv.org/abs/2604.23468 ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Son Ho and Jonathan Protzenko, "Aeneas: Rust verification by functional translation", ''Proceedings of the ACM on Programming Languages'' 6 (ICFP), 2022, pp. 711–741. doi:10.1145/3547647 ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]].
* W. A. Howard, "The formulae-as-types notion of construction", in J. P. Seldin and J. R. Hindley (eds.), ''To H. B. Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism'', Academic Press, 1980, pp. 479–490. Written and circulated in 1969. ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].
* Thomas Hubert, Rishi Mehta, Laurent Sartran, et al., "Olympiad-level formal mathematical reasoning with reinforcement learning", ''Nature'' 651, pp. 607–613, published online 12 November 2025. doi:10.1038/s41586-025-09833-y ''Cited on'' [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Gérard P. Huet, "A unification algorithm for typed λ-calculus", ''Theoretical Computer Science'' 1(1), 1975, pp. 27–57. doi:10.1016/0304-3975(75)90011-0 ''Cited on'' [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]].
* Antonius J. C. Hurkens, "A simplification of Girard's paradox", in ''Typed Lambda Calculi and Applications'' (TLCA 1995), Lecture Notes in Computer Science 902, Springer, 1995, pp. 266–278. https://doi.org/10.1007/BFb0014058 ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].<ref>Read for [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]; [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] cites it from its bibliographic record.</ref>
* L. S. van Benthem Jutting, ''Checking Landau's "Grundlagen" in the Automath System'', Mathematical Centre Tracts 83, Mathematisch Centrum, Amsterdam, 1979. ISBN 90-6196-147-5. Record and scan: https://ir.cwi.nl/pub/13104 ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Jeffrey C. Lagarias, "The 3x+1 problem: an annotated bibliography (1963–1999) (sorted by author)", arXiv:math/0309224 (2003, revised 2011). https://arxiv.org/abs/math/0309224 ''Cited on'' [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]].
* Per Martin-Löf, "An intuitionistic theory of types", written 1972 at the University of Stockholm; published in G. Sambin and J. M. Smith (eds.), ''Twenty-Five Years of Constructive Type Theory'', Oxford University Press, 1998, pp. 127–172. Copy of the 1972 text: https://archive-pml.github.io/martin-lof/pdfs/An-Intuitionistic-Theory-of-Types-1972.pdf ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Per Martin-Löf, "An intuitionistic theory of types: predicative part", in H. E. Rose and J. C. Shepherdson (eds.), ''Logic Colloquium '73'', Studies in Logic and the Foundations of Mathematics 80, North-Holland, 1975, pp. 73–118. doi:10.1016/S0049-237X(08)71945-1 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Per Martin-Löf, ''Intuitionistic Type Theory'', notes by Giovanni Sambin of a series of lectures given in Padua, June 1980, Bibliopolis, Naples, 1984. Re-typeset edition: https://archive-pml.github.io/martin-lof/pdfs/Bibliopolis-Book-retypeset-1984.pdf ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Per Martin-Löf, "Constructive mathematics and computer programming", in L. J. Cohen, J. Łoś, H. Pfeiffer and K.-P. Podewski (eds.), ''Logic, Methodology and Philosophy of Science VI'', North-Holland, 1982, pp. 153–175. doi:10.1016/S0049-237X(09)70189-2 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Patrick Massot, Floris van Doorn and Oliver Nash, "Formalising the h-principle and sphere eversion", arXiv:2210.07746, October 2022. https://arxiv.org/abs/2210.07746 ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* The mathlib Community, "The Lean mathematical library", in ''Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (CPP 2020)'', ACM, 2020, pp. 367–381. [https://doi.org/10.1145/3372885.3373824 doi:10.1145/3372885.3373824]; also arXiv:1910.09336. ''Cited on'' [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]], [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]], [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]], [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Further reading|Further reading]].
* Conor McBride, Healfdene Goguen and James McKinna, "A Few Constructions on Constructors", in ''Types for Proofs and Programs'' (TYPES 2004), Lecture Notes in Computer Science 3839, Springer, 2006, pp. 186–200. https://doi.org/10.1007/11617990_12 ''Cited on'' [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].
* Markus de Medeiros, Muhammad Naveed, Tancrède Lepoint, Temesghen Kahsai, Tristan Ravitch, Stefan Zetzsche, Anjali Joshi, Joseph Tassarotti, Aws Albarghouthi and Jean-Baptiste Tristan, "Verified Foundations for Differential Privacy", ''Proceedings of the ACM on Programming Languages'' 9 (PLDI), 2025, pp. 1094–1118. doi:10.1145/3729294. arXiv:2412.01671 ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]].
* Alex Meiburg, Leonardo A. Lessa and Rodolfo R. Soldati, "A Formalization of the Generalized Quantum Stein's Lemma in Lean", arXiv:2510.08672, October 2025. https://arxiv.org/abs/2510.08672 ''Cited on'' [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* Dale Miller, "A logic programming language with lambda-abstraction, function variables, and simple unification", ''Journal of Logic and Computation'' 1(4), 1991, pp. 497–536. doi:10.1093/logcom/1.4.497 ''Cited on'' [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]].
* Robin Milner, ''Logic for Computable Functions: Description of a Machine Implementation'', Stanford Artificial Intelligence Memo AIM-169, Computer Science Report STAN-CS-72-288, Stanford University, May 1972. http://i.stanford.edu/pub/cstr/reports/cs/tr/72/288/CS-TR-72-288.pdf ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* Robin Milner, "A theory of type polymorphism in programming", ''Journal of Computer and System Sciences'' 17 (3), 1978, pp. 348–375. doi:10.1016/0022-0000(78)90014-4 ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]], [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]], [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]], [[Lean theorem prover/Further reading|Further reading]].
* Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37. Author's copy: https://lean-lang.org/papers/lean4.pdf ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]], [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/The Lean kernel|The Lean kernel]], [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]], [[Lean theorem prover/System/The tactic framework|The tactic framework]], [[Lean theorem prover/System/Decision procedures|Decision procedures]], [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]], [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]], [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]], [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]], [[Lean theorem prover/History/Lean 4|Lean 4]], [[Lean theorem prover/Applications/Principia Machina|Principia Machina]], [[Lean theorem prover/Further reading|Further reading]].<ref>[[Lean theorem prover/Applications/Principia Machina|Principia Machina]], [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]] and [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]] give the title without "(System Description)"; [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]] and [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]] omit the volume number 12699.</ref>
* R. P. Nederpelt, J. H. Geuvers and R. C. de Vrijer (eds.), ''Selected Papers on Automath'', Studies in Logic and the Foundations of Mathematics 133, North-Holland, Amsterdam, 1994. ISBN 0-444-89822-0. Publisher's page with contents: https://shop.elsevier.com/books/selected-papers-on-automath/nederpelt/978-0-444-89822-7 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Ulf Norell, ''Towards a Practical Programming Language Based on Dependent Type Theory'', PhD thesis, Chalmers University of Technology and Göteborg University, 2007. https://www.cse.chalmers.se/~ulfn/papers/thesis.pdf ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Azim Ospanov, Farzan Farnia and Roozbeh Yousefzadeh, "miniF2F-Lean Revisited: Reviewing Limitations and Charting a Path Forward", arXiv:2511.03108, 5 November 2025. [https://arxiv.org/abs/2511.03108 arxiv.org/abs/2511.03108] ''Cited on'' [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]].
* Christine Paulin-Mohring, "Inductive definitions in the system Coq: rules and properties", in ''Typed Lambda Calculi and Applications (TLCA '93)'', Lecture Notes in Computer Science 664, Springer, 1993, pp. 328–345. doi:10.1007/BFb0037116 ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* Christine Paulin-Mohring, "Introduction to the Calculus of Inductive Constructions", in B. Woltzenlogel Paleo and D. Delahaye (eds.), ''All about Proofs, Proofs for All'', Studies in Logic 55, College Publications, 2015. https://inria.hal.science/hal-01094195 ''Cited on'' [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* Lawrence C. Paulson, "The foundation of a generic theorem prover", ''Journal of Automated Reasoning'' 5 (3), 1989, pp. 363–397. doi:10.1007/BF00248324. Preprint: https://arxiv.org/abs/cs/9301105 ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* R. Pollack, "How to believe a machine-checked proof", in Giovanni Sambin and Jan M. Smith (eds), ''Twenty Five Years of Constructive Type Theory'', Oxford University Press, 1998, chapter 11 (from p. 205); first issued as BRICS Report RS-97-18, Aarhus University, 1997. [https://doi.org/10.7146/brics.v4i18.18945 doi:10.7146/brics.v4i18.18945] ''Cited on'' [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]], [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]], [[Lean theorem prover/Further reading|Further reading]].
* William Pugh, "The Omega test: a fast and practical integer programming algorithm for dependence analysis", ''Proceedings of the 1991 ACM/IEEE Conference on Supercomputing (Supercomputing '91)'', ACM, 1991, pp. 4–13. doi:10.1145/125826.125848. Read in an expanded version whose first page states that it appeared in ''Communications of the ACM'' in August 1992, there titled "A practical algorithm for exact array dependence analysis", 35(8), pp. 102–114, doi:10.1145/135226.135233. ''Cited on'' [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Bertrand Russell, "Mathematical logic as based on the theory of types", ''American Journal of Mathematics'' 30 (3), 1908, pp. 222–262. [https://doi.org/10.2307/2369948 doi:10.2307/2369948] ''Not read: the pages rest on its bibliographic record or on a secondary account (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].
* Daniel Selsam, Sebastian Ullrich and Leonardo de Moura, "Tabled Typeclass Resolution", arXiv:2001.04301 [cs.PL], 2020. https://arxiv.org/abs/2001.04301 ''Cited on'' [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]], [[Lean theorem prover/Further reading|Further reading]].
* Joseph Tooby-Smith, "Formalization of physics index notation in Lean 4", arXiv:2411.07667, November 2024. https://arxiv.org/abs/2411.07667 ''Cited on'' [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* Joseph Tooby-Smith, "HepLean: Digitalising high energy physics", ''Computer Physics Communications'' 308 (2025), article 109457. [https://doi.org/10.1016/j.cpc.2024.109457 doi:10.1016/j.cpc.2024.109457]; preprint arXiv:2405.08863. ''Cited on'' [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]], [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* Joseph Tooby-Smith, "Formalizing the stability of the two Higgs doublet model potential into Lean: identifying an error in the literature", arXiv:2603.08139, version 2, 20 April 2026. [https://arxiv.org/abs/2603.08139 arxiv.org/abs/2603.08139] ''Cited on'' [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]].
* A. M. Turing, "On Computable Numbers, with an Application to the Entscheidungsproblem", ''Proceedings of the London Mathematical Society'', series 2, vol. 42 (1936–37), pp. 230–265. doi:10.1112/plms/s2-42.1.230 ''Cited on'' [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]], [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].
* Sebastian Ullrich and Leonardo de Moura, "Counting Immutable Beans: Reference Counting Optimized for Purely Functional Programming", in ''Proceedings of the 31st Symposium on Implementation and Application of Functional Languages (IFL 2019)'', ACM, 2019, article 3, pp. 1–12. doi:[https://doi.org/10.1145/3412932.3412935 10.1145/3412932.3412935]; preprint [https://arxiv.org/abs/1908.05647 arXiv:1908.05647]. ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]], [[Lean theorem prover/Further reading|Further reading]].
* Sebastian Ullrich and Leonardo de Moura, "Beyond Notations: Hygienic Macro Expansion for Theorem Proving Languages", ''Logical Methods in Computer Science'' 18(2), 2022, article 1, 21 pp. Extended version of the paper in ''Automated Reasoning: IJCAR 2020'', Lecture Notes in Computer Science 12167, Springer, 2020, pp. 167–182 (doi:10.1007/978-3-030-51054-1_10). doi:[https://doi.org/10.46298/lmcs-18(2:1)2022 10.46298/lmcs-18(2:1)2022]; preprint [https://arxiv.org/abs/2001.10490 arXiv:2001.10490]. ''Cited on'' [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]], [[Lean theorem prover/Further reading|Further reading]].
* Sebastian Ullrich and Leonardo de Moura, "‘do’ Unchained: Embracing Local Imperativity in a Purely Functional Language (Functional Pearl)", ''Proceedings of the ACM on Programming Languages'' 6 (ICFP), article 109, August 2022, 28 pp. doi:[https://doi.org/10.1145/3547640 10.1145/3547640]; author's copy [https://lean-lang.org/papers/do.pdf lean-lang.org/papers/do.pdf]. ''Cited on'' [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].
* The Univalent Foundations Program, ''Homotopy Type Theory: Univalent Foundations of Mathematics'', Institute for Advanced Study, 2013; Notes to Chapter 1, Example 3.1.9 and §7.2. https://homotopytypetheory.org/book/ ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].
* Philip Wadler, "Propositions as types", ''Communications of the ACM'' 58 (12), 2015, pp. 75–84. [https://doi.org/10.1145/2699407 doi:10.1145/2699407] ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]], [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].
* Benjamin Werner, "Sets in types, types in sets", in Martín Abadi and Takayasu Ito (eds.), ''Theoretical Aspects of Computer Software (TACS 1997)'', Lecture Notes in Computer Science 1281, Springer, 1997, pp. 530–546. https://doi.org/10.1007/BFb0014566 ''Cited on'' [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].
* Freek Wiedijk, "A new implementation of Automath", ''Journal of Automated Reasoning'' 29 (3–4), 2002, pp. 365–387. doi:10.1023/A:1021983302516. Author's copy: https://www.cs.ru.nl/~freek/aut/aut.pdf ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Kaiyu Yang, Aidan M. Swope, Alex Gu, Rahul Chalamala, Peiyang Song, Shixing Yu, Saad Godil, Ryan Prenger and Anima Anandkumar, "LeanDojo: Theorem Proving with Retrieval-Augmented Language Models", NeurIPS 2023 Datasets and Benchmarks Track. arXiv:2306.15626 ''Cited on'' [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Kunhao Zheng, Jesse Michael Han and Stanislas Polu, "MiniF2F: a cross-system benchmark for formal Olympiad-level mathematics", International Conference on Learning Representations (ICLR), 2022. arXiv:2109.00110 ''Cited on'' [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].

== Lean documentation and source ==

=== The Lean Language Reference ===

* ''The Lean Language Reference'', version for Lean 4.34.0, front page and table of contents. [https://lean-lang.org/doc/reference/4.34.0/ lean-lang.org/doc/reference/4.34.0/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover|Lean theorem prover]], [[Lean theorem prover/Sources|Sources]], [[Lean theorem prover/Further reading|Further reading]].
* ''The Lean Language Reference'', version 4.34.0, chapter 8 "Axioms": the introduction, §8.2 "Consistency", §8.3 "Reduction", §8.4 "Standard Axioms" and §8.5 "Displaying Axiom Dependencies". https://lean-lang.org/doc/reference/4.34.0/Axioms/ ''Cited on'' [[Lean theorem prover/Foundations/The three axioms|The three axioms]], [[Lean theorem prover/Sources|Sources]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 20.1, "Natural Numbers". https://lean-lang.org/doc/reference/4.34.0/Basic-Types/Natural-Numbers/ ''Cited on'' [[Lean theorem prover/Explainers/Computation inside proofs|Computation inside proofs]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].
* "Build Tools and Distribution", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/] ''Cited on'' [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]], [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* ''The Lean Language Reference'', version for Lean 4.34.0, section "Lake". [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Lake/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Lake], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]], [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]].
* ''The Lean Language Reference'', version for Lean 4.34.0, section "Managing Toolchains with Elan". [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Managing-Toolchains-with-Elan/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Managing-Toolchains-with-Elan], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]].
* Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Coercions". https://lean-lang.org/doc/reference/4.34.0/Coercions/ ''Cited on'' [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].
* ''The Lean Language Reference'', version for Lean 4.34.0, section "Recursive Definitions". [https://lean-lang.org/doc/reference/4.34.0/Definitions/Recursive-Definitions/ lean-lang.org/doc/reference/4.34.0/Definitions/Recursive-Definitions], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]], [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]], [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]], [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].
* Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Elaboration and Compilation". https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/ ''Cited on'' [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]], [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]], [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]], [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]], [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]], [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/The Lean kernel|The Lean kernel]], [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]], [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]], [[Lean theorem prover/Glossary|Glossary]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), "Error Explanations": <code>lean.synthInstanceFailed</code>. https://lean-lang.org/doc/reference/4.34.0/Error-Explanations/About___--synthInstanceFailed/ ''Cited on'' [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]].
* "Functors, Monads and do-Notation", chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), introduction and section 18.3 "Syntax". [https://lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/ lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/]; [https://lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/Syntax/ …/Syntax/] ''Cited on'' [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].
* ''The Lean Language Reference'', section 1.1 "History", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/Introduction/ ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]], [[Lean theorem prover/History/Lean 4|Lean 4]], [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* "Custom Operators", section 23.1 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Custom-Operators/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Custom-Operators/] ''Cited on'' [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]].
* "Elaborators", section 23.6 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Elaborators/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Elaborators/] ''Cited on'' [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].
* "Macros", section 23.5 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), including 23.5.1 "Hygiene", 23.5.3 "Quotation" and 23.5.5 "Defining Macros". [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/] ''Cited on'' [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]], [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].
* "Notations", section 23.3 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Notations/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Notations/] ''Cited on'' [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]].
* "Foreign Function Interface", section 12.4 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Foreign-Function-Interface/ lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Foreign-Function-Interface/] ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* "Reference Counting", section 12.2 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), including 12.2.2 "Compiler IR". [https://lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Reference-Counting/ lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Reference-Counting/] ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), chapter 14, "Tactic Proofs". https://lean-lang.org/doc/reference/4.34.0/Tactic-Proofs/ ''Cited on'' [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]], [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/System/The tactic framework|The tactic framework]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), section 14.8, "Custom Tactics". https://lean-lang.org/doc/reference/4.34.0/Tactic-Proofs/Custom-Tactics/ ''Cited on'' [[Lean theorem prover/Explainers/Tactics|Tactics]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), section 14.5, "Tactic Reference". https://lean-lang.org/doc/reference/4.34.0/Tactic-Proofs/Tactic-Reference/ ''Cited on'' [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]], [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]], [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]], [[Lean theorem prover/Explainers/Computation inside proofs|Computation inside proofs]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 13.2, "Function Types". https://lean-lang.org/doc/reference/4.34.0/Terms/Function-Types/ ''Cited on'' [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 13.3, "Functions". https://lean-lang.org/doc/reference/4.34.0/Terms/Functions/ ''Cited on'' [[Lean theorem prover/Notation|Notation]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), chapter 16, "The grind tactic". https://lean-lang.org/doc/reference/4.34.0/The--grind--tactic/ ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/System/Decision procedures|Decision procedures]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* ''The Lean Language Reference'', version for Lean 4.34.0 (lean-lang.org, 2026), chapter 15, "The Simplifier". https://lean-lang.org/doc/reference/4.34.0/The-Simplifier/ ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* ''The Lean Language Reference'', version for Lean 4.34.0, chapter 4, "The Type System". [https://lean-lang.org/doc/reference/4.34.0/The-Type-System/ lean-lang.org/doc/reference/4.34.0/The-Type-System/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]], [[Lean theorem prover/Glossary|Glossary]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.1, "Functions". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Functions/ ''Cited on'' [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]], [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], [[Lean theorem prover/Notation|Notation]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.4, "Inductive Types". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/ ''Cited on'' [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]], [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]], [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]], [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]], [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.2, "Propositions". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Propositions/ ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Foundations/The three axioms|The three axioms]], [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].
* ''The Lean Language Reference'', version 4.34.0, §4.5 "Quotients": the introduction, §4.5.5 "Logical Model", §4.5.5.2 "Quotients and Inductive Types", §4.5.6 "Quotients and Function Extensionality" and §4.5.7 "Squash Types". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Quotients/ ''Cited on'' [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]], [[Lean theorem prover/Foundations/Quotient types|Quotient types]].
* ''The Lean Language Reference'', version for Lean 4.34.0, section 4.3, "Universes". [https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Universes/ lean-lang.org/doc/reference/4.34.0/The-Type-System/Universes/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], [[Lean theorem prover/Glossary|Glossary]].
* Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Type Classes", and its section "Instance Synthesis". https://lean-lang.org/doc/reference/4.34.0/Type-Classes/ ''Cited on'' [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].
* ''The Lean Language Reference'', version for Lean 4.34.0, section "Validating a Lean Proof". [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]], [[Lean theorem prover/Explainers/Computation inside proofs|Computation inside proofs]], [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]], [[Lean theorem prover/Foundations/The three axioms|The three axioms]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]], [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/The Lean kernel|The Lean kernel]], [[Lean theorem prover/System/Decision procedures|Decision procedures]], [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]], [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]], [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]], [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]], [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* "Lean 4.22.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), Highlights, "New compiler". [https://lean-lang.org/doc/reference/4.34.0/releases/v4.22.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.22.0/] ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, release notes, "Lean 4.27.0", section "Language". https://lean-lang.org/doc/reference/4.34.0/releases/v4.27.0/ ''Cited on'' [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].
* "Lean 4.28.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "External Checker". [https://lean-lang.org/doc/reference/4.34.0/releases/v4.28.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.28.0/] ''Cited on'' [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* "Lean 4.32.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), Highlights and Language sections. [https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.32.0/] ''Cited on'' [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].
* ''The Lean Language Reference'', version for Lean 4.34.0, "Lean 4.32.1 (2026-07-22)", release notes. [https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.1/ lean-lang.org/doc/reference/4.34.0/releases/v4.32.1], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* ''The Lean Language Reference'', version for Lean 4.34.0, "Lean 4.32.2 (2026-07-28)", release notes. [https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.2/ lean-lang.org/doc/reference/4.34.0/releases/v4.32.2], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* ''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, release notes, "Lean 4.8.0" (functional induction principles) and "Lean 4.18.0" (the <code>fun_induction</code> tactic). https://lean-lang.org/doc/reference/4.34.0/releases/v4.8.0/ and https://lean-lang.org/doc/reference/4.34.0/releases/v4.18.0/ ''Cited on'' [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].
* ''The Lean Language Reference'', version for Lean 4.35.0, front page and table of contents. [https://lean-lang.org/doc/reference/4.35.0/ lean-lang.org/doc/reference/4.35.0/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Sources|Sources]].
* The Lean Developers, "Axioms", ''The Lean Language Reference'', for Lean 4.35.0, chapter 8. [https://lean-lang.org/doc/reference/4.35.0/Axioms/ lean-lang.org/doc/reference/4.35.0/Axioms/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], [[Lean theorem prover/Sources|Sources]].
* The Lean Developers, "Finite natural numbers", ''The Lean Language Reference'', for Lean 4.35.0, section 21.3. [https://lean-lang.org/doc/reference/4.35.0/Basic-Types/Finite-Natural-Numbers/ lean-lang.org/doc/reference/4.35.0/Basic-Types/Finite-Natural-Numbers/] (accessed 14 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]].
* The Lean Developers, "Subtypes", ''The Lean Language Reference'', for Lean 4.35.0, section 21.20. [https://lean-lang.org/doc/reference/4.35.0/Basic-Types/Subtypes/ lean-lang.org/doc/reference/4.35.0/Basic-Types/Subtypes/] (accessed 14 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]].
* The Lean Developers, "Introduction", ''The Lean Language Reference'', for Lean 4.35.0, section 1.1, "History". [https://lean-lang.org/doc/reference/4.35.0/Introduction/ lean-lang.org/doc/reference/4.35.0/Introduction/] (accessed 14 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].
* The Lean Developers, "The type system", ''The Lean Language Reference'', for Lean 4.35.0, chapter 4. [https://lean-lang.org/doc/reference/4.35.0/The-Type-System/ lean-lang.org/doc/reference/4.35.0/The-Type-System/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]], [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]], [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].
* The Lean Developers, "Propositions", ''The Lean Language Reference'', for Lean 4.35.0, section 4.2. [https://lean-lang.org/doc/reference/4.35.0/The-Type-System/Propositions/ lean-lang.org/doc/reference/4.35.0/The-Type-System/Propositions/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].
* The Lean Developers, "Universes", ''The Lean Language Reference'', for Lean 4.35.0, section 4.3. [https://lean-lang.org/doc/reference/4.35.0/The-Type-System/Universes/ lean-lang.org/doc/reference/4.35.0/The-Type-System/Universes/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].
* The Lean Developers, "Validating a Lean proof", ''The Lean Language Reference'', for Lean 4.35.0. [https://lean-lang.org/doc/reference/4.35.0/ValidatingProofs/ lean-lang.org/doc/reference/4.35.0/ValidatingProofs/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], [[Lean theorem prover/Sources|Sources]].
* ''The Lean Language Reference'', version for Lean 4.35.0, "Release Notes", list of versions with their dates. [https://lean-lang.org/doc/reference/4.35.0/releases/ lean-lang.org/doc/reference/4.35.0/releases/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Sources|Sources]].
* ''The Lean Language Reference'', "Release Notes", list of versions with their dates (read 14 October 2026). https://lean-lang.org/doc/reference/latest/releases/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]], [[Lean theorem prover/Chronology|Chronology]].
* ''The Lean Language Reference'', "Lean 4.22.0 (2025-08-14)", release notes. https://lean-lang.org/doc/reference/latest/releases/v4.22.0/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].<ref>The same notes, in the edition of the manual for Lean 4.34.0, are listed above, cited on [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]]. This citation uses the address under "latest", which follows the newest version.</ref>

=== Other documentation and textbooks ===

* Christopher A. Bailey, with contributions from the Lean community, ''Type Checking in Lean 4'' (online book), chapters "Weak and strong reduction", "Definitional Equality" and "Reduction". https://ammkrn.github.io/type_checking_in_lean4/ ''Cited on'' [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].
* ''Type Checking in Lean 4'', online book, chapter "Trust". [https://ammkrn.github.io/type_checking_in_lean4/trust/trust.html ammkrn.github.io/type_checking_in_lean4], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]], [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]], [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]].
* Heather Macbeth, ''The Mechanics of Proof'', online book for Math 2001, Fordham University, 2022–2024. https://hrmacbeth.github.io/math2001/ ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Further reading|Further reading]].
* Documentation of <code>Lean.Compiler.implementedByAttr</code>, Lean API documentation. [https://lean-lang.org/doc/api/Lean/Compiler/ImplementedByAttr.html lean-lang.org/doc/api/Lean/Compiler/ImplementedByAttr.html] ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* Module documentation of <code>Lean.Compiler.LCNF.Basic</code>, "Lean Compiler Normal Form (LCNF)", Lean API documentation. [https://lean-lang.org/doc/api/Lean/Compiler/LCNF/Basic.html lean-lang.org/doc/api/Lean/Compiler/LCNF/Basic.html] ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* David Thrane Christiansen, ''Functional Programming in Lean'', front page. [https://lean-lang.org/functional_programming_in_lean/ lean-lang.org/functional_programming_in_lean/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]], [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Sources|Sources]], [[Lean theorem prover/Further reading|Further reading]].
* David Thrane Christiansen, ''Functional Programming in Lean'', online book (code tested with Lean 4.33.0), section 4.5 "The IO Monad". [https://lean-lang.org/functional_programming_in_lean/Monads/The-IO-Monad/ lean-lang.org/functional_programming_in_lean/Monads/The-IO-Monad/] ''Cited on'' [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].
* David Thrane Christiansen, ''Functional Programming in Lean'', online book (code tested with Lean 4.33.0), section 4.4 "<code>do</code>-Notation for Monads". [https://lean-lang.org/functional_programming_in_lean/Monads/do--Notation-for-Monads/ lean-lang.org/functional_programming_in_lean/Monads/do--Notation-for-Monads/] ''Cited on'' [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', front page. [https://lean-lang.org/theorem_proving_in_lean4/ lean-lang.org/theorem_proving_in_lean4/], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Sources|Sources]], [[Lean theorem prover/Further reading|Further reading]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the Lean Community, ''Theorem Proving in Lean 4'', chapter 12, "Axioms and Computation", online book for Lean 4.33.0. [https://lean-lang.org/theorem_proving_in_lean4/Axioms-and-Computation/ lean-lang.org/theorem_proving_in_lean4/Axioms-and-Computation/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], [[Lean theorem prover/Foundations/Quotient types|Quotient types]], [[Lean theorem prover/Foundations/The three axioms|The three axioms]], [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', lean-lang.org (version for Lean 4.33.0), chapter 2, "Dependent Type Theory". https://lean-lang.org/theorem_proving_in_lean4/Dependent-Type-Theory/ ''Cited on'' [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]], [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'' (online edition for Lean 4.33.0, lean-lang.org), chapter 7, "Inductive Types". https://lean-lang.org/theorem_proving_in_lean4/Inductive-Types/ ''Cited on'' [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]], [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]], [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]], [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the Lean Community, ''Theorem Proving in Lean 4'', chapter 1, "Introduction", online book for Lean 4.33.0. [https://lean-lang.org/theorem_proving_in_lean4/Introduction/ lean-lang.org/theorem_proving_in_lean4/Introduction/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the Lean Community, ''Theorem Proving in Lean 4'', chapter 3, "Propositions and Proofs", section 3.1, online book for Lean 4.33.0. [https://lean-lang.org/theorem_proving_in_lean4/Propositions-and-Proofs/ lean-lang.org/theorem_proving_in_lean4/Propositions-and-Proofs/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]], [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]], [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the Lean Community, ''Theorem Proving in Lean 4'', chapter 4, "Quantifiers and Equality", section 4.2, "Equality", online book for Lean 4.33.0. [https://lean-lang.org/theorem_proving_in_lean4/Quantifiers-and-Equality/ lean-lang.org/theorem_proving_in_lean4/Quantifiers-and-Equality/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].
* Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'' (online edition for Lean 4.33.0, lean-lang.org), chapter 5, "Tactics". https://lean-lang.org/theorem_proving_in_lean4/Tactics/ ''Cited on'' [[Lean theorem prover/Explainers/Tactics|Tactics]], [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].<ref>[[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] cites the chapter at its earlier address, lean-lang.org/theorem_proving_in_lean4/tactics.html, which now forwards here.</ref>
* Lean community, "Lean projects" (installation instructions). [https://leanprover-community.github.io/install/project.html leanprover-community.github.io/install/project.html], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]].
* Arthur Paulino, Damiano Testa, Edward Ayers, Evgenia Karunus, Henrik Böving, Jannis Limperg, Siddhartha Gadgil and Siddharth Bhat, ''Metaprogramming in Lean 4'', online book, Lean community. https://leanprover-community.github.io/lean4-metaprogramming-book/ ''Cited on'' [[Lean theorem prover/Further reading|Further reading]].
* Arthur Paulino, Damiano Testa, Edward Ayers, Evgenia Karunus, Henrik Böving, Jannis Limperg, Siddhartha Gadgil and Siddharth Bhat, ''Metaprogramming in Lean 4'', online book, chapter "MetaM". [https://leanprover-community.github.io/lean4-metaprogramming-book/main/04_metam.html leanprover-community.github.io/lean4-metaprogramming-book/main/04_metam.html] ''Cited on'' [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]], [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]], [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].
* J. Avigad, J. Hua, R. Y. Lewis and F. van Doorn, ''Logic and Proof'', online textbook, Lean 4 edition, read 14 October 2026. https://leanprover-community.github.io/logic_and_proof/ ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Further reading|Further reading]].
* Jeremy Avigad and Patrick Massot, ''Mathematics in Lean'', online book, read 14 October 2026. https://leanprover-community.github.io/mathematics_in_lean/ ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Further reading|Further reading]].
* Jeremy Avigad and Patrick Massot, ''Mathematics in Lean'', online book, chapter 8, "Hierarchies". https://leanprover-community.github.io/mathematics_in_lean/C08_Hierarchies.html ''Cited on'' [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].
* Kevin Buzzard, ''Formalising Mathematics'', course handbook, Imperial College London, 2024 edition. https://www.ma.imperial.ac.uk/~buzzard/xena/formalising-mathematics-2024/ ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]], [[Lean theorem prover/Further reading|Further reading]].

=== Source code ===

* ''Batteries'' (README). [https://github.com/leanprover-community/batteries github.com/leanprover-community/batteries], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]].
* Lean 3 community edition, README file and its earlier version. https://github.com/leanprover-community/lean ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Lean 3 community edition, change log (<code>doc/changes.md</code>), entries from v3.2.0 (June 2017) to 3.51.1c (24 May 2023). https://github.com/leanprover-community/lean/blob/master/doc/changes.md ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Lean 3 mathlib, README file. https://github.com/leanprover-community/mathlib ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]], [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Mathlib, README of the Lean 4 library. https://github.com/leanprover-community/mathlib4 ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Mathlib, source file <code>Mathlib/Basic/Real/Basic.lean</code>, module documentation "Real numbers from Cauchy sequences". [https://github.com/leanprover-community/mathlib4/blob/master/Mathlib/Basic/Real/Basic.lean github.com/leanprover-community/mathlib4], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]].
* Mathport, README file. https://github.com/leanprover-community/mathport ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]].
* Lean 2 source code, README file ("This is a snapshot of the Lean 0.2 theorem prover..."). https://github.com/leanprover/lean2 ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Lean 3 source code, README file, notice that the code is frozen and Lean 4 is the official line. https://github.com/leanprover/lean3 ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Lean 3 source code, version tag v3.0.0, published 20 January 2017. https://github.com/leanprover/lean3/releases/tag/v3.0.0 ''Cited on'' [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].
* Lean 4 source, file <code>src/Init/Classical.lean</code>, version 4.34.1: <code>Classical.em</code> ("Diaconescu's theorem"), <code>Classical.choose</code> and <code>Classical.propDecidable</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Classical.lean ''Cited on'' [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* Lean 4 source, file <code>src/Init/Core.lean</code>, version 4.34.1: the definitions of <code>Setoid</code>, <code>Quotient</code> and <code>Quotient.exact</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Core.lean ''Cited on'' [[Lean theorem prover/Foundations/Quotient types|Quotient types]], [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Grind/Tactics.lean</code>: the documentation string of the <code>grind</code> tactic. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Grind/Tactics.lean ''Cited on'' [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Lean 4 source, file <code>src/Init/Prelude.lean</code>, version 4.34.1: the <code>init_quot</code> command and the documentation of <code>Quot</code>, <code>Quot.mk</code>, <code>Quot.lift</code>, <code>Quot.ind</code>, <code>Quot.sound</code> and <code>Quot.lcInv</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Prelude.lean ''Cited on'' [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]], [[Lean theorem prover/Foundations/Quotient types|Quotient types]], [[Lean theorem prover/System/Elaboration|Elaboration]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Tactics.lean</code>: the documentation strings and definitions of <code>all_goals</code>, <code>focus</code>, <code>first</code>, <code>try</code>, <code><;></code>, <code>repeat</code>, <code>exact?</code> and <code>apply?</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Tactics.lean ''Cited on'' [[Lean theorem prover/System/The tactic framework|The tactic framework]], [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Lean 4 source code, version 4.34.1 (2026), files <code>src/Lean/Elab/Notation.lean</code> (the functions <code>elabNotation</code> and <code>mkUnexpander</code>) and <code>src/Lean/Elab/Macro.lean</code> (the function <code>elabMacro</code>). Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Notation.lean ''Cited on'' [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/SyntheticMVars.lean</code>: the function <code>synthesizeSyntheticMVars</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/SyntheticMVars.lean ''Cited on'' [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/The tactic framework|The tactic framework]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/BVDecide.lean</code>: the overview of <code>bv_decide</code>, sections "Architecture" and "Axioms". Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/BVDecide.lean ''Cited on'' [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/Basic.lean</code>: the definitions <code>TacticM</code>, <code>Tactic</code>, <code>getGoals</code> and <code>tryCatchRestore</code>, with the structure <code>Tactic.State</code> in <code>src/Lean/Elab/Term/TermElabM.lean</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/Basic.lean ''Cited on'' [[Lean theorem prover/System/The tactic framework|The tactic framework]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/Omega.lean</code>: implementation notes of the <code>omega</code> tactic. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/Omega.lean ''Cited on'' [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Term/TermElabM.lean</code>: the function <code>elabTermAux</code> and the type <code>SyntheticMVarKind</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Term/TermElabM.lean ''Cited on'' [[Lean theorem prover/System/Elaboration|Elaboration]], [[Lean theorem prover/System/The tactic framework|The tactic framework]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Environment.lean</code>: the structure <code>Lean.Kernel.Environment</code>, the option <code>debug.skipKernelTC</code> and the function <code>addDeclWithoutChecking</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Environment.lean ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* Lean 4 source, <code>src/Lean/Expr.lean</code>, documentation of <code>Expr.bvar</code>, version 4.34.1. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Expr.lean ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Message.lean</code>: the messages for <code>Kernel.Exception</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Message.lean ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Meta/ExprDefEq.lean</code>: the notes on pattern unification and its approximations A1 to A7. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Meta/ExprDefEq.lean ''Cited on'' [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Meta/SynthInstance.lean</code>: the notes on tabled resolution and table keys, the function <code>generate</code>, and the notes on <code>outParam</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Meta/SynthInstance.lean ''Cited on'' [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/MetavarContext.lean</code>: the design notes at the head of the file. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/MetavarContext.lean ''Cited on'' [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]], [[Lean theorem prover/System/The tactic framework|The tactic framework]].
* Lean 4 source, file <code>src/Lean/Parser/Term.lean</code>, version 4.34.1: the documentation comment of the <code>h ▸ e</code> syntax. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Parser/Term.lean ''Cited on'' [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/Std/Tactic/BVDecide/Reflect.lean</code>: the definition <code>verifyBVExpr</code> and the theorem <code>unsat_of_verifyBVExpr_eq_true</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Std/Tactic/BVDecide/Reflect.lean ''Cited on'' [[Lean theorem prover/System/Decision procedures|Decision procedures]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/environment.cpp</code>: the functions <code>add_axiom</code>, <code>add_definition</code>, <code>add_theorem</code>, <code>add_opaque</code>, <code>add_mutual</code> and <code>check_constant_val</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/environment.cpp ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/inductive.cpp</code>: the functions <code>check_constructors</code> and <code>check_positivity</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/inductive.cpp ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/type_checker.cpp</code>: the functions <code>is_def_eq_core</code>, <code>lazy_delta_reduction_step</code> and <code>reduce_nat</code>; with the function <code>compare</code> in <code>src/kernel/declaration.cpp</code>, which orders unfolding by definitional height. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/type_checker.cpp ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* Lean 4 source code, version tag v4.0.0, published 8 September 2023. https://github.com/leanprover/lean4/releases/tag/v4.0.0 ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]].
* Lean 4 source, version 4.34.1: files <code>src/Init/Core.lean</code> (<code>propext</code>), <code>src/Init/Prelude.lean</code> (<code>Quot.sound</code>, <code>Classical.choice</code>, <code>sorryAx</code>) and <code>src/Init/Classical.lean</code> (the proof of <code>Classical.em</code>). Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/Init ''Cited on'' [[Lean theorem prover/Foundations/The three axioms|The three axioms]].
* Lean 4 source code, version 4.34.1 (2026), directory <code>src/Lean/Compiler/LCNF</code>: in <code>Passes.lean</code> the passes of the impure phase (<code>insertResetReuse</code>, <code>inferBorrow</code>, <code>explicitBoxing</code>, <code>explicitRc</code>, <code>expandResetReuse</code>), in <code>Main.lean</code> the translation of their result to IR (<code>IR.toIR</code>), and <code>EmitC.lean</code>, which emits C. Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/Lean/Compiler/LCNF ''Cited on'' [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].
* Lean 4 source code, version 4.34.1 (2026), directory <code>src/kernel</code> (36 files <code>*.cpp</code> and <code>*.h</code>, plus <code>CMakeLists.txt</code>). Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/kernel ''Cited on'' [[Lean theorem prover/System/The Lean kernel|The Lean kernel]].
* ''lean4checker'' (README of the archived project; now distributed with Lean as <code>leanchecker</code>). [https://github.com/leanprover/lean4checker github.com/leanprover/lean4checker], consulted 13 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].
* ''lean4export'' (README). [https://github.com/leanprover/lean4export github.com/leanprover/lean4export], consulted 13 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].
* "lean4export", Reservoir, the index of Lake packages: "A simple declaration exporter for Lean 4 using the Lean 4 NDJSON export format". [https://reservoir.lean-lang.org/@leanprover/lean4export reservoir.lean-lang.org/@leanprover/lean4export] ''Cited on'' [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

== Projects and announcements ==

* ACM SIGPLAN, "Programming Languages Software Award", recipients, 2025: Lean Theorem Prover. https://www.sigplan.org/Awards/Software/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* Adam Topaz, "Definitions in the liquid tensor experiment", Lean community blog, 14 October 2022. https://leanprover-community.github.io/blog/posts/lte-examples/ ''Cited on'' [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].
* Alexander Bentkamp, Jon Eugster et al., "Lean 4 Game", the source of the Lean Game Server: project description and list of hosted games, read 14 October 2026. https://github.com/leanprover-community/lean4game ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]].
* Announcement of the 1991 ACM Turing Award to Robin Milner, with the short citation, forwarded to the TYPES mailing list, 1 November 1991. https://www.engineering.upenn.edu/~sweirich/types/archive/1991/msg00062.html ''Cited on'' [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].
* Anthropic, "Formalizing Fermat's Last Theorem", 4 September 2026. https://www.anthropic.com/research/formalizing-fermats-last-theorem ''Cited on'' [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* CADE Inc., "Skolem Award", with the list of recipients (awards at CADE-30, July 2025). https://cadeinc.org/Skolem-Award ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* EPFL, "Prof. Viazovska's proofs of sphere packing formalized with AI", EPFL news, March 2026. https://actu.epfl.ch/news/prof-viazovska-s-proofs-of-sphere-packing-formaliz/ ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* Floris van Doorn et al., "Formalization of a generalized Carleson's theorem" (project description, read 13 October 2026). https://github.com/fpvandoorn/carleson ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* Freek Wiedijk, "Automath" (notes accompanying the aut checker). https://www.cs.ru.nl/~freek/aut/ ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* Google DeepMind, "AI achieves silver-medal standard solving International Mathematical Olympiad problems", 25 July 2024. https://deepmind.google/discover/blog/ai-solves-imo-problems-at-silver-medal-level/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* ''Isabelle'', home page. [https://isabelle.in.tum.de/ isabelle.in.tum.de] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].
* Johan Commelin, "Liquid Tensor Experiment: an update", Lean community blog, 31 December 2021. https://leanprover-community.github.io/blog/posts/lte-update/ ''Cited on'' [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].
* John Harrison, ''The HOL Light theorem prover'', home page. [https://www.cl.cam.ac.uk/~jrh13/hol-light/ www.cl.cam.ac.uk/~jrh13/hol-light/] (accessed 14 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].
* Kesha Hietala and Emina Torlak, "Lean Into Verified Software Development", AWS Open Source Blog, 8 April 2024. https://aws.amazon.com/blogs/opensource/lean-into-verified-software-development/ ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]].
* Kevin Buzzard, "A Lean formalisation of Fermat's Last Theorem" (the project's general information), written December 2023. https://github.com/ImperialCollegeLondon/FLT/blob/main/GENERAL.md ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]], [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]].
* Kevin Buzzard, "AI at IMO 2025: a round-up", ''Xena'' (blog), 3 August 2025. https://xenaproject.wordpress.com/2025/08/03/ai-at-imo-2025-a-round-up/ ''Cited on'' [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Kevin Buzzard et al., "Fermat's Last Theorem" (project page and README), Imperial College London, read 14 October 2026. https://imperialcollegelondon.github.io/FLT/ and https://github.com/ImperialCollegeLondon/FLT ''Cited on'' [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]].
* Kevin Buzzard, "Fermat's Last Theorem — how it's going", ''Xena'' (blog), 11 December 2024. https://xenaproject.wordpress.com/2024/12/11/fermats-last-theorem-how-its-going/ ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]].
* Kevin Buzzard, "FLT: Anthropic has beaten me to it", ''Xena'' (blog), 4 September 2026. https://xenaproject.wordpress.com/2026/09/04/flt-anthropic-has-beaten-me-to-it/ ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Kevin Buzzard, "Formalizing Fermat workshop", ''Xena'' (blog), 15 May 2026. https://xenaproject.wordpress.com/2026/05/15/formalizing-fermat-workshop/ ''Cited on'' [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Kevin Buzzard, Jon Eugster et al., ''Natural Number Game'', Lean 4 version, game text and credits. https://github.com/leanprover-community/NNG4 ''Cited on'' [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]].
* Kevin Buzzard, Jon Eugster et al., ''Natural Number Game'', Lean 4 version, on the Lean Game Server: https://adam.math.hhu.de/#/g/leanprover-community/nng4 (source and credits: https://github.com/leanprover-community/NNG4) ''Cited on'' [[Lean theorem prover/Further reading|Further reading]].
* Kevin Buzzard, "The Annals Challenge", ''Xena'' (blog), 13 August 2026. https://xenaproject.wordpress.com/2026/08/13/the-annals-challenge/ ''Cited on'' [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Kevin Buzzard, "The Fermat's Last Theorem Project", Lean community blog, 30 April 2024. https://leanprover-community.github.io/blog/posts/FLT-announcement/ ''Cited on'' [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]].
* Lean community, "Community teams" and "Mathlib reviewers" (read 14 October 2026). https://leanprover-community.github.io/teams.html ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Lean community, "Contributing to mathlib" (read 14 October 2026). https://leanprover-community.github.io/contribute/index.html ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Lean community, "Mathlib maintainers" (read 14 October 2026). https://leanprover-community.github.io/teams/maintainers.html ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Lean community, "Mathlib porting status" (read 14 October 2026). https://leanprover-community.github.io/mathlib-port-status/ ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]].
* Lean community, "Mathlib statistics". [https://leanprover-community.github.io/mathlib_stats.html leanprover-community.github.io/mathlib_stats.html], consulted 14 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]], [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Lean FRO, "About" page, with its timeline "A Brief History of Lean" (read 14 October 2026). https://lean-lang.org/fro/about/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* Lean FRO, home page, "Vision" and "Mission" (read 14 October 2026). https://lean-lang.org/fro/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* Lean FRO, "Roadmap" (index of the roadmaps from August 2023). https://lean-lang.org/fro/roadmap/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* Lean FRO, "The Lean FRO Year 4 - Part 1 Roadmap", covering September 2026 to February 2027. https://lean-lang.org/fro/roadmap/y4-1/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* ''Lean Kernel Arena''. [https://arena.lean-lang.org arena.lean-lang.org], consulted 13 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]], [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* "lean4lean", checker page, Lean Kernel Arena. [https://arena.lean-lang.org/checker/lean4lean arena.lean-lang.org/checker/lean4lean] ''Cited on'' [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* Leonardo de Moura, "Postmortem for Kernel Soundness Bug #14576", 1 August 2026. https://leodemoura.github.io/blog/2026-8-1-postmortem-for-kernel-soundness-bug-14576/ ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* "nanoda", checker page, Lean Kernel Arena. [https://arena.lean-lang.org/checker/nanoda/ arena.lean-lang.org/checker/nanoda/] ''Cited on'' [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* ''nanoda_lib'' (README), an external type checker for Lean 4 written in Rust. [https://github.com/ammkrn/nanoda_lib github.com/ammkrn/nanoda_lib], consulted 13 October 2026. ''Cited on'' [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].
* Peter Scholze, "Half a year of the Liquid Tensor Experiment: amazing developments", guest post on the ''Xena'' blog, 5 June 2021. [https://xenaproject.wordpress.com/2021/06/05/half-a-year-of-the-liquid-tensor-experiment-amazing-developments/ xenaproject.wordpress.com] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]], [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]], [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* Peter Scholze, "Liquid tensor experiment", guest post on the ''Xena'' blog, 5 December 2020. [https://xenaproject.wordpress.com/2020/12/05/liquid-tensor-experiment/ xenaproject.wordpress.com] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]], [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].
* Physlib, "About Physlib", project website, read 14 October 2026. https://physlib.io/about ''Cited on'' [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* ''Physlib'' (README). [https://github.com/leanprover-community/physlib github.com/leanprover-community/physlib], consulted 14 October 2026; also [https://physlib.io physlib.io]. ''Cited on'' [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]], [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* "Principia Machina: the move to Lean", the page [[Principia Machina/Lean transition]] on this wiki, status as of 14 October 2026. ''Cited on'' [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]], [[Lean theorem prover/Applications/Principia Machina|Principia Machina]].
* Renaissance Philanthropy, "Kevin Buzzard and Alex Kontorovich on the Future of Formal Mathematics: A Mathlib Initiative Interview", 3 October 2025. https://www.renaissancephilanthropy.org/insights/kevin-buzzard-and-alex-kontorovich-on-the-future-of-formal-mathematics-a-mathlib-initiative-interview ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].
* Renaissance Philanthropy, "Lean FRO and Mathlib receive $10M from XTX Markets Founder Alex Gerko to further advance the use of AI for mathematical research", 24 July 2025. https://www.renaissancephilanthropy.org/insights/lean-fro-and-mathlib-receive-10m-from-xtx-markets-founder-alex-gerko-to-further-advance-the-use-of-ai-for-mathematical-research ''Cited on'' [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* Son Ho, Cédric Fournet, Antoine Delignat-Lavaud, Samuel Lee, Jason Fisher and Jessica Krynitsky, "Verifying Rust cryptography in SymCrypt, from standards to code", Microsoft Research Blog, 13 July 2026. https://www.microsoft.com/en-us/research/blog/verifying-rust-cryptography-in-symcrypt-from-standards-to-code/ ''Cited on'' [[Lean theorem prover/Applications/Software verification|Software verification]], [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* Terence Tao, "A pilot project in universal algebra to explore new ways to collaborate and use machine assistance?", ''What's new'' (blog), 25 September 2024. https://terrytao.wordpress.com/2024/09/25/a-pilot-project-in-universal-algebra-to-explore-new-ways-to-collaborate-and-use-machine-assistance/ ''Cited on'' [[Lean theorem prover/Applications/The equational theories project|The equational theories project]].
* Terence Tao, "Formalizing the proof of PFR in Lean4 using Blueprint: a short tour", ''What's new'' (blog), 18 November 2023. https://terrytao.wordpress.com/2023/11/18/formalizing-the-proof-of-pfr-in-lean4-using-blueprint-a-short-tour/ ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* Terence Tao, "On a conjecture of Marton", ''What's new'' (blog), 13 November 2023. https://terrytao.wordpress.com/2023/11/13/on-a-conjecture-of-marton/ ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* Terence Tao, post on Mathstodon, 5 December 2023. https://mathstodon.xyz/@tao/111526765350663641 ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* Terence Tao, Yaël Dillies et al., "The Polynomial Freiman-Ruzsa Conjecture" (project page, with blueprint and Lean source), read 14 October 2026. https://teorth.github.io/pfr/ ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* The Agda Team, "What is Agda?", ''Agda documentation''. [https://agda.readthedocs.io/en/latest/getting-started/what-is-agda.html agda.readthedocs.io] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].
* The Automath Archive, Eindhoven University of Technology, "About Automath". https://automath.win.tue.nl/aboutautomath.htm ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* "The collected works of Per Martin-Löf", an online archive of his papers, list of works with dates. https://archive-pml.github.io/ ''Cited on'' [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* "The first official release of Lean 4", Lean community blog, 8 September 2023. https://leanprover-community.github.io/blog/posts/first-lean-release/ ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]], [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* The mathlib community, "Completion of the Liquid Tensor Experiment", Lean community blog, 15 July 2022. https://leanprover-community.github.io/blog/posts/lte-final/ ''Cited on'' [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]], [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].
* The Rocq Prover Reference Manual, "History of Coq", including "A short history of the early versions" written by Thierry Coquand, Gérard Huet and Christine Paulin-Mohring in September 2015 and Huet's summary of February 1995. https://rocq-prover.org/doc/master/refman/history.html ''Cited on'' [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* The Rocq Team, "About Rocq", ''The Rocq Prover''. [https://rocq-prover.org/about rocq-prover.org/about] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* The Rocq Team, "Rocq 9.0.0", ''The Rocq Prover'', 12 March 2025. [https://rocq-prover.org/releases/9.0.0 rocq-prover.org/releases/9.0.0] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].
* The Xena Project (blog), "Division by zero in type theory: a FAQ", 5 July 2020. [https://xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq/ xenaproject.wordpress.com/2020/07/05/division-by-zero-in-type-theory-a-faq] ''Cited on'' [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]].
* "Tutorial" test suite, Lean Kernel Arena. [https://arena.lean-lang.org/tutorial/ arena.lean-lang.org/tutorial/] ''Cited on'' [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].
* UK Research and Innovation, Gateway to Research, "Formalising Fermat", grant EP/Y022904/1, principal investigator Kevin Buzzard, Imperial College London. https://gtr.ukri.org/projects?ref=EP%2FY022904%2F1 ''Cited on'' [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]].
* University of Bonn, Department of Mathematics, "Skolem Award for Floris van Doorn", 27 May 2025. https://www.mathematics.uni-bonn.de/en/news/skolem-award-for-floris-van-doorn ''Cited on'' [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].
* "Update on mathport (Dec 2021)", Lean community blog, 22 December 2021. https://leanprover-community.github.io/blog/posts/intro-to-mathport/ ''Cited on'' [[Lean theorem prover/History/Lean 4|Lean 4]].

== Press and encyclopedias ==

* B. Jack Copeland, "The Church-Turing Thesis", ''The Stanford Encyclopedia of Philosophy'' (first published 1997, substantive revision 18 December 2023), section 1.7. https://plato.stanford.edu/entries/church-turing/ ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].
* Bernard Linsky and Andrew David Irvine, "Principia Mathematica", ''The Stanford Encyclopedia of Philosophy'', substantive revision of 10 March 2026. [https://plato.stanford.edu/entries/principia-mathematica/ plato.stanford.edu/entries/principia-mathematica/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].
* Davide Castelvecchi, "Mathematicians welcome computer-assisted proof in 'grand unification' theory", ''Nature'' 595, 2021, pp. 18–19 (news, 18 June 2021). doi:10.1038/d41586-021-01627-2 ''Read in part: the headline, the summary and the first paragraph; the rest is behind a paywall (see [[Lean theorem prover/Sources|Sources]]).'' ''Cited on'' [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].
* Harry Deutsch, Oliver Marshall and Andrew David Irvine, "Russell's paradox", ''The Stanford Encyclopedia of Philosophy'', substantive revision of 13 March 2026. [https://plato.stanford.edu/entries/russell-paradox/ plato.stanford.edu/entries/russell-paradox/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].
* John L. Bell, "The Axiom of Choice", ''Stanford Encyclopedia of Philosophy'', substantive revision of 10 December 2021, §5 "The Axiom of Choice and Logic" and note 15. https://plato.stanford.edu/entries/axiom-choice/ ''Cited on'' [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]].
* Kevin Hartnett, "Proof Assistant Makes Jump to Big-League Math", ''Quanta Magazine'', 28 July 2021. https://www.quantamagazine.org/lean-computer-program-confirms-peter-scholze-proof-20210728/ ''Cited on'' [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].
* Leila Sloman, "'A-Team' of Math Proves a Critical Link Between Addition and Sets", ''Quanta Magazine'', 6 December 2023. https://www.quantamagazine.org/a-team-of-math-proves-a-critical-link-between-addition-and-sets-20231206/ ''Cited on'' [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].
* Liesbeth De Mol, "Turing Machines", ''The Stanford Encyclopedia of Philosophy'' (first published 2018, substantive revision 21 May 2025), section 2.4. https://plato.stanford.edu/entries/turing-machine/ ''Cited on'' [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]].
* Mathematics Genealogy Project, entry for Lambert S. van Benthem Jutting: Ph.D., Technische Universiteit Eindhoven, 1977, dissertation "Checking Landau's 'Grundlagen' in the Automath System", advisors N. G. de Bruijn and W. Peremans. https://www.mathgenealogy.org/id.php?id=63580 ''Cited on'' [[Lean theorem prover/History/Automath|Automath]].
* nLab, "Burali-Forti's paradox", section "In type theory: Girard's paradox", revision of 24 November 2023. https://ncatlab.org/nlab/show/Girard%27s+paradox ''Cited on'' [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].
* Panu Raatikainen, "Gödel's Incompleteness Theorems", ''The Stanford Encyclopedia of Philosophy'' (first published 2013, substantive revision 8 October 2025), sections 1 and 4.2. https://plato.stanford.edu/entries/goedel-incompleteness/ ''Cited on'' [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].
* Peter Dybjer and Erik Palmgren, "Intuitionistic type theory", ''The Stanford Encyclopedia of Philosophy'', substantive revision of 23 September 2024, sections 3.6 and 7.4. [https://plato.stanford.edu/entries/type-theory-intuitionistic/ plato.stanford.edu/entries/type-theory-intuitionistic/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]].
* Thierry Coquand, "Type theory", ''The Stanford Encyclopedia of Philosophy'', substantive revision of 6 September 2022, section 6. [https://plato.stanford.edu/entries/type-theory/ plato.stanford.edu/entries/type-theory/] (accessed 13 October 2026). ''Cited on'' [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].

== Next ==

* [[Lean theorem prover/Further reading|Further reading]]

== References ==

<references />

Lean theorem prover/Sources

2026-10-15T19:35:51Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Sources}}
{{Lean theorem prover map}}
This page states what the rest of the edition rests on. It is not a bibliography; [[Lean theorem prover/Bibliography|that is separate]]. It accounts for which sources were read and which were not, what each unread source carries on its page and what carries it instead, which versions of Lean and of its documentation the pages describe, and what remains open.

The short version, before the detail. '''What the pages say about Lean rests on Lean itself, run on every fragment shown, and on Lean's own documentation and source, read in the versions the citations name.''' The edition cites 277 distinct works in 501 citations. Of these works, 258 were opened and read and 19 were not. None of the 19 carries a claim about Lean: each gives a date, a title, a venue, an attribution or a classical result, and each such claim rests as well on a bibliographic record, an abstract, or a source that was read.

== What the edition rests on ==

Every citation falls in one of four classes. The pages add a fifth kind of evidence of their own, Lean's output.

{| class="wikitable"
! class !! works !! citations !! not read
|-
| Lean's output, from running Lean 4.34.1 || colspan="3" | 214 fragments of Lean on 51 pages, and 111 blocks of what Lean printed
|-
| Lean's documentation and source || 114 || 233 || 0
|-
| Papers and books || 86 || 167 || 18
|-
| Project pages and announcements || 64 || 86 || 0
|-
| Press and encyclopedias || 13 || 15 || 1, read in part
|}

'''Lean's output.''' The content pages show 214 fragments of Lean code, on 51 pages. Of these, 213 are compiled with Lean 4.34.1, each on its own or, where it continues an earlier fragment on the same page, together with the fragments before it (40 do so), and 52 of the compiled fragments are meant to be refused; their pages quote the error. One uses Mathlib, the community's library, and is shown without being compiled; its page says so. Output that a page quotes, from <code>#eval</code>, <code>#check</code>, <code>#print axioms</code> or an error, is the output Lean 4.34.1 printed, copied and not recalled; 111 such passages are set apart in blocks of their own. On 14 October 2026 every compiled fragment behaved as its page says: those meant to be accepted were accepted, and those meant to be refused were refused. A reader with Lean 4.34.1 can repeat each check.

'''Lean's documentation and source.''' There are 114 works, all read: 52 parts of ''The Lean Language Reference'', 39 files, directories and descriptions of Lean's source and of tools that work with it, and 23 other documents, among them ''Theorem Proving in Lean 4'', ''Functional Programming in Lean'' and the community's textbooks. The Foundations and System pages draw on them for what they say about how Lean works, and show much of it in Lean's output.

'''Papers and books.''' There are 86 works: the papers on type theory and its history behind the Foundations and History pages, the papers that describe Lean, and the papers of the projects described under Applications. Of these, 68 were read, in whole or in the parts cited, and 18 were not; they are listed below.

'''Project pages and announcements.''' There are 64 works, all read: project sites and descriptions, blog posts, lists of awards, roadmaps and announcements. Many of them change over time; see the known gaps below.

'''Press and encyclopedias.''' There are 13 works: entries of the ''Stanford Encyclopedia of Philosophy'' and of the nLab, articles in ''Quanta Magazine'' and ''Nature'', and a record of the Mathematics Genealogy Project. One, the ''Nature'' article, was read in part.

== Versions ==

'''Lean.''' The pages describe Lean 4.34.1. Every fragment is compiled with it, and every quoted output is its output. Lean 4.34.1 was published on 24 September 2026, ten days after 4.34.0; Lean 4.35.0 followed on 12 October 2026.<ref name="relnotes">''The Lean Language Reference'', version for Lean 4.35.0, "Release Notes", list of versions with their dates. [https://lean-lang.org/doc/reference/4.35.0/releases/ lean-lang.org/doc/reference/4.35.0/releases/], consulted 14 October 2026.</ref> Citations of Lean's source name the tag v4.34.1 (33 citations do), so that what they describe is the code that was run.

'''The reference manual.''' ''The Lean Language Reference'' is published in editions numbered by version. The edition for 4.34.0 states that it covers Lean version 4.34.0,<ref name="man4340">''The Lean Language Reference'', version for Lean 4.34.0, front page and table of contents. [https://lean-lang.org/doc/reference/4.34.0/ lean-lang.org/doc/reference/4.34.0/], consulted 14 October 2026.</ref> and there is no edition for 4.34.1. Most pages cite the edition for 4.34.0: 40 of its parts, in 114 citations on 45 pages. Six explainers, [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]], [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]], [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]], [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]] and [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]], cite the edition for 4.35.0, which was the newest when they were read.

The two editions differ. To find out where, the eight chapters and sections cited in the edition for 4.35.0 were compared with their text in the edition for 4.34.0. Five read the same, apart from section numbers and the label of a marginal note: "Introduction", "The Type System", "Propositions", "Universes" and "Subtypes". "Finite Natural Numbers" differs in the signature of one library function. "Axioms" and "Validating a Lean Proof" differ in substance. Lean 4.35.0 removed the axiom <code>Lean.trustCompiler</code> and the machinery around it,<ref name="val4350">''The Lean Language Reference'', version for Lean 4.35.0, "Validating a Lean Proof". [https://lean-lang.org/doc/reference/4.35.0/ValidatingProofs/ lean-lang.org/doc/reference/4.35.0/ValidatingProofs/], consulted 14 October 2026.</ref> so the edition for 4.34.0 lists seven standard axioms, three of which record trust in Lean's compiler, and the edition for 4.35.0 lists four.<ref name="ax4340">''The Lean Language Reference'', version for Lean 4.34.0, chapter 8, "Axioms". [https://lean-lang.org/doc/reference/4.34.0/Axioms/ lean-lang.org/doc/reference/4.34.0/Axioms/], consulted 14 October 2026.</ref><ref name="ax4350">''The Lean Language Reference'', version for Lean 4.35.0, chapter 8, "Axioms". [https://lean-lang.org/doc/reference/4.35.0/Axioms/ lean-lang.org/doc/reference/4.35.0/Axioms/], consulted 14 October 2026.</ref> In Lean 4.34.1 the axiom still exists, and a proof by native evaluation already depends on an axiom of its own, whose name contains <code>_native</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check Lean.trustCompiler

theorem two_plus_two : 2 + 2 = 4 := by native_decide
#print axioms two_plus_two
</pre>

Lean 4.34.1 prints:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Lean.trustCompiler : True
'two_plus_two' depends on axioms: [two_plus_two._native.native_decide.ax_1_1]
</pre>

None of the six explainers relies on the difference. What they take from the two chapters, the three axioms known to be consistent, <code>sorryAx</code>, and the axioms with <code>_native</code> in their names, holds in Lean 4.34.1 as in 4.35.0.

The edition for 4.35.0 also inserts a chapter, "The vcgen tactic", as chapter 17, and adds a twenty-sixth, so its chapters from 17 on are numbered one higher than in the edition for 4.34.0.<ref name="man4340" /><ref name="man4350">''The Lean Language Reference'', version for Lean 4.35.0, front page and table of contents. [https://lean-lang.org/doc/reference/4.35.0/ lean-lang.org/doc/reference/4.35.0/], consulted 14 October 2026.</ref> A section number given on a page belongs to the edition that page cites.

Some citations use an address marked "latest", which always shows the newest edition (4 citations in all): the manual's list of versions and its notes for Lean 4.22.0, on [[Lean theorem prover/History/Lean since 2023|Lean since 2023]] and in the [[Lean theorem prover/Chronology|chronology]], and the documentation of Agda, on [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]]. What those addresses show will change. The same notes for Lean 4.22.0 are also cited, in the edition for 4.34.0, on [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].

'''The books.''' ''Theorem Proving in Lean 4'' states that it assumes Lean 4.33.0,<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', front page. [https://lean-lang.org/theorem_proving_in_lean4/ lean-lang.org/theorem_proving_in_lean4/], consulted 14 October 2026.</ref> and the code of ''Functional Programming in Lean'' is tested with Lean 4.33.0.<ref name="fpil">David Thrane Christiansen, ''Functional Programming in Lean'', front page. [https://lean-lang.org/functional_programming_in_lean/ lean-lang.org/functional_programming_in_lean/], consulted 14 October 2026.</ref> The pages cite them for explanations and definitions. Every output the pages show is that of Lean 4.34.1.

== What was not read ==

The 19 works below were not read, or, in one case, read only in part. For each, the table gives the pages that cite it, what they take from it, and what carries that claim instead.

{| class="wikitable"
! work !! cited on !! what the page takes from it !! what carries it
|-
| Bove, Dybjer and Norell, "A brief overview of Agda", 2009 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] || that an overview of the new Agda appeared in 2009, beside the account of its predecessors || Norell's thesis, read, cited beside it; the bibliographic record
|-
| Constable and others, ''Implementing Mathematics with the Nuprl Proof Development System'', 1986 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] || that Nuprl rests on an extensional theory close to Martin-Löf's of 1982 || the ''Stanford Encyclopedia'' entry on intuitionistic type theory, read, cited beside it; a library catalogue record
|-
| Coquand and Huet, "Constructions: a higher order proof system for mechanizing mathematics", 1985 || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] || that the calculus was described at EUROCAL in 1985 || the bibliographic record; the history in the Rocq reference manual, read
|-
| Coquand and Paulin, "Inductively defined types", 1990 || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] || that the paper was given at COLOG-88 and printed in 1990 || the history in the Rocq reference manual, read, cited beside it; the bibliographic record
|-
| Curry, "Functionality in combinatory logic", 1934 || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]] || Curry's observation of 1934 || Wadler's "Propositions as types", read, cited beside it. The journal's copies could not be fetched
|-
| Castelvecchi, "Mathematicians welcome computer-assisted proof in 'grand unification' theory", ''Nature'', 2021 || [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]] || its date, its author and its summary || the headline, the summary and the first paragraph, read; the rest is behind a paywall
|-
| Diaconescu, "Axiom of choice and complementation", 1975 || [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]] || the theorem's name and date, and the setting of the first proof || ''Theorem Proving in Lean 4'' and the ''Stanford Encyclopedia'' entry on the axiom of choice, read, cited beside it; the abstract in the publisher's record
|-
| Gödel, "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I", 1931 || [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]] || the incompleteness theorems, as the pages state them || the ''Stanford Encyclopedia'' entry on the incompleteness theorems, read, cited beside it; Turing's paper of 1936, read, which cites it with the same details. No open copy was found
|-
| Goldfarb, "The undecidability of the second-order unification problem", 1981 || [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] || that unification is undecidable from order 2 || the introduction of Miller's paper of 1991, read, which states the result with this citation. The publisher refused access
|-
| Goodman and Myhill, "Choice implies excluded middle", 1978 || [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]] || the note's title and date || the bibliographic record, and the ''Stanford Encyclopedia'' entry on the axiom of choice, read. No open copy was found
|-
| Gordon, Milner, Morris, Newey and Wadsworth, "A metalanguage for interactive proof in LCF", 1978 || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] || that ML was described at the 1978 Symposium on Principles of Programming Languages || the bibliographic record
|-
| Gordon, Milner and Wadsworth, ''Edinburgh LCF'', 1979 || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] || that the work was written up as a book in 1979 || the bibliographic record; Gordon's history of LCF and HOL, read
|-
| Hales, "A proof of the Kepler conjecture", 2005 || [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]] || that the proof was published without complete certification || the Flyspeck paper, read, cited beside it; the journal's page for the article
|-
| Howard, "The formulae-as-types notion of construction", 1980 || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]] || that Howard's notes of 1969 circulated privately and were printed in 1980 || Wadler's "Propositions as types", read, cited beside it, with its list of references
|-
| Martin-Löf, "An intuitionistic theory of types: predicative part", 1975 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] || the hierarchy of universes and the identity type of that version || the ''Stanford Encyclopedia'' entry on intuitionistic type theory, read, cited beside it; the bibliographic record
|-
| Martin-Löf, "Constructive mathematics and computer programming", 1982 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] || the extensional form of the theory || the same entry, read, cited beside it; the bibliographic record
|-
| Nederpelt, Geuvers and de Vrijer (eds.), ''Selected Papers on Automath'', 1994 || [[Lean theorem prover/History/Automath|Automath]] || the collection and its contents || the publisher's page with the contents, read
|-
| Paulin-Mohring, "Inductive definitions in the system Coq: rules and properties", 1993 || [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]], [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] || why the Calculus of Constructions was extended with inductive definitions, and that the rules were set out in 1993 || the paper's abstract, read; the history in the Rocq reference manual, read. No open copy was found
|-
| Russell, "Mathematical logic as based on the theory of types", 1908 || [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]] || that the ramified theory was set out in a paper of 1908 || the ''Stanford Encyclopedia'' entry on Russell's paradox, read, cited beside it
|}

Two further works were read for one page and cited from their records on another. Hurkens's "A simplification of Girard's paradox" (1995) was read, in a copy on a university site, for [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], and is cited on [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] for its date. Coquand and Huet's "The calculus of constructions" (1988) was read, in a scan of the published article, for [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], and is cited on [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] for its journal and year.

'''What this costs.''' Eleven of the unread works are cited on the History pages, for dates, venues and attributions; the others support the history of an idea, or a classical result, on explainers and technical pages. The sharpest cost is on [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]: its account of why the Calculus of Constructions was extended with inductive definitions rests on the abstract of Paulin-Mohring's paper, not on the paper. The next is on [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]], where Goldfarb's result is stated as Miller reports it.

== Read in part, or in another copy ==

* The ''Nature'' article of 2021 was read in its headline, summary and first paragraph; the rest is behind a paywall.
* Carneiro's paper on Lean4Lean was read in its arXiv text: version 2 for [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] and [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], version 3 for the other pages that cite it. The pages that cite the version published in 2026 read the arXiv text as well.
* Some papers were read in copies held elsewhere than their publishers: Hurkens (1995) and Coquand and Huet (1988), for [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]], on university sites; Milner's paper of 1978 on type polymorphism, for [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]], in a course archive, in its opening pages; Abel and Coquand's paper on normalisation, for [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]], in its arXiv source.
* De Bruijn's survey of Automath, his paper of 1970 and van Benthem Jutting's book of 1979 were read in scans with machine-read text, the paper of 1970 in its opening pages; de Bruijn's paper of 1972 on nameless dummies was read in its first two pages.
* The ACM's own pages refused automated access. The Turing Award citation on [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] is quoted from the announcement forwarded to the TYPES mailing list, and the software award named on [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]] rests on the Rocq site and on search results that showed the ACM's announcement.

== The rules the edition followed ==

* '''No citation from memory.''' Every work cited was checked: by opening it, or, for the works listed above as not read, through its bibliographic record. A detail that could not be checked was left out.
* '''Short quotations.''' Sources are paraphrased. The rule was to quote at most one short passage, of 25 words or fewer, from any one source on a page, in quotation marks and with its citation; Lean's own documentation and source, published under the Apache License, are quoted a little more freely. No quotation in the prose of the content pages is longer than 25 words.
* '''Every Lean fragment compiled.''' Each fragment is compiled with Lean 4.34.1, and each one meant to fail is checked to fail, as described above.
* '''Recent figures dated.''' Figures that change, such as the size of Mathlib or the state of a project, are given as of the date on which their source was read, and the citation carries that date. In all, 92 citations carry a date of reading.
* '''Versions named.''' A citation of the manual names its edition, and a citation of Lean's source names its tag.

== Known gaps ==

* '''Closed or refused.''' No open copy was found of Gödel (1931), Diaconescu (1975), Goodman and Myhill (1978), Goldfarb (1981) or Paulin-Mohring (1993). The ''Nature'' article is behind a paywall. The ACM refused automated access to its award pages, and the journal's copies of Curry (1934) could not be fetched.
* '''Undated web pages.''' Of the cited web pages, 21, among them project descriptions, README files, pages of the Lean Kernel Arena and pages of Lean's API documentation, have neither a version nor a date of reading in their citations. They describe things that change, and the citation does not say which state of the page was read.
* '''Addresses marked "latest".''' The citations at such addresses, described under Versions, will show other text as Lean moves on.
* '''Two editions of the manual.''' Six explainers cite the edition for 4.35.0 while the pages describe 4.34.1. The comparison above found no claim that depends on the difference, but the citations do not name the version described.
* '''Two versions of one paper.''' Carneiro's Lean4Lean paper was read in two versions of its arXiv text, and is cited both in that form and in its published form.
* '''Forms of citation.''' One work is sometimes cited in different forms on different pages. The [[Lean theorem prover/Bibliography|Bibliography]] gives one form for each and notes the differences that matter.

== What would close the gaps ==

'''For the closed papers.''' Read the five papers in a library, and the ''Nature'' article in full. Each would confirm a date or an attribution. None would change what the pages say about Lean.

'''For the versions.''' Cite the edition for 4.34.0 on the six explainers, and an edition by number in place of each address marked "latest", so that every citation of the manual names the version the pages describe. Read Lean4Lean once, in one version, for every page that cites it.

'''For the web pages.''' Give each undated citation of a changing page the date on which it was read, or a versioned address where one exists.

== Next ==

* [[Lean theorem prover/Bibliography|Bibliography]]

== References ==

<references />

Lean theorem prover/Notation

2026-10-15T19:35:49Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Notation}}
{{Lean theorem prover map}}
This page fixes the notation used across the edition. The Foundations pages write the rules
of Lean's type theory in the notation of the type-theory literature, inside formulas. Lean
writes many of the same things in its own syntax, inside code. The tables set the two side by
side, with a one-line meaning and the page on which each first appears in the reading order;
where the formula and the Lean syntax first appear on different pages, both are named. A dash
means that the notation has no counterpart on that side.

The formulas follow Carneiro's presentation of Lean's type theory, as
[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
explains; the Lean syntax is that of Lean 4.34.1.

== Judgments and rules ==

A '''judgment''' is a statement about the theory, made by its rules; it is not a proposition
inside Lean, and Lean has no syntax for asserting one. Lean shows judgments in what it prints:
<code>#check</code> prints <code>e : A</code>, and the display of a goal lists a context above
<code>⊢</code>.

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>\Gamma</math> || the lines above <code>⊢</code> in a goal || a '''context''': variables with their types, <math>x_1 : A_1, \ldots, x_n : A_n</math>, each type may mention the variables before it || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\vdash</math> || <code>⊢</code> || in a formula, "derives"; in a goal, it separates what may be used, above, from what must be shown, after it || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; goal: [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]]
|-
| <math>\Gamma \vdash e : A</math> || <code>e : A</code>, as <code>#check e</code> prints it || the '''typing judgment''': in the context <math>\Gamma</math>, the term <math>e</math> has type <math>A</math> || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\Gamma \vdash e \equiv e'</math> || – || '''definitional equality''': <math>e</math> and <math>e'</math> are equal by computation and unfolding, with no proof; Lean tests it when it checks <code>rfl</code> || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>e \Leftrightarrow e'</math> || – || Carneiro's '''algorithmic definitional equality''', the relation the Lean kernel's test decides; it implies <math>e \equiv e'</math> || [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]]
|-
| <math>\Gamma\ \mathrm{ok}</math>, <math>\cdot</math> || – || the context is well formed; the empty context || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\frac{J_1 \qquad J_2}{J}</math> || – || an '''inference rule''': from the judgments above the line, the one below || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>B[a/x]</math> || – || <math>B</math> with <math>a</math> put in place of the variable <math>x</math> || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|}

== Functions, types and universes ==

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>(x : A) \to B</math>, <math>\Pi x : A.\, B</math>, <math>\prod_{a \in A} B(a)</math> || <code>(x : A) → B</code>, <code>∀ x : A, B</code> || '''dependent function type''': functions whose result type <math>B</math> may mention the argument <math>x</math>; Lean prints it with <code>∀</code> when <math>B</math> is a proposition || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]], <math>\Pi</math> at [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]]; Lean: [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]]
|-
| <math>A \to B</math> || <code>A → B</code> || function type, when <math>B</math> does not mention the argument; implication, when <math>A</math> and <math>B</math> are propositions || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| <math>\lambda x : A.\, e</math> || <code>fun (x : A) => e</code>, also written <code>fun x ↦ e</code> or <code>λ x => e</code> || '''function abstraction''': the function sending <math>x</math> to <math>e</math> || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; Lean: [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <math>f\,a</math> || <code>f a</code> || application of <math>f</math> to <math>a</math> || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\mathrm{let}\ x : A := v;\ e</math> || <code>let x : A := v; e</code> || a local definition || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\mathrm{Sort}\,u</math> || <code>Sort u</code> || the '''universe''' at level <math>u</math>, the type of the types at that level || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; Lean: [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]]
|-
| <math>\mathrm{Sort}\,0</math> || <code>Prop</code> || the universe of propositions || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| <math>\mathrm{Sort}\,(u+1)</math> || <code>Type u</code>; <code>Type</code> is <code>Type 0</code> || the universes of data || [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]]
|-
| <math>\mathrm{U}_u</math> || – || Carneiro's name for the universe written <math>\mathrm{Sort}\,u</math> in this edition || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\mathrm{imax}\,u\,v</math> || <code>imax u v</code> || the level of a function type: <math>0</math> if <math>v = 0</math>, otherwise <math>\max(u, v)</math> || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; Lean: [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]
|-
| <math>c.\{\bar u\}</math> || <code>c.{u}</code> || the constant <math>c</math> used at the universe levels <math>\bar u</math> || formula: [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; Lean: [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]]
|-
| – || <code>{x : A}</code>, <code>[C A]</code> || an '''implicit''' argument, filled in by unification; an '''instance-implicit''' argument, filled in by instance resolution || [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]]; explained at [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]]
|-
| – || <code>⟨a, b⟩</code> || the '''anonymous constructor''': a value of a type with one constructor, such as a pair or a proof of <code>p ∧ q</code> || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| – || <code>A × B</code> || the type of pairs || [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]]
|-
| <math>\Sigma x : A.\, B</math> || <code>(x : A) × B</code>, <code>Σ x : A, B</code> || '''dependent pair''': pairs whose second part has a type that depends on the first || named at [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]; no page writes the symbol
|-
| <math>\mathrm{Nat.rec}</math> || <code>Nat.rec</code> || the '''recursor''' of the natural numbers, at once induction and primitive recursion || formula: [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]; Lean: [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]]
|-
| <math>\prec</math>, <math>\mathrm{Acc}\;x</math> || <code>WellFounded</code>, <code>Acc</code> || a well-founded relation; the proposition that <math>x</math> is accessible, the basis of well-founded recursion || [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]
|}

In Lean the dependent function type, function abstraction and the dependent pair are written
as in the second column; the reference manual gives the full syntax, including <code>↦</code>
in place of <code>=></code>.<ref name="rm-fun-terms">''The Lean Language Reference'', for Lean
4.34.0, lean-lang.org, 2026, section 13.3, "Functions". https://lean-lang.org/doc/reference/4.34.0/Terms/Functions/</ref><ref name="rm-fun-types">''The
Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.1, "Functions".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Functions/</ref> Each line below
is accepted by Lean 4.34.1:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : Sort 0 = Prop := rfl
example : Sort 1 = Type := rfl
example : Type 1 = Sort 2 := rfl
example : (fun (x : Nat) => x + 1) 2 = 3 := rfl
example : (fun (x : Nat) ↦ x + 1) 2 = 3 := rfl
example : (λ (x : Nat) => x + 1) 2 = 3 := rfl
def pair : (n : Nat) × Fin (n + 1) := ⟨2, 0⟩
def pair' : Σ n : Nat, Fin (n + 1) := ⟨2, 0⟩

#check ∀ x : Nat, x = x
#check (x : Nat) → Fin (x + 1)
#check Nat → Nat
#check fun (x : Nat) => x + 1
#check (Σ n : Nat, Fin (n + 1))
</pre>

The five <code>#check</code> lines print:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
∀ (x : Nat), x = x : Prop
(x : Nat) → Fin (x + 1) : Type
Nat → Nat : Type
fun x => x + 1 : Nat → Nat
(n : Nat) × Fin (n + 1) : Type
</pre>

The same dependent function type is printed with <code>∀</code> when its result is a
proposition and with <code>→</code> otherwise, and Lean prints a dependent pair written with
<code>Σ</code> in the form <code>(n : Nat) × …</code>.

== Logic ==

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>\forall x\, \phi</math> || <code>∀ x : A, P x</code> || for every <math>x</math>; a dependent function type into <code>Prop</code> || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]]
|-
| <math>\exists x\, \phi</math> || <code>∃ x : A, P x</code>, the type <code>Exists</code> || there is an <math>x</math>; proved by a witness and a proof, <code>⟨w, h⟩</code> || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]]
|-
| – || <code>p ∧ q</code>, the type <code>And</code> || and || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| <math>p \lor q</math> || <code>p ∨ q</code>, the type <code>Or</code> || or || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| <math>\neg p</math> || <code>¬p</code>, defined as <code>p → False</code> || not || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <math>a \leftrightarrow b</math> || <code>p ↔ q</code>, the type <code>Iff</code> || if and only if || [[Lean theorem prover/Foundations/The three axioms|The three axioms]]
|-
| <math>\mathrm{True}</math>, <math>\mathrm{False}</math> || <code>True</code>, <code>False</code> || the proposition with one proof, and the one with none || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: <code>True</code> at [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]], <code>False</code> at [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]]
|-
| <math>\neq</math> || <code>a ≠ b</code>, meaning <code>¬(a = b)</code> || not equal || formula: [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; Lean: [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]]
|}

Each of these proofs is accepted by Lean 4.34.1; the last shows that <code>¬p</code> is
<code>p → False</code> by definition:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (p q : Prop) (hp : p) (hq : q) : p ∧ q := ⟨hp, hq⟩
example (p q : Prop) (hp : p) : p ∨ q := Or.inl hp
example (p q : Prop) (h : p → q) (hp : p) : q := h hp
example (p q : Prop) : p ∧ q ↔ q ∧ p := ⟨fun ⟨a, b⟩ => ⟨b, a⟩, fun ⟨a, b⟩ => ⟨b, a⟩⟩
example : ∀ n : Nat, n + 0 = n := fun _ => rfl
example : ∃ n : Nat, n + 2 = 5 := ⟨3, rfl⟩
example : (2 : Nat) ≠ 3 := by decide
example (p : Prop) : (¬p) = (p → False) := rfl
</pre>

== Equality ==

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>a = b</math> || <code>a = b</code>, the type <code>Eq a b</code> || '''propositional equality''': a proposition, whose proofs are terms || formula: [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]; Lean: [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <math>e \equiv e'</math> || – || definitional equality, the judgment above || [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
|-
| <math>\mathrm{Eq.refl}\,a</math> || <code>rfl</code>, <code>Eq.refl a</code> || the one constructor of equality: a proof of <math>a = a</math> || formula: [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]; Lean: [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]]
|-
| <math>\mathrm{Eq.rec}</math> || <code>Eq.rec</code> || the eliminator of equality: what holds of <math>a</math> holds of <math>b</math> when <math>a = b</math> || [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]
|-
| – || <code>h ▸ e</code> || '''substitution''': <math>e</math> carried along a proof <code>h : a = b</code> || [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]
|-
| – || <code>a ≍ b</code>, the type <code>HEq a b</code> || '''heterogeneous equality''', between terms whose types may differ || [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]
|-
| <math>\mathrm{Quot}\,r</math>, <math>\mathrm{Quot.mk}\,r\,a</math> || <code>Quot r</code>, <code>Quot.mk r a</code> || the quotient of a type by a relation <math>r</math>, and the element of it that <math>a</math> gives || formula: [[Lean theorem prover/Foundations/Quotient types|Quotient types]]; Lean: [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]
|}

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (a b : Nat) (h : a = b) (P : Nat → Prop) (hp : P a) : P b := h ▸ hp
example (n : Nat) (x : Fin n) : x ≍ x := HEq.rfl
#check @HEq
</pre>

Lean 4.34.1 accepts both and prints <code>@HEq : {α : Sort u_1} → α → {β : Sort u_1} → β → Prop</code>:
the two sides of <code>≍</code> may have different types.

== Holes and unification ==

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>?m</math> || <code>?m.12</code> || a '''metavariable''', a hole the elaborator has yet to fill || formula: [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]]; Lean: [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]]
|-
| <math>s =^{?} t</math> || <code>s =?= t</code> || a '''unification problem''': find values of the metavariables that make the two sides definitionally equal || [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]]
|}

== Metatheory ==

{| class="wikitable"
! in formulas !! in Lean !! meaning !! first used
|-
| <math>T \vdash \mathrm{Con}(S)</math> || – || the theory <math>T</math> proves that the theory <math>S</math> is consistent || [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]]
|-
| <math>\mathrm{ZFC}_n</math> || – || Zermelo–Fraenkel set theory with choice and <math>n</math> inaccessible cardinals || [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]]
|-
| <math>\mathrm{CIC}_n</math>, <math>\mathrm{Lean}_n</math> || – || the Calculus of Inductive Constructions, or Lean's type theory, with <math>n</math> universes || [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]]
|}

== Commands and keywords ==

{| class="wikitable"
! in Lean !! meaning !! first used
|-
| <code>example : A := e</code>, <code>theorem c : A := e</code>, <code>def c : A := e</code> || a term <code>e</code> of type <code>A</code>, unnamed, as a named theorem, or as a named definition || [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]]
|-
| <code>by</code> || the term that follows is to be built by tactics || [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]]
|-
| <code>rfl</code> || the proof of <code>a = a</code>; it closes a goal whose two sides are definitionally equal || [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]]
|-
| <code>sorry</code> || a placeholder for a missing proof, recorded as the axiom <code>sorryAx</code> || [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <code>#check e</code> || print the type of <code>e</code> || [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]]
|-
| <code>#print c</code> || print the definition of <code>c</code> || [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <code>#print axioms c</code> || list the axioms that <code>c</code> depends on || [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]]
|-
| <code>#eval e</code> || compute <code>e</code> and print the result || [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]]
|}

== Next ==

[[Lean theorem prover/Sources|Sources]], what was read for the edition.

== References ==

<references />

Lean theorem prover/Glossary

2026-10-15T19:35:48Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Glossary}}
{{Lean theorem prover map}}
Terms the pages of this edition define, each where it is first set out in bold, with the page that defines it and, where there is one, the page that explains it in plain language. The definitions here are short; the pages carry the working ones, with their sources. Symbols are on [[Lean theorem prover/Notation|the notation page]].

== A ==

'''Automated theorem prover.''' A program built to find proofs by itself, for statements in a restricted form, rather than to check proofs that a person supplies. See [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].

'''Automath.''' The formal language for mathematics, and the project around it, that N. G. de Bruijn designed at Eindhoven in the late 1960s; its checkers confirmed proofs written out in full. See [[Lean theorem prover/History/Automath|Automath]]; in plain language, [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].

'''Axiom.''' A constant of a given type that is simply postulated; when its type is a proposition, an assumed proof of it. Lean cannot check that an axiom is consistent, and <code>#print axioms</code> lists the axioms a theorem rests on. See [[Lean theorem prover/Foundations/The three axioms|The three axioms]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

'''Axiom K.''' Streicher's principle that every proof of <code>a = a</code> is <code>Eq.refl a</code>. It is equivalent to uniqueness of identity proofs, and in Lean it holds by definition. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].

== B ==

'''Beta reduction.''' The rule that applying a function abstraction to an argument substitutes the argument for the bound variable. It is one of the reductions that make up definitional equality.<ref name="gl-types">''The Lean Language Reference'', version for Lean 4.34.0, chapter 4, "The Type System". [https://lean-lang.org/doc/reference/4.34.0/The-Type-System/ lean-lang.org/doc/reference/4.34.0/The-Type-System/], consulted 14 October 2026.</ref> See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]] and [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].

'''Blueprint.''' A tool written by Patrick Massot that links a human-readable account of a proof, lemma by lemma, to its Lean counterparts, and draws their dependency graph with the progress of each. See [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]].

== C ==

'''Calculus of Inductive Constructions.''' The Calculus of Constructions extended with primitive inductive definitions. Coq, now Rocq, was named after it. See [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].

'''Comparator.''' A tool that checks a proposed proof against a theorem statement written beforehand in a trusted setting: it compiles the proof in a sandbox, exports it, replays the export with the Lean kernel or an independent checker, and confirms that exactly the stated theorems were proved. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

'''Condensed mathematics.''' The framework begun by Clausen and Scholze that proposes condensed sets in place of topological spaces in the foundations of mathematics. The theorem checked in the Liquid Tensor Experiment belongs to it. See [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].

'''Congruence closure.''' Grouping terms known to be equal, together with what follows from the rule that equal arguments give equal results. It is one of the methods of <code>grind</code>. See [[Lean theorem prover/System/Decision procedures|Decision procedures]].

'''Constructive logic.''' A logic in which a proof of "P or Q" must say which side holds, so that the law of the excluded middle is not available in general. Lean's logic without axioms is constructive. See [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]] and [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

'''Constructor.''' One of the rules that make the values of an inductive type. The values of the type are exactly those its constructors make. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]; in plain language, [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]].

'''Context.''' A list of variables with their types, each type able to mention the variables before it. A typing judgment is made in a context. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

'''Conversion rule.''' The typing rule that a term of type <math>A</math> also has every type definitionally equal to <math>A</math>. It is where computation enters typing. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

'''Course-of-values recursion.''' Structural recursion in which a call may use the results for any smaller argument, not only for the immediately smaller one. Lean provides it through the constructions <code>below</code> and <code>brecOn</code>. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

'''Curry–Howard correspondence.''' Another name for propositions as types, after two of the logicians who found it. See [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

== D ==

'''de Bruijn criterion.''' The requirement that a proof assistant's proofs can be checked independently by a small program, one that a person can inspect; named after N. G. de Bruijn. In Lean the small program is the Lean kernel. See [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]] and [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]] and [[Lean theorem prover/History/Automath|Automath]].

'''de Bruijn factor.''' The ratio between the size of a formal text and the size of the informal original it renders, both compressed. For the Automath translation of Landau's ''Grundlagen'' it is about 3.7. See [[Lean theorem prover/History/Automath|Automath]].

'''de Bruijn index.''' A number standing for a bound variable: the count of binders between the variable and the binder that introduces it. In Lean the nearest binder has index 0. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]] and [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].

'''<code>decide</code>.''' The tactic that proves a statement by finding a procedure that decides it and running it. It works when the statement has no unknowns and such a procedure is available. See [[Lean theorem prover/System/Decision procedures|Decision procedures]]; in plain language, [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].

'''Decision procedure.''' An algorithm that settles every question in a fixed class with yes or no. In Lean it is useful only when its yes comes with evidence the Lean kernel accepts. See [[Lean theorem prover/System/Decision procedures|Decision procedures]].

'''Default instance.''' An instance tried when a search for instances would otherwise fail without selecting one. It is why <code>fun x => x + 1</code> elaborates to a function on <code>Nat</code>. See [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]] and [[Lean theorem prover/System/Elaboration|Elaboration]].

'''Definitional equality.''' The equality that holds between two terms by computation and the unfolding of definitions, without proof. Lean's checker tests it for itself, and no proof records it.<ref name="gl-types" /> See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]]; in plain language, [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].

'''Delta reduction.''' The rule that a defined constant equals its definition.<ref name="gl-types" /> See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

'''Dependent function type.''' The type of functions whose result type may depend on the argument, written <code>(x : A) → B</code>; also called a dependent product or Π-type. It is the only kind of function type in Lean's core theory: ordinary function types, "for all" and implication are special cases. See [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]]; in plain language, [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]].

'''Dependent type.''' A type that depends on a value, such as the type of lists of a given length. See [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]] and [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

'''do-notation.''' Lean's syntax for writing programs that use a monad in an imperative style, with sequencing, mutable local variables, loops and early return. A <code>do</code> block is translated into an ordinary term. See [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].

== E ==

'''E-matching.''' Instantiating a theorem by matching its pattern against terms, up to the equalities known so far. It is one of the methods of <code>grind</code>. See [[Lean theorem prover/System/Decision procedures|Decision procedures]].

'''Elaboration.''' The step that turns what a person types into a fully explicit term of Lean's core type theory, supplying omitted arguments, instances, coercions and universe levels. The program that does it, the elaborator, need not be trusted, because its output goes to the Lean kernel. See [[Lean theorem prover/System/Elaboration|Elaboration]]; in plain language, [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]] and [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]].

'''elan.''' The toolchain manager, which installs versions of Lean and selects the one a project names. A toolchain is the set of programs and files for one version of Lean. See [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]].

'''Equational law.''' An identity that a binary operation may satisfy for all values of its variables, such as the commutative law. A magma is a set with one such operation and no further rules; one law implies another when every magma satisfying the first satisfies the second. See [[Lean theorem prover/Applications/The equational theories project|The equational theories project]].

'''Eta.''' For functions, the rule that <math>\lambda x.\, f\,x</math> equals <math>f</math>; for structures, the rule that a value equals the constructor applied to its fields. Both are part of Lean's definitional equality. See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]] and [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].

'''External checker.''' A second program, written separately, that reads a proof exported from Lean and checks it again. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]; in plain language, [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]] and [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].

== F ==

'''Function extensionality.''' The principle that functions giving equal results on every argument are equal. In Lean it is a theorem, proved from quotients. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

== G ==

'''Global choice.''' The axiom <code>Classical.choice</code>: from a proof that a type has a value, it gives a value of the type. See [[Lean theorem prover/Foundations/The three axioms|The three axioms]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

'''Goal.''' A statement still to be proved, with the hypotheses that may be used to prove it. In Lean's tactic framework each goal is a metavariable; the first in the list is the main goal. See [[Lean theorem prover/System/The tactic framework|The tactic framework]]; in plain language, [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]] and [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].

'''<code>grind</code>.''' A tactic that collects facts in one shared store and works on them with several methods at once, among them congruence closure, E-matching, case splits and solvers for arithmetic. See [[Lean theorem prover/System/Decision procedures|Decision procedures]]; in plain language, [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].

== H ==

'''Heterogeneous equality.''' An equality between terms whose types are not known to be definitionally equal, written <code>a ≍ b</code> in Lean 4.34.1. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].

'''Higher-order unification.''' Unification in which a metavariable stands for a function applied to arguments. It is undecidable in general, and decidable for patterns, in which a metavariable is applied only to distinct bound variables. See [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]].

'''Hygiene.''' The property of Lean's macros that a name a macro introduces cannot capture a name the user wrote, nor the reverse. It is implemented by macro scopes, which tag each name a macro introduces. See [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]].

== I ==

'''Implicit argument.''' An argument the caller does not write. An implicit argument is filled by unification; a strict implicit one likewise, but only once a later explicit argument is given; an instance-implicit one by instance resolution. See [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].

'''Impredicativity.''' The property of <code>Prop</code> that a proposition may quantify over all propositions, or over types at any level, and still be a proposition. Its opposite, predicativity, holds for the universes <code>Type u</code>. See [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]; in plain language, [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].

'''Index.''' An argument of an inductive family that may differ from one constructor to another; a parameter is fixed across the whole definition. In <code>a = b</code>, <code>b</code> is an index. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] and [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].

'''Induction hypothesis.''' In a proof by induction on the natural numbers, the assumption that the statement holds for <math>k</math>, used in the induction step to prove it for <math>k + 1</math>; the base case is the proof for 0. See [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]].

'''Inductive family.''' An inductive definition with indices, which defines a whole family of types at once. The notion is Dybjer's. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

'''Inductive type.''' A type whose values are exactly those made by its constructors. Apart from functions, universes and quotient types, which are built into Lean, every type in Lean is an inductive type or is defined from these. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]; in plain language, [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]].

'''Instance.''' A definition registered for a type class, which the elaborator finds by itself when a term needs it; for example, the definition that says how to add two values of given types. See [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]]; in plain language, [[Lean theorem prover/Explainers/When Lean says no|When Lean says no]].

'''Instance resolution.''' The search by which the elaborator finds instances, also called instance synthesis. Lean's is tabled. See [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].

'''Iota reduction.''' The rule that a recursor applied to a constructor reduces to the corresponding minor premise. It is part of definitional equality.<ref name="gl-types" /> See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] and [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

'''IR.''' The compiler's lower-level form of a definition, translated from LCNF, which Lean prints on request and which its interpreter runs. See [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].

== L ==

'''Lake.''' The tool that ships with every version of Lean for compiling Lean code and fetching what a project depends on; a project organised for it is a Lake package. It records the exact version of each dependency in the file <code>lake-manifest.json</code>. See [[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]]; in plain language, [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]].

'''Large elimination.''' Eliminating a proof of a proposition into any universe, so as to produce data. Lean allows it only when the proposition is a syntactic subsingleton. See [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].

'''Law of the excluded middle.''' The principle that every proposition is either true or false. It cannot be proved in Lean's logic without axioms; with choice and the two extensionality principles it can (Diaconescu's theorem). See [[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

'''LCNF.''' Lean Compiler Normal Form: the compiler's representation of a definition in A-normal form, in which every intermediate result is bound to a name. See [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].

'''Lean kernel.''' The type checker that decides whether a definition, theorem, axiom or inductive type may enter Lean's environment, its table of definitions and theorems. It is the small part of Lean that has to be trusted. It has no termination checker and performs no unification.<ref name="gl-kernel">''The Lean Language Reference'', version for Lean 4.34.0, section 2.3, "The Kernel". [https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/ lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/], consulted 14 October 2026.</ref> See [[Lean theorem prover/System/The Lean kernel|The Lean kernel]]; in plain language, [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]].

'''Lean Kernel Arena.''' A site that runs checkers for Lean on the same exported tests, some to be accepted and some to be rejected, and publishes the results. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]; in plain language, [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].

'''<code>lean4export</code>.''' A program that writes the constants of a Lean module, and everything they depend on, to a file of terms alone, for other checkers to read. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

'''Lean4Lean.''' A type checker for Lean 4 written in Lean by Mario Carneiro, parts of which have been proved correct against a formalisation of Lean's type theory. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]; in plain language, [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].

'''<code>leanchecker</code>.''' The program, part of the Lean toolchain, that replays every definition and theorem in compiled Lean files through the Lean kernel. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

'''Locally nameless.''' The representation of terms with de Bruijn indices for bound variables and names for free ones, which Lean uses. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

== M ==

'''Macro.''' A rule that rewrites one piece of syntax into another before it is given meaning. Macro expansion is interleaved with elaboration, and Lean's macros are hygienic. See [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]] and [[Lean theorem prover/System/Elaboration|Elaboration]].

'''Mathlib.''' The single library of mathematics formalised in Lean and maintained by its community, begun in 2017 for Lean 3 and later translated to Lean 4. See [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]] and [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].

'''Measure.''' A quantity that must be smaller at every recursive call, named with <code>termination_by</code>; it justifies a definition by well-founded recursion. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]; in plain language, [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]].

'''Metaprogram.''' A Lean program whose data is Lean itself: syntax, terms, goals and Lean's environment. Tactics and elaborators are metaprograms. See [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].

'''Metatheory.''' What can be proved about Lean's type theory rather than in it; chiefly its consistency, which has been proved, for the type theory of Lean 3, relative to set theory with inaccessible cardinals. See [[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].

'''Metavariable.''' A named hole in a term: a placeholder for a subterm not yet known, which may be filled only with a term whose free variables are in its local context. Metavariables are natural, synthetic or synthetic opaque, according to who may fill them. See [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]]; in plain language, [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]].

'''Monad.''' A type constructor, with operations for sequencing computations, that Lean uses to represent effects such as failure, state, input and output as values. See [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]].

'''Motive.''' The argument of a recursor that says what is produced, or proved, for each value. A recursor also takes one minor premise for each constructor, and the major premise, the value the recursion runs on. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

== N ==

'''<code>nanoda</code>.''' A checker for exported Lean proofs written in Rust, developed independently of Lean. See [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]; in plain language, [[Lean theorem prover/Explainers/Checking a proof again later|Checking a proof again later]].

'''Nested inductive type.''' An inductive type that occurs, in its own definition, as an argument of another inductive type, as in a tree whose nodes hold lists of subtrees. Lean's kernel accepts one by translating it into a mutual definition. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

== O ==

'''<code>omega</code>.''' The tactic for linear arithmetic over the integers and the natural numbers, after Pugh's omega test. See [[Lean theorem prover/System/Decision procedures|Decision procedures]]; in plain language, [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].

'''Opaque constant.''' A constant with a type and no definition that the Lean kernel may unfold. A <code>partial</code> definition enters the logic as one. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

== P ==

'''<code>partial</code>.''' A mark for a recursive definition whose termination is not proved: it is compiled as written, and enters the logic as an opaque constant. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

'''Pattern matching.''' Defining a function by one case for each constructor of its argument's type. Lean checks that every case is covered. See [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]].

'''Pre-definition.''' The form a recursive definition takes first, elaborated as if the core language had recursion. The compiler uses it, and termination analysis turns it into a non-recursive term for the Lean kernel. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

'''Proof assistant.''' A program that checks proofs written in a formal language, step by step, while a person writes them. A formal language is a notation with fixed rules for what counts as a statement and what counts as a valid step. See [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]].

'''Proof irrelevance.''' The rule that any two proofs of the same proposition are interchangeable. In Lean they are definitionally equal. The name goes back to the Automath project, in 1974. See [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]]; in plain language, [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

'''Proof object.''' A complete record of a proof, in which every step is explicit, that a small program can check. See [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].

'''Proof state.''' The list of goals at a point in a tactic proof. The proof is complete when the list is empty. See [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]] and [[Lean theorem prover/Explainers/Tactics|Tactics]].

'''Proposition.''' A statement. In Lean a proposition is a type in the universe <code>Prop</code>, and its values are its proofs. See [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]] and [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].

'''Propositional equality.''' The proposition <code>a = b</code>: an inductive family with a single constructor, whose proofs are terms. It differs from definitional equality, which the checker tests and no term records. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]]; in plain language, [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].

'''Propositional extensionality.''' The axiom <code>propext</code>: propositions that imply each other are equal. See [[Lean theorem prover/Foundations/The three axioms|The three axioms]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

'''Propositions as types.''' The correspondence under which a statement is a type and a proof of it is a value of that type. See [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

== Q ==

'''Quotient type.''' A type whose elements are those of an existing type, with every pair related by a given relation made equal. Quotients are primitive in Lean, with one axiom, quotient soundness (<code>Quot.sound</code>). See [[Lean theorem prover/Foundations/Quotient types|Quotient types]]; in plain language, [[Lean theorem prover/Explainers/What the axioms are|What the axioms are]].

== R ==

'''Ramified theory of types.''' The more elaborate of Russell's theories of types, set out in a paper of 1908. See [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].

'''Recursor.''' The constant Lean derives from an inductive definition, which is at once the type's induction principle and its means of primitive recursion; also called its recursion principle. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]; in plain language, [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]] and [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]].

'''Reducibility hint.''' The mark stored with every definition, <code>opaque</code>, <code>abbrev</code>, or <code>regular</code> with a definitional height, that decides which side Lean's kernel unfolds first when it compares two terms. See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

'''Reference counting.''' Lean's way of managing memory: each object counts the references to it and is freed when the count reaches zero. A value that is not shared may be changed in place, so code written as pure functions can run with updates in place. See [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].

'''Reflexivity.''' The principle that everything is equal to itself. The proof <code>rfl</code> proves an equation exactly when the two sides are definitionally equal. See [[Lean theorem prover/Explainers/Two kinds of equality|Two kinds of equality]].

'''Restricted elimination.''' The rule that a proof can be taken apart to produce data only when its proposition is a subsingleton. See [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]] and [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].

== S ==

'''Setoid.''' A type with a chosen relation and a proof that the relation is reflexive, symmetric and transitive; Lean's <code>Quotient</code> is the quotient by a setoid's relation. See [[Lean theorem prover/Foundations/Quotient types|Quotient types]].

'''<code>simp</code>.''' The simplifier: a tactic that rewrites the goal with the simp set, the theorems marked <code>@[simp]</code>, each read as an equation from left to right. See [[Lean theorem prover/System/Decision procedures|Decision procedures]]; in plain language, [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]].

'''Specification.''' A precise statement of what is required of a program or a value. A type can serve as one. See [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]] and [[Lean theorem prover/Applications/Software verification|Software verification]].

'''Strict positivity.''' The condition that the type being defined occur in the argument types of its constructors only to the right of every arrow, or as an argument of another inductive type. Lean's kernel enforces it, because a type breaking it would prove <code>False</code>. See [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

'''Structural recursion.''' Recursion in which every call is on a strict part of one fixed argument. Lean compiles it through the recursor, so no separate test of termination is needed. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]; in plain language, [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]].

'''Structure.''' An inductive type with exactly one constructor, whose arguments are called its fields. See [[Lean theorem prover/Explainers/Building things from constructors|Building things from constructors]].

'''Subject reduction.''' The property that a term which type-checks still type-checks after it is reduced. Lean's typing, with the algorithmic definitional equality that the Lean kernel checks, lacks it. See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

'''Subsingleton.''' A proposition that, by its shape, can have at most one proof. Subsingleton elimination is the permission such a proposition has to be eliminated into any universe. See [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]] and [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

'''Subtype.''' The type of the values of a given type that have a given property, written <code>{x : A // p x}</code>. Each of its values is a value together with a proof. See [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]].

'''Syntax quotation.''' Syntax written inside <code>`(...)</code>, used in a macro to match syntax or to produce it; antiquotations inside it are the holes. Each grammar rule belongs to a syntax category, such as <code>term</code>. See [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]].

'''Synthetic metavariable.''' A metavariable that unification avoids assigning, because another procedure, usually instance resolution, is responsible for it; the elaborator uses them for postponed work. A synthetic opaque metavariable is never assigned by unification; goals are of this kind. See [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] and [[Lean theorem prover/System/Elaboration|Elaboration]].

== T ==

'''Tabled typeclass resolution.''' Lean's method of instance resolution, which keeps a table from each subgoal to the solutions already found for it and reuses them. Its authors proposed it to remove the exponential cost of diamonds in a hierarchy of classes and the loops caused by cycles of instances. See [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].

'''Tactic.''' A program that constructs part of a proof term, acting on goals. The name is Milner's, from LCF: there a tactic was a function reducing a goal to subgoals, and tacticals combined tactics. See [[Lean theorem prover/System/The tactic framework|The tactic framework]] and [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]; in plain language, [[Lean theorem prover/Explainers/Tactics|Tactics]].

'''Term.''' Anything in Lean's type theory: a number, a function, a type, a proposition, a proof. In a proof written as a term, the term is an expression whose type is the statement. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]; in plain language, [[Lean theorem prover/Explainers/Tactics|Tactics]].

'''Total function.''' A function defined on every argument, which returns in finitely many steps. Lean's logic treats every function as total. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

'''Transport.''' Obtaining, from a proof of <code>a = b</code> and a term whose type mentions <code>a</code>, the same term at <code>b</code>. It is derived from the eliminator of equality. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].

'''Type class.''' A structure whose values, the instances, Lean finds by itself: a description of what a type must provide. See [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]]; in plain language, [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]].

'''Type inference.''' Computing a type for a term in a context. Type checking, by contrast, decides whether a term has a given type. Lean's kernel is built around inference. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

'''Typing judgment.''' The basic statement of the theory, <math>\Gamma \vdash e : A</math>: in the context <math>\Gamma</math>, the term <math>e</math> has type <math>A</math>. A term is well-typed when such a judgment can be derived for it. See [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

== U ==

'''Unification.''' The search for values of metavariables that make two terms definitionally equal. See [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]]; in plain language, [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]].

'''Uniqueness of identity proofs.''' The principle that any two proofs of <code>a = b</code> are equal. In Lean it holds by definitional proof irrelevance. See [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]].

'''Universe.''' A type whose members are types; also called a sort.<ref name="gl-universes">''The Lean Language Reference'', version for Lean 4.34.0, section 4.3, "Universes". [https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Universes/ lean-lang.org/doc/reference/4.34.0/The-Type-System/Universes/], consulted 14 October 2026.</ref> Lean's universes <code>Sort u</code> form a hierarchy without top, each a member of the next, with <code>Prop</code> at the bottom; they are not cumulative. See [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]; in plain language, [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].

'''<code>unsafe</code>.''' A mark that frees a definition from Lean's restrictions, at the price that only other unsafe definitions may use it and no theorem may. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

== W ==

'''Weak head normal form.''' The result of reducing a term at its head until no rule applies: a sort, a function type, an abstraction, a literal, a constructor application, or an application whose head cannot be unfolded or reduced. See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

'''Well-founded recursion.''' Recursion justified by a quantity, or a well-founded relation, that decreases at every call. A relation is well-founded when it has no infinite descending chain. See [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]; in plain language, [[Lean theorem prover/Explainers/Functions that always finish|Functions that always finish]].

== Z ==

'''Zeta reduction.''' The rule that a local definition equals its body with the defined value substituted.<ref name="gl-types" /> See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

== Next ==

* [[Lean theorem prover/Notation|Notation]]

== References ==

<references />

Lean theorem prover/Chronology

2026-10-15T19:35:46Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Chronology}}
{{Lean theorem prover map}}
A timeline of Lean and of the work it grew from, from Automath to October 2026.

Every entry is stated, with its source, on the page named in its last column, and this page
adds nothing to those pages. Dates are of first statement, first publication or first
version, as the entry says. The dates of Lean's versions are those of its version
notes.<ref name="relnotes">''The Lean Language Reference'', "Release Notes", list of versions
with their dates (read 14 October 2026). https://lean-lang.org/doc/reference/latest/releases/</ref>
Where a page gives two dates for one event, both are given here.

== Before Lean: 1966 to 2012 ==

{| class="wikitable"
! date !! event !! page
|-
| 1966 or 1967 || '''Automath''' conceived by N. G. de Bruijn at Eindhoven; his own accounts give 1966 and early 1967 || [[Lean theorem prover/History/Automath|Automath]]
|-
| Dec 1968 || De Bruijn presents the Automath language at the Symposium on Automatic Demonstration, Versailles; printed 1970 || [[Lean theorem prover/History/Automath|Automath]]
|-
| 1969 || Dana Scott devises the logic for computable functions that LCF is named after; his manuscript is published in 1993 || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1971 || Per Martin-Löf's first type theory, an unpublished preprint, with a type of all types || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1971 to 1976 || I. Zandleven writes most of Automath's checking programs || [[Lean theorem prover/History/Automath|Automath]]
|-
| 1972 || Jean-Yves Girard's thesis shows a type of all types contradictory; Martin-Löf replaces it by a universe of small types (paper published 1998) || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1972 || De Bruijn proposes writing bound variables as numbers, the '''de Bruijn indices''' Lean's terms still use || [[Lean theorem prover/History/Automath|Automath]]
|-
| May 1972 || Robin Milner's report on '''Stanford LCF''' || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| c. 1973 || Milner begins Edinburgh LCF: a protected type of theorems, and tactics || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| Jul 1973 || Martin-Löf at the Logic Colloquium, Bristol: a hierarchy of universes and an identity type; printed 1975 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1974 || The name '''proof irrelevance''' appears in an Automath report || [[Lean theorem prover/History/Automath|Automath]]
|-
| 1976 || L. S. van Benthem Jutting's translation of Landau's ''Grundlagen der Analysis'' into Automath, in a five-volume report; his thesis 1977, published 1979 || [[Lean theorem prover/History/Automath|Automath]]
|-
| 1978 || ML, the metalanguage of LCF, described at the Symposium on Principles of Programming Languages; Milner's paper on polymorphic type inference || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1979 || ''Edinburgh LCF'', by Gordon, Milner and Wadsworth || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1979 || Martin-Löf, "Constructive mathematics and computer programming", Hannover; the extensional theory; published 1982 || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1980 || De Bruijn's survey of the Automath project || [[Lean theorem prover/History/Automath|Automath]]
|-
| Jun 1980 || Martin-Löf's Padua lectures, published in 1984 as ''Intuitionistic Type Theory'' || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1983 to 1985 || The first type checker for the Theory of Constructions, mostly Gérard Huet's work || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| Jun 1984 || Coquand and Huet present a preliminary version of the calculus at Sophia-Antipolis || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 31 Jan 1985 || Thierry Coquand defends his thesis on the Theory of Constructions || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| c. 1985 || Cambridge LCF, by Lawrence Paulson; described in his book of 1987 || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1986 || Nuprl, a proof assistant for an extensional type theory, described in a book; Martin-Löf recasts his theory in a logical framework || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| May 1986 || '''The Calculus of Constructions''', under that name, in an INRIA report; in ''Information and Computation'' 1988 || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 1988 || Version 4.7 of the system later named Coq keeps its proof checker, the Constructive Engine, apart as a trusted core; HOL88 appears about the same year || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]], [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1989 || Inductive types added as primitives: the '''Calculus of Inductive Constructions''', by the Coq manual's date; the paper, presented at COLOG-88, is published in 1990 || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| end of 1989 || The system is named Coq, with version 5.1 || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 1991 || Milner receives the ACM Turing Award; the citation names LCF and ML || [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]
|-
| 1993 || Christine Paulin-Mohring sets out the rules of the Calculus of Inductive Constructions || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 1994 || ''Selected Papers on Automath''; the ALF proof editor || [[Lean theorem prover/History/Automath|Automath]], [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 1995 || Antonius Hurkens publishes a simplified form of Girard's paradox || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|-
| 2002 || Freek Wiedijk's new Automath checker checks the ''Grundlagen'' translation in 0.6 seconds || [[Lean theorem prover/History/Automath|Automath]]
|-
| 2007 || Ulf Norell's thesis designs and implements a new Agda || [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]
|}

== Lean 1 to Lean 3: 2013 to 2022 ==

{| class="wikitable"
! date !! event !! page
|-
| 2013 || '''Lean''' begun by Leonardo de Moura at Microsoft Research || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| 2013 || The ACM Software System Award goes to the team that first developed Coq || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 16 Jun 2014 || Lean 0.1, the first version || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| 2015 || '''"The Lean Theorem Prover (system description)"''', CADE-25, describing the version now called Lean 2 || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| 2016 || Maryna Viazovska proves that the <math>E_8</math> lattice gives the densest sphere packing in eight dimensions || [[Lean theorem prover/Applications/Research mathematics|Research mathematics]]
|-
| 20 Jan 2017 || Lean 3.0.0 || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| 2017 || Metaprogramming in Lean 3: tactics written in Lean itself || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| summer 2017 || '''mathlib''' begins, from the core library of Lean 3 || [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]]
|-
| 2018 || Work on Lean 4 begins || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 18 Jan 2019 || Lean 3.4.2, the last official version of Lean 3 || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| 2019 || Mario Carneiro's account of Lean's type theory || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 26 Dec 2019 || Lean 3.5.0c, the first version maintained by the community || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| Jan 2020 || "The Lean Mathematical Library", by the mathlib Community, at CPP in New Orleans || [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]]
|-
| 5 Dec 2020 || Peter Scholze sets the '''Liquid Tensor Experiment''' challenge || [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]]
|-
| early 2021 || Lean 4 made public || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 2021 || '''"The Lean 4 Theorem Prover and Programming Language"''', CADE-28 || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 2021 || The miniF2F benchmark of formal competition problems || [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]]
|-
| 28 May 2021 || The proof of Theorem 9.4, the one result Scholze had been worried about, is formalised || [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]]
|-
| Dec 2021 || Plan for porting mathlib, then over 700,000 lines, to Lean 4 with Mathport || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 14 Jul 2022 || The Liquid Tensor Experiment completed || [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]]
|}

== Lean 4: 2023 to October 2026 ==

{| class="wikitable"
! date !! event !! page
|-
| 24 May 2023 || Lean 3.51.1c, the last community version of Lean 3 || [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]
|-
| Jul 2023 || De Moura and Sebastian Ullrich found the '''Lean Focused Research Organization''' || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| 16 Jul 2023 || The port of mathlib to Lean 4 declared complete || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 8 Sep 2023 || '''Lean 4.0.0''', the first stable version; a new version about every month follows || [[Lean theorem prover/History/Lean 4|Lean 4]]
|-
| 9 Nov 2023 || Gowers, Green, Manners and Tao post their proof of the polynomial Freiman–Ruzsa conjecture in characteristic 2 || [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]]
|-
| 5 Dec 2023 || The formalisation of that proof is complete, three weeks after it began || [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]]
|-
| Dec 2023 || Start of the Fermat's Last Theorem project, by the Lean FRO's timeline; announced April 2024 || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]]
|-
| Mar 2024 || Sidharth Hariharan and Viazovska begin formalising the eight-dimensional sphere packing || [[Lean theorem prover/Applications/Research mathematics|Research mathematics]]
|-
| 2024 || HepLean, later part of Physlib, begins || [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]]
|-
| Jul 2024 || Google DeepMind reports that AlphaProof, with a second system for geometry, reached silver-medal standard at the International Mathematical Olympiad || [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]]
|-
| 25 Sep 2024 || Terence Tao proposes the '''equational theories project''' || [[Lean theorem prover/Applications/The equational theories project|The equational theories project]]
|-
| Oct 2024 || The Fermat project's research council fellowship begins, to run until September 2029 || [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]]
|-
| Dec 2024 || Kevin Buzzard reports the problem met in a 1965 paper on divided powers sorted out, and the Fermat project back on track || [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]]
|-
| 12 Mar 2025 || Version 9.0 of the Rocq Prover completes the renaming of Coq || [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]
|-
| 14 Apr 2025 || The equational theories project reaches its primary goal: all 22,028,942 implications decided || [[Lean theorem prover/Applications/The equational theories project|The equational theories project]]
|-
| 2025 || Lean receives the ACM SIGPLAN Programming Languages Software Award; the 2015 system description receives the CADE Skolem Award || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| Jul 2025 || Gifts of $5 million each to the Lean FRO and to Mathlib announced, with a Mathlib Initiative to be set up || [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]]
|-
| 14 Aug 2025 || Lean 4.22.0: a new compiler, and the <code>grind</code> tactic || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| Nov 2025 || AlphaProof's method published in ''Nature'' || [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]]
|-
| Dec 2025 || The equational theories project's paper, with 34 authors || [[Lean theorem prover/Applications/The equational theories project|The equational theories project]]
|-
| Feb 2026 || The formal proof of sphere packing in dimension 8 completed, its final stages by an autoformalisation model || [[Lean theorem prover/Applications/Research mathematics|Research mathematics]]
|-
| Jul 2026 || Microsoft's SymCrypt code verified in Lean is in preview versions of Windows || [[Lean theorem prover/Applications/Software verification|Software verification]]
|-
| 22 Jul 2026 || Lean 4.32.1 fixes a soundness bug in the Lean kernel open to malicious metaprograms || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| 25 Jul 2026 || A false "disproof" of the Collatz conjecture, exploiting a bug in the Lean kernel, is published || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| 28 Jul 2026 || The exploit reduced to a short proof of <code>False</code> and reported; Lean 4.32.2 fixes it || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| Aug 2026 || A dataset of Lean statements of 50 theorems from the ''Annals of Mathematics'' announced || [[Lean theorem prover/Applications/Research mathematics|Research mathematics]]
|-
| 4 Sep 2026 || Anthropic announces a machine-written formal proof of Fermat's Last Theorem || [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]]
|-
| Sep 2026 || The Lean FRO moves to six-month roadmaps, with independent checking planned as a routine step || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| 24 Sep 2026 || '''Lean 4.34.1''', the version with which this edition's code is checked || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| 12 Oct 2026 || Lean 4.35.0 || [[Lean theorem prover/History/Lean since 2023|Lean since 2023]]
|-
| Oct 2026 || This wiki's framework for testing physical hypotheses is being restated in Lean, with Lean 4.34.1 pinned || [[Lean theorem prover/Applications/Principia Machina|Principia Machina]]
|}

== Next ==

[[Lean theorem prover/Glossary|Glossary]], the edition's terms.

== References ==

<references />

Lean theorem prover/Applications/Principia Machina

2026-10-15T19:35:45Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Principia Machina}}
{{Lean theorem prover map}}
'''Principia Machina''' is this wiki's framework for testing physical hypotheses, restated in Lean 4. Its first version, [[The Principia Machina]], stays on the wiki as history; the second is being written as Lean definitions and theorems. This page describes the framework, and the reasons for the move, only as far as the wiki's own account, [[Principia Machina/Lean transition|the move to Lean]], states them, with that account's status as of 14 October 2026.<ref name="lt">"Principia Machina: the move to Lean", the page [[Principia Machina/Lean transition]] on this wiki, status as of 14 October 2026.</ref>

== The framework ==

The framework exists so that anyone can check a result afterwards. A piece of research starts from a sealed set of laws and assumptions. Its derivations show every step and count every assumption. Its results stand only while nothing contradicts them. AI agents may do much of the work without being trusted for it.<ref name="lt" />

Version 2 names its parts with words rather than three-letter codes:<ref name="lt" />
* the '''Starting Set''': the laws, assumptions, boundaries and constants a piece of research starts from;
* the '''Correspondence Table''': the dictionary between the Starting Set and what is measured;
* the '''Criteria Set''': the declared yardsticks and tests;
* the '''Research Assembly''': the three together, sealed;
* '''Custos''': the thin server extension that guards the wiki;
* the '''Calculator''': the one compiled program, <code>pcalc</code>.

Each of these words except Custos also names a part of the Lean sources, such as <code>Principia.StartingSet</code> for the Starting Set. The authority rules do not change: the Declarer declares each version and each admission, the Operator runs every action on the wiki and its host, no agent handles a secret, and nothing is deleted.<ref name="lt" />

== Why Lean ==

In version 1 three things were kept apart. The rules were written in prose. The computation existed in two hand-written copies, PHP for the server and Python for agents, which 6,786 test cases held identical. Many checks were left to a reader's judgement.<ref name="lt" />

Lean 4 is three things in one language: a precise way to state rules, a programming language that compiles to native programs, and a proof checker, the Lean kernel, which accepts a result only when it is proved.<ref name="lt" /><ref name="cade">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref> The account of the move pairs each aim of the framework with what Lean provides for it; among the pairs:<ref name="lt" />
* results anyone can check afterwards: the Lean kernel checks every proof, whoever wrote it;
* a sealed Starting Set: definitions and hypotheses, named in every statement that uses them;
* derivations that count every assumption: a proof cites each definition, lemma and hypothesis it uses, and Lean lists the axioms beneath it;
* checks the server runs, not a person: the same definitions compile to a program, the Calculator;
* AI agents who need not be trusted: the Lean kernel judges the proof, not its author.

== One Calculator for the server and every agent ==

Version 2 writes the rules once, as Lean definitions and theorems. The same sources compile to one program, the Calculator, which serves both the wiki's server and every agent. Version 1 needed a corpus of tests to show that its two calculators agreed; with one program the two sides agree by construction.<ref name="lt" />

Custos keeps what MediaWiki forces into PHP: its hooks, its API surface and its job queue, together with the forms, the meter and the page writes. Every computation is a call into the Calculator, and the program's digest is checked before each call.<ref name="lt" />

== The Lean kernel as the proof gate ==

The first version to be declared is to be the Principia Framework Specification 1.0.0 with the Calculator 1.0.0, and it must meet eight criteria. One of them is '''the proof gate''': nothing is accepted with an unfinished proof (<code>sorry</code>), a new axiom, <code>native_decide</code> or unsafe code, and a machine enforces this, not a reviewer. Another asks for key properties to be proved, at least these: every digest's input encoding is one-to-one; every zone and record survives a round trip through its text form; the yardstick rules never rank a refuted record above a sound one, never improve a rank for an added assumption, and never let a measurement strike a derivation; and the server's first three admission lanes are never refused for lack of budget.<ref name="lt" />

Version 1 had two check classes, INSPECTION and MECHANICAL. Version 2 adds a third, '''PROVED''': a property the Lean kernel has checked once, for every input. A derivation may take one of three forms, and the server records the highest form it actually checked:<ref name="lt" />

{| class="wikitable"
! Form !! Checked by !! Class recorded
|-
| <code>PROSE</code> || a person or an agent || INSPECTION
|-
| <code>STRUCTURED</code> || the Calculator || MECHANICAL
|-
| <code>KERNEL</code> || the Lean kernel || PROVED
|}

A form the server cannot yet check is recorded as prose, never as checked. Structured derivations come in the first version; derivations checked by the Lean kernel follow once a checker for them has been shown to run within the host's limits.<ref name="lt" />

== Specification pages from the sources ==

In version 1 the specification was prose, separate from the code that computed it. In version 2 the specification is the source code. The specification pages are generated from the same Lean sources as the Calculator, so the published rules and the program that applies them come from one text and cannot drift apart.<ref name="lt" />

== A small example ==

The account of the move solves a two-doors riddle twice, once in ordinary mathematics and once in Lean, and shows the whole Lean file.<ref name="lt" /> In a shortened form, two guards stand at two doors; one always tells the truth, the other always lies; and the strategy is to ask either guard whether the other would say the left door is safe, then take the right door on "yes" and the left on "no":

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Door where
| left
| right
deriving DecidableEq, Repr

inductive Guard where
| truthful
| liar
deriving DecidableEq, Repr

def Guard.other : Guard → Guard
| .truthful => .liar
| .liar => .truthful

def Guard.says : Guard → Bool → Bool
| .truthful, b => b
| .liar, b => !b

def safeIs (s d : Door) : Bool := decide (s = d)

def heard (g : Guard) (s : Door) : Bool :=
g.says (g.other.says (safeIs s .left))

def choose : Bool → Door
| true => .right
| false => .left

theorem choose_is_safe (g : Guard) (s : Door) : choose (heard g s) = s := by
cases g <;> cases s <;> rfl

#print axioms choose_is_safe
</pre>

The proof splits into the four worlds that cannot be told apart (which guard is asked, which door is safe) and checks each by computation. Lean 4.34.1 accepts it and prints <code>'choose_is_safe' does not depend on any axioms</code>. The account then changes the riddle, replacing the liar with a guard who lies or tells the truth by a hidden coin; Lean refuses the old theorem and names the four worlds in which the strategy fails, and a sharper statement is then proved.<ref name="lt" /> That cycle of a cheap, specific refusal followed by a revised hypothesis is what the framework wants from Lean.

== Where it stands ==

As of 14 October 2026, Phase 0 of seven, the development setup, is under way, and Phase 1 has begun beside it. No physics machinery has been ported yet, by design: Phase 0 ports one small part of version 1, the digest input encoding, as its test subject, and the port itself is the work of Phase 2.<ref name="lt" />

Phase 0 has pinned Lean 4.34.1; written a first Lean library holding the digest input encoding with three theorems, the Calculator <code>pcalc</code>, and a test runner over a first corpus of six cases, all passing; and set up the proof gate, an audit of the axioms behind every definition and theorem, with seven checked and no failures.<ref name="lt" />

The first test of Phase 1, T1, has run. Its outcome is that the Calculator is started as a command rather than inside a web request: one Calculator still serves both sides, and Custos calls it outside the web request rather than during it.<ref name="lt" />

Questions still open include whether to use core Lean or the Mathlib library, which brings real-number analysis at the cost of a large cache of compiled files, and how SHA-256 and Unicode normalisation are to be provided.<ref name="lt" /> The steps by which a sponsored AI agent is certified are carried over from version 1 and are to be built in Phases 3 to 5; no agent has yet been admitted, and only the Declarer admits.<ref name="lt" />

== What Lean does not do here ==

The account of the move states the limits as plainly as the gains.<ref name="lt" />
* '''Lean proves the model, not the world.''' If the definitions misread the situation, the theorems are true of the wrong one. Version 1's rule still holds: internal consistency is not veracity, and comparison with the world happens outside the proof.
* '''A proof checker is not a reviewer.''' It confirms that a proof proves its statement, not that the statement was the right one to make; see [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]].
* '''Real-number physics needs a library.''' Uncertainties and equations over the real numbers need Mathlib, which version 2 has not yet chosen; see [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]] and [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]].
* '''It costs more to write than to read.''' The riddle's prose solution is one paragraph; its Lean file is 133 lines with comments. The cost falls as definitions are reused.

== Next ==

* [[Lean theorem prover/Chronology|Chronology]], the dated events of the edition.
* [[Principia Machina/Lean transition|The move to Lean]], the full account, with the riddle worked step by step.

== References ==
<references />

Lean theorem prover/Applications/Physics in Lean

2026-10-15T19:35:44Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Physics in Lean}}
{{Lean theorem prover map}}
Physics is formalised in Lean less than mathematics, but the work has a library of its own, '''Physlib''', and a growing list of results. This page describes that library and its origins, a few results formalised so far, and what a Lean proof can and cannot say about physics. The plain-language companion is [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]].

== Physlib ==

Physlib is an open-source, community project to digitalise results from physics into Lean 4: definitions, theorems, lemmas and calculations, organised by area of physics and documented in physical terms. It is maintained under the Lean community and builds on Mathlib.<ref name="readme">The Physlib community, "Physlib: The Lean Physics Library", project description, read 14 October 2026. https://github.com/leanprover-community/physlib</ref>

It began in 2024 as '''HepLean''', a project to digitalise high energy physics, described by Joseph Tooby-Smith. His paper on it proposed four uses: making existing results easier to find, creating new results with automated and AI methods, reviewing papers for mathematical correctness, and new ways of teaching. It demonstrated the approach on CKM matrices in flavour physics, on local anomaly cancellation, and on Higgs physics.<ref name="heplean">Joseph Tooby-Smith, "HepLean: Digitalising high energy physics", ''Computer Physics Communications'' 308 (2025), 109457. doi:10.1016/j.cpc.2024.109457. arXiv:2405.08863</ref> The project was later renamed '''PhysLean''', and Physlib was formed by merging PhysLean with the quantum-information library Lean-QuantumInfo.<ref name="readme" /><ref name="site">Physlib, "About Physlib", project website, read 14 October 2026. https://physlib.io/about</ref>

As of October 2026 its main part is divided into areas that include classical mechanics, classical field theory, electromagnetism, relativity, quantum mechanics, quantum field theory, statistical mechanics, thermodynamics, condensed matter, cosmology, fluid dynamics, optics, particle physics and string theory, with a separate part for quantum information.<ref name="readme" />

The project states its own rules. It is for mainstream physics only; it is not tied to any one axiomatisation of physics, such as axiomatic quantum field theory, so that it can accommodate different starting points; and its content is reviewed for reuse and readability. Another part, PhyslibAlpha, has a lighter review so that larger contributions, including AI-generated ones, can come in more easily; even that review checks, among other things, that no axioms are added.<ref name="readme" />

== Some results ==

'''Index notation.''' Physicists write tensors with indices, as in <math>T^{\mu}{}_{\nu}</math>, and contract them by repeating an index. Tooby-Smith gave what he describes as the first formally verified implementation of this notation in Lean 4, built on ideas from category theory, so that calculations can be written in the form physicists use and still be checked.<ref name="index">Joseph Tooby-Smith, "Formalization of physics index notation in Lean 4", arXiv:2411.07667, November 2024. https://arxiv.org/abs/2411.07667</ref>

'''The generalised quantum Stein's lemma.''' This result in quantum hypothesis testing gives relative entropy an operational meaning in quantum resource theories. An earlier proof was found to have a gap, and Hayashi and Yamasaki gave a corrected one in 2024. Alex Meiburg, Leonardo A. Lessa and Rodolfo R. Soldati formalised that proof in Lean, drawing on topology, analysis and operator algebra; the formalisation exposed minor imprecisions, which they corrected, and led them to a more precise definition of a quantum resource theory.<ref name="stein">Alex Meiburg, Leonardo A. Lessa and Rodolfo R. Soldati, "A Formalization of the Generalized Quantum Stein's Lemma in Lean", arXiv:2510.08672, October 2025. https://arxiv.org/abs/2510.08672</ref>

== What a proof about physics says ==

A Lean theorem about physics is a theorem about a mathematical model. The small example below models an elastic collision of two bodies of equal mass on a line, in which the velocities are exchanged, and proves that momentum and kinetic energy are the same after the collision as before. It uses whole numbers because core Lean has no real numbers; those come from Mathlib.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
/-- Two bodies of equal mass on a line, by their velocities (whole numbers here). -/
structure Pair where
v₁ : Int
v₂ : Int

/-- The model of an elastic collision of equal masses: the velocities are exchanged. -/
def collide (p : Pair) : Pair := ⟨p.v₂, p.v₁⟩

def momentum (m : Int) (p : Pair) : Int := m * p.v₁ + m * p.v₂

/-- Twice the kinetic energy, to stay within whole numbers. -/
def twiceEnergy (m : Int) (p : Pair) : Int := m * (p.v₁ * p.v₁) + m * (p.v₂ * p.v₂)

theorem momentum_conserved (m : Int) (p : Pair) :
momentum m (collide p) = momentum m p := by
simp only [momentum, collide]
exact Int.add_comm _ _

theorem energy_conserved (m : Int) (p : Pair) :
twiceEnergy m (collide p) = twiceEnergy m p := by
simp only [twiceEnergy, collide]
exact Int.add_comm _ _

#print axioms momentum_conserved
</pre>

Lean 4.34.1 accepts both theorems and prints <code>'momentum_conserved' depends on axioms: [propext]</code>. What has been proved is that the model conserves both quantities. Whether real bodies exchange their velocities when they collide is a question for experiment, and Lean does not touch it. This wiki's [[Principia Machina/Lean transition|account of the move to Lean]] states the same rule for its own framework: Lean proves the model, not the world, and internal consistency is not veracity.<ref name="lt">"Principia Machina: the move to Lean", the page [[Principia Machina/Lean transition]] on this wiki, status as of 14 October 2026.</ref>

== What is within reach ==

Within reach are the parts of physics that are already mathematics: definitions, symmetries, conservation laws, exact calculations, and theorems about models whose mathematics Mathlib supports. Equations and uncertainties over the real numbers need Mathlib, which brings real analysis with it.<ref name="lt" /> Parts of physics whose mathematics is not settled are harder. A result that physicists derive by methods with no rigorous foundation cannot be proved in Lean until a foundation is chosen. Physlib, for its part, does not tie itself to any one axiomatisation.<ref name="readme" /> In every case the hardest step is the one Lean cannot check: whether the Lean definitions say what the physicist means. [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]] treats that problem in general.

This wiki's own framework for testing physical hypotheses is moving to Lean, with the choice of Mathlib still open;<ref name="lt" /> see [[Lean theorem prover/Applications/Principia Machina|Principia Machina]]. Its version 1 surveyed Lean, Mathlib and Physlib among physics tools on [[The Principia Machina/Tools/Physlib|a page of its own]].

== Next ==

* [[Lean theorem prover/Applications/Principia Machina|Principia Machina]], this wiki's framework and its move to Lean.
* [[Lean theorem prover/Explainers/Lean and physics|Lean and physics]], the plain-language companion.

== References ==
<references />

Lean theorem prover/Applications/Machine learning and theorem proving

2026-10-15T19:35:43Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Machine learning and theorem proving}}
{{Lean theorem prover map}}
Machine-learning systems now write Lean proofs, from competition problems to large formalisations of research mathematics. Lean's role in this work is that of the checker: a proof that the Lean kernel accepts is correct whoever, or whatever, wrote it. This page describes the benchmarks the field uses, the main results so far, why the check matters, and what it leaves open, chiefly whether the statement that was proved is the statement that was meant.

== Why a checker matters ==

A language model can write text that looks like a proof and is not. Read by a person, such output costs time to check and may still mislead. Written in Lean, the same output is either accepted by the Lean kernel or refused, and an accepted proof is correct relative to Lean's axioms and the stated theorem, whatever produced it. Microsoft's SymCrypt team states the arrangement plainly: AI agents help draft its proofs, Lean's small trusted kernel checks every one of them, and an agent's proof counts only if Lean accepts it.<ref name="symcrypt">Son Ho, Cédric Fournet, Antoine Delignat-Lavaud, Samuel Lee, Jason Fisher and Jessica Krynitsky, "Verifying Rust cryptography in SymCrypt, from standards to code", Microsoft Research Blog, 13 July 2026. https://www.microsoft.com/en-us/research/blog/verifying-rust-cryptography-in-symcrypt-from-standards-to-code/</ref> Kevin Buzzard has made the same point: when machine-written mathematics comes with Lean code, that code at least guarantees that the argument is correct, so a reader can be more confident that the time spent reading it is not wasted.<ref name="annals">Kevin Buzzard, "The Annals Challenge", ''Xena'' (blog), 13 August 2026. https://xenaproject.wordpress.com/2026/08/13/the-annals-challenge/</ref>

The check has a second use. Because Lean decides automatically whether a proof is correct, it can grade a learning system's attempts without a person, and a system can learn from its own verified successes; DeepMind's AlphaProof, described below, feeds the proofs it finds back into its training in this way.<ref name="dmblog" />

== Benchmarks ==

'''miniF2F''', published in 2021 by Kunhao Zheng, Jesse Michael Han and Stanislas Polu, is a set of 488 formal problem statements drawn from the AIME and AMC competitions, the International Mathematical Olympiad, and high-school and undergraduate courses. It was written for Metamath and Lean, with partial coverage of Isabelle and HOL Light, so that systems built on different provers could be compared.<ref name="minif2f">Kunhao Zheng, Jesse Michael Han and Stanislas Polu, "MiniF2F: a cross-system benchmark for formal Olympiad-level mathematics", International Conference on Learning Representations (ICLR), 2022. arXiv:2109.00110</ref>

'''LeanDojo''', by Kaiyu Yang and colleagues, is an open-source toolkit that extracts data from Lean and lets a program interact with Lean as a user would, step by step. Its benchmark contains 98,734 theorems and proofs from Lean's mathematical library, split so as to test whether a system can use library lemmas it never saw in training. With it the authors trained ReProver, a prover that retrieves relevant lemmas from the library before proposing a step.<ref name="leandojo">Kaiyu Yang, Aidan M. Swope, Alex Gu, Rahul Chalamala, Peiyang Song, Shixing Yu, Saad Godil, Ryan Prenger and Anima Anandkumar, "LeanDojo: Theorem Proving with Retrieval-Augmented Language Models", NeurIPS 2023 Datasets and Benchmarks Track. arXiv:2306.15626</ref>

== Competition mathematics ==

At the International Mathematical Olympiad of 2024, Google DeepMind's AlphaProof proved two algebra problems and one number theory problem, including the hardest problem of the contest, in Lean; a separate system, AlphaGeometry 2, solved the geometry problem. Together they scored 28 of 42 points, the standard of a silver medal. The problems were translated into formal language by hand, and some solutions took up to three days rather than the nine hours allowed to contestants.<ref name="dmblog">Google DeepMind, "AI achieves silver-medal standard solving International Mathematical Olympiad problems", 25 July 2024. https://deepmind.google/discover/blog/ai-solves-imo-problems-at-silver-medal-level/</ref> The method was published in ''Nature'' in November 2025: AlphaProof learns by reinforcement learning, in the manner of AlphaZero, from millions of problems that were translated into Lean automatically, and for the hardest problems it generates and learns from variants of the problem while solving it.<ref name="nature">Thomas Hubert, Rishi Mehta, Laurent Sartran, et al., "Olympiad-level formal mathematical reasoning with reinforcement learning", ''Nature'' 651, pp. 607–613, published online 12 November 2025. doi:10.1038/s41586-025-09833-y</ref>

At the 2025 Olympiad two companies announced results in Lean: ByteDance's Seed Prover, at silver-medal level or at gold with additional attempts, and Harmonic's system, at gold-medal level, both by their own accounts. Buzzard pointed out that the Olympiad set no rules for machine entrants, that the companies marked their own work, and that neither company said how the answers to the problems that ask for a value were given to its system.<ref name="imo2025">Kevin Buzzard, "AI at IMO 2025: a round-up", ''Xena'' (blog), 3 August 2025. https://xenaproject.wordpress.com/2025/08/03/ai-at-imo-2025-a-round-up/</ref>

== Research mathematics ==

By 2026 machine systems were completing large formalisations of research mathematics. The formal proof of sphere packing in dimension 8 was finished in February 2026, its final stages carried out by Math, Inc.'s autoformalisation model Gauss.<ref name="packing">Sidharth Hariharan, Christopher Birkbeck, Seewoo Lee, Ho Kiu Gareth Ma, Bhavik Mehta, Auguste Poiroux and Maryna Viazovska, "Progress in Formalizing Sphere Packing in Dimension 8", arXiv:2604.23468, April 2026. https://arxiv.org/abs/2604.23468</ref> In September 2026 Anthropic announced a complete formal proof of Fermat's Last Theorem, about 13 million lines of Lean written in some 11 days by agents of its model Claude, with mathematical input from people limited, by the company's account, to occasional high-level instructions.<ref name="anthropic">Anthropic, "Formalizing Fermat's Last Theorem", 4 September 2026. https://www.anthropic.com/research/formalizing-fermats-last-theorem</ref> Both are described on [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], and the second in full, with Buzzard's assessment of it, on [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]]. Not every project found language models useful: in the [[Lean theorem prover/Applications/The equational theories project|equational theories project]], automated theorem provers did most of the work, and on the hardest cases the participants found that language models offered nothing beyond what they could propose themselves.<ref name="etp">Matthew Bolan, Joachim Breitner, Jose Brox, et al. (34 authors, including Terence Tao), "The Equational Theories Project: Advancing Collaborative Mathematical Research at Scale", arXiv:2512.07087, December 2025, section 11. https://arxiv.org/abs/2512.07087</ref>

== What the check does not cover ==

'''What the proof rests on.''' A proof can be accepted because it assumes what it should prove. The command <code>#print axioms</code> lists every axiom a theorem depends on, so an assumption slipped in by the author shows up:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
/-- An assumption slipped in by whoever wrote the proof. -/
axiom shortcut : ∀ n : Nat, n * 0 = 1

theorem claimed (n : Nat) : n * 0 = 1 := shortcut n

#print axioms claimed
</pre>

Lean 4.34.1 accepts this and prints <code>'claimed' depends on axioms: [shortcut]</code>. A proof left unfinished with <code>sorry</code> is caught the same way: Lean warns, and the list shows <code>sorryAx</code>.

'''Whether the statement is the one meant.''' This is the harder limit. Lean checks that the proof proves the theorem as written; it cannot check that the theorem as written says what the problem meant. A mistyped hypothesis can make a theorem true for no interesting reason:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
/-- Intended: "a number below 10 is at most 9". The hypothesis was mistyped as `x < 0`,
which no natural number satisfies, so the theorem says nothing at all. -/
theorem vacuous (x : Nat) (h : x < 0) : x ≤ 9 := by
omega
</pre>

Lean accepts it without comment. Translating a problem into Lean is itself a source of such errors, and translation, Buzzard notes, is not uniquely determined by the problem. Olympiad problems that ask for a value raise a further difficulty: a system must not be allowed to answer "the value is whatever satisfies the condition", so the answer is usually supplied first and then proved, and that formal question has to be checked against the original.<ref name="imo2025" /> In May 2026 Buzzard judged that automatic formalisation could not yet reliably, on its own, formalise definitions correctly or state theorems idiomatically.<ref name="workshop">Kevin Buzzard, "Formalizing Fermat workshop", ''Xena'' (blog), 15 May 2026. https://xenaproject.wordpress.com/2026/05/15/formalizing-fermat-workshop/</ref> One remedy is to compare the proved statement with one written independently. The machine-written proof of Fermat's Last Theorem was checked in both of the ways described here: its announcement reports that it uses only Lean's three standard axioms, and that a comparison tool confirmed that the statement proved matches the one already in Mathlib.<ref name="anthropic" /> Buzzard ran the comparison again himself, and also had an AI agent list everything in the code that was neither a definition nor a proof, then inspected the roughly 100 lines it found, an approach he called not perfect.<ref name="beaten">Kevin Buzzard, "FLT: Anthropic has beaten me to it", ''Xena'' (blog), 4 September 2026. https://xenaproject.wordpress.com/2026/09/04/flt-anthropic-has-beaten-me-to-it/</ref>

'''The checker itself.''' The guarantee is only as good as the Lean kernel and the hardware and software it runs on; [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]] sets out that list, and [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]] treats the statement problem in general.

== Next ==

* [[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]].
* [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].

== References ==
<references />

Lean theorem prover/Applications/Teaching with Lean

2026-10-15T19:35:41Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Teaching with Lean}}
{{Lean theorem prover map}}
Lean is used to teach mathematical proof, the logic behind it, and programming. This page describes the main free materials, from a puzzle game for beginners to textbooks for undergraduates and researchers, and some university courses built on them. It also says what a proof checker adds to teaching and what it does not.

== What a proof checker gives a learner ==

A student writing a proof on paper waits for a teacher to mark it. A student writing a proof in Lean is answered at once: each step is accepted, or refused with the goal that is still open (see [[Lean theorem prover/Explainers/Holes and goals|Holes and goals]]). The checker never tires, and it does not accept a step because it looks plausible. It cannot tell a student whether a proof is well written or why it works; those remain the teacher's work.

== The Natural Number Game ==

The '''Natural Number Game''' is a browser game that teaches the first steps of proof in Lean. It starts from a definition of the natural numbers made from zero and a successor operation, and asks the player to prove facts about them in order: first that 2 + 2 = 4, then that <math>x + y = y + x</math>, and so on through a sequence of "worlds", each made of levels that are theorems.<ref name="nngsrc">Kevin Buzzard, Jon Eugster et al., ''Natural Number Game'', Lean 4 version, game text and credits. https://github.com/leanprover-community/NNG4</ref>

The game was written for Lean 3 by Kevin Buzzard and Mohammad Pedramfar. Its Lean 4 version is credited to Buzzard and Jon Eugster, on a game engine by Alexander Bentkamp, Eugster and Patrick Massot.<ref name="nngsrc" /> It runs on the Lean Game Server, which also hosts games maintained by other authors, among them a set theory game (Dan Velleman), a real analysis game (Alex Kontorovich) and ''Reintroduction to Proofs'' (Emily Riehl).<ref name="gameserver">Alexander Bentkamp, Jon Eugster et al., "Lean 4 Game", the source of the Lean Game Server: project description and list of hosted games, read 14 October 2026. https://github.com/leanprover-community/lean4game</ref>

A small piece in the game's style shows the idea. The natural numbers are defined from scratch, addition is defined by recursion on its second argument, and adding zero on the left then needs a proof by induction:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive MyNat where
| zero : MyNat
| succ : MyNat → MyNat

namespace MyNat

def add : MyNat → MyNat → MyNat
| a, zero => a
| a, succ b => succ (add a b)

/-- Adding zero on the right is the definition; on the left it needs induction. -/
theorem zero_add (n : MyNat) : add zero n = n := by
induction n with
| zero => rfl
| succ k ih => rw [add, ih]

end MyNat
</pre>

Lean 4.34.1 accepts it. A beginner who offers <code>rfl</code> as the whole proof is refused: Lean reports that the left-hand side, <code>zero.add n</code>, is not definitionally equal to the right-hand side, <code>n</code>. The definition of addition says nothing directly about <code>add zero n</code> while <code>n</code> is unknown. That refusal is the point at which induction is learned. The explainer [[Lean theorem prover/Explainers/Induction, as the machine sees it|Induction, as the machine sees it]] says more.

== Textbooks ==

The standard free books are published by the Lean community and the Lean developers.
* '''''Theorem Proving in Lean 4''''', by Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, with contributions from the community, teaches Lean's logic itself: dependent type theory, propositions and proofs, tactics, inductive types, structures, type classes and the axioms.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', online book, read 14 October 2026. https://lean-lang.org/theorem_proving_in_lean4/</ref>
* '''''Mathematics in Lean''''', by Avigad and Patrick Massot, teaches how to do mathematics with Mathlib, in chapters running from basic logic and number theory through structures, algebra and linear algebra to topology, differential calculus, and integration and measure theory.<ref name="mil">Jeremy Avigad and Patrick Massot, ''Mathematics in Lean'', online book, read 14 October 2026. https://leanprover-community.github.io/mathematics_in_lean/</ref>
* '''''Functional Programming in Lean''''', by David Thrane Christiansen, is a free book on Lean as a programming language, from its basics through type classes, monads and dependent types to proofs about programs and performance.<ref name="fpil">David Thrane Christiansen, ''Functional Programming in Lean'', online book, read 14 October 2026. https://lean-lang.org/functional_programming_in_lean/</ref>
* '''''Logic and Proof''''', written by Avigad, Lewis and van Doorn and adapted to Lean 4 by Hua, is an introduction to symbolic logic and mathematical proof. Its stated goals are that a reader learn to write clear proofs, to model deductive proof formally, and to use an interactive proof assistant.<ref name="lap">J. Avigad, J. Hua, R. Y. Lewis and F. van Doorn, ''Logic and Proof'', online textbook, Lean 4 edition, read 14 October 2026. https://leanprover-community.github.io/logic_and_proof/</ref>

== University courses ==

Two published course texts show Lean in use at different levels.
* '''''The Mechanics of Proof''''', by Heather Macbeth, was written for the course Math 2001 at Fordham University and is aimed at the early university level. It describes itself as a book about writing careful, rigorous proofs, and it is paired with Lean code throughout, with an appendix on moving on to mainstream Lean.<ref name="mop">Heather Macbeth, ''The Mechanics of Proof'', online book for Math 2001, Fordham University, 2022–2024. https://hrmacbeth.github.io/math2001/</ref>
* '''''Formalising Mathematics''''', by Kevin Buzzard, is the handbook for his course of that name at Imperial College London, aimed at students with some mathematical background, such as those in the final year of a mathematics degree. It teaches how to formalise mathematics in Lean using Mathlib, and includes a catalogue of basic tactics.<ref name="fm">Kevin Buzzard, ''Formalising Mathematics'', course handbook, Imperial College London, 2024 edition. https://www.ma.imperial.ac.uk/~buzzard/xena/formalising-mathematics-2024/</ref>

Courses are offered elsewhere too; this page lists only those whose published materials could be checked.

== How quickly mathematicians learn ==

The authors of the formalisation of perfectoid spaces reported that mathematicians without training in computer science can become proficient with a proof assistant within a short time.<ref name="perfectoid">Kevin Buzzard, Johan Commelin and Patrick Massot, "Formalising perfectoid spaces", in ''CPP 2020: Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs'', 2020, pp. 299–312. doi:10.1145/3372885.3373830. arXiv:1910.12320</ref> Buzzard hoped that his Fermat project would be a good source of smaller Lean projects for doctoral students in number theory who want to learn the language.<ref name="general">Kevin Buzzard, "A Lean formalisation of Fermat's Last Theorem" (the project's general information), written December 2023. https://github.com/ImperialCollegeLondon/FLT/blob/main/GENERAL.md</ref>

== What it does not teach ==

Lean checks that a proof is correct. It does not show which proof is clearest, and a proof written for Lean can be longer and harder to read than one written for people. Course texts such as Macbeth's present themselves as books about writing careful, rigorous proofs, with Lean as the companion that checks them.<ref name="mop" /> The gap between a proof that Lean accepts and a proof a reader understands is discussed in [[Lean theorem prover/Explainers/Checking instead of convincing|Checking instead of convincing]].

== Next ==

* [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].
* [[Lean theorem prover/Explainers/What a proof assistant does|What a proof assistant does]], for a reader starting from the beginning.

== References ==
<references />

Lean theorem prover/Applications/Software verification

2026-10-15T19:35:40Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Software verification}}
{{Lean theorem prover map}}
Because Lean is a programming language as well as a proof checker, the same file can hold a program, a precise statement of what the program should do, and a proof that it does it. This page describes three industrial uses of Lean for software: Amazon's Cedar policy language, Amazon's SampCert library for differential privacy, and Microsoft's verified cryptography in SymCrypt. For each it says what "verified" covers and what it does not, since the word means something different in each case.

== Specify, then prove ==

To verify a program is to prove that it meets a '''specification''', a precise statement of its intended behaviour. In Lean both the program and the specification are written as Lean definitions, and the claim that one meets the other is a theorem. The proof says nothing about any other program, and nothing about properties the specification leaves out. Two questions therefore come with every claim of verified software: which code was the proof about, and what does the specification say?

== Cedar ==

Cedar is a language for writing authorisation policies, developed at Amazon Web Services: rules that say which users may take which actions on which resources.<ref name="oopsla">Joseph W. Cutler, Craig Disselkoen, Aaron Eline, et al., "Cedar: A New Language for Expressive, Fast, Safe, and Analyzable Authorization", ''Proceedings of the ACM on Programming Languages'' 8 (OOPSLA1), 2024, pp. 670–697. doi:10.1145/3649835</ref> Its developers wrote executable models of Cedar's evaluator, authoriser and validator in Lean, and these models serve as Cedar's specification. They proved properties of the models, among them that a satisfied <code>forbid</code> policy always leads to a denial, that a request is denied when no <code>permit</code> policy is satisfied, that the order of the policies does not matter, that a policy accepted by the validator never produces a type error, and that every function terminates.<ref name="vgd">Craig Disselkoen, Aaron Eline, Shaobo He, et al., "How We Built Cedar: A Verification-Guided Approach", in ''Companion Proceedings of the 32nd ACM International Conference on the Foundations of Software Engineering (FSE Companion '24)'', 2024. doi:10.1145/3663529.3663854. arXiv:2407.01688</ref>

The shape of such a proof can be shown in a few lines. The block below is a toy authoriser in the same style, not Cedar's model: a request is allowed when some permit policy applies and no forbid policy does, and the theorem proves the first of the properties above for every list of policies and every request.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Effect where
| permit
| forbid
deriving DecidableEq

/-- A policy: its effect, and the requests it applies to. -/
structure Policy (Req : Type) where
effect : Effect
applies : Req → Bool

inductive Decision where
| allow
| deny
deriving DecidableEq, Repr

def satisfied {Req : Type} (e : Effect) (ps : List (Policy Req)) (r : Req) :
List (Policy Req) :=
ps.filter (fun p => p.effect == e && p.applies r)

/-- Allow when some permit policy applies and no forbid policy does. -/
def isAuthorized {Req : Type} (ps : List (Policy Req)) (r : Req) : Decision :=
if (satisfied .forbid ps r).isEmpty && !(satisfied .permit ps r).isEmpty
then .allow else .deny

/-- If any forbid policy applies, the request is denied. -/
theorem forbid_trumps_permit {Req : Type} (ps : List (Policy Req)) (r : Req)
(p : Policy Req) (hp : p ∈ ps) (hf : p.effect = .forbid) (ha : p.applies r = true) :
isAuthorized ps r = .deny := by
have hmem : p ∈ satisfied .forbid ps r := by
simp [satisfied, hp, hf, ha]
have hne : (satisfied .forbid ps r).isEmpty = false := by
cases h : satisfied .forbid ps r with
| nil => simp [h] at hmem
| cons _ _ => rfl
simp [isAuthorized, hne]

#print axioms forbid_trumps_permit
</pre>

Lean 4.34.1 accepts the proof and prints <code>'forbid_trumps_permit' depends on axioms: [propext]</code>, one of Lean's three standard axioms, which the simplifier used.

'''What is verified, and what is not.''' The proofs are about the Lean models. The code that runs in production is written separately, in Rust, for speed and for useful error messages among other reasons, and it is not proved correct. It is checked against the Lean model by '''differential random testing''': large numbers of generated inputs are given to both, and any difference in output is a bug in one of them. Parts of the Rust code that the model does not cover, such as the parser, are tested for properties instead.<ref name="vgd" /> The team reported running millions of such tests every night, and releasing a new version of Cedar only when the models, the proofs and the tests are all up to date.<ref name="awsblog">Kesha Hietala and Emina Torlak, "Lean Into Verified Software Development", AWS Open Source Blog, 8 April 2024. https://aws.amazon.com/blogs/opensource/lean-into-verified-software-development/</ref> The proofs found four bugs in the validator; the testing found 21 more in various parts of Cedar.<ref name="vgd" /> The Lean models, 1,673 lines in all, are about an order of magnitude smaller than their Rust counterparts; the proofs about them run to 5,714 lines.<ref name="vgd" />

== SampCert ==

'''Differential privacy''' is a mathematical guarantee that the published result of a computation reveals little about any one person in the data. It is usually achieved by adding carefully calibrated random noise. SampCert is a Lean library, with over 12,000 lines of proof that make heavy use of Mathlib, that formalises the theory of differential privacy in several of its variants, gives a framework for building and composing private mechanisms, and contains verified algorithms for sampling from the discrete Laplace and Gaussian distributions. Its authors write that it is used in the differential privacy offerings of Amazon Web Services.<ref name="sampcert">Markus de Medeiros, Muhammad Naveed, Tancrède Lepoint, Temesghen Kahsai, Tristan Ravitch, Stefan Zetzsche, Anjali Joshi, Joseph Tassarotti, Aws Albarghouthi and Jean-Baptiste Tristan, "Verified Foundations for Differential Privacy", ''Proceedings of the ACM on Programming Languages'' 9 (PLDI), 2025, pp. 1094–1118. doi:10.1145/3729294. arXiv:2412.01671</ref>

'''What is verified, and what is not.''' The samplers are written in a small probabilistic language inside Lean, and the proofs show that they produce the intended distributions. Running them needs code outside the proofs. One route compiles them through Lean's interface to C++, which adds five functions, 57 lines of C++, to what must be trusted; randomness comes from reading bytes from the operating system's random source, and the conversion of those bytes into uniform samples is itself written and verified in Lean. The authors point out that such external functions cannot make Lean's logic unsound, but that Lean gives no formal guarantee about the behaviour of the compiled program. The route used for deployment translates the samplers through the Dafny language into Python.<ref name="sampcert" /> The proofs therefore cover the algorithms; the translation, the C++ functions and the random source are trusted.

== SymCrypt ==

SymCrypt is Microsoft's cryptographic library. Its team now writes new implementations in Rust and verifies them in Lean with '''Aeneas''', a tool that translates Rust code into a pure functional model in Lean.<ref name="symcrypt">Son Ho, Cédric Fournet, Antoine Delignat-Lavaud, Samuel Lee, Jason Fisher and Jessica Krynitsky, "Verifying Rust cryptography in SymCrypt, from standards to code", Microsoft Research Blog, 13 July 2026. https://www.microsoft.com/en-us/research/blog/verifying-rust-cryptography-in-symcrypt-from-standards-to-code/</ref><ref name="aeneas">Son Ho and Jonathan Protzenko, "Aeneas: Rust verification by functional translation", ''Proceedings of the ACM on Programming Languages'' 6 (ICFP), 2022, pp. 711–741. doi:10.1145/3547647</ref> The first verified components are the key-encapsulation scheme ML-KEM and SHA-3, the standard family of functions that compute digests. A verified function is proved to refine a Lean specification written to follow the public standard: on inputs that meet stated preconditions, it returns what the specification returns. AI agents help draft specifications and proofs; a proof counts only when Lean accepts it, and a specification an agent helped to draft is audited by people. As of July 2026 the verified code was in preview versions of Windows.<ref name="symcrypt" />

'''What is verified, and what is not.''' The proofs are about the Lean model that Aeneas produces from the Rust code, so the faithfulness of that translation is trusted. Some low-level wrappers, such as those that expose platform instructions, are described by small, carefully reviewed Lean specifications rather than proved, and the project's dashboards list such trusted models and the remaining assumptions for developers.<ref name="symcrypt" /> The blog post does not claim proofs about timing or other side channels.

== What the three have in common ==

In each case Lean checks a proof about a model, and the link between the model and the code that runs is made by other means: testing in Cedar, a small trusted compilation layer in SampCert, an automatic translation in SymCrypt. That link and the specification itself are where the remaining risk lies. The general point is made in [[Lean theorem prover/Explainers/Types as specifications|Types as specifications]] and [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]].

== Next ==

* [[Lean theorem prover/Applications/Teaching with Lean|Teaching with Lean]].
* [[Lean theorem prover/Explainers/Programs and proofs in one language|Programs and proofs in one language]], on why one language can do both.

== References ==
<references />

Lean theorem prover/Applications/The equational theories project

2026-10-15T19:35:39Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The equational theories project}}
{{Lean theorem prover map}}
The '''equational theories project''' was an online collaboration, proposed by Terence Tao in September 2024, to settle every implication between 4,694 simple algebraic laws. It ended with all 22,028,942 implications decided, on the strength of proofs and refutations checked by Lean.<ref name="etp">Matthew Bolan, Joachim Breitner, Jose Brox, et al. (34 authors, including Terence Tao), "The Equational Theories Project: Advancing Collaborative Mathematical Research at Scale", arXiv:2512.07087, December 2025 (revised 16 December 2025). https://arxiv.org/abs/2512.07087</ref> It was also an experiment in how mathematicians, automated provers and a proof checker can share one piece of research. This page describes the question, the scale, the tools and the result.

== The question ==

A '''magma''' is a set with one binary operation, written here <math>x \diamond y</math>, and no further rules. An '''equational law''' is an identity that the operation may satisfy for all values of its variables: the commutative law <math>x \diamond y = y \diamond x</math> is one, the associative law another. One law '''implies''' another when every magma that satisfies the first also satisfies the second.<ref name="etp" />

Tao proposed the project on his blog on 25 September 2024. He suggested taking every law in which the operation appears at most four times, up to renaming of variables and the symmetry of equality, and finding out which of them imply which.<ref name="proposal">Terence Tao, "A pilot project in universal algebra to explore new ways to collaborate and use machine assistance?", ''What's new'' (blog), 25 September 2024. https://terrytao.wordpress.com/2024/09/25/a-pilot-project-in-universal-algebra-to-explore-new-ways-to-collaborate-and-use-machine-assistance/</ref> There are 4,694 such laws, so there are <math>4694 \times 4693 = 22{,}028{,}942</math> ordered pairs of distinct laws to decide. No algorithm can decide such implications in general, and even for short laws some known implications had needed long computer-assisted proofs. A second goal was added as the work went on: to decide the same implications for finite magmas only, where the answers can differ.<ref name="etp" />

== How it was done ==

Each claim had to be entered as Lean code, so that it could be checked mechanically rather than read by a moderator; the paper notes that review by people, as in earlier online collaborations, would not have scaled to over twenty million statements.<ref name="etp" /> Contributors claimed tasks from a shared dashboard, and every submission was checked automatically to compile.<ref name="etp" />

Two kinds of result were needed. An implication is proved by deriving the second law from the first. A non-implication is refuted by exhibiting a magma that satisfies the first law but not the second. Both kinds fit in a few lines of Lean. The block below defines a magma and states three laws, proves that the law <math>x = y \diamond z</math> implies that all elements are equal, and refutes the claim that commutativity implies associativity with a two-element magma, the operation "not both" on the truth values:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class Magma (G : Type) where
op : G → G → G

infixl:65 " ◇ " => Magma.op

def SingletonLaw (G : Type) [Magma G] : Prop := ∀ x y : G, x = y
def CommutativeLaw (G : Type) [Magma G] : Prop := ∀ x y : G, x ◇ y = y ◇ x
def AssociativeLaw (G : Type) [Magma G] : Prop := ∀ x y z : G, x ◇ (y ◇ z) = (x ◇ y) ◇ z
def CollapseLaw (G : Type) [Magma G] : Prop := ∀ x y z : G, x = y ◇ z

/-- An implication: the law x = y ◇ z forces every element to equal every other. -/
theorem collapse_implies_singleton (G : Type) [Magma G] (h : CollapseLaw G) :
SingletonLaw G := by
intro a b
calc a = a ◇ a := h a a a
_ = b := (h b a a).symm

/-- A refutation: on the two truth values, "not both" is commutative but not associative. -/
instance nand : Magma Bool where
op a b := !(a && b)

theorem commutative_not_implies_associative :
∃ (G : Type) (_ : Magma G), CommutativeLaw G ∧ ¬ AssociativeLaw G := by
refine ⟨Bool, nand, ?_, ?_⟩
· intro x y
cases x <;> cases y <;> rfl
· intro h
exact absurd (h true true false) (by decide)

#print axioms collapse_implies_singleton
#print axioms commutative_not_implies_associative
</pre>

Lean 4.34.1 accepts both theorems and reports that neither depends on any axioms. The project's own code worked the same way at scale, with a custom magma class and a command that generated each numbered law.<ref name="etp" />

Most of the work was done by machines, and most of the machine output was not trusted directly. Tao's proposal already named the automated prover Prover9 for implications and the model finder Mace4 for counterexamples, with their output to be converted into Lean.<ref name="proposal" /> In the event the project used several automated theorem provers, among them Vampire, and SAT solvers such as Kissat. For proofs found by Vampire, contributors implemented its inference steps as Lean tactics, so that each proof could be replayed and checked by Lean. Rules of order and of duality cut the work sharply: only 10,657 of the true implications needed a direct proof, the rest following from those.<ref name="etp" />

Large language models played a small part. They helped write code for the project's user interfaces and completed Lean code during formalisation, and in one case a chat model guessed a complete rewriting system for a law, which was then verified formally. For the hardest implications, the authors found that such models offered nothing beyond what the human participants could already propose.<ref name="etp" />

== The result ==

The project reached its primary goal on 14 April 2025. Counting each law's implication of itself, 8,178,279 of the 22,033,636 possible implications (37.12 per cent) are true and 13,855,357 (62.88 per cent) are false. Lean checked a generating set of 10,657 proofs and 586,925 refutations; the step from these to the whole graph, by transitivity and duality, is carried out by programs outside Lean, though the authors note that it could in principle be done inside it. Some refutations needed new constructions; the hardest single one took several months and just over 4,000 lines of Lean from several contributors.<ref name="etp" />

For finite magmas, all but two implications were settled, one and its mirror image under reversing the operation. The authors were unable to prove or refute that pair and tentatively conjecture that the implication is false.<ref name="etp" /> The work also turned up new structures. Finite magmas satisfying one of the laws, which the authors call weak central groupoids, have been observed always to have <math>n^2</math> or <math>2n^2</math> elements, a pattern they report without proof.<ref name="etp" />

The account of the project was posted in December 2025 as a paper with 34 authors.<ref name="etp" /> It reports the mathematics and also the organisation: how tasks were assigned, how automated output was turned into checked proofs, and how a proof checker let many people contribute to one result without each contribution being read by a person.

== What it showed ==

The project took the method of [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|the polynomial Freiman–Ruzsa formalisation]] to a far larger number of statements, citing that project as its precedent and automating the assignment of tasks that had been done by hand there.<ref name="etp" /> Lean's role was that of a common referee. A human proof, a proof replayed from an automated prover and a counterexample found by a SAT solver all entered on the same terms: they counted once Lean had checked them. What Lean cannot check is whether the laws were stated as intended, which is the subject of [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]].

== Next ==

* [[Lean theorem prover/Applications/Software verification|Software verification]], where the same checker is applied to programs.
* [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]], on what automated tactics can and cannot do.

== References ==
<references />

Lean theorem prover/Applications/The Fermat's Last Theorem project

2026-10-15T19:35:38Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The Fermat's Last Theorem project}}
{{Lean theorem prover map}}
The '''Fermat's Last Theorem project''' is a multi-author, open-source effort, led by Kevin Buzzard at Imperial College London, to formalise in Lean a proof of Fermat's Last Theorem.<ref name="readme">Kevin Buzzard et al., "Fermat's Last Theorem" (project page and README), Imperial College London, read 14 October 2026. https://imperialcollegelondon.github.io/FLT/ and https://github.com/ImperialCollegeLondon/FLT</ref> This page describes its aims, its method and its state as of October 2026, including the separate, machine-written formalisation of the theorem announced in September 2026.

== The theorem and the proof ==

Fermat's Last Theorem says that if <math>x, y, z, n</math> are positive integers and <math>n \ge 3</math>, then <math>x^n + y^n</math> never equals <math>z^n</math>. Fermat raised it in 1637; Andrew Wiles, assisted by Richard Taylor, settled it more than 350 years later. Although the statement is about counting numbers, every known proof uses much deeper mathematics: elliptic curves, modular forms, finite flat group schemes and Galois representations, among other things. Written out in full from the axioms, any known proof would run to several thousand pages.<ref name="general">Kevin Buzzard, "A Lean formalisation of Fermat's Last Theorem" (the project's general information), written December 2023. https://github.com/ImperialCollegeLondon/FLT/blob/main/GENERAL.md</ref>

== Aims ==

The project is funded by a fellowship from the Engineering and Physical Sciences Research Council, "Formalising Fermat" (EP/Y022904/1), worth £934,043, which runs from October 2024 to September 2029.<ref name="ukri">UK Research and Innovation, Gateway to Research, "Formalising Fermat", grant EP/Y022904/1, principal investigator Kevin Buzzard, Imperial College London. https://gtr.ukri.org/projects?ref=EP%2FY022904%2F1</ref> Buzzard announced it on the Lean community's blog in April 2024.<ref name="announce">Kevin Buzzard, "The Fermat's Last Theorem Project", Lean community blog, 30 April 2024. https://leanprover-community.github.io/blog/posts/FLT-announcement/</ref>

The first goal is not the whole theorem. It is to reduce Fermat's Last Theorem to claims that mathematicians knew by the end of the 1980s, which would then be assumed rather than proved.<ref name="announce" /> The grant's own summary puts the same aim another way: to formalise much of the mathematics of a modern proof, and so to reduce the task to formalising results from the 1980s.<ref name="ukri" />

Buzzard gave several reasons for the work. Many standard objects of modern number theory had not been defined in Lean or in any other theorem prover, so many recent results could not even be stated, let alone proved; the project would have to define them. Foundational material would go into Mathlib, Lean's mathematical library. And when he wrote, in December 2023, Fermat's Last Theorem was the one problem left unformalised on Freek Wiedijk's list of 100 challenge theorems for computer formalisation.<ref name="general" />

== Method ==

The proof being formalised is not Wiles's original. It is a modern variant of the Wiles and Taylor–Wiles argument that borrows heavily from the ideas of Khare and Wintenberger, and its route was planned almost entirely by Richard Taylor in discussions with Buzzard.<ref name="readme" /> At its heart is still the idea, proved by Wiles in crucial cases, that a certain deformation ring <math>R</math> is isomorphic to a Hecke algebra <math>T</math>.<ref name="general" />

The project is organised with a blueprint, the LaTeX map of the proof whose dependency graph shows which pieces are done, a method described on [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|the polynomial Freiman–Ruzsa conjecture]]. It works from both ends at once: down from the main theorem, stating the large claims to be assumed, and up from the basics, adding general material to Mathlib, with the aim of meeting in the middle.<ref name="general" />

Formalisation checks the literature as well as the proof. In 2024 the work on divided powers, on which the theory of crystalline cohomology relies, met a problem in the literature: a lemma in a 1965 paper by Norbert Roby appeared to be false, and the gap blocked a definition the project needed. Antoine Chambert-Loir and María Inés de Frutos-Fernández were formalising the theory; Chambert-Loir worked on a repair, and by December 2024 Buzzard reported the issues sorted out and the project back on track. In the same period Andrew Yang proved in Lean an abstract result of commutative algebra on which the <math>R = T</math> step depends.<ref name="going">Kevin Buzzard, "Fermat's Last Theorem — how it's going", ''Xena'' (blog), 11 December 2024. https://xenaproject.wordpress.com/2024/12/11/fermats-last-theorem-how-its-going/</ref>

In 2026 Buzzard gave a lecture course of eleven lectures on the proof's route, and announced a workshop in London for July 2026, funded by the company Logos Research, to find out which parts of the proof AI tools could formalise. In May 2026 he judged that such tools could not yet reliably formalise definitions correctly, or state theorems in the idiom of Mathlib, without help.<ref name="workshop">Kevin Buzzard, "Formalizing Fermat workshop", ''Xena'' (blog), 15 May 2026. https://xenaproject.wordpress.com/2026/05/15/formalizing-fermat-workshop/</ref>

== A complete formal proof by other means ==

On 4 September 2026 Anthropic announced a complete formal proof of Fermat's Last Theorem in Lean, produced, by its account, in about 11 days by dozens of instances of its model Claude working largely on their own on Prove2Me, a collaborative formalisation platform from Columbia University. The proof follows the 1995 exposition of Wiles's argument by Henri Darmon, Fred Diamond and Richard Taylor.<ref name="beaten" /> It is about 13 million lines of Lean, proves some 30,300 theorems of which about 29,500 are used in the final proof, rests only on Lean's three standard axioms, and adapts pieces of the Imperial project and of an earlier formalisation of the theorem for regular primes. A comparison tool confirmed that the statement proved matches Mathlib's own statement of Fermat's Last Theorem.<ref name="anthropic">Anthropic, "Formalizing Fermat's Last Theorem", 4 September 2026. https://www.anthropic.com/research/formalizing-fermats-last-theorem</ref>

Buzzard compiled the code and ran the comparison himself, and reported that it checks out; he also described the proof as gigantic, over 13.4 million lines that take nearly twenty times as long to compile as Mathlib. He noted that the formalisation follows the early literature and adds nothing new mathematically, and that it closes Wiedijk's list.<ref name="beaten">Kevin Buzzard, "FLT: Anthropic has beaten me to it", ''Xena'' (blog), 4 September 2026. https://xenaproject.wordpress.com/2026/09/04/flt-anthropic-has-beaten-me-to-it/</ref> Its route is the older one, not the modern proof the Imperial project follows.<ref name="beaten" /> In answer to readers who asked whether the program could have exploited a flaw in Lean, he described asking an AI agent to list everything in the code that was neither a definition nor a proof, and inspecting the roughly 100 lines it found, which he concluded only defined a convenience tactic; he added that this was not a perfect approach.<ref name="beaten" /> What the Lean kernel's check does and does not establish is the subject of [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]].

== State as of October 2026 ==

The machine-written proof goes further than the grant's first goal, since it proves the whole theorem rather than reducing it to the 1980s. Buzzard wrote that it does not discharge the project's other commitments: to add the fundamental objects of modern number theory to Mathlib, which is continuing, and to produce a document through which people can explore the modern proof.<ref name="beaten" /> The project page still describes the work as ongoing, led by Buzzard and funded until September 2029.<ref name="readme" />

== Next ==

* [[Lean theorem prover/Applications/The equational theories project|The equational theories project]], a collaboration on a different scale.
* [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]], for machine-written proofs in general.

== References ==
<references />

Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture

2026-10-15T19:35:36Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The polynomial Freiman-Ruzsa conjecture}}
{{Lean theorem prover map}}
The '''polynomial Freiman–Ruzsa conjecture''', also called '''Marton's conjecture''', is a statement in additive combinatorics about sets that are nearly closed under addition. In November 2023 W. T. Gowers, Ben Green, Freddie Manners and Terence Tao proved it in characteristic 2, and in about three weeks a group of volunteers led by Tao checked the proof in Lean. This page describes the result, how the checking was organised, and what it found.

== The statement ==

Take the strings of <math>n</math> bits, added place by place with 1 + 1 = 0; mathematicians write this space <math>\mathbb{F}_2^n</math>. For a set <math>A</math> of such strings, <math>A + A</math> is the set of all sums of two of its elements. If <math>A</math> is a subspace, adding gives nothing new and <math>A + A = A</math>. The conjecture says the converse holds in a robust form: if <math>A + A</math> is not much larger than <math>A</math>, then <math>A</math> is close to a subspace.

In the form Tao gave on his blog: if <math>|A + A| \le K|A|</math>, then <math>A</math> can be covered by at most <math>2K^{12}</math> translates of a subspace <math>H</math> with <math>|H| \le |A|</math>.<ref name="taoblog">Terence Tao, "On a conjecture of Marton", ''What's new'' (blog), 13 November 2023. https://terrytao.wordpress.com/2023/11/13/on-a-conjecture-of-marton/</ref> What matters is that the number of translates is bounded by a power of <math>K</math>; the best earlier bound, which Tao attributes to Konyagin, grew faster than any power.<ref name="taoblog" /> The conjecture connects a simple test on sums with algebraic structure, and it has links to areas such as coding theory and cryptography; ''Quanta Magazine'' reported that Gil Kalai had called it "a holy grail" of the field.<ref name="quanta">Leila Sloman, "'A-Team' of Math Proves a Critical Link Between Addition and Sets", ''Quanta Magazine'', 6 December 2023. https://www.quantamagazine.org/a-team-of-math-proves-a-critical-link-between-addition-and-sets-20231206/</ref>

== The proof ==

The paper "On a conjecture of Marton" was posted on 9 November 2023 and revised on 12 December 2023.<ref name="arxiv">W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "On a conjecture of Marton", arXiv:2311.05762, 9 November 2023 (revised 12 December 2023). https://arxiv.org/abs/2311.05762</ref> Its argument works with the entropy of random variables, in Shannon's sense, rather than with Fourier analysis, and it proceeds by induction on a doubling constant defined through entropy.<ref name="taoblog" /> It was published in the ''Annals of Mathematics'' in 2025.<ref name="annals">W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "On a conjecture of Marton", ''Annals of Mathematics'' 201 (2025), no. 2, pp. 515–549. doi:10.4007/annals.2025.201.2.5</ref> In April 2024 the same four authors extended the method to abelian groups of bounded torsion.<ref name="torsion">W. T. Gowers, Ben Green, Freddie Manners and Terence Tao, "Marton's Conjecture in abelian groups with bounded torsion", arXiv:2404.02244, 2 April 2024. https://arxiv.org/abs/2404.02244</ref>

== The formalisation ==

In his blog post of 13 November 2023 Tao wrote that he planned to formalise the paper in Lean 4.<ref name="taoblog" /> The project was started by Tao, Yaël Dillies and Bhavik Mehta, and less than a week after its launch a significant part of the paper was already formalised in full or in part.<ref name="tour">Terence Tao, "Formalizing the proof of PFR in Lean4 using Blueprint: a short tour", ''What's new'' (blog), 18 November 2023. https://terrytao.wordpress.com/2023/11/18/formalizing-the-proof-of-pfr-in-lean4-using-blueprint-a-short-tour/</ref> About 25 volunteers took part.<ref name="quanta" />

The work was organised with '''Blueprint''', a tool written by Patrick Massot. A blueprint is a human-readable LaTeX version of the proof in which each definition and lemma is linked to its Lean counterpart. From it the tool draws a dependency graph: lemmas appear as bubbles and definitions as rectangles, and the colours show progress. Green means fully formalised; blue means the statement is formalised and its proof is ready to be formalised. When a proof compiles, its author marks it done in the LaTeX by hand, since the tool does not check that mark itself.<ref name="tour" /> Tasks were handed out on the Lean community's chat forum: Tao posted threads of outstanding tasks, contributors claimed them first come, first served, and he kept the list up to date by hand.<ref name="etp">Matthew Bolan, Joachim Breitner, Jose Brox, et al. (34 authors, including Terence Tao), "The Equational Theories Project: Advancing Collaborative Mathematical Research at Scale", arXiv:2512.07087, December 2025, section 4.5. https://arxiv.org/abs/2512.07087</ref>

On 5 December 2023 Tao announced that the project had succeeded after three weeks: every node of the dependency graph was green, and Lean reported that the conjecture follows from the standard axioms.<ref name="mastodon">Terence Tao, post on Mathstodon, 5 December 2023. https://mathstodon.xyz/@tao/111526765350663641</ref> The formalisation found a few minor typos in the paper.<ref name="quanta" />

The final statement, as it stands in the project's Lean files, uses the Mathlib library and is shown here without its proof:<ref name="pfrsite">Terence Tao, Yaël Dillies et al., "The Polynomial Freiman-Ruzsa Conjecture" (project page, with blueprint and Lean source), read 14 October 2026. https://teorth.github.io/pfr/</ref>

<pre class="lean lean-mathlib" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem PFR_conjecture {G : Type*} [AddCommGroup G] [Module (ZMod 2) G]
{A : Set G} {K : ℝ} (hA₀ : A.Nonempty) (Afin : A.Finite)
(hA : (A + A).ncard ≤ K * A.ncard) :
∃ (H : Submodule (ZMod 2) G) (c : Set G), c.Finite ∧ (H : Set G).Finite ∧
Nat.card c < 2 * K ^ 12 ∧ (H : Set G).ncard ≤ A.ncard ∧ A ⊆ c + H := by
-- the proof follows in the project's files
</pre>

Read in words: <code>G</code> is any space of the kind described above, a vector space over the two-element field; <code>A</code> is a finite, nonempty set in it whose sum set has at most <code>K</code> times as many elements; then there are a subspace <code>H</code>, no larger than <code>A</code>, and a finite set <code>c</code> of fewer than <math>2K^{12}</math> shifts, such that <code>A</code> lies inside <code>c + H</code>. Every hypothesis is written out. The hypothesis that <code>A</code> is nonempty is one example: it was added to the Lean statement before it appeared in the blueprint's LaTeX.<ref name="tour" />

== After the main result ==

When the main goal was reached, a second stage formalised several consequences of the theorem and an argument of Jyun-Jie Liao that lowers the exponent from 12 to 11; the project page records that stage as complete, and names among the theorems its Lean files prove both the extension to groups of bounded torsion and a further refinement of Liao's that lowers the exponent to 9.<ref name="pfrsite" />

== What it showed ==

The blueprint divided a paper of some 35 journal pages<ref name="annals" /> into small nodes, each of which a contributor could take on without mastering the whole argument, while Lean checked that the pieces fitted together. In that arrangement the organisers did not need to trust a contribution, only Lean's verdict on it. The [[Lean theorem prover/Applications/The equational theories project|equational theories project]] cites this project as its precedent and automated the claiming of tasks that had been done by hand here.<ref name="etp" />

The formalisation did not change the mathematics; the errors it found were minor typos.<ref name="quanta" /> What it changed was the evidence: a reader who doubts the theorem can check the Lean proof instead of the paper.

== Next ==

* [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]], a far larger formalisation organised the same way.
* [[Lean theorem prover/Applications/Research mathematics|Research mathematics]], for other formalised results.

== References ==
<references />

Lean theorem prover/Applications/Research mathematics

2026-10-15T19:35:35Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Research mathematics}}
{{Lean theorem prover map}}
Since about 2019 working mathematicians have used Lean to formalise current research, not only textbook material. This page gives an overview: a few of the results that have been formalised, the reasons mathematicians give for doing it, and the limits of what it establishes. Three projects have pages of their own: [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|the polynomial Freiman–Ruzsa conjecture]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|the Fermat's Last Theorem project]] and [[Lean theorem prover/Applications/The equational theories project|the equational theories project]].

== The library underneath ==

Almost all of this work rests on '''Mathlib''', a single library of mathematics formalised in Lean and maintained by its community. Its authors describe it as built on dependent type theory, focused on classical mathematics, organised around a large hierarchy of structures, and run as a distributed, community project.<ref name="mathlib">The mathlib Community, "The Lean mathematical library", in ''Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (CPP 2020)'', 2020. arXiv:1910.09336. doi:10.1145/3372885.3373824</ref> A research project usually adds new definitions and theorems on top of it, and moves the general ones into it later. Its history is told in [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].

== Some formalised results ==

'''Perfectoid spaces.''' Peter Scholze introduced perfectoid spaces in 2012. Kevin Buzzard, Johan Commelin and Patrick Massot formalised enough topology, algebra and geometry in Lean to define them. Their point was that a proof assistant can handle the complexity of advanced definitions, not only long proofs about simple objects.<ref name="perfectoid">Kevin Buzzard, Johan Commelin and Patrick Massot, "Formalising perfectoid spaces", in ''CPP 2020: Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs'', 2020, pp. 299–312. doi:10.1145/3372885.3373830. arXiv:1910.12320</ref>

'''Liquid vector spaces.''' In December 2020 Scholze challenged the Lean community to check a theorem of his and Dustin Clausen's in the theory of condensed mathematics. The formalisation was completed on 14 July 2022.<ref name="lte">The mathlib community, "Completion of the Liquid Tensor Experiment", Lean community blog, 15 July 2022. https://leanprover-community.github.io/blog/posts/lte-final/</ref> The story is told in [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].

'''Sphere eversion.''' Massot, Floris van Doorn and Oliver Nash formalised the local h-principle for first-order, open, ample differential relations, a result of Gromov from 1973, and derived from it Smale's theorem that a sphere can be turned inside out through immersions. They took it as evidence that geometric mathematics, not only algebra, can be formalised.<ref name="eversion">Patrick Massot, Floris van Doorn and Oliver Nash, "Formalising the h-principle and sphere eversion", arXiv:2210.07746, October 2022. https://arxiv.org/abs/2210.07746</ref>

'''Carleson's theorem.''' Carleson's theorem says that the Fourier series of a continuous periodic function converges to it at almost every point. A team of 17 authors wrote a blueprint that reduces it to a new, more general theorem on doubling metric measure spaces due to harmonic analysts in Bonn, and proves that theorem.<ref name="carleson" /> Its final version, revised in August 2025, is presented as a guide to the accompanying Lean code.<ref name="carlesonbp">Lars Becker, María Inés de Frutos-Fernández, Leo Diedering, Floris van Doorn, Sébastien Gouëzel, et al., "A blueprint for the formalization of Carleson's theorem on convergence of Fourier series", arXiv:2405.06423, May 2024 (revised 6 August 2025). https://arxiv.org/abs/2405.06423</ref> The project's description states that the proof has been formalised and names the Lean theorems for the classical statement and for both general forms.<ref name="carleson">Floris van Doorn et al., "Formalization of a generalized Carleson's theorem" (project description, read 13 October 2026). https://github.com/fpvandoorn/carleson</ref>

'''Sphere packing in dimension 8.''' In 2016 Maryna Viazovska proved that the <math>E_8</math> lattice gives the densest packing of equal spheres in eight dimensions. In March 2024 Sidharth Hariharan and Viazovska began formalising the proof in Lean. The main result was formally verified in February 2026, with the final stages carried out by Gauss, an autoformalisation model of the company Math, Inc.<ref name="packing">Sidharth Hariharan, Christopher Birkbeck, Seewoo Lee, Ho Kiu Gareth Ma, Bhavik Mehta, Auguste Poiroux and Maryna Viazovska, "Progress in Formalizing Sphere Packing in Dimension 8", arXiv:2604.23468, April 2026 (revised May 2026). https://arxiv.org/abs/2604.23468</ref> EPFL reported in March 2026 that, after the team had written a detailed blueprint and progressively translated it into Lean, Gauss's help let the dimension 8 case be wrapped up in five days, and the considerably larger case of dimension 24 in two weeks.<ref name="epfl">EPFL, "Prof. Viazovska's proofs of sphere packing formalized with AI", EPFL news, March 2026. https://actu.epfl.ch/news/prof-viazovska-s-proofs-of-sphere-packing-formaliz/</ref>

== Why mathematicians do it ==

'''To settle a doubt.''' Scholze's liquid tensor challenge centred on one theorem in his notes with Clausen, the only result in them that he was worried about. The check confirmed the argument but found a few small gaps, all repairable, of the kind he had feared. He also reported that the work showed him why the argument works, which he had not understood when he set the challenge.<ref name="scholze">Peter Scholze, "Half a year of the Liquid Tensor Experiment: amazing developments", guest post on ''Xena'' (blog), 5 June 2021. https://xenaproject.wordpress.com/2021/06/05/half-a-year-of-the-liquid-tensor-experiment-amazing-developments/</ref>

'''To find errors in the literature.''' Formalisation cannot pass over a gap. The Fermat project found a lemma in a 1965 paper on divided powers that appeared to be false, and the gap had to be repaired before the work could go on.<ref name="flt">Kevin Buzzard, "Fermat's Last Theorem — how it's going", ''Xena'' (blog), 11 December 2024. https://xenaproject.wordpress.com/2024/12/11/fermats-last-theorem-how-its-going/</ref> In August 2026 a team led by Buzzard announced a dataset of Lean statements of 50 theorems published in the ''Annals of Mathematics'' in the 2020s. He reported that the work had already found several typos that made main theorems false as printed, four of them in papers by Fields medallists, and that each of those four was a missing hypothesis.<ref name="annals">Kevin Buzzard, "The Annals Challenge", ''Xena'' (blog), 13 August 2026. https://xenaproject.wordpress.com/2026/08/13/the-annals-challenge/</ref>

'''To collaborate without trusting every contributor.''' In the polynomial Freiman–Ruzsa and equational theories projects, people who had not read the whole argument contributed pieces, and Lean, not an organiser, decided whether each piece was correct.<ref name="etp">Matthew Bolan, Joachim Breitner, Jose Brox, et al. (34 authors, including Terence Tao), "The Equational Theories Project: Advancing Collaborative Mathematical Research at Scale", arXiv:2512.07087, December 2025. https://arxiv.org/abs/2512.07087</ref>

'''To be able to state modern mathematics at all.''' Buzzard's team stated the main theorems of about 20 per cent of the papers that the ''Annals'' has published since 2020. Many others mention objects, such as cuspidal automorphic representations, that Mathlib does not yet define, so their statements cannot be written in Lean until those definitions are built.<ref name="annals" /> The Fermat project gave the same gap as one of its reasons: many standard objects of modern number theory had not been defined in any theorem prover.<ref name="general">Kevin Buzzard, "A Lean formalisation of Fermat's Last Theorem" (the project's general information), written December 2023. https://github.com/ImperialCollegeLondon/FLT/blob/main/GENERAL.md</ref>

'''To check machine-written mathematics.''' Buzzard has argued that a proof which comes with Lean code at least guarantees that the argument is correct, so that a reader of AI-generated mathematics can be more confident that the reading is not wasted.<ref name="annals" /> The use of Lean as a checker for machine-generated proofs is the subject of [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].

== What it does not establish ==

A formal proof establishes that the Lean statement follows from Lean's axioms. It does not establish that the Lean statement says what the paper meant; that has to be read by people, and it is the hard part when the definitions are new. Buzzard concedes that formalisation by machine forgoes a gain that formalisation by hand has historically brought: teaching people new abstractions.<ref name="annals" /> Formalising a known proof need not add new mathematics either: Buzzard wrote of the machine-written proof of Fermat's Last Theorem that it follows the literature faithfully and adds nothing.<ref name="beaten">Kevin Buzzard, "FLT: Anthropic has beaten me to it", ''Xena'' (blog), 4 September 2026. https://xenaproject.wordpress.com/2026/09/04/flt-anthropic-has-beaten-me-to-it/</ref>

== Next ==

* [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman–Ruzsa conjecture]], a research result checked within weeks of its proof.
* [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]], on the limit named above.

== References ==
<references />

Lean theorem prover/History/Lean since 2023

2026-10-15T19:35:34Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Lean since 2023}}
{{Lean theorem prover map}}
Since 2023 Lean has been developed by a non-profit organisation set up for the purpose, with a new version roughly every month. This page covers that organisation, the versions and the automation added to them, the growth of the work done in Lean, and two flaws found in Lean's kernel in July 2026, with the response to them. It describes the state of things in October 2026.

== The Lean Focused Research Organization ==

In July 2023 Leonardo de Moura and Sebastian Ullrich launched the Lean Focused Research Organization (FRO), a non-profit within Convergent Research. It was supported at the start by the Simons Foundation International, the Alfred P. Sloan Foundation and Richard Merkin, and the Lean reference manual reports that it now has more than ten employees.<ref name="refhist">''The Lean Language Reference'', section 1.1 "History", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/Introduction/</ref> De Moura leads it as chief architect and Ullrich as head of engineering.<ref name="froabout">Lean FRO, "About" page, with its timeline "A Brief History of Lean" (read 14 October 2026). https://lean-lang.org/fro/about/</ref>

The FRO states its mission as improving Lean's critical systems and guiding Lean towards long-term self-sustainability. Its listed areas of focus include scalability, usability, proof automation and documentation.<ref name="frohome">Lean FRO, home page, "Vision" and "Mission" (read 14 October 2026). https://lean-lang.org/fro/</ref> It published a roadmap for each year of its work from August 2023. From September 2026 it moved to six-month roadmaps, saying that the field was changing too quickly to plan a year ahead.<ref name="roadmaps">Lean FRO, "Roadmap" (index of the roadmaps from August 2023). https://lean-lang.org/fro/roadmap/</ref><ref name="y41">Lean FRO, "The Lean FRO Year 4 - Part 1 Roadmap", covering September 2026 to February 2027. https://lean-lang.org/fro/roadmap/y4-1/</ref> In July 2025 Alex Gerko, founder of XTX Markets, announced gifts of $5 million to the FRO and $5 million to Mathlib.<ref name="rpgift">Renaissance Philanthropy, "Lean FRO and Mathlib receive $10M from XTX Markets Founder Alex Gerko to further advance the use of AI for mathematical research", 24 July 2025. https://www.renaissancephilanthropy.org/insights/lean-fro-and-mathlib-receive-10m-from-xtx-markets-founder-alex-gerko-to-further-advance-the-use-of-ai-for-mathematical-research</ref>

== A version every month ==

Version 4.0.0, of 8 September 2023, was the first stable version of Lean 4. Its announcement planned a new minor version roughly each month, each preceded by a candidate version.<ref name="firststable">"The first official release of Lean 4", Lean community blog, 8 September 2023. https://leanprover-community.github.io/blog/posts/first-lean-release/</ref> The plan has held. The manual's notes list every version from 4.1.0 of 26 September 2023 to 4.35.0 of 12 October 2026, with occasional patch versions between them.<ref name="relnotes">''The Lean Language Reference'', "Release Notes", list of versions (read 14 October 2026). https://lean-lang.org/doc/reference/latest/releases/</ref> The Lean code in this edition is checked with version 4.34.1, of 24 September 2026.<ref name="relnotes" />

Version 4.22.0, of 14 August 2025, brought two large changes. The old compiler was replaced by a new one. And Lean gained '''grind''', which its notes call an SMT-style tactic, with solvers for particular theories, among them a solver for linear integer arithmetic and one based on Gröbner bases.<ref name="rn422">''The Lean Language Reference'', "Lean 4.22.0 (2025-08-14)", release notes. https://lean-lang.org/doc/reference/latest/releases/v4.22.0/</ref>

The manual describes how <code>grind</code> works. Several engines share a common store of facts: congruence closure, constraint propagation, E-matching, guided case analysis, and solvers for linear integer arithmetic and commutative rings. Every proof it finds is by contradiction. Like other tactics, it produces ordinary Lean proof terms. For problems that are purely Boolean, the manual points instead to <code>bv_decide</code>, which calls an external SAT solver and checks the certificate it returns inside Lean.<ref name="grind">''The Lean Language Reference'', chapter 16, "The grind tactic", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/The--grind--tactic/</ref> The following example is the manual's, given a name so that its axioms can be printed:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem no_solution (x y : Int) :
27 ≤ 11 * x + 13 * y →
11 * x + 13 * y ≤ 45 →
-10 ≤ 7 * x - 9 * y →
7 * x - 9 * y ≤ 4 →
False := by
grind

#print axioms no_solution
</pre>

Lean 4.34.1 accepts the proof and prints <code>'no_solution' depends on axioms: [propext, Classical.choice, Quot.sound]</code>. The search was done by the tactic; the term it produced was checked by Lean's kernel, and rests on Lean's three axioms and nothing else. How such procedures fit into Lean is described at [[Lean theorem prover/System/Decision procedures|Decision procedures]] and [[Lean theorem prover/Explainers/Automation and its limits|Automation and its limits]]; the axioms at [[Lean theorem prover/Foundations/The three axioms|The three axioms]].

== Wider use ==

Mathlib kept growing; its history is at [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]]. The FRO's timeline dates the start of several large collaborative projects: on the polynomial Freiman–Ruzsa conjecture in November 2023, on Fermat's Last Theorem in December 2023, and on equational theories in September 2024.<ref name="froabout" /> They are described at [[Lean theorem prover/Applications/The polynomial Freiman-Ruzsa conjecture|The polynomial Freiman-Ruzsa conjecture]], [[Lean theorem prover/Applications/The Fermat's Last Theorem project|The Fermat's Last Theorem project]] and [[Lean theorem prover/Applications/The equational theories project|The equational theories project]].

Lean also became a target for machine learning. In July 2024 Google DeepMind reported AlphaProof, a system that trains itself to prove statements in Lean. With a second system for geometry it solved four of the six problems of the 2024 International Mathematical Olympiad, for 28 points out of 42, the level of a silver medal. The problems were translated into formal language by hand, and some took the systems up to three days.<ref name="alphaproof">Google DeepMind, "AI achieves silver-medal standard solving International Mathematical Olympiad problems", 25 July 2024. https://deepmind.google/discover/blog/ai-solves-imo-problems-at-silver-medal-level/</ref> Later work of this kind is described at [[Lean theorem prover/Applications/Machine learning and theorem proving|Machine learning and theorem proving]].

In 2025 Lean received two awards. The ACM SIGPLAN Programming Languages Software Award went to Lean, with Gabriel Ebner, Soonho Kong, Leonardo de Moura and Sebastian Ullrich named as contributors. Its citation mentions Mathlib at more than 1.6 million lines, the verification asked for by Peter Scholze, the polynomial Freiman–Ruzsa conjecture, and industrial uses, among them two at Amazon Web Services.<ref name="sigplan">ACM SIGPLAN, "Programming Languages Software Award", recipients, 2025: Lean Theorem Prover. https://www.sigplan.org/Awards/Software/</ref> The CADE Skolem Award, given for a paper from the Conference on Automated Deduction of ten years earlier that has passed the test of time, went to the 2015 system description of Lean, the paper discussed at [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].<ref name="skolemcade">CADE Inc., "Skolem Award", with the list of recipients (awards at CADE-30, July 2025). https://cadeinc.org/Skolem-Award</ref><ref name="skolem">University of Bonn, Department of Mathematics, "Skolem Award for Floris van Doorn", 27 May 2025. https://www.mathematics.uni-bonn.de/en/news/skolem-award-for-floris-van-doorn</ref>

== Flaws in Lean's kernel, July 2026 ==

Two versions of July 2026 each fixed a soundness bug in Lean's kernel. Version 4.32.1, of 22 July, fixed one by which a malicious metaprogram running in the same process as Lean's kernel could make it accept a proof of <code>False</code>. Its notes say that this opened no new line of attack, since such a program already has blunter ways to have bad proofs accepted, and that checking possibly dishonest proofs with comparator, described below, was not affected.<ref name="rn4321">''The Lean Language Reference'', version for Lean 4.34.0, "Lean 4.32.1 (2026-07-22)", release notes. https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.1/</ref>

The second bug is the subject of a postmortem. On 25 July 2026 a purported "disproof" of the Collatz conjecture, produced with the help of AI, was published. It was not valid: it exploited a bug in the Lean kernel's handling of nested inductive types. On 28 July the exploit was reduced to a short proof of <code>False</code> and reported, and a fix was made within an hour. Leonardo de Moura's postmortem explains the bug. When an inductive type occurred nested inside another inductive type, parameters of the containing type that none of its constructors mention dropped out of an auxiliary type that Lean's kernel generates, so an ill-typed argument in that place was never checked. The bug could be reached only by metaprogramming, by sending the definition straight to Lean's kernel; Lean's front end would have caught the ill-typed term. The postmortem calls it "an implementation bug, not a hole in Lean's meta-theory."<ref name="postmortem">Leonardo de Moura, "Postmortem for Kernel Soundness Bug #14576", 1 August 2026. https://leodemoura.github.io/blog/2026-8-1-postmortem-for-kernel-soundness-bug-14576/</ref> Version 4.32.2, of 28 July 2026, fixes it. Its notes add that this bug could be exploited even when proofs are checked with comparator, and advise users who must guard against malicious proofs to upgrade nanoda as well.<ref name="rn4322">''The Lean Language Reference'', version for Lean 4.34.0, "Lean 4.32.2 (2026-07-28)", release notes. https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.2/</ref>

The same false proof had also passed a week-old version of nanoda, the main independent checker for Lean, written in Rust. That was a second, unrelated bug in nanoda, fixed a week before the Lean bug was reported. The postmortem draws the practical lesson. Checking with an independent checker still works, since this exploit needed two distinct bugs in two implementations, but users who rely on it need current versions of both. It also rejects the suggestion of restricting metaprogramming. The elaborator is untrusted by design, so soundness cannot depend on it refusing to produce a bad term, and Lean's kernel has to reject ill-typed definitions by itself. With help from an AI system specialised in security, further mistakes in Lean's kernel were found and fixed; nanoda caught all of them.<ref name="postmortem" />

The FRO's roadmap for September 2026 to February 2027 makes independent checking a routine step. It plans commands for Lake, Lean's build tool, that re-check a development with the Lean kernel, with an alternative checker, or with every checker shipped with Lean, and it plans to include the comparator tool in Lean's distribution.<ref name="y41" /> The manual already calls comparator the gold standard against deliberately misleading proofs. It compiles the proposed proof in a sandbox, then replays it outside with Lean's kernel or an external checker, and confirms that the theorems proved are the ones stated in a trusted file.<ref name="validating">''The Lean Language Reference'', "Validating a Lean Proof", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref> The reasons for this arrangement are set out at [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]] and [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

<blockquote>
Provenance: the FRO's own pages, the Lean reference manual (history, version notes including those of 4.32.1 and 4.32.2, the chapter on <code>grind</code> and the section on validating proofs), de Moura's postmortem, the DeepMind announcement, the SIGPLAN and CADE award pages and the Bonn announcement were read on or before 14 October 2026. Dates of projects come from the FRO's timeline, which is the developers' own account. The postmortem names no version of Lean; the versions and dates of the two fixes come from the version notes. The one quotation is from the postmortem. Events after mid-October 2026 are not covered.
</blockquote>

== Next ==

[[Lean theorem prover/Applications/Research mathematics|Research mathematics]] · [[Lean theorem prover/Chronology|Chronology]]

== References ==
<references />

Lean theorem prover/History/The Liquid Tensor Experiment

2026-10-15T19:35:32Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The Liquid Tensor Experiment}}
{{Lean theorem prover map}}
The Liquid Tensor Experiment was the formalisation in Lean of a recent and difficult theorem by Dustin Clausen and Peter Scholze. Scholze posed it as a public challenge in December 2020. The part of the proof he was unsure of was checked by June 2021, and the whole statement was proved on 14 July 2022. The project was led by Johan Commelin. This page states what the challenge was, how the work went, what it found, and what it did and did not show.

== The challenge ==

On 5 December 2020 Kevin Buzzard's Xena Project blog carried a guest post by Scholze headed "Liquid tensor experiment". It asked for a formal proof of a theorem of Clausen and Scholze: for real numbers 0 < ''p''′ < ''p'' ≤ 1, a profinite set ''S'' and a ''p''-Banach space ''V'', the Ext groups from the space of ''p''′-measures on ''S'' to ''V'' vanish in all positive degrees. Scholze described this as a special case of Theorem 9.1 of his lecture notes on analytic geometry, and as the essence of the proof of Theorem 6.5 of the same notes.<ref name="final" /><ref name="challenge">Peter Scholze, "Liquid tensor experiment", guest post on the Xena Project blog, 5 December 2020. https://xenaproject.wordpress.com/2020/12/05/liquid-tensor-experiment/</ref>

The theorem belongs to '''condensed mathematics''', which Clausen and Scholze had begun to develop about two years before. It proposes condensed sets as a replacement for topological spaces in the foundations of mathematics. Scholze wrote that this claim stands only if the condensed approach also works in real functional analysis, and that this theorem decides whether it does.<ref name="challenge" />

He gave his reasons for wanting a formal proof. The theorem was of foundational importance, so being "99.9% sure is not enough". It would be used as a black box, where a mistake could go unnoticed. He had spent much of 2019 on the proof, and did not think anyone else had checked its details. He noted that he had in the past been persuasive with wrong arguments. And success would be a strong signal that computer verification of current research in very abstract mathematics had become possible.<ref name="challenge" />

== The first half ==

Six months later Scholze reported on the project in a second guest post. The Lean and mathlib community had discussed the challenge on the Lean Zulip immediately after it was posted. Reid Barton did important early work, and Commelin then took the lead: he worked directly towards the proof and handed self-contained lemmas to others. By 14 January 2021 he had formalised the statement of Theorem 9.4 of the lecture notes, the technical core of the argument, and its proof was completed on 28 May 2021 with the help of many members of the community.<ref name="halfway">Peter Scholze, "Half a year of the Liquid Tensor Experiment: Amazing developments", guest post on the Xena Project blog, 5 June 2021. https://xenaproject.wordpress.com/2021/06/05/half-a-year-of-the-liquid-tensor-experiment-amazing-developments/</ref>

Scholze wrote that Theorem 9.4 was the only result he had been worried about, and that with its formal verification he had no remaining doubts about the correctness of the main proof. To him the experiment had succeeded, though the challenge itself was perhaps half done. The remaining half needed condensed abelian groups, Ext groups in abelian categories and the surrounding theory to be formalised.<ref name="halfway" />

The work did not proceed as he had expected. He had imagined that a group would first rewrite the proof as many small lemmas and only then formalise them. Instead the formalisation followed the lecture notes lemma by lemma, typed directly into Lean. The human-readable "blueprint" was written afterwards, from the formal proof, not before it.<ref name="halfway" />

== What the formalisation found ==

Scholze answered the question whether the proof in his notes was correct: yes, up to the usual slight imprecisions.<ref name="halfway" /> He named them.

* One subtlety concerned quotient norms: the infimum that defines a quotient norm need not be attained. He thought an informal check would probably have missed it. It caused unexpected difficulty but needed only very minor changes to the argument.
* A hypothesis of Lemma 9.6 and some imprecision around Proposition 8.17 had to be corrected.
* Commelin found that the Breen–Deligne resolution, a non-explicit object whose existence uses stable homotopy theory, could be replaced for this purpose by an explicit complex with the same key properties. This made the rest of the proof more elementary.
* The formalisation of convex geometry needed for Gordan's lemma showed Scholze what makes the proof work: a reduction from a non-convex problem over the reals to a convex problem over the integers.
* Question 9.9 of the notes, on the growth of certain constants, was answered: explicit recursive definitions were verified, and the constants grow roughly doubly exponentially.

He estimated the ratio of the formal proof's length to the human proof's, the de Bruijn factor named after [[Lean theorem prover/History/Automath|Automath]]'s designer, at about 20.<ref name="halfway" />

== Completion ==

The Lean community announced that the experiment was completed at 15:46:13 (Eastern time) on Thursday 14 July 2022, a year and a half after the challenge. The project was led by Commelin with continuous mathematical support from Scholze; Adam Topaz contributed much of the homological algebra and condensed mathematics, and sixteen other people are named as contributors. The work was finished at ICERM in Providence, Rhode Island, during the workshop "Lean for the Curious Mathematician 2022", and relied heavily on mathlib.<ref name="final">"Completion of the Liquid Tensor Experiment", Lean community blog, 15 July 2022. https://leanprover-community.github.io/blog/posts/lte-final/</ref>

A formal proof is only as good as its statement. A theorem that Ext groups vanish proves nothing if Ext has been defined wrongly. Topaz described how the team addressed this: a separate collection of examples, written to be readable by mathematicians with little Lean, checks that each definition in the final statement behaves as expected.<ref name="lteexamples">Adam Topaz, "Definitions in the liquid tensor experiment", Lean community blog, 14 October 2022. https://leanprover-community.github.io/blog/posts/lte-examples/</ref> The general problem is the subject of [[Lean theorem prover/Explainers/Stating the right thing|Stating the right thing]].

== Coverage ==

The first milestone was reported in ''Nature'' on 18 June 2021, in a news article by Davide Castelvecchi.<ref name="lteupdate">Johan Commelin, "Liquid Tensor Experiment: an update", Lean community blog, 31 December 2021. https://leanprover-community.github.io/blog/posts/lte-update/</ref><ref name="nature">Davide Castelvecchi, "Mathematicians welcome computer-assisted proof in 'grand unification' theory", ''Nature'' 595, 2021, pp. 18–19 (news, 18 June 2021). doi:10.1038/d41586-021-01627-2</ref> Its summary says that proof-assistant software had handled an abstract concept at the cutting edge of research.<ref name="nature" /> ''Quanta Magazine'' followed on 28 July 2021 with an article by Kevin Hartnett. It describes Commelin posting parts of the proof on Zulip for volunteers to formalise, about a dozen mathematicians contributing, and Scholze answering their questions there, and it quotes him as saying that the experiment had drastically changed his impression of what proof assistants can do.<ref name="quanta">Kevin Hartnett, "Proof Assistant Makes Jump to Big-League Math", ''Quanta Magazine'', 28 July 2021. https://www.quantamagazine.org/lean-computer-program-confirms-peter-scholze-proof-20210728/</ref>

== What it showed, and what it did not ==

The experiment showed that a proof at the edge of current research, in abstract mathematics, could be formalised within a reasonable time by following the author's own notes. Scholze called this a landmark, and wrote that the proof assistant had helped in understanding the proof, because it always stated the current goal clearly.<ref name="halfway" />

He was also clear about the limits. He could read the Lean definitions and statements without training, but not the proofs. The formal proof gave him reassurance that the route up the mountain could be climbed, he wrote, but no sense of the surrounding terrain.<ref name="halfway" /> A checked proof establishes that a statement follows from the axioms; it does not by itself explain why. Other large projects that followed are described at [[Lean theorem prover/Applications/Research mathematics|Research mathematics]].

<blockquote>
Provenance: Scholze's two posts and the community blog's posts on completion and on definitions were read. The ''Nature'' article was read only in its headline, summary and first paragraph, the rest being behind a paywall; the ''Quanta'' article was read in full. The one quotation, "99.9% sure is not enough", is Scholze's.
</blockquote>

== Next ==

[[Lean theorem prover/History/Lean since 2023|Lean since 2023]]

== References ==
<references />

Lean theorem prover/History/Mathlib and its community

2026-10-15T19:35:31Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Mathlib and its community}}
{{Lean theorem prover map}}
Mathlib is the main library of formalised mathematics for Lean. It began in 2017 as mathlib, a library for Lean 3, and was carried over to Lean 4 in 2023, where it is written with a capital letter. It is maintained by its users, not by Lean's developers. This page covers how it started, how changes to it are reviewed, where its community talks, and how large it is, with each figure dated.

== From the core library to mathlib ==

The library's own account of its origins is the paper "The Lean Mathematical Library", presented at the Conference on Certified Programs and Proofs (CPP) in New Orleans in January 2020. It was published under the collective name "The mathlib Community", standing for the 73 contributors listed in its acknowledgements.<ref name="cpp2020">The mathlib Community, "The Lean Mathematical Library", in ''Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (CPP 2020)'', ACM, 2020, pp. 367–381. doi:10.1145/3372885.3373824. Preprint: https://arxiv.org/abs/1910.09336</ref>

According to the paper, in the summer of 2017 much of the core library that came with Lean 3 was moved out of the system's own code, and this became the base of mathlib. The project was led at first by Mario Carneiro and Johannes Hölzl at Carnegie Mellon University. It drew users through Lean's documentation, its emphasis on classical mathematics, and its real-time chat. In the two years after the split it grew from 15,000 to 140,000 lines of code, not counting blank lines and comments.<ref name="cpp2020" />

The paper names the features that set mathlib apart: dependently typed foundations, a focus on classical mathematics, an extensive hierarchy of structures, automation at both large and small scale, and a distributed organisation. It notes that, unlike most such libraries, many of its contributors have a background in pure mathematics, and that this shaped its contents. It treats the writing of tactics as part of library design, not of system development, a division of labour it credits to Lean 3's metaprogramming.<ref name="cpp2020" /> How the hierarchy of structures is organised is described at [[Lean theorem prover/Explainers/A library of mathematics|A library of mathematics]] and [[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]].

== Review and maintainers ==

Mathlib has no central organisation directing its content; design decisions and directions are discussed in public.<ref name="cpp2020" /> Changes are proposed openly and reviewed before they are accepted. In 2020 eleven community members had been designated maintainers, responsible for approving changes in their areas, and reviews were welcomed from anyone.<ref name="cpp2020" />

The community's own description of the maintainers, as read in October 2026, is that they have the power to give final approval to proposed changes and must keep the library's design cohesive and its implementation of high quality. They usually have research-level knowledge of some field of mathematics or computer science. They join at the invitation of the current maintainers, and serve renewable two-year terms. The page then listed 28 maintainers.<ref name="maintainers">Lean community, "Mathlib maintainers" (read 14 October 2026). https://leanprover-community.github.io/teams/maintainers.html</ref> A separate team of reviewers does much of the daily reviewing and passes changes it judges ready to the maintainers for a final decision. Other teams handle moderation, the code of conduct and the community's infrastructure.<ref name="teams">Lean community, "Community teams" and "Mathlib reviewers" (read 14 October 2026). https://leanprover-community.github.io/teams.html</ref>

The contribution guide asks contributors to consider whether material belongs in the library at all. It suggests asking whether the material is taught or studied in a mathematics department, and whether it lies within the maintainers' mathematical interests, since material outside them may be hard for them to maintain. It states plainly that the library's remit is not all of mathematics, and that a review need not come from a maintainer.<ref name="contribute">Lean community, "Contributing to mathlib" (read 14 October 2026). https://leanprover-community.github.io/contribute/index.html</ref>

== The Zulip forum ==

Much of the discussion takes place on the Lean Zulip, a chat forum organised into channels. The 2020 paper describes a channel for new members that welcomes elementary questions, and another for formalising advanced mathematics; it reports that several people cited the forum's accessibility as their reason for choosing Lean.<ref name="cpp2020" /> Projects built on the library range from published research to weekend collaborations coordinated there.<ref name="cpp2020" /> One of them is described at [[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]].

== From mathlib to Mathlib ==

The move to Lean 4 is described at [[Lean theorem prover/History/Lean 4|Lean 4]]. The Lean 4 library describes itself as "a user maintained library for the Lean theorem prover", containing programming infrastructure, mathematics, and the tactics that serve both.<ref name="mathlib4readme">Mathlib, README of the Lean 4 library. https://github.com/leanprover-community/mathlib4</ref> The Lean 3 library is now marked as no longer actively maintained.<ref name="mathlib3readme">Lean 3 mathlib, README. https://github.com/leanprover-community/mathlib</ref>

== Size ==

Dozens of changes are approved every week, so each figure here carries the date of its source.<ref name="maintainers" />

* At the end of Lean 3 mathlib had over one million lines; the Lean reference manual, in the edition for version 4.34.0, says Mathlib has since grown to over 1.5 million.<ref name="refhist">''The Lean Language Reference'', section 1.1 "History", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/Introduction/</ref>
* In October 2025 Renaissance Philanthropy described the library as nearly two million lines of computer-verified mathematics.<ref name="rpinterview">Renaissance Philanthropy, "Kevin Buzzard and Alex Kontorovich on the Future of Formal Mathematics: A Mathlib Initiative Interview", 3 October 2025. https://www.renaissancephilanthropy.org/insights/kevin-buzzard-and-alex-kontorovich-on-the-future-of-formal-mathematics-a-mathlib-initiative-interview</ref>
* As of October 2026 the community's statistics page counted 137,993 definitions, 290,354 theorems and 772 contributors.<ref name="stats">Lean community, "Mathlib statistics" (read 14 October 2026). https://leanprover-community.github.io/mathlib_stats.html</ref>

Review has not kept pace with contributions. In the same 2025 interview, Oliver Nash reported that August 2025 was the library's busiest month, with over 1,100 contributions reviewed and added, and that about 2,000 more were waiting for review.<ref name="rpinterview" />

== The Mathlib Initiative ==

In July 2025 Alex Gerko, founder of XTX Markets, announced a gift of $5 million to Mathlib, alongside $5 million to the Lean Focused Research Organization. With the gift for Mathlib, a new Mathlib Initiative was to be set up within Renaissance Philanthropy.<ref name="rpgift">Renaissance Philanthropy, "Lean FRO and Mathlib receive $10M from XTX Markets Founder Alex Gerko to further advance the use of AI for mathematical research", 24 July 2025. https://www.renaissancephilanthropy.org/insights/lean-fro-and-mathlib-receive-10m-from-xtx-markets-founder-alex-gerko-to-further-advance-the-use-of-ai-for-mathematical-research</ref> Its stated purpose is to give the library professional support while keeping it open and collaborative. It is led by Johan Commelin, Oliver Nash and Adam Topaz, and a major aim is to increase the capacity for review.<ref name="rpinterview" /> Several maintainers now describe themselves, on the maintainers' page, as working for it.<ref name="maintainers" />

<blockquote>
Provenance: the 2020 CPP paper, the community's team, contribution and statistics pages (read on 14 October 2026), the README files, the Lean reference manual and the two Renaissance Philanthropy pages were read. The one quotation is the Lean 4 library's description of itself. Figures from different sources measure different things (lines, definitions, theorems) and are not comparable with each other.
</blockquote>

== Next ==

[[Lean theorem prover/History/The Liquid Tensor Experiment|The Liquid Tensor Experiment]]

== References ==
<references />

Lean theorem prover/History/Lean 4

2026-10-15T19:35:30Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Lean 4}}
{{Lean theorem prover map}}
Lean 4 is a reimplementation of Lean, written for the most part in Lean itself. Its development began in 2018, it was described at the Conference on Automated Deduction in 2021, and its first stable version, 4.0.0, appeared on 8 September 2023. In the same year the mathematical library was carried over from Lean 3. This page covers the rewrite, the stable versions, and the port.

== Why a rewrite ==

Lean 3 was written in C++. Its developers name two problems with that in the Lean 4 system description. Users could not change many parts of the system without changing the C++ source. And proof automation written as Lean 3 metaprograms was slow compared with the same procedures written in C++ or OCaml, chiefly because Lean 3 interpreted metaprograms in a virtual machine.<ref name="lean4">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37. Author's copy: https://lean-lang.org/papers/lean4.pdf</ref> The Lean reference manual adds that a C++ implementation limited Lean's flexibility and made it harder to develop, because of the range of skills it required.<ref name="refhist">''The Lean Language Reference'', section 1.1 "History", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/Introduction/</ref> The earlier versions are described at [[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]].

== The 2021 system description ==

Leonardo de Moura and Sebastian Ullrich described the new system at CADE-28 in 2021. Their abstract calls Lean 4 a reimplementation of the Lean interactive theorem prover in Lean itself, and says that users can modify and extend the parser, the elaborator, the tactics, the decision procedures, the pretty printer and the code generator.<ref name="lean4" />

The paper lists what was new. A hygienic macro system, designed for theorem provers, lets users add notation without accidental capture of names. Type class resolution uses a tabled procedure, which addressed performance problems reported by users. The compiler produces C code, so that automation written in Lean can be compiled to native code and loaded as a plugin. Memory is managed by reference counting, which lets a function update data in place when nothing else shares it, a style the authors call "functional but in-place". An editor server implements the Language Server Protocol. The paper ends by noting that Lean's trusted kernel is relatively small, and that its interface lets users export their developments to other systems and write their own reference checkers.<ref name="lean4" /> The paper also states that Lean 4 was made public at the beginning of 2021, with the community already porting mathlib.<ref name="lean4" />

The manual gives the result of the rewrite in one figure: from version 4, about 90 per cent of the code that implements Lean is written in Lean.<ref name="refhist" /> The interface the system uses for itself is open to users. The function that runs a tactic, for example, is an ordinary Lean definition:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
#eval Lean.versionString
#check @Lean.Elab.Tactic.evalTactic
</pre>

With version 4.34.1, the version used for the code in this edition, Lean prints <code>"4.34.1"</code> and then <code>Lean.Elab.Tactic.evalTactic : Lean.Syntax → Lean.Elab.Tactic.TacticM Unit</code>: a tactic is run by a function from syntax to an action in the tactic monad. How that machinery works is described at [[Lean theorem prover/System/The tactic framework|The tactic framework]] and [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]]; the macro system at [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]]; the compiler at [[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]].

== The first stable version ==

Until September 2023 most of the Lean 4 ecosystem worked with nightly versions.<ref name="firststable" /> Version 4.0.0, dated 8 September 2023, was the first stable version.<ref name="v400">Lean 4 source code, version tag v4.0.0, published 8 September 2023. https://github.com/leanprover/lean4/releases/tag/v4.0.0</ref><ref name="refhist" /> The announcement on the Lean community blog set out a schedule: a new minor version roughly each month, preceded by a candidate version early in the month, with breaking changes documented but no promise yet of backward compatibility.<ref name="firststable">"The first official release of Lean 4", Lean community blog, 8 September 2023. https://leanprover-community.github.io/blog/posts/first-lean-release/</ref> Versions have followed in sequence since; this edition's examples are checked with version 4.34.1. The manual records that the development of Lean 4 took about as long as all earlier versions together, and that no further rewrite is planned.<ref name="refhist" />

== The port of mathlib ==

In December 2021 mathlib, the Lean 3 mathematical library, had more than 700,000 lines. Lean 4 could not run Lean 3 code. The plan, set out on the community blog in December 2021, was a semi-automated port by a tool called Mathport, written mostly by Mario Carneiro and Daniel Selsam.<ref name="mathportpost">"Update on mathport (Dec 2021)", Lean community blog, 22 December 2021. https://leanprover-community.github.io/blog/posts/intro-to-mathport/</ref> Mathport has two parts. One translates the compiled Lean 3 files into compiled Lean 4 files, so that the whole library could be imported at once; the other makes a best-effort translation of the Lean 3 source text into Lean 4 syntax.<ref name="mathportpost" /><ref name="mathportreadme">Mathport, README file. https://github.com/leanprover-community/mathport</ref>

The post explains why the port could not be mechanical. Mathlib kept growing while the port went on, so the plan was not to freeze it until late. Files would move to the new library from the bottom of the import hierarchy up, with Mathport re-run on the still-changing Lean 3 sources and lining up definitions already ported. Mathport did not translate the library's tactics: metaprogramming in Lean 4 differs too much, so they had to be written again by hand.<ref name="mathportpost" />

The manual records that the port was completed in 2023 through a community effort supported by the Lean developers.<ref name="refhist" /> The community's page tracking the port records it as declared complete as of 16 July 2023.<ref name="portstatus">Lean community, "Mathlib porting status" (read 14 October 2026). https://leanprover-community.github.io/mathlib-port-status/</ref> The Lean 3 library is now marked as no longer actively maintained.<ref name="mathlib3readme">Lean 3 mathlib, README file. https://github.com/leanprover-community/mathlib</ref> According to the same manual, mathlib had over one million lines at the end of Lean 3 and has since grown to over 1.5 million, and Lean 4 checks the larger library faster than Lean 3 checked the smaller one.<ref name="refhist" /> The library and the people who maintain it are the subject of [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].

In July 2023, two months before the first stable version, de Moura and Ullrich founded the Lean Focused Research Organization, whose staff now work on Lean; its work is followed at [[Lean theorem prover/History/Lean since 2023|Lean since 2023]].<ref name="refhist" />

<blockquote>
Provenance: the 2021 system description, the Lean reference manual's history section (as of version 4.34.0), the two community blog posts, the community's porting status page and the Mathport and mathlib README files were read. The quotation "functional but in-place" is the 2021 paper's name for its technique. The date on which the port was declared complete is the one given on the community's porting status page.
</blockquote>

== Next ==

[[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]]

== References ==
<references />

Lean theorem prover/History/Lean 1 to Lean 3

2026-10-15T19:35:29Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Lean 1 to Lean 3}}
{{Lean theorem prover map}}
Lean was started in 2013 by Leonardo de Moura at Microsoft Research. Its first three major versions were written in C++ and developed mainly at Microsoft Research and Carnegie Mellon University. This page covers them: the system described in 2015, the second version's mode for homotopy type theory and why it did not survive, the third version and its metaprogramming in Lean, and the community's maintenance of that version after its developers turned to [[Lean theorem prover/History/Lean 4|Lean 4]].

== The start, 2013 ==

The Lean 4 system description dates the project's start to 2013, as an interactive theorem prover based on the Calculus of Inductive Constructions.<ref name="lean4">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37. Author's copy: https://lean-lang.org/papers/lean4.pdf</ref> A 2017 paper by three of its early users adds that de Moura started it, and that it was developed mainly at Microsoft Research and Carnegie Mellon University under the Apache 2.0 licence.<ref name="hott2017">Floris van Doorn, Jakob von Raumer and Ulrik Buchholtz, "Homotopy type theory in Lean", in ''Interactive Theorem Proving (ITP 2017)'', Lecture Notes in Computer Science 10499, Springer, 2017, pp. 479–495. doi:10.1007/978-3-319-66107-0_30. Preprint: https://arxiv.org/abs/1704.06781</ref>

The Lean reference manual records that Lean 0.1, the first version, appeared officially on 16 June 2014. It states the project's goal as combining the trust that comes from a small logical core, the Lean kernel, which others can implement independently, with the convenience and automation of tools such as SMT solvers. The first versions were mainly C++ libraries in which client code could construct proofs that could be checked independently; the design then moved towards a conventional interactive prover, first with tactics written in the scripting language Lua and later with a syntax of its own.<ref name="refhist">''The Lean Language Reference'', section 1.1 "History", for version 4.34.0 of Lean. https://lean-lang.org/doc/reference/4.34.0/Introduction/</ref>

== The 2015 system description ==

The first published account is "The Lean Theorem Prover (system description)" by de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, presented at the 25th Conference on Automated Deduction (CADE-25) in 2015.<ref name="lean2015">Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf</ref> It states the aim in one line: to bridge the gap between interactive and automated theorem proving, by placing automated tools inside a framework that supports user interaction and the construction of fully specified axiomatic proofs.

The paper describes Lean's small trusted kernel, written in two layers of C++: a type checker and the operations on terms in about 6,000 lines, and inductive families in about 700 more. The logic could be configured. With an impredicative sort of propositions, which could also be made proof-irrelevant, it gave a version of the Calculus of Inductive Constructions; without one, a version of Martin-Löf type theory. In both cases the universes were non-cumulative and definitions could be polymorphic in universe levels. Above the Lean kernel sat an elaborator that handled higher-order unification, coercions, overloading and type classes together. Proofs could be written as terms, in a declarative style resembling Mizar and Isabelle/Isar, or with tactics. Editing ran in Emacs with continuous checking, and JavaScript bindings let Lean run in a web browser. At Carnegie Mellon it was being used to formalise category theory, homotopy type theory and abstract algebra, and for a course in the spring of 2015.<ref name="lean2015" />

The paper ends with plans: more search and decision procedures, better support for homotopy type theory, and an independent type checker, which it says Lean's small kernel makes simpler to write.<ref name="lean2015" /> Independent checkers for Lean now exist; see [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

== The second version and homotopy type theory ==

The version described in 2015 is the one now called Lean 2; its published source describes itself as a snapshot of Lean 0.2, kept separately because it has special support for homotopy type theory.<ref name="lean2readme">Lean 2 source code, README file ("This is a snapshot of the Lean 0.2 theorem prover..."). https://github.com/leanprover/lean2</ref>

Lean 2's kernel had two modes. In the standard mode the lowest universe, <code>Prop</code>, was proof-irrelevant: any two proofs of a proposition were equal by definition. Proof irrelevance is incompatible with homotopy type theory, in which equality corresponds to paths in a space, so a second mode without proof irrelevance was added, and a library for homotopy type theory was written in it.<ref name="hott2017" />

The third version did not keep that mode. Van Doorn, von Raumer and Buchholtz give two design decisions as reasons: Lean 3's virtual machine erases proofs, and its mechanism for defining functions by pattern matching relies on axiom K. In 2017 the library therefore remained in Lean 2, which was still maintained but no longer developed.<ref name="hott2017" /> The reason the standard mode is proof-irrelevant is set out at [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].

== Lean 3 ==

Version 3.0.0 of Lean is dated 20 January 2017, the date the reference manual also gives.<ref name="refhist" /><ref name="v300">Lean 3 source code, version tag v3.0.0, published 20 January 2017. https://github.com/leanprover/lean3/releases/tag/v3.0.0</ref> The 2017 homotopy paper places the third major version in 2016, and records that many of Lean's components were rewritten for it and that its unification was restricted, because the full higher-order unification of Lean 2 could produce timeouts and error messages unrelated to the user's mistake.<ref name="hott2017" />

The change that mattered most was metaprogramming in Lean itself. Ebner, Ullrich, Roesch, Avigad and de Moura described it in 2017. Definitions marked <code>meta</code> may use an interface to Lean's internal structures and procedures, and may recurse without proof of termination. They are compiled to bytecode and run in a virtual machine. Tactics become ordinary Lean programs in a tactic monad, written in the same files and with the same library as the mathematics. The paper's examples range from small interactive tactics to a simplifier and a superposition prover.<ref name="ebner2017">Gabriel Ebner, Sebastian Ullrich, Jared Roesch, Jeremy Avigad and Leonardo de Moura, "A metaprogramming framework for formal verification", ''Proceedings of the ACM on Programming Languages'' 1 (ICFP), article 34, 2017. doi:10.1145/3110278. Author's copy: https://lean-lang.org/papers/tactic.pdf</ref> The idea is followed backwards at [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] and forwards at [[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]].

In 2017, on Lean 3, a community of users started the mathematical library mathlib.<ref name="lean4" /> Its history is at [[Lean theorem prover/History/Mathlib and its community|Mathlib and its community]].

== The community's Lean 3 ==

The last official version of Lean 3 was 3.4.2, dated 18 January 2019.<ref name="lean3community" /><ref name="lean3changes">Lean 3 community edition, change log (<code>doc/changes.md</code>), entries from v3.2.0 (June 2017) to 3.51.1c (24 May 2023). https://github.com/leanprover-community/lean/blob/master/doc/changes.md</ref> The developers turned to a reimplementation, and the original Lean 3 source now carries a notice that it is frozen and that Lean 4 is the official line.<ref name="lean3frozen">Lean 3 source code, README file, notice that the code is frozen and Lean 4 is the official line. https://github.com/leanprover/lean3</ref>

Mathlib's users still needed Lean 3, and they continued it themselves. Version 3.5.0c of 26 December 2019 is recorded as the first community version, and the community line ran to 3.51.1c of 24 May 2023.<ref name="lean3changes" /> The community's edition describes itself as a fork of Lean 3 maintained by the Lean community, and now warns that Lean 3 is no longer actively maintained and that Lean 4 should be used instead.<ref name="lean3community">Lean 3 community edition, README file and its earlier version. https://github.com/leanprover-community/lean</ref> Mathlib's own move to Lean 4 is told at [[Lean theorem prover/History/Lean 4|Lean 4]].

The Lean 4 system description names the limits that led to the rewrite. Many parts of Lean 3 could not be changed without editing its C++ source, and proof automation written as Lean 3 metaprograms ran slowly, chiefly because of the overhead of interpreting it in the virtual machine.<ref name="lean4" />

<blockquote>
Provenance: the 2015, 2017 and 2021 papers were read, as were the README files and the community change log. The date of version 3.0.0 is the date on its tag; the 2017 homotopy paper's "2016" is reported as that paper states it. Nothing here is quoted except one line of the Lean 2 README file, in the references.
</blockquote>

== Next ==

[[Lean theorem prover/History/Lean 4|Lean 4]]

== References ==
<references />

Lean theorem prover/History/The Calculus of Constructions

2026-10-15T19:35:28Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The Calculus of Constructions}}
{{Lean theorem prover map}}
The Calculus of Constructions is a type theory introduced by Thierry Coquand and Gérard Huet in the mid-1980s. With inductive types added in 1989, it became the Calculus of Inductive Constructions, the logic of the proof assistant Coq, now called the Rocq Prover. Lean's logic is a member of the same family. This page follows the calculus from Coquand's thesis to the present and states where Lean departs from its relatives.

== Coquand's thesis and the first engine ==

Coquand and Huet both worked at INRIA. Coquand's thesis, which presented what was first called the Theory of Constructions, was defended on 31 January 1985. The Coq reference manual's history, written by Huet, Coquand and Christine Paulin-Mohring, describes the first software as a prototype type checker for that formalism, developed from late 1983 to early 1985 and mostly Huet's work. It names Girard's polymorphic System F and de Bruijn's Automath as influences; Huet's earlier summary in the same manual describes the calculus as combining Martin-Löf's type theory and Girard's polymorphic calculus in a higher-order extension of the Automath language. The prototype used a single binding operator for both the dependent product and function abstraction, in the manner of Automath, and handled substitution with de Bruijn indices.<ref name="rocqhist">The Rocq Prover Reference Manual, "History of Coq", including "A short history of the early versions" written by Thierry Coquand, Gérard Huet and Christine Paulin-Mohring in September 2015 and Huet's summary of February 1995. https://rocq-prover.org/doc/master/refman/history.html</ref>

A preliminary version of their paper on the calculus was presented at the International Symposium on Semantics of Data Types at Sophia-Antipolis in June 1984. Coquand and Huet described it at EUROCAL in 1985, and under its present name in an INRIA report of May 1986 and in the journal ''Information and Computation'' in 1988.<ref name="ch1986">Thierry Coquand and Gérard Huet, "The calculus of constructions", INRIA Research Report RR-0530, May 1986. https://inria.hal.science/inria-00076024</ref><ref name="ch1985">Thierry Coquand and Gérard Huet, "Constructions: a higher order proof system for mechanizing mathematics", in ''EUROCAL '85'', Lecture Notes in Computer Science 203, Springer, 1985, pp. 151–184. doi:10.1007/3-540-15983-5_13</ref><ref name="ch1988">Thierry Coquand and Gérard Huet, "The calculus of constructions", ''Information and Computation'' 76 (2–3), 1988, pp. 95–120. doi:10.1016/0890-5401(88)90005-3</ref>

== What the calculus says ==

In the 1986 report every proof is a lambda-expression whose type is the proposition it proves. Erasing the types leaves a pure lambda-term, the algorithm the proof contains, and computing with it corresponds to cut elimination. The authors call the correspondence between propositions and types, as Martin-Löf had advocated, a powerful paradigm for computer science. They prove that every computation in the calculus terminates, and obtain the consistency of the logic as a corollary. They also say that their terms are inspired by the Automath languages.<ref name="ch1986" />

The calculus is '''impredicative''': a proposition may be formed by quantifying over all propositions, itself included. Christine Paulin-Mohring's later introduction gives the standard example. The type of the polymorphic identity on propositions, "for every proposition ''X'', ''X'' implies ''X''", is itself a proposition. She adds that impredicativity is powerful but fragile. Only the sort of propositions may have it; making the next universe impredicative as well gives an inconsistent system.<ref name="pm2015">Christine Paulin-Mohring, "Introduction to the Calculus of Inductive Constructions", in B. Woltzenlogel Paleo and D. Delahaye (eds.), ''All about Proofs, Proofs for All'', Studies in Logic 55, College Publications, 2015. https://inria.hal.science/hal-01094195</ref> Lean's <code>Prop</code> has the same property; see [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].

== Inductive types ==

The pure calculus can encode natural numbers, lists and other data by impredicative definitions, but Paulin-Mohring records two drawbacks: functions over the encoded types compute inefficiently, and some natural properties of them cannot be proved.<ref name="pm2015" /> Version 4.4 of the software, frozen in March 1988, already offered inductive types encoded in this way.<ref name="rocqhist" />

Coquand and Paulin-Mohring then added inductive definitions as primitives, following the pattern of Martin-Löf's type theory. Their paper "Inductively defined types" was presented at COLOG-88 and published in 1990; the manual dates the extension to 1989.<ref name="rocqhist" /><ref name="cp1990">Thierry Coquand and Christine Paulin, "Inductively defined types", in P. Martin-Löf and G. Mints (eds.), ''COLOG-88'', Lecture Notes in Computer Science 417, Springer, 1990, pp. 50–66. doi:10.1007/3-540-52335-9_47</ref> The result is the '''Calculus of Inductive Constructions'''. Its rules were set out by Paulin-Mohring in 1993.<ref name="pm1993">Christine Paulin-Mohring, "Inductive definitions in the system Coq: rules and properties", in ''Typed Lambda Calculi and Applications (TLCA '93)'', Lecture Notes in Computer Science 664, Springer, 1993, pp. 328–345. doi:10.1007/BFb0037116</ref> In Lean every inductive type comes with a recursor that is its induction principle; see [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]].

== Coq ==

At the end of 1989 the system was renamed Coq, for the Calculus of Inductive Constructions, with version 5.1.<ref name="rocqhist" /> The name referred to the Calculus of Constructions, to Thierry Coquand, and to the rooster, a French national symbol.<ref name="rocqabout">The Rocq Prover, "About" page, sections "An Overview of the Name's Evolution" and "Awards". https://rocq-prover.org/about</ref>

The early system already had the division of labour Lean has today. Its theorem prover ran tactics written in CAML "in the LCF fashion", and users could add their own.<ref name="rocqhist" /> From version 4.7 in 1988 the proof checker, called the Constructive Engine, was kept apart as the trusted core: a proof term assembled by tactics was checked again in full by the engine, so the tactics did not themselves need to be certified.<ref name="rocqhist" /> The idea is followed at [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]].

In 2013 the ACM Software System Award was given to the team that first developed Coq.<ref name="rocqabout" /> The project later took a new name. Version 9.0 of the Rocq Prover, issued on 12 March 2025, completed the renaming from the Coq Proof Assistant.<ref name="rocq9">The Rocq Prover, "Rocq 9.0.0" (announcement of version 9.0.0, 12 March 2025). https://rocq-prover.org/releases/9.0.0</ref> The new name honours Inria Rocquencourt, where the prover was first developed.<ref name="rocqabout" />

== Lean's place in the family ==

Lean implements a version of the Calculus of Inductive Constructions. Its developers have said so from the start: the 2015 system description presents Lean's trusted kernel as a version of it when the sort of propositions is impredicative, and the 2017 paper on Lean 3's metaprogramming cites Coquand and Huet (1988) and Coquand and Paulin (1990) for the logic.<ref name="lean2015">Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf</ref><ref name="ebner2017">Gabriel Ebner, Sebastian Ullrich, Jared Roesch, Jeremy Avigad and Leonardo de Moura, "A metaprogramming framework for formal verification", ''Proceedings of the ACM on Programming Languages'' 1 (ICFP), article 34, 2017. doi:10.1145/3110278. Author's copy: https://lean-lang.org/papers/tactic.pdf</ref>

It is not the same theory as Coq's. Mario Carneiro's 2019 account of Lean's type theory lists the differences as they then stood. Coq's universes are cumulative, so that a type in one universe also belongs to every larger one, and Lean's are not. Coq's core language has primitive constructs for recursion and pattern matching, while Lean's kernel has only the recursors, and recursive definitions are compiled into them. Lean's definitions are polymorphic in universe levels. Lean has definitional proof irrelevance, any two proofs of a proposition being equal by definition, where Coq then had it only as an axiom. And Lean has quotient types with a computation rule.<ref name="carneiro2019">Mario Carneiro, ''The Type Theory of Lean'', thesis, April 2019, section 2.8 "Differences from Coq". https://github.com/digama0/lean-type-theory/releases/download/v1.0/main.pdf</ref> The 2015 description had already noted that, unlike Coq, Lean keeps fixed-point expressions, match expressions and the termination checker out of the Lean kernel.<ref name="lean2015" /> These features of Lean are treated at [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]], [[Lean theorem prover/Foundations/Quotient types|Quotient types]] and [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

<blockquote>
Provenance: the Rocq reference manual's history, the 1986 INRIA report, Paulin-Mohring's 2015 introduction, Carneiro's thesis, the two Lean papers and the Rocq project's pages were read. Coquand's thesis, the 1985, 1988, 1990 and 1993 papers were not opened; their details come from the publishers' records and the manual. The date of the decision to rename Coq was not verified and is not given.
</blockquote>

== Next ==

[[Lean theorem prover/History/Lean 1 to Lean 3|Lean 1 to Lean 3]]

== References ==
<references />

Lean theorem prover/History/Martin-Löf type theory

2026-10-15T19:35:26Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Martin-Löf type theory}}
{{Lean theorem prover map}}
Per Martin-Löf's intuitionistic theory of types, begun at Stockholm in 1971, made the identification of propositions with types the foundation of a whole system of mathematics, not an observation about one. Its first version was inconsistent; the versions that followed from 1972 to 1984 are predicative and have stood. This page follows that development and the proof assistants built on it, and says what Lean took from it.

== The first version and Girard's paradox ==

Martin-Löf's first theory, an unpublished Stockholm preprint of 1971, contained an axiom that there is a type of all types.<ref name="pml" /><ref name="sep">Peter Dybjer and Erik Palmgren, "Intuitionistic Type Theory", ''Stanford Encyclopedia of Philosophy'', first published 12 February 2016, substantive revision 23 September 2024. https://plato.stanford.edu/entries/type-theory-intuitionistic/</ref> Jean-Yves Girard showed that this axiom leads to a contradiction. In the paper that replaced it, Martin-Löf describes the first version as based on the "strongly impredicative axiom that there is a type of all types", records that it had to be abandoned after Girard showed it contradictory, and thanks Girard for showing him the paradox.<ref name="ml1972">Per Martin-Löf, "An intuitionistic theory of types", written 1972 at the University of Stockholm; published in G. Sambin and J. M. Smith (eds.), ''Twenty-Five Years of Constructive Type Theory'', Oxford University Press, 1998, pp. 127–172. Copy of the 1972 text: https://archive-pml.github.io/martin-lof/pdfs/An-Intuitionistic-Theory-of-Types-1972.pdf</ref> Girard's argument encodes the Burali-Forti paradox of the largest ordinal.<ref name="sep" /> It appeared in his doctoral thesis at the University of Paris VII in 1972, which Martin-Löf cites when he states that a universe containing itself leads to a contradiction.<ref name="ml1984">Per Martin-Löf, ''Intuitionistic Type Theory'', notes by Giovanni Sambin of a series of lectures given in Padua, June 1980, Bibliopolis, Naples, 1984. Re-typeset edition: https://archive-pml.github.io/martin-lof/pdfs/Bibliopolis-Book-retypeset-1984.pdf</ref> A simplified form of the paradox was published by Antonius Hurkens in 1995.<ref name="hurkens">Antonius J. C. Hurkens, "A simplification of Girard's paradox", in ''Typed Lambda Calculi and Applications (TLCA '95)'', Lecture Notes in Computer Science 902, Springer, 1995, pp. 266–278. doi:10.1007/BFb0014058</ref>

The lesson is the reason Lean has a hierarchy of universes instead of a single type of all types. It is told for the general reader at [[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]] and formally at [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].

== The predicative versions, 1972 to 1984 ==

The 1972 paper replaced the type of all types by a '''universe''' of small types, closed under all the ways of forming types except that it does not contain itself.<ref name="sep" /> Martin-Löf wrote there that the change was drastic: the theory no longer contained intuitionistic simple type theory, and its proof-theoretic strength should be close to that of predicative analysis.<ref name="ml1972" /> The paper was not published until 1998.<ref name="sep" />

The next published version was his paper to the Logic Colloquium held at Bristol in July 1973, printed in 1975 as "An intuitionistic theory of types: predicative part".<ref name="pml">"The collected works of Per Martin-Löf", an online archive of his papers, list of works with dates. https://archive-pml.github.io/</ref> It extended the single universe to a countable hierarchy of universes and added a uniform identity type, the type of proofs that two objects are equal.<ref name="sep" /><ref name="ml1975">Per Martin-Löf, "An intuitionistic theory of types: predicative part", in H. E. Rose and J. C. Shepherdson (eds.), ''Logic Colloquium '73'', Studies in Logic and the Foundations of Mathematics 80, North-Holland, 1975, pp. 73–118. doi:10.1016/S0049-237X(08)71945-1</ref>

At the International Congress of Logic, Methodology and Philosophy of Science at Hannover in 1979 he presented "Constructive mathematics and computer programming", published in 1982. It explained that the theory is at once a programming language and a foundation for constructive mathematics. It also introduced the extensional form of the theory, in which two objects proved equal are treated as the same for the purposes of type checking.<ref name="sep" /><ref name="ml1982">Per Martin-Löf, "Constructive mathematics and computer programming", in L. J. Cohen, J. Łoś, H. Pfeiffer and K.-P. Podewski (eds.), ''Logic, Methodology and Philosophy of Science VI'', North-Holland, 1982, pp. 153–175. doi:10.1016/S0049-237X(09)70189-2</ref>

The best-known account is the short book ''Intuitionistic Type Theory'', Giovanni Sambin's notes of lectures Martin-Löf gave in Padua in June 1980, published by Bibliopolis in 1984.<ref name="ml1984" /> In 1986 Martin-Löf reformulated the theory once more, inside a '''logical framework''' in which function abstraction and the dependent function type are the only binding operations; the encyclopedia entry calls this now the main version.<ref name="sep" />

== Propositions as types as the foundation ==

The Padua lectures distinguish a proposition from a judgement. A proposition is what logical operations combine; a judgement is an act of holding something true, such as "A is a proposition" or "A is true". A proposition is explained by saying what counts as a proof of it, much as a set is explained by saying how its elements are formed. Martin-Löf concludes that keeping the two notions apart would only duplicate them, and identifies them: a proposition is a set, and a proof is an element of it. He calls this the formulae-as-types, or propositions-as-sets, interpretation on which the theory is based.<ref name="ml1984" />

The correspondence itself was older. Curry had observed it for propositional logic in 1958, and Howard and de Bruijn extended it to predicate logic, which needs types that depend on objects.<ref name="sep" /> (For de Bruijn's part, see [[Lean theorem prover/History/Automath|Automath]].) What Martin-Löf added was a theory in which the correspondence is the starting point: the logical connectives and quantifiers are type formers, and a mathematical proof is a program. Lean works the same way; see [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]] and [[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].

== Descendants ==

'''Nuprl.''' One of the first proof assistants for type theory was Nuprl, built by R. L. Constable and colleagues and described in their book of 1986. It is based on an extensional theory close to Martin-Löf's of 1982.<ref name="sep" /><ref name="nuprl">R. L. Constable, S. F. Allen, H. M. Bromley, W. R. Cleaveland, J. F. Cremer, R. W. Harper, D. J. Howe, T. B. Knoblock, N. P. Mendler, P. Panangaden, J. T. Sasaki and S. F. Smith, ''Implementing Mathematics with the Nuprl Proof Development System'', Prentice-Hall, 1986. ISBN 0-13-451832-2. Catalogue record: https://openlibrary.org/books/OL2715187M</ref> Gordon counts it among the systems built in the LCF manner, with ML as metalanguage.<ref name="gordon2000">Mike Gordon, "From LCF to HOL: a short history", in G. Plotkin, C. Stirling and M. Tofte (eds.), ''Proof, Language, and Interaction: Essays in Honour of Robin Milner'', MIT Press, 2000. Author's copy: https://www.cl.cam.ac.uk/~mjcg/papers/HolHistory.pdf</ref>

'''ALF and Agda.''' Ulf Norell's doctoral thesis at Chalmers in 2007 designed and implemented a new Agda, a programming language based on dependent type theory that is also a proof assistant. It cites as earlier systems the ALF proof editor of L. Magnusson and B. Nordström (1994) and the earlier Agda of Catarina Coquand and Thierry Coquand (1999).<ref name="norell">Ulf Norell, ''Towards a Practical Programming Language Based on Dependent Type Theory'', PhD thesis, Chalmers University of Technology and Göteborg University, 2007. https://www.cse.chalmers.se/~ulfn/papers/thesis.pdf</ref><ref name="agda2009">Ana Bove, Peter Dybjer and Ulf Norell, "A brief overview of Agda – a functional language with dependent types", in ''Theorem Proving in Higher Order Logics (TPHOLs 2009)'', Lecture Notes in Computer Science 5674, Springer, 2009, pp. 73–78. doi:10.1007/978-3-642-03359-9_6</ref> Agda is based on the logical-framework formulation of Martin-Löf's predicative theory.<ref name="sep" />

'''The other branch.''' Coq and Lean descend instead from the Calculus of Constructions, which is impredicative; that line is followed at [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]. The encyclopedia entry notes that the Calculus of Inductive Constructions has a predicative part that follows Martin-Löf's principles.<ref name="sep" />

== What Lean took ==

Lean's logic combines the two lines. The 2015 description of Lean says that with an impredicative sort of propositions Lean's trusted kernel gives a version of the Calculus of Inductive Constructions, and without one it gives a version of Martin-Löf type theory; in both cases there is a sequence of type universes, which in Lean are not cumulative.<ref name="lean2015">Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf</ref> The universes <code>Type 0</code>, <code>Type 1</code> and so on, each a member of the next and none of itself, follow the pattern Martin-Löf adopted after Girard's paradox in 1972 and extended in 1973. The impredicative <code>Prop</code> is the other branch's contribution.

<blockquote>
Provenance: Martin-Löf's 1972 paper (its first page) and the 1984 Padua notes were read, as were the encyclopedia entry by Dybjer and Palmgren, Norell's thesis (introduction and references), Gordon's history and the 2015 Lean paper. Girard's 1972 thesis, the 1975 and 1982 papers, Hurkens's paper, the Nuprl book and the 2009 Agda overview were not opened; their details come from the publishers' records, the encyclopedia entry and Martin-Löf's own references.
</blockquote>

== Next ==

[[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]]

== References ==
<references />

Lean theorem prover/History/LCF and the tactic idea

2026-10-15T19:35:25Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:LCF and the tactic idea}}
{{Lean theorem prover map}}
LCF was a proof checker built by Robin Milner, first at Stanford in 1972 and then, in a new design, at Edinburgh. Two ideas from the Edinburgh design run through many proof assistants since: a protected type of theorems, so that only the rules of the logic can produce one, and tactics, programs that reduce a goal to simpler goals. To make tactics programmable, Milner and his colleagues designed a programming language, ML. This page follows those ideas from 1972 to Lean.

== Stanford LCF ==

"LCF" stands for Logic for Computable Functions, Milner's name for a logic Dana Scott devised in 1969 for reasoning about recursively defined functions; Scott's manuscript was not published until 1993.<ref name="gordon2000">Mike Gordon, "From LCF to HOL: a short history", in G. Plotkin, C. Stirling and M. Tofte (eds.), ''Proof, Language, and Interaction: Essays in Honour of Robin Milner'', MIT Press, 2000. Author's copy: https://www.cl.cam.ac.uk/~mjcg/papers/HolHistory.pdf</ref> Milner built the first checker for it at Stanford in 1972, with Whitfield Diffie, Richard Weyhrauch and Malcolm Newey. His report of that year describes it as an interactive program for generating formal proofs about computable functions, helped by a subgoaling facility and a simplifier.<ref name="gordon2000" /><ref name="milner1972">Robin Milner, ''Logic for Computable Functions: Description of a Machine Implementation'', Stanford Artificial Intelligence Memo AIM-169, Computer Science Report STAN-CS-72-288, Stanford University, May 1972. http://i.stanford.edu/pub/cstr/reports/cs/tr/72/288/CS-TR-72-288.pdf</ref>

A user stated a goal and split it into subgoals with a fixed set of commands, such as induction, until the simplifier could finish each one. Gordon names two limits of the system. The proofs it stored filled the available memory, and its fixed set of proof commands could not easily be extended.<ref name="gordon2000" />

== Edinburgh LCF and the type of theorems ==

Around 1973 Milner moved to Edinburgh and began a successor, Edinburgh LCF, first with Lockwood Morris and Malcolm Newey, and from 1975 with Christopher Wadsworth and Mike Gordon.<ref name="gordon2000" />

The answer to the first limit was to keep theorems and discard proofs. To keep that safe, Milner made '''theorem''' an abstract data type. Its only given values were instances of the axioms, and its only operations were the rules of inference. A program could hold a value of type theorem only if it had obtained it from axioms by applying rules, so type checking alone guaranteed that every such value was a theorem of the logic.<ref name="gordon2000" /> The steps of a proof were carried out but not recorded. The guarantee lies in the programming language, not in a stored proof that someone else could check later.

== ML, tactics and tacticals ==

The answer to the second limit was a programming language in which users could write their own proof procedures. Milner, with Morris and Newey, designed '''ML''', the "Meta Language", strictly typed so that the abstract type of theorems could not be circumvented.<ref name="gordon2000" /> It was described at the 1978 Symposium on Principles of Programming Languages.<ref name="popl1978">M. Gordon, R. Milner, L. Morris, M. Newey and C. Wadsworth, "A metalanguage for interactive proof in LCF", in ''Proceedings of the 5th ACM SIGACT-SIGPLAN Symposium on Principles of Programming Languages (POPL '78)'', ACM, 1978, pp. 119–130. doi:10.1145/512760.512773</ref> Milner's account of ML's polymorphic type inference appeared the same year.<ref name="milner1978">Robin Milner, "A theory of type polymorphism in programming", ''Journal of Computer and System Sciences'' 17 (3), 1978, pp. 348–375. doi:10.1016/0022-0000(78)90014-4</ref>

In ML a strategy for reducing a goal to subgoals is a function, which Milner called a '''tactic'''. Operations that combine strategies, taking tactics as arguments and returning tactics, are higher-order functions, which he called '''tacticals'''. Since a tactic may be applied to a goal it cannot handle, ML was given exceptions, so that a failing tactic could signal failure and another be tried. Gordon records that the needs of theorem proving shaped the first ML in detail.<ref name="gordon2000" />

The work was written up as ''Edinburgh LCF'' by Gordon, Milner and Wadsworth in 1979.<ref name="lcf1979">Michael J. Gordon, Robin Milner and Christopher P. Wadsworth, ''Edinburgh LCF: A Mechanised Logic of Computation'', Lecture Notes in Computer Science 78, Springer, 1979. doi:10.1007/3-540-09724-4</ref> In 1991 Milner received the ACM Turing Award; the citation names LCF, "probably the first theoretically based yet practical tool for machine-assisted proof construction", and ML among his achievements.<ref name="turing1991">Announcement of the 1991 ACM Turing Award to Robin Milner, with the short citation, forwarded to the TYPES mailing list, 1 November 1991. https://www.engineering.upenn.edu/~sweirich/types/archive/1991/msg00062.html</ref>

== Descendants ==

'''Cambridge LCF.''' In the early 1980s Lawrence Paulson at Cambridge and Gérard Huet in France reworked the system together. Huet improved and extended ML, and his group went on to develop Caml. Paulson's version, Cambridge LCF, was completed around 1985 and described in his 1987 book ''Logic and Computation''.<ref name="gordon2000" />

'''HOL.''' Gordon adapted Cambridge LCF to classical higher-order logic for verifying hardware. HOL kept LCF's syntax, its abstract type of theorems and its tactics, but read types as ordinary sets. A stable version, HOL88, appeared in about 1988. Reimplementations followed: HOL90, in Standard ML, by Konrad Slind, and HOL Light, in Caml Light, by John Harrison and Konrad Slind.<ref name="gordon2000" /> In 2017 Ebner and colleagues noted that HOL4 and HOL Light still work in the original LCF manner, with the user interacting directly in ML.<ref name="ebner2017">Gabriel Ebner, Sebastian Ullrich, Jared Roesch, Jeremy Avigad and Leonardo de Moura, "A metaprogramming framework for formal verification", ''Proceedings of the ACM on Programming Languages'' 1 (ICFP), article 34, 2017. doi:10.1145/3110278. Author's copy: https://lean-lang.org/papers/tactic.pdf</ref>

'''Isabelle.''' Paulson then built Isabelle, a generic prover in which the rules of many logics are stated declaratively in a common metalogic and combined by higher-order unification.<ref name="gordon2000" /><ref name="paulson1989">Lawrence C. Paulson, "The foundation of a generic theorem prover", ''Journal of Automated Reasoning'' 5 (3), 1989, pp. 363–397. doi:10.1007/BF00248324. Preprint: https://arxiv.org/abs/cs/9301105</ref> Gordon notes that Isabelle keeps Milner's key idea, the abstract type of theorems, and lifts it to the metalogic.<ref name="gordon2000" />

'''Type theories.''' The LCF method, with ML as its metalanguage, was also applied to logics quite unlike Scott's. Gordon lists Nuprl, a proof system for Martin-Löf type theory, and one for the Calculus of Constructions among the LCF-style systems.<ref name="gordon2000" /> Those are the subjects of [[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]] and [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].

== The line to Lean ==

Lean took the tactic idea and changed where the guarantee lies. In Lean, as in Automath, a proof is a term of the type that states the theorem. Tactics are instructions that describe how to construct such a term, and they support writing a proof incrementally, one step at a time.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', chapter "Tactics". https://lean-lang.org/theorem_proving_in_lean4/tactics.html</ref> The first description of Lean, in 2015, presents tactics as one way, beside writing terms directly, of constructing proof terms, as in Coq, HOL Light, Isabelle and PVS, and describes Lean's small trusted kernel and proof terms that can be checked independently.<ref name="lean2015">Leonardo de Moura, Soonho Kong, Jeremy Avigad, Floris van Doorn and Jakob von Raumer, "The Lean Theorem Prover (system description)", in ''Automated Deduction – CADE-25'', Lecture Notes in Computer Science 9195, Springer, 2015, pp. 378–388. doi:10.1007/978-3-319-21401-6_26. Author's copy: https://lean-lang.org/papers/system.pdf</ref> In LCF a faulty tactic is stopped by the type discipline of ML; in Lean whatever term a tactic produces must still pass Lean's kernel. The two arrangements are compared at [[Lean theorem prover/Explainers/What has to be trusted|What has to be trusted]].

Lean also took the metalanguage idea, but made the metalanguage Lean itself. The 2017 paper on Lean 3's metaprogramming framework recalls that ML was designed as the metalanguage for LCF, and describes tactics written in Lean, in the same files and with the same library as the mathematics they serve.<ref name="ebner2017" /> Lean 4 goes further: it is implemented largely in Lean, and users can extend its parser, elaborator and tactics in Lean.<ref name="lean4">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37. Author's copy: https://lean-lang.org/papers/lean4.pdf</ref> How tactics work in Lean today is described at [[Lean theorem prover/Explainers/Tactics|Tactics]] and [[Lean theorem prover/System/The tactic framework|The tactic framework]].

<blockquote>
Provenance: Gordon's 2000 history, the Lean papers of 2015, 2017 and 2021 and the tactics chapter of ''Theorem Proving in Lean 4'' were read for this page. Milner's 1972 report was read in its opening pages only. Milner's 1978 paper was read in its opening pages, and Paulson's 1989 paper in its preprint (abstract and history). The 1978 POPL paper and the 1979 book were not opened; their details come from Gordon's reference list and the publishers' records. The account of Stanford and Edinburgh LCF follows Gordon, a participant from 1975.
</blockquote>

== Next ==

[[Lean theorem prover/History/Martin-Löf type theory|Martin-Löf type theory]]

== References ==
<references />

Lean theorem prover/History/Automath

2026-10-15T19:35:23Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Automath}}
{{Lean theorem prover map}}
Automath was the first working system for checking mathematics by computer.<ref name="gn2022" /> N. G. de Bruijn designed it at Eindhoven in the late 1960s, and his group used it through the 1970s. This page states what the project set out to do, what its languages were, what its largest text showed, and which of its ideas Lean still uses.

== A language for whole books ==

De Bruijn's own survey of 1980 says the project "was conceived in 1966" and that the first report was written in 1968.<ref name="survey">N. G. de Bruijn, "A survey of the project Automath", in J. P. Seldin and J. R. Hindley (eds.), ''To H. B. Curry: Essays on Combinatory Logic, Lambda Calculus and Formalism'', Academic Press, 1980, pp. 579–606; reprinted in Nederpelt, Geuvers and de Vrijer (eds.), ''Selected Papers on Automath'' (1994), pp. 141–161. Scan in the Automath Archive: https://automath.win.tue.nl/archive/pdf/aut072.pdf</ref> His preface to van Benthem Jutting's book of 1979 gives early 1967 instead, and the Automath Archive at Eindhoven dates the first ideas to around 1967 and the large-scale work to roughly 1970–1975.<ref name="cwi" /><ref name="archive">The Automath Archive, Eindhoven University of Technology, "About Automath". https://automath.win.tue.nl/aboutautomath.htm</ref> An early published account is de Bruijn's paper to the Symposium on Automatic Demonstration at Versailles in December 1968, printed in 1970, which says that the language was developed in 1967 and 1968.<ref name="aut1970">N. G. de Bruijn, "The mathematical language AUTOMATH, its usage, and some of its extensions", in ''Symposium on Automatic Demonstration'', Lecture Notes in Mathematics 125, Springer, 1970, pp. 29–61. doi:10.1007/BFb0060623. Scan in the Automath Archive: https://automath.win.tue.nl/archive/pdf/aut002.pdf</ref>

The aim was a way of writing entire mathematical theories so precisely that their correctness could be checked by formal operations on the text, without any appeal to meaning. If the checking is formal, a computer can do it.<ref name="survey" /> The name means mathematics aided by an automaton.<ref name="gn2022">Herman Geuvers and Rob Nederpelt, "Characteristics of de Bruijn's early proof checker Automath", ''Fundamenta Informaticae'' 185 (4), 2022, pp. 313–336. doi:10.3233/FI-222112. Preprint: https://arxiv.org/abs/2203.01173</ref>

An Automath text is a '''book''': a sequence of lines, each checked against the lines before it. A line either opens an assumption (a variable of a stated type), makes a definition (a name for an expression of a stated type), or introduces a primitive notion, which is how axioms enter. A theorem is a definition whose type is the proposition and whose body is the proof. Contexts are named by their last variable, so a later line can return to an earlier context without repeating it.<ref name="gn2022" />

== Propositions as types ==

Automath treated a proof of a proposition as an object whose type is that proposition. De Bruijn's survey traces this idea to Curry and Feys (1958) and to Howard (1969), and states that it appeared in his own 1968 work independently of them.<ref name="survey" /> In the same survey he records the name '''proof irrelevance''' for the rule that any two proofs of one proposition are definitionally equal, introduced in a report of 1974.<ref name="survey" /> Both ideas are part of Lean's logic: see [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]] and [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].

== The languages ==

Automath was a family of languages, not one. The survey presents them in stages. A simple base language, PAL, admits typed variables and definitions; adding lambda abstraction gives '''AUT-68''', long called simply Automath; a slightly stronger variant is '''AUT-QE'''. J. Zucker's '''AUT-PI''' extended AUT-68 in another direction and was easier to write. '''AUT-SL''' ("single line") removed the restrictions on abstraction so that a whole book could be written as one expression, mainly to give the theory a clean form.<ref name="survey" /> AUT-68 and AUT-QE were the languages most used.<ref name="gn2022" />

The survey reports that for these languages checking is decidable: a machine can always settle whether a line is correct. Doing so efficiently was harder, since the naive method of reducing expressions to normal form could repeat a great deal of work. Most of the work on the checking programs was done by I. Zandleven between 1971 and 1976.<ref name="survey" />

== Landau's ''Grundlagen'' ==

The test of the system was a whole textbook. L. S. van Benthem Jutting translated Edmund Landau's ''Grundlagen der Analysis'' (1930), which constructs the number systems from the natural numbers up to the complex numbers, line by line into AUT-QE. A five-volume report of the translation appeared in 1976, and his experiences are in his doctoral thesis, written under de Bruijn and W. Peremans and completed at Eindhoven in 1977.<ref name="survey" /><ref name="wiedijk2002" /><ref name="mgp">Mathematics Genealogy Project, entry for Lambert S. van Benthem Jutting: Ph.D., Technische Universiteit Eindhoven, 1977, dissertation "Checking Landau's 'Grundlagen' in the Automath System", advisors N. G. de Bruijn and W. Peremans. https://www.mathgenealogy.org/id.php?id=63580</ref> The thesis was published in 1979 as Mathematical Centre Tracts 83.<ref name="cwi">L. S. van Benthem Jutting, ''Checking Landau's "Grundlagen" in the Automath System'', Mathematical Centre Tracts 83, Mathematisch Centrum, Amsterdam, 1979. ISBN 90-6196-147-5. Record and scan: https://ir.cwi.nl/pub/13104</ref>

De Bruijn explained the choice of book: Landau's steps do not grow larger towards the end, and the group wanted to show that Automath could handle mathematics written without it in mind, rather than mathematics rewritten to suit it.<ref name="survey" />

The files outlived the machines. By the early 1990s the original checkers no longer ran, because the language they were written in and the computer they ran on no longer existed, and the copies of the translation had become corrupted. Freek Wiedijk repaired them from the printed 1976 report and wrote a new checker for AUT-68 and AUT-QE. By his count the translation has 10,702 lines and is about 3.9 times the size of the German original, or 3.7 times when both files are compressed; he had earlier named that compressed ratio the '''de Bruijn factor'''. He reports that the two checkers of the 1970s took about 35 and 69 minutes over it, and his own 0.6 seconds on a 1 GHz machine.<ref name="wiedijk2002">Freek Wiedijk, "A new implementation of Automath", ''Journal of Automated Reasoning'' 29 (3–4), 2002, pp. 365–387. doi:10.1023/A:1021983302516. Author's copy: https://www.cs.ru.nl/~freek/aut/aut.pdf</ref>

== What it did not have ==

Automath had no automation. Every proof term was written by hand, and the checker only confirmed it.<ref name="bw2005">Henk Barendregt and Freek Wiedijk, "The challenge of computer mathematics", ''Philosophical Transactions of the Royal Society A'' 363 (1835), 2005, pp. 2351–2375. doi:10.1098/rsta.2005.1650. Author's copy: https://www.cs.ru.nl/~freek/pubs/rspaper.pdf</ref> It had no inductive types, so basic types had to be introduced by axioms; and the large texts of the 1970s used classical logic.<ref name="wiedijk-page">Freek Wiedijk, "Automath" (notes accompanying the aut checker). https://www.cs.ru.nl/~freek/aut/</ref> Wiedijk writes that the project was very active in the 1970s and ended when its funding stopped.<ref name="wiedijk2002" />

== What lasted ==

'''De Bruijn indices.''' In 1972 de Bruijn proposed writing a bound variable not by a name but by a number counting how many binders lie between the variable and the one that binds it. Renaming bound variables causes considerable trouble in programs that manipulate formulas, and with this notation it never arises. The paper claims that its notation is good for machines and for reasoning about the calculus, but not that it is easy for human readers, and a section of it applies the notation to Automath.<ref name="nameless">N. G. de Bruijn, "Lambda calculus notation with nameless dummies, a tool for automatic formula manipulation, with application to the Church-Rosser theorem", ''Indagationes Mathematicae'' 34 (= ''Proceedings KNAW'' A 75), 1972, pp. 381–392. doi:10.1016/1385-7258(72)90034-0. Reprint from ''Selected Papers on Automath'' in the Eindhoven repository: https://alexandria.tue.nl/repository/freearticles/597619.pdf</ref> Lean represents a bound variable in exactly this way: in its type of expressions, the constructor for a bound variable carries a de Bruijn index.<ref name="leanexpr">Lean 4 source, <code>src/Lean/Expr.lean</code>, documentation of <code>Expr.bvar</code>, version 4.34.1. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Expr.lean</ref>

'''The de Bruijn criterion.''' A proof may run to megabytes, yet the program that checks it can be small enough for a person to inspect. Barendregt and Wiedijk call a system that allows its proofs to be checked independently by such a small program one that satisfies the '''de Bruijn criterion'''.<ref name="bw2005" /> The name is later than Automath; the practice it names is Automath's. Lean's version of it is described at [[Lean theorem prover/Explainers/The small trusted core|The small trusted core]] and [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]].

'''The line to the Calculus of Constructions.''' Geuvers and Nederpelt state that Automath's goals and syntactic ideas inspired Thierry Coquand and Gérard Huet to develop the Calculus of Constructions, the ancestor of the logic Lean uses.<ref name="gn2022" /> That line is followed at [[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].

The standard collection of the project's papers, including parts of van Benthem Jutting's thesis and de Bruijn's survey, is ''Selected Papers on Automath'' (1994).<ref name="sp1994">R. P. Nederpelt, J. H. Geuvers and R. C. de Vrijer (eds.), ''Selected Papers on Automath'', Studies in Logic and the Foundations of Mathematics 133, North-Holland, Amsterdam, 1994. ISBN 0-444-89822-0. Publisher's page with contents: https://shop.elsevier.com/books/selected-papers-on-automath/nederpelt/978-0-444-89822-7</ref>

<blockquote>
Provenance: de Bruijn's 1980 survey, Wiedijk's 2002 paper, Barendregt and Wiedijk's 2005 paper and Geuvers and Nederpelt's 2022 paper were read for this page; the 1970 and 1972 papers were read in their opening pages only, in scans. The published form of van Benthem Jutting's thesis was read in its title page, contents, de Bruijn's preface and introduction. The 1994 collection was not opened; its details come from the publisher's record.
</blockquote>

== Next ==

[[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]]

== References ==
<references />

Lean theorem prover/System/Monads and do-notation

2026-10-15T19:35:22Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Monads and do-notation}}
{{Plebeian|Lean theorem prover/Explainers/Programs and proofs in one language}}
{{Lean theorem prover map}}

Lean is a purely functional language: a function's result depends only on its arguments,
and evaluating it changes nothing else. Programs still need failure, state, input and output.
Lean represents these '''effects''' as values, using '''monads''', and provides
'''do-notation''' so that programs using them can be written in an imperative style, with
sequencing, mutable local variables, loops and early return. This page shows the
<code>Monad</code> class, the monad <code>IO</code>, and the features of do-notation, and
then prints what Lean 4.34.1 turns a <code>do</code> block into. The result is an ordinary
term, which is why programs written this way can still be reasoned about.

== The Monad class ==

A monad is a type constructor <code>m</code>, such as <code>Option</code> or
<code>IO</code>, with two operations. <code>pure</code> makes a value into a computation that
has no effect, and <code>bind</code>, written <code>>>=</code>, runs one computation and
passes its result to the next.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @pure
#check @bind
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">@pure : {f : Type u_1 → Type u_2} → [self : Pure f] → {α : Type u_1} → α → f α
@bind : {m : Type u_1 → Type u_2} → [self : Bind m] → {α β : Type u_1} → m α → (α → m β) → m β</pre>

The class <code>Monad</code> brings these together, as a
[[Lean theorem prover/System/Type classes and instance resolution|type class]], with the
related classes <code>Functor</code> and <code>Applicative</code>. The reference manual
notes that these classes follow the use of functors and monads in programming, which is
narrower than the general mathematical notion.<ref name="rm-monads">"Functors, Monads and do-Notation", chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), introduction and section 18.3 "Syntax". [https://lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/ lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/]; [https://lean-lang.org/doc/reference/4.34.0/Functors___-Monads-and--do--Notation/Syntax/ …/Syntax/]</ref>
An instance is not required to obey the monad laws; the separate class
<code>LawfulMonad</code> records that it does, and proofs about monadic programs use
it.<ref name="rm-monads" /><ref name="do">Sebastian Ullrich and Leonardo de Moura, "‘do’ Unchained: Embracing Local Imperativity in a Purely Functional Language (Functional Pearl)", ''Proceedings of the ACM on Programming Languages'' 6 (ICFP), article 109, August 2022, 28 pp. doi:[https://doi.org/10.1145/3547640 10.1145/3547640]; author's copy [https://lean-lang.org/papers/do.pdf lean-lang.org/papers/do.pdf].</ref>

<code>Option</code> is the simplest useful case. A computation of type <code>Option
α</code> either produces a value (<code>some a</code>) or fails (<code>none</code>), and
<code>bind</code> stops at the first failure.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def safeDiv (a b : Nat) : Option Nat :=
if b == 0 then none else some (a / b)

def compute (a b c : Nat) : Option Nat := do
let x ← safeDiv a b
let y ← safeDiv x c
return x + y

#eval compute 100 5 2
#eval compute 100 0 2

example (a b c : Nat) :
compute a b c =
(safeDiv a b >>= fun x => safeDiv x c >>= fun y => pure (x + y)) := rfl
</pre>

The two evaluations print <code>some 30</code> and <code>none</code>. The
<code>example</code> states what the <code>do</code> block means, and <code>rfl</code>
proves it: the block is, by definition, a chain of <code>bind</code>s. The basic rules are
few. A block consisting of one expression is that expression. <code>let x ← e</code>
followed by the rest becomes <code>e >>= fun x => …</code>; an expression whose result is
not named becomes <code>e >>= fun () => …</code>; and <code>let x := e</code> is an ordinary
local definition.<ref name="fpil-do">David Thrane Christiansen, ''Functional Programming in Lean'', online book (code tested with Lean 4.33.0), section 4.4 "<code>do</code>-Notation for Monads". [https://lean-lang.org/functional_programming_in_lean/Monads/do--Notation-for-Monads/ lean-lang.org/functional_programming_in_lean/Monads/do--Notation-for-Monads/]</ref><ref name="rm-monads" />

A '''nested action''' saves naming a result used once: <code>(← e)</code> inside an
expression is lifted out and bound just before the statement that contains it, within the
enclosing <code>do</code> block.<ref name="do" />

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def halfPlusOne (a : Nat) : Option Nat := do
return (← safeDiv a 2) + 1

#eval halfPlusOne 10
</pre>

This prints <code>some 6</code>.

== IO ==

Input and output are effects of the same kind. Lean prints the definition of
<code>IO</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print IO
#print EIO
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">@[reducible] def IO : Type → Type :=
EIO IO.Error
def EIO : Type → Type → Type :=
fun ε α => EST ε IO.RealWorld α</pre>

An <code>IO</code> action is a computation that may fail with an <code>IO.Error</code> and
that takes and returns a token whose type is built from <code>IO.RealWorld</code> (in 4.34.1,
<code>Void IO.RealWorld</code>).<ref name="fpil-io" /> Christiansen's
''Functional Programming in Lean'' explains the device: an action receives a token
standing for the world and returns the changed world, and this is safe as long as no token
is used twice.<ref name="fpil-io">David Thrane Christiansen, ''Functional Programming in Lean'', online book (code tested with Lean 4.33.0), section 4.5 "The IO Monad". [https://lean-lang.org/functional_programming_in_lean/Monads/The-IO-Monad/ lean-lang.org/functional_programming_in_lean/Monads/The-IO-Monad/]</ref>
Seen from inside the logic, an <code>IO</code> action is a value like any other; seen from
outside, it is a set of instructions that the run-time system carries out (see
[[Lean theorem prover/System/The compiler and runtime|the compiler and runtime]]). The
metaprogramming monads described in
[[Lean theorem prover/System/Metaprogramming in Lean|metaprogramming in Lean]] are built on
the same base.

== Mutable variables, loops and early return ==

Haskell's do-notation provides sequencing and little more. Ullrich and de Moura's paper
"‘do’ Unchained" extends it with three features from imperative languages: local mutable
variables, early return, and <code>for</code> loops with <code>break</code> and
<code>continue</code>. The paper gives translation rules from each feature back to pure
code, implements them in Lean 4, and proves in Lean that the rules preserve the meaning of
the program with respect to a simple semantics.<ref name="do" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def sumUntilZero (xs : List Nat) : Nat := Id.run do
let mut total := 0
for x in xs do
if x == 0 then break
total := total + x
return total

#eval sumUntilZero [3, 4, 0, 10]
</pre>

This prints <code>7</code>. <code>Id</code> is the monad with no effect, and
<code>Id.run</code> extracts the result, so <code>sumUntilZero</code> is a pure function
written in imperative style. A mutable variable is local to its <code>do</code> block and
cannot be changed from outside it.<ref name="rm-monads" />

Early return leaves the whole block, from inside a loop if need be:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def findBig (xs : List Nat) : Option Nat := Id.run do
for x in xs do
if x > 10 then return some x
return none

#eval findBig [3, 12, 40]
#eval findBig [1, 2]
</pre>

The results are <code>some 12</code> and <code>none</code>. The same features work in
<code>IO</code>:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def report (lines : List String) : IO Unit := do
let mut count := 0
for line in lines do
if line.isEmpty then continue
count := count + 1
IO.println s!"{count}: {line}"
IO.println s!"{count} non-empty lines"

#eval report ["alpha", "", "beta"]
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">1: alpha
2: beta
2 non-empty lines</pre>

== How they are translated ==

In the paper's rules, each feature becomes a monad transformer wrapped around the block.
A mutable variable becomes the state of a <code>StateT</code> layer, initialised with its
first value; a reassignment sets that state. An early return becomes an exception in an
<code>ExceptT</code> layer, caught at the edge of the block. A <code>for</code> loop becomes
a call to a loop function over the collection, with <code>break</code> and
<code>continue</code> as two further exceptions, one caught outside the loop and one around
its body.<ref name="do" /> The reference manual describes the implementation in the same
terms: the effects are produced by transforming the whole block "in a manner akin to monad
transformers", not by rewriting each statement locally, and a loop requires the collection's
type to implement the class <code>ForIn</code>.<ref name="rm-monads" />

Lean's own implementation differs in its details from the paper's reference
rules.<ref name="do" /> Since version 4.32.0, the default is a new elaborator for
<code>do</code>; the earlier one is still available with <code>set_option
backward.do.legacy true</code>.<ref name="rn432">"Lean 4.32.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), Highlights and Language sections. [https://lean-lang.org/doc/reference/4.34.0/releases/v4.32.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.32.0/]</ref>
What it produces can be printed.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print sumUntilZero
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">def sumUntilZero : List Nat → Nat :=
fun xs =>
(have total := 0;
do
let __s ←
forIn xs total fun x __s =>
have total := __s;
if (x == 0) = true then pure (ForInStep.done total)
else
have total := total + x;
pure (ForInStep.yield total)
have total : Nat := __s
pure total).run</pre>

The loop has become a call to <code>forIn</code>, the method of <code>ForIn</code>. The
mutable variable <code>total</code> is the loop's state: each pass of the body receives it
as <code>__s</code> and returns the new value. <code>break</code> has become
<code>ForInStep.done</code>, which tells <code>forIn</code> to stop, and the normal end of
the body has become <code>ForInStep.yield</code>, which tells it to go on. "Mutation" is
rebinding a name with <code>have</code>.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print findBig
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">def findBig : List Nat → Option Nat :=
fun xs =>
(do
let __s ←
forIn xs (none, ()) fun x __s =>
if x > 10 then pure (ForInStep.done (some (some x), ())) else pure (ForInStep.yield (none, ()))
have __r : Option (Option Nat) × Unit := __s
match __r.fst with
| some r => pure r
| none => pure none).run</pre>

Here the early return travels in the loop's state. The first component is
<code>none</code> while the loop runs normally and <code>some v</code> once
<code>return v</code> has been executed; after the loop, a <code>match</code> either returns
that value or continues with the rest of the block. This is the exception path of the
paper's rules, encoded directly.

== Why it matters for proofs ==

The output of the translation is an ordinary Lean term built from <code>bind</code>,
<code>pure</code>, <code>forIn</code> and local definitions. Nothing about it is special to
the Lean kernel, and a theorem about a <code>do</code> program is a theorem about that term.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem sumUntilZero_nil : sumUntilZero [] = 0 := rfl

example : sumUntilZero [1, 2, 3, 0, 5] = 6 := by decide

theorem findBig_nil : findBig [] = none := rfl
</pre>

All three are accepted. Ullrich and de Moura prove more general facts in the same way, for
example that a block with two nested <code>for</code> loops and an early return equals a
search function defined by recursion, for every monad satisfying <code>LawfulMonad</code>,
using induction and the simplifier.<ref name="do" /> Local imperativity is therefore a
matter of notation. The programs remain pure functions, and the reasoning about them is the
reasoning used for any other Lean definition.

== Next ==

[[Lean theorem prover/History/Automath|Automath]] begins the history, with the first system
for checking mathematics by computer. Within this section, the page on
[[Lean theorem prover/System/Syntax extension and hygienic macros|syntax
extension and hygienic macros]] shows how notation of this kind is defined.

== References ==

<references />

Lean theorem prover/System/Proof export and independent checkers

2026-10-15T19:35:20Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Proof export and independent checkers}}
{{Plebeian|Lean theorem prover/Explainers/Checking a proof again later}}
{{Lean theorem prover map}}

When a Lean source file is elaborated, the Lean kernel checks every definition and theorem
before it enters Lean's environment, its table of definitions and theorems. That first check
happens inside the same program that parsed the file, ran its tactics and executed whatever
code the file and its imports contain. This page is about checking again: listing the axioms
a theorem depends on, replaying compiled results through the Lean kernel with
<code>leanchecker</code>, exporting proofs to a file, and checking that file with checkers
written independently of Lean. For each, it says what the check guards against and what it
does not. The examples were run with Lean 4.34.1.

== What the first check leaves open ==

Lean's reference manual sets out an escalating series of checks and distinguishes two
situations. In the '''honest''' case the author is trying to produce a valid proof and the
risks are mistakes and bugs. In the '''malicious''' case someone is trying to mislead: by
exploiting bugs, by code that circumvents the system, or by compromising the machine; the
manual counts unreviewed proofs generated by AI in this case. It also separates two
questions: whether a theorem has a valid proof, and what the theorem's statement
means.<ref name="rm-vp">"Validating a Lean Proof", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), with its sections "The Blue Double Check Marks", "Printing Axioms", "Re-Checking Proofs with lean4checker", "Gold Standard: comparator and external checkers", "Remaining Issues" and "On Lean.trustCompiler (up to Lean 4.28.0)". [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs/]</ref>

The ordinary check, a theorem accepted in the editor or a Lake build of its Lean module
without errors or warnings, protects against incomplete proofs, an explicit
<code>sorry</code> in the theorem itself and honest bugs in tactics and other metaprograms. It assumes that the statement says
what is intended, that the authors of imported libraries are honest, and that no unsound
axiom has been declared and used.<ref name="rm-vp" /> The checks below remove some of these
assumptions.

== Listing the axioms ==

<code>#print axioms</code> lists every axiom a theorem depends on, directly or through the
theorems it uses.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem two_add_two : 2 + 2 = 4 := rfl

theorem em_or (p : Prop) : p ∨ ¬p := Classical.em p

theorem unfinished : 2 + 2 = 5 := sorry

#print axioms two_add_two
#print axioms em_or
#print axioms unfinished
</pre>

Lean warns <code>declaration uses `sorry`</code> at the third theorem, and prints:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">'two_add_two' does not depend on any axioms
'em_or' depends on axioms: [propext, Classical.choice, Quot.sound]
'unfinished' depends on axioms: [sorryAx]</pre>

<code>propext</code>, <code>Classical.choice</code> and <code>Quot.sound</code> are Lean's
three standard axioms (see [[Lean theorem prover/Foundations/The three axioms|the three
axioms]]). <code>sorryAx</code> marks a gap: a <code>sorry</code> or an incomplete proof
somewhere in the dependencies, which the editor's mark next to the theorem does not
reveal.<ref name="rm-vp" />

The command also exposes proofs that rest on running compiled code. The page on
[[Lean theorem prover/System/The compiler and runtime|the compiler and runtime]] defines a
function whose compiled code, supplied through <code>@[implemented_by]</code>, disagrees
with its definition. A tactic that trusts compiled code can then prove a falsehood:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def alwaysZero (_ : Nat) : Nat := 0

@[implemented_by alwaysZero]
def ident (n : Nat) : Nat := n

theorem ident_five : ident 5 = 5 := rfl

theorem ident_five_zero : ident 5 = 0 := by decide +native

theorem oops : False := by
have h1 := ident_five
have h2 := ident_five_zero
omega

#print axioms oops
</pre>

Everything is accepted, and the last line prints

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">'oops' depends on axioms: [propext, Quot.sound, ident_five_zero._native.decide.ax_1_1]</pre>

<code>decide +native</code> evaluated the claim with compiled code and admitted the result
as a new axiom. Since Lean 4.29.0 each such computation has its own axiom, named after the
theorem that made it; before that, all of them appeared as one axiom,
<code>Lean.trustCompiler</code>.<ref name="rm-vp" /> Any axiom other than the standard three
means that the proof depends on something the Lean kernel did not check.

<code>#print axioms</code> reads Lean's environment as it stands. It cannot detect a theorem
that entered that table without being checked at all.

== Replaying through the Lean kernel: leanchecker ==

Lean's environment is held in memory while a file is processed and saved, Lean module by
Lean module, in <code>.olean</code> files. Code run during elaboration has the access it
needs to add a constant to that table without passing it to the Lean kernel, and Lean has
a debugging option, <code>debug.skipKernelTC</code>, that skips the check.<ref name="rm-vp" /> The
following file uses it together with the false tactic from [[Lean theorem prover/System/Metaprogramming in Lean|metaprogramming in
Lean]], which the Lean kernel would reject.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Elab Tactic

elab "cheat" : tactic => do
let goal ← getMainGoal
goal.assign (mkConst ``True.intro)
replaceMainGoal []

set_option debug.skipKernelTC true in
theorem bad : False := by cheat

#print axioms bad
</pre>

As the library <code>Hack</code> of a small Lake package, it compiles without error, and the
axiom check reports nothing amiss:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">ℹ [2/3] Built Hack (868ms)
info: Hack.lean:12:0: 'bad' does not depend on any axioms
Build completed successfully (3 jobs).</pre>

The reference manual names <code>debug.skipKernelTC</code> as an example of code whose only
purpose is to circumvent the system.<ref name="rm-vp" /> The second check exists for this
case. '''<code>leanchecker</code>''', which is part of the Lean 4.34.1 toolchain, reads the
<code>.olean</code> files and replays every definition and theorem in them through the Lean
kernel.<ref name="rm-bt">"Build Tools and Distribution", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/]</ref>
Since Lean 4.28.0 the program is the external checker <code>lean4checker</code>, shipped with
every toolchain;<ref name="rn428">"Lean 4.28.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "External Checker". [https://lean-lang.org/doc/reference/4.34.0/releases/v4.28.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.28.0/]</ref>
the reference manual's chapter on validating proofs still calls it by that
name.<ref name="rm-vp" /> Run as <code>lake env leanchecker --fresh
Hack</code>, it reports:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">uncaught exception: while replaying declaration 'bad':
(kernel) declaration type mismatch, 'bad' has type
True
but it is expected to have type
False</pre>

and exits with a failure. With <code>--fresh</code> it replays the named Lean module and
everything it imports into an empty table; without it, it replays only the Lean module's own
constants on top of its imports.<ref name="rm-vp" /><ref name="l4l" />

According to the reference manual, this check protects against bugs in Lean's handling of
the Lean kernel's state, for instance in parallel processing or imports, and against
metaprograms that deliberately bypass that state. It trusts that the <code>.olean</code>
files are well formed, and a crafted file could defeat it. It also runs after the code under
test has been compiled, and such code, the manual warns, can perform arbitrary actions when
run; a determined attacker can compromise the machine before any check takes
place.<ref name="rm-vp" /> And it uses the same Lean kernel, so it cannot find a bug in the
Lean kernel itself.

== Exporting proofs ==

The next step separates the proof from the program that produced it. '''lean4export''' writes
the constants of a Lean module and everything it depends on to a file in an NDJSON format,
one JSON record per line.<ref name="res-export">"lean4export", Reservoir, the index of Lake packages: "A simple declaration exporter for Lean 4 using the Lean 4 NDJSON export format". [https://reservoir.lean-lang.org/@leanprover/lean4export reservoir.lean-lang.org/@leanprover/lean4export]</ref>
The file contains terms of the type theory and nothing else: no tactics, no notation, no
elaborator. A checker that reads it needs to implement only the type theory: universes,
dependent function types, inductive types and their recursors, quotients and definitional
equality. It need not trust what the file says about derived data. A test in the
Lean Kernel Arena makes the point that a checker "must not blindly trust the recursors it is
handed", and should either check them or derive them anew from the inductive type
itself.<ref name="arena-tut">"Tutorial" test suite, Lean Kernel Arena. [https://arena.lean-lang.org/tutorial/ arena.lean-lang.org/tutorial/]</ref>

== Independent checkers ==

Three programs illustrate the range.

'''nanoda''' is a checker for Lean exports written in Rust, developed independently of
Lean.<ref name="rm-vp" /><ref name="arena-nanoda">"nanoda", checker page, Lean Kernel Arena. [https://arena.lean-lang.org/checker/nanoda/ arena.lean-lang.org/checker/nanoda/]</ref>
A bug would have to occur in both nanoda and the Lean kernel, written separately in
different languages, to let a false theorem through both.

'''Lean4Lean''', by Mario Carneiro, is a type checker for Lean 4 written in Lean. It reads
compiled <code>.olean</code> files, offers the same interface as lean4checker, and can check
the whole of Mathlib, running 20 to 50 per cent slower than the Lean kernel, which is
written in C++. Because it is written in a language with proofs, parts of it can be, and have
been, proved correct against a formalisation of Lean's type theory; that work found a
soundness bug in the Lean kernel, which has since been fixed.<ref name="l4l">Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean, in Lean", in ''31st International Conference on Types for Proofs and Programs (TYPES 2025)'', Leibniz International Proceedings in Informatics 384, Schloss Dagstuhl, 2026, 2:1–2:23. doi:[https://doi.org/10.4230/LIPIcs.TYPES.2025.2 10.4230/LIPIcs.TYPES.2025.2]; full version [https://arxiv.org/abs/2403.14064 arXiv:2403.14064].</ref>
Its description in the Lean Kernel Arena notes the limit of the approach: it follows the C++
implementation closely, and so "likely shares some implementation bugs with it".<ref name="arena-l4l">"lean4lean", checker page, Lean Kernel Arena. [https://arena.lean-lang.org/checker/lean4lean arena.lean-lang.org/checker/lean4lean]</ref>

'''comparator''' is the reference manual's "gold standard" for high-risk settings; the manual
names proof marketplaces, competitions with high rewards, and unaligned AI. The theorem
statement is written first, in a trusted setting, as a challenge file. comparator compiles
the proposed proof inside a sandbox, exports it, and, outside the sandbox, validates the export, replays it with the Lean kernel,
nanoda or both, and checks that the proved statements are exactly those in the challenge
file.<ref name="rm-vp" />

The '''Lean Kernel Arena''' tests such checkers side by side. It runs each on the same
exported tests, some of which a correct checker must accept and some of which it must
reject, and publishes the results; the Lean kernel of version 4.34.1 is among the checkers
listed.<ref name="arena">Lean Kernel Arena: "presents, tests and benchmarks proof checkers for the Lean Theorem Prover". [https://arena.lean-lang.org arena.lean-lang.org]</ref><ref name="arena-tut" />

== What each check guards against ==

{| class="wikitable"
! Check !! Reads !! Guards against !! Does not guard against
|-
| Editor or Lake build || source files || incomplete proofs, <code>sorry</code> in the theorem, honest bugs in tactics || gaps in dependencies, extra axioms, bypassed checks
|-
| <code>#print axioms</code> || Lean's environment in memory || <code>sorry</code> anywhere in the dependencies, custom axioms, native computation || constants that were never checked
|-
| <code>leanchecker</code> || <code>.olean</code> files || constants added without the Lean kernel's check, bugs in handling the Lean kernel's state || crafted <code>.olean</code> files, a compromised machine, bugs in the Lean kernel
|-
| comparator with an external checker || an export, outside a sandbox || malicious proofs, a bug present in one checker but not all || a bug shared by every checker, an unsound logic, a wrong statement
|}

Sources: the reference manual's chapter on validating proofs,<ref name="rm-vp" /> and the
demonstrations above.

== Why check outside the tool that made the proof ==

The Lean kernel is small, but it is a program, and programs have bugs. Lean 4's kernel was
extended for performance, with fast arithmetic on natural numbers, nested inductive types and
primitive projections among other things, and Carneiro reports that some soundness bugs
entered in the process.<ref name="l4l" /> A second implementation does not make a bug
impossible. It makes a bug matter only if every implementation has it.

There is a second reason. Elaboration runs code, much of it written by users, with the full
rights of a program. A check that runs in the same process, on the same machine, after that
code, inherits whatever that code did. A check that reads an exported file elsewhere depends
only on the file and on the checker.

The checks do not answer the other question, whether the statement means what it is taken to
mean. The reference manual lists among the assumptions that remain even at its gold
standard: the soundness of Lean's logic, the correctness of the tools and the sandbox, the
absence of a bug shared by all checkers, and a statement free of human error, with custom
notation and type classes named as places to look.<ref name="rm-vp" /> That question is
taken up in [[Lean theorem prover/Explainers/Stating the right thing|stating the right thing]].

== Next ==

[[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]] returns to Lean
as a programming language.

== References ==

<references />

Lean theorem prover/System/Lake and Lean projects

2026-10-15T19:35:19Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Lake and Lean projects}}
{{Plebeian|Lean theorem prover/Explainers/A library of mathematics}}
{{Lean theorem prover map}}

A single Lean source file can be checked with the command <code>lean</code>. Anything larger,
a library of hundreds of files or a program with dependencies, is organised as a '''Lake
package''' and compiled by '''Lake''', Lean's build tool, which ships with every version of
Lean. Which version of Lean a project uses is fixed by a one-line file and enforced by
'''elan''', the toolchain manager. This page shows a minimal project as files, the commands
that compile and test it, and how dependencies are pinned, all with Lean 4.34.1 and the Lake
that comes with it.

== The toolchain ==

A Lean '''toolchain''' is the set of programs and files for one version of Lean, among them
<code>lean</code> itself, <code>lake</code>, a C compiler (<code>leanc</code>, a version of Clang), the
program <code>leanchecker</code>, and the compiled standard library and runtime. Toolchains
are installed and selected by elan.<ref name="rm-bt">"Build Tools and Distribution", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/]</ref>
The <code>lean</code> and <code>lake</code> commands a user types are small proxies installed
by elan. Each looks for a file named <code>lean-toolchain</code> in the current directory and
its parents, reads the toolchain named there, installs it if it is missing, and runs the
program from that toolchain. A command can also name a toolchain directly, as in
<code>lake +leanprover/lean4:v4.34.1 new greeting</code>.<ref name="rm-elan">"Managing Toolchains with Elan", section 24.2 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Managing-Toolchains-with-Elan/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Managing-Toolchains-with-Elan/]</ref>

The file holds one line:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">leanprover/lean4:v4.34.1</pre>

The part before the colon names where toolchains come from, and the part after it the
version. A project's file should name an exact version, not a channel such as
<code>stable</code>, so that everyone working on it uses the same Lean. Changing the version
is a one-line edit; the new toolchain is downloaded the next time it is
needed.<ref name="rm-elan" /> This matters more for a proof assistant than for most
languages. The elaborator, the tactics and the library change from one version of Lean to
the next, and a proof that is accepted under one version may fail under another. The
toolchain file records under which version a body of proofs was checked.

== A minimal Lake package ==

<code>lake new greeting</code> creates a directory with a library, an executable and a
configuration file. With Lean 4.34.1 the configuration it writes, <code>lakefile.toml</code>,
is:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">name = "greeting"
version = "0.1.0"
defaultTargets = ["greeting"]

[[lean_lib]]
name = "Greeting"

[[lean_exe]]
name = "greeting"
root = "Main"</pre>

The first lines describe the Lake package itself. Each <code><nowiki>[[lean_lib]]</nowiki></code> table
declares a '''library''', a collection of Lean modules under a root name, here
<code>Greeting</code>; each <code><nowiki>[[lean_exe]]</nowiki></code> declares an '''executable''', a
program whose Lean module defines <code>main</code>.<ref name="rm-lake">"Lake", section 24.1 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), including 24.1.1 "Concepts and Terminology", 24.1.1.2 "Builds", 24.1.1.5 "Test and Lint Drivers" and the TOML configuration reference. [https://lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Lake/ lean-lang.org/doc/reference/4.34.0/Build-Tools-and-Distribution/Lake/]</ref>
The source files follow the names. <code>Greeting.lean</code> is the root of the library and
imports its parts:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">-- This module serves as the root of the `Greeting` library.
-- Import modules here that should be built as part of the library.
import Greeting.Basic</pre>

<code>Greeting/Basic.lean</code> holds the one definition:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">def hello := "world"</pre>

and <code>Main.lean</code> is the program:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">import Greeting

def main : IO Unit :=
IO.println s!"Hello, {hello}!"</pre>

A Lean module's name is its path: <code>Greeting/Basic.lean</code> is the Lean module
<code>Greeting.Basic</code>, and <code>import Greeting.Basic</code> refers to it. Lake reads
the imports to work out the order in which the Lean modules must be compiled.<ref name="rm-lake" />

The configuration can also be written in Lean, as <code>lakefile.lean</code>. <code>lake new
greet2 std.lean</code> writes:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">import Lake
open Lake DSL

package "greet2" where
version := v!"0.1.0"

lean_lib «Greet2» where
-- add library configuration options here

@[default_target]
lean_exe "greet2" where
root := `Main</pre>

The TOML form is purely declarative. The Lean form is a Lean program and can compute its
configuration or define new kinds of target.<ref name="rm-lake" />

== Compiling ==

<code>lake build</code> compiles the default targets and everything they need. In the new
directory it reports:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">info: greeting: no previous manifest, creating one from scratch
info: toolchain not updated; already up-to-date
✔ [2/8] Built Greeting.Basic (277ms)
✔ [3/8] Built Greeting.Basic:c.o (58ms)
✔ [4/8] Built Greeting (225ms)
✔ [5/8] Built Greeting:c.o (66ms)
✔ [6/8] Built Main (244ms)
✔ [7/8] Built Main:c.o (69ms)
✔ [8/8] Built greeting:exe (289ms)
Build completed successfully (8 jobs).</pre>

The first two lines appear on the first run only, and the times in brackets vary from run
to run. Each Lean module is elaborated, which produces an <code>.olean</code> file holding
its definitions and theorems in compiled form, and C code, which is compiled to an object file (<code>:c.o</code>); the
object files are linked into the executable. <code>lake exe greeting</code> then prints
<code>Hello, world!</code>.

Elaboration includes the Lean kernel's check of every definition and theorem, so a
Lake build of a Lean module that finishes without errors or warnings gives the same assurance
as opening it in an editor and seeing it accepted: every theorem in it, and in everything it
imports, has been checked. The reference manual makes the comparison explicitly.<ref name="rm-validating">"Validating a Lean Proof", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "The Blue Double Check Marks". [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs/]</ref>

Running <code>lake build</code> again with nothing changed prints only <code>Build completed
successfully (8 jobs).</code> Lake keeps a '''trace''' for every output, recording a digest of
each input from which it was made; when no input has changed, the output is reused and its
saved messages are replayed instead of being produced again.<ref name="rm-lake" /> Lake keeps its
working state under the directory <code>.lake/</code>: compiled outputs in
<code>.lake/build/</code> and the sources of dependencies in
<code>.lake/packages/</code>.<ref name="rm-lake" />

== Testing ==

<code>lake test</code> runs the Lake package's '''test driver''', a target named in the
configuration. Lake is not a test framework: it finds the driver, compiles it, and, for an
executable, runs it and treats a non-zero exit code as failure. A library can serve as the
driver, and then any elaboration error counts as a failure, including a failed
<code>#guard</code>.<ref name="rm-lake" /> Adding <code>testDriver = "GreetingTest"</code>
and a second library to the configuration,

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">[[lean_lib]]
name = "GreetingTest"</pre>

with the file <code>GreetingTest.lean</code>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">import Greeting

#guard hello == "world"
#guard hello.length == 5</pre>

makes <code>lake test</code> succeed. Changing the last line to claim a length of 6 makes it
fail, with this among its messages:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">error: GreetingTest.lean:4:0: Expression
hello.length == 6
did not evaluate to `true`</pre>

For a library of proofs the distinction between compiling and testing is thin. A theorem
that is false, or whose proof is broken, does not compile.

== Dependencies ==

A Lake package may require others. In <code>lakefile.toml</code> each dependency is a
<code><nowiki>[[require]]</nowiki></code> table. A dependency can come from Reservoir, an online index of Lake
packages, from a Git repository at a given revision, or from a local
path.<ref name="rm-lake" /> The reference manual's example of a dependency taken from
Reservoir is:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">[[require]]
name = "example"
version = "≥2.12.0"
scope = "exampleDev"</pre>

The configuration says which dependencies are wanted. The file
<code>lake-manifest.json</code> says exactly which versions are in use: for each dependency
it records the source and the precise revision. Lake brings each dependency's local copy into
line with lake-manifest.json before compiling, and creates the file if it is missing;
<code>lake update</code> moves the recorded revisions forward. The file is meant to be kept
with the source.<ref name="rm-lake" /> For the minimal project, which has no dependencies,
Lake wrote:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">{"version": "1.2.0",
"packagesDir": ".lake/packages",
"packages": [],
"name": "greeting",
"lakeDir": ".lake",
"fixedToolchain": false}</pre>

Together, <code>lean-toolchain</code>, the configuration file and lake-manifest.json fix the
version of Lean and the exact source of every dependency. That is what makes a Lean project
reproducible: another person, or the same person years later, can obtain the same toolchain
and the same dependencies and have every proof checked again. The large mathematical
libraries described in [[Lean theorem prover/Explainers/A library of mathematics|a library
of mathematics]] are distributed in this form.

== Next ==

[[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]
describes how the results of a Lake build can be checked again outside the program that
produced them.

== References ==

<references />

Lean theorem prover/System/The compiler and runtime

2026-10-15T19:35:16Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The compiler and runtime}}
{{Plebeian|Lean theorem prover/Explainers/Programs and proofs in one language}}
{{Lean theorem prover map}}

A Lean definition is used in two ways. The Lean kernel checks it as a term of the type theory,
and the compiler turns it into machine code that runs. The two paths start from the same
definition and, except in the cases described at the end of this page, do not meet again.
This page follows the second path in Lean 4.34.1: from a definition through the compiler's
intermediate representations to C, the run-time system's reference counting and its updates
in place, the attributes that let compiled code differ from the definition the Lean kernel
sees, and what all of this adds to what has to be trusted.

== Two consumers of one definition ==

When a definition is elaborated, the result goes two ways. The compiler receives it with its
recursion intact; the Lean kernel receives a version in which recursion has been expressed
through recursors or well-founded recursion and can be checked.<ref name="rm-ec">"Elaboration and Compilation", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), sections "Elaboration Results" and "Compilation". [https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/ lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/]</ref>
Before generating code, the compiler erases proofs, which have no run-time
content.<ref name="cade">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction: CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635, section 3. doi:[https://doi.org/10.1007/978-3-030-79876-5_37 10.1007/978-3-030-79876-5_37]; author's copy [https://lean-lang.org/papers/lean4.pdf lean-lang.org/papers/lean4.pdf].</ref>
The compiled code is never shown to the Lean kernel. A theorem about a function is a theorem
about the definition; that the machine code computes the same function is a property of the
compiler, not something the Lean kernel has checked.

== From definitions to C ==

Lean's notes for version 4.22.0, of 14 August 2025, state that "the old compiler has been
replaced by the new compiler".<ref name="rn422">"Lean 4.22.0", in "Release Notes", ''The Lean Language Reference'' (edition covering Lean 4.34.0), Highlights, "New compiler". [https://lean-lang.org/doc/reference/4.34.0/releases/v4.22.0/ lean-lang.org/doc/reference/4.34.0/releases/v4.22.0/]</ref>
In 4.34.1 that compiler, written in Lean, is the one in use. It works in stages:

# The elaborated definition is translated into '''LCNF''', the Lean Compiler Normal Form, a representation in A-normal form in which every intermediate result is bound to a name.<ref name="lcnf">Module documentation of <code>Lean.Compiler.LCNF.Basic</code>, "Lean Compiler Normal Form (LCNF)", Lean API documentation. [https://lean-lang.org/doc/api/Lean/Compiler/LCNF/Basic.html lean-lang.org/doc/api/Lean/Compiler/LCNF/Basic.html]</ref>
# Later passes, still over LCNF, make allocation, reference-count updates and memory reuse explicit instructions. The result is also translated into the compiler's '''IR''', the form that Lean prints on request (below).<ref name="src-compiler">Lean 4 source code, version 4.34.1 (2026), directory <code>src/Lean/Compiler/LCNF</code>: in <code>Passes.lean</code> the passes of the impure phase (<code>insertResetReuse</code>, <code>inferBorrow</code>, <code>explicitBoxing</code>, <code>explicitRc</code>, <code>expandResetReuse</code>), in <code>Main.lean</code> the translation of their result to IR (<code>IR.toIR</code>), and <code>EmitC.lean</code>, which emits C. Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/Lean/Compiler/LCNF</ref><ref name="rm-rc">"Reference Counting", section 12.2 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), including 12.2.2 "Compiler IR". [https://lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Reference-Counting/ lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Reference-Counting/]</ref>
# The same result is emitted as C. Each Lean module becomes a C file, which a C compiler shipped with Lean compiles to native code.<ref name="src-compiler" /><ref name="rm-ec" />

When Lean evaluates code while processing a file, as <code>#eval</code> does, an
interpreter runs the IR, and switches to native code for any function that has been
compiled ahead of time, which includes the standard library.<ref name="cade" /><ref name="rm-ec" />

The IR of a definition can be printed. This function adds one to every element of a list.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option trace.compiler.ir.result true in
def incAll : List Nat → List Nat
| [] => []
| x :: xs => (x + 1) :: incAll xs
</pre>

Lean 4.34.1 prints:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">[Compiler.IR] [result]
def incAll (x_1 : tobj) : tobj :=
case x_1 : tobj of
List.nil →
ret x_1
List.cons →
let x_2 : tobj := proj[0] x_1;
let x_3 : tobj := proj[1] x_1;
block_4 (x_5 : tobj) (x_6 : u8) :=
let x_7 : tagged := 1;
let x_8 : tobj := Nat.add x_2 x_7;
dec x_2;
let x_9 : tobj := incAll x_3;
block_10 (x_11 : obj) :=
ret x_11;
case x_6 : u8 of
Bool.false →
set x_5[1] := x_9;
set x_5[0] := x_8;
jmp block_10 x_5
Bool.true →
let x_12 : obj := ctor_1[List.cons] x_8 x_9;
jmp block_10 x_12;
let x_13 : u8 := isShared x_1;
case x_13 : u8 of
Bool.false →
jmp block_4 x_1 x_13
Bool.true →
inc x_3;
inc x_2;
dec x_1;
jmp block_4 ◾ x_13</pre>

The same definition, given to <code>lean -c</code>, yields a C function. In an excerpt, the
test, the call to the C implementation of addition and the two ways of producing the new
cell read:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">v_isSharedCheck_13_ = !lean_is_exclusive(v_x_1_);
…
v___x_8_ = lean_nat_add(v_head_2_, v___x_7_);
…
if (v_isShared_6_ == 0)
{
lean_ctor_set(v___x_5_, 1, v___x_9_);
lean_ctor_set(v___x_5_, 0, v___x_8_);
…
v_reuseFailAlloc_12_ = lean_alloc_ctor(1, 2, 0);</pre>

== Reference counting and update in place ==

Lean manages memory by '''reference counting'''. Every object on the heap carries a count of
the references to it; the count rises when a reference is copied and falls when one is
dropped, and an object whose count reaches zero is freed at once.<ref name="rm-rc" /> The
traditional objection to reference counting in functional languages is its cost.
Ullrich and de Moura's answer is that an exact count is also information: it says whether a
value is '''shared''', and a value that is not shared may be changed in place without any
observer being able to tell.<ref name="beans">Sebastian Ullrich and Leonardo de Moura, "Counting Immutable Beans: Reference Counting Optimized for Purely Functional Programming", in ''Proceedings of the 31st Symposium on Implementation and Application of Functional Languages (IFL 2019)'', ACM, 2019, article 3, pp. 1–12. doi:[https://doi.org/10.1145/3412932.3412935 10.1145/3412932.3412935]; preprint [https://arxiv.org/abs/1908.05647 arXiv:1908.05647].</ref>

The IR above shows the mechanism. <code>isShared x_1</code> tests the count of the incoming
list cell. If the cell is not shared, the branch <code>Bool.false</code> overwrites its two
fields with <code>set</code> and returns the same cell: the old list is updated in place.
If it is shared, <code>ctor_1[List.cons]</code> allocates a new cell and the old one is left
for its other owners. In the paper this pair of steps is a <code>reset</code> instruction,
which drops an unshared value's references to its fields but keeps its cell, followed by
<code>reuse</code>, which places the new constructor in that cell. The authors observe that
many objects die just before an object of the same kind is created, which they call the
'''resurrection hypothesis''', and that a function such as <code>map</code> applied to an
unshared list therefore allocates no memory at all.<ref name="beans" /> In the Lean 4 system
description this is presented as a programming style, '''functional but in place''': code
is written as pure functions, and runs with destructive updates wherever values are not
shared.<ref name="cade" />

Arrays and strings follow the same rule. Their primitive operations modify the value in place
when they hold the only reference, and copy it otherwise.<ref name="rm-rc" /><ref name="beans" />
Two further techniques keep the cost down. '''Borrowed''' parameters, which a function uses
without consuming, need no count updates, and the compiler infers many of them; and values
reachable from only one thread use cheaper, unsynchronised count updates. Reference counting
cannot reclaim cycles, but the part of Lean that can be reasoned about cannot create
cyclic data, so the runtime has no cycle collector.<ref name="rm-rc" /><ref name="beans" />

== Code that differs from its definition ==

Two attributes let the code that runs differ from the definition that the Lean kernel checks.

'''<code>@[extern "sym"]</code>''' binds a definition to a C symbol: compiled code calls the C
function <code>sym</code> instead of code generated from the definition.<ref name="rm-ffi">"Foreign Function Interface", section 12.4 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Foreign-Function-Interface/ lean-lang.org/doc/reference/4.34.0/Run-Time-Code/Foreign-Function-Interface/]</ref>
Addition of natural numbers is an example. The definition of <code>Nat.add</code>, the one
theorems are about, is by recursion on the unary representation (zero and successor);
compiled code calls <code>lean_nat_add</code>, as in the C above. At run time a natural
number is either a small value stored directly in the machine word or a pointer to a
multi-precision number.<ref name="rm-ffi" /> Lean reports the binding:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean

#eval show CoreM (Option String) from do
return getExternNameFor (← getEnv) `c ``Nat.add
</pre>

This prints <code>some "lean_nat_add"</code>.

'''<code>@[implemented_by f]</code>''' replaces a definition by another Lean function
<code>f</code> in compiled code. Lean's own documentation of the attribute states that "the
provided implementation is not checked to be equivalent to the original
definition".<ref name="impl">Documentation of <code>Lean.Compiler.implementedByAttr</code>, Lean API documentation. [https://lean-lang.org/doc/api/Lean/Compiler/ImplementedByAttr.html lean-lang.org/doc/api/Lean/Compiler/ImplementedByAttr.html]</ref>
Nothing prevents a wrong one.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def alwaysZero (_ : Nat) : Nat := 0

@[implemented_by alwaysZero]
def ident (n : Nat) : Nat := n

#eval ident 5

theorem ident_five : ident 5 = 5 := rfl
</pre>

<code>#eval</code> prints <code>0</code>, and the theorem that <code>ident 5 = 5</code> is
accepted. Both are correct by their own lights: <code>#eval</code> ran the code the compiler
was told to use, and the Lean kernel checked the definition. The most common uses, according to
the same documentation, are to give an efficient unsafe implementation of a function whose
definition is simple to reason about, and to make an unsafe function callable from safe
code.<ref name="impl" /> A safer variant,
<code>@[csimp]</code>, makes the same substitution only on the strength of a proved
equation between the two functions.<ref name="impl" />

== What it adds to what has to be trusted ==

For a proof, ordinarily nothing. Apart from one deprecated primitive,
<code>Lean.reduceBool</code>, whose use <code>#print axioms</code> reports as the axiom
<code>Lean.trustCompiler</code>, the Lean kernel never runs compiled code,<ref name="src-core">Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Core.lean</code>: the documentation of <code>Lean.reduceBool</code> ("When the kernel tries to reduce a term <code>Lean.reduceBool c</code>, it will invoke the Lean interpreter to evaluate <code>c</code>"), deprecated since 2026-02-01, and of <code>Lean.trustCompiler</code> and <code>Lean.ofReduceBool</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Core.lean</ref> so neither the
compiler nor any <code>@[extern]</code> or <code>@[implemented_by]</code> annotation is
consulted when a theorem is checked. The theorem <code>ident_five</code> above holds whatever
the compiled code does.

For a program, everything above is trusted: the compiler, the C compiler, the runtime, and the
claim behind every <code>@[extern]</code> and <code>@[implemented_by]</code> that the code
computes what the definition says. A proof about a function is a proof about the definition.

The two meet in one place. Some tactics, such as <code>decide +native</code> and
<code>bv_decide</code>, prove a statement by running compiled code and admitting its result.
Such a proof depends on the compiler and on every <code>@[extern]</code> and
<code>@[implemented_by]</code> on the path,
and can be wrong when the compiled code disagrees with the definition. Since Lean 4.29.0 each
such computation introduces its own axiom, which <code>#print axioms</code> lists, so the
dependence is visible.<ref name="rm-validating">"Validating a Lean Proof", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "On Lean.trustCompiler (up to Lean 4.28.0)". [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs/]</ref>
[[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]]
shows the function <code>ident</code> above used to prove a falsehood in exactly this way, and
how the axiom gives it away.

== Next ==

[[Lean theorem prover/System/Lake and Lean projects|Lake and Lean projects]] describes how
Lean source files are organised into Lake packages and compiled together.

== References ==

<references />

Lean theorem prover/System/Metaprogramming in Lean

2026-10-15T19:35:15Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Metaprogramming in Lean}}
{{Plebeian|Lean theorem prover/Explainers/Tactics}}
{{Lean theorem prover map}}

A '''metaprogram''' is a Lean program whose data is Lean itself: syntax, terms, goals,
Lean's environment (its table of definitions and theorems). Tactics, elaborators and
custom commands are metaprograms. Lean 4 is written largely in Lean, and the data
structures and functions its own elaborator and tactics use are available to any Lean source
file that imports the library <code>Lean</code>.<ref name="cade">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction: CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:[https://doi.org/10.1007/978-3-030-79876-5_37 10.1007/978-3-030-79876-5_37]; author's copy [https://lean-lang.org/papers/lean4.pdf lean-lang.org/papers/lean4.pdf].</ref>
This page shows the representation of terms, the monads metaprograms run in, and three small
metaprograms compiled by Lean 4.34.1: a term elaborator, a command and a tactic. It ends with
the point on which the whole arrangement rests. A metaprogram is not trusted. What it
produces is checked by the Lean kernel, and a wrong result is rejected, unless that check has
been switched off.

== Terms as data ==

Every term that reaches the Lean kernel is a value of the inductive type
<code>Lean.Expr</code>. Lean prints its definition on request.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Meta Elab Term Command Tactic

#print Lean.Expr
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">inductive Lean.Expr : Type
number of parameters: 0
constructors:
Lean.Expr.bvar : Nat → Expr
Lean.Expr.fvar : FVarId → Expr
Lean.Expr.mvar : MVarId → Expr
Lean.Expr.sort : Level → Expr
Lean.Expr.const : Name → List Level → Expr
Lean.Expr.app : Expr → Expr → Expr
Lean.Expr.lam : Name → Expr → Expr → BinderInfo → Expr
Lean.Expr.forallE : Name → Expr → Expr → BinderInfo → Expr
Lean.Expr.letE : Name → Expr → Expr → Expr → Bool → Expr
Lean.Expr.lit : Literal → Expr
Lean.Expr.mdata : MData → Expr → Expr
Lean.Expr.proj : Name → Nat → Expr → Expr</pre>

The twelve constructors are the type theory's term formers with some additions for
practical use. <code>sort</code> is a universe, <code>const</code> a reference to a named
definition or theorem at given universe levels, <code>app</code> an application,
<code>lam</code> a function, <code>forallE</code> a dependent function type and
<code>letE</code> a local definition. <code>lit</code> holds a natural-number or string
literal, <code>proj</code> a projection from a structure, and <code>mdata</code> attaches
metadata that does not change meaning. Three constructors are variables of different
kinds. <code>bvar</code> is a variable bound inside the term, named by a number, the
'''de Bruijn index''', which counts binders outward; <code>fvar</code> is a free variable
of the current local context, such as a hypothesis in a goal; <code>mvar</code> is a
'''metavariable''', a hole still to be filled (see
[[Lean theorem prover/System/Metavariables and unification|metavariables and unification]]).

A small definition shows the encoding.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def k : Nat → Nat → Nat := fun a _b => a

#eval show MetaM Unit from do
let info ← getConstInfo ``k
IO.println (repr info.value!)
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">Lean.Expr.lam
`a
(Lean.Expr.const `Nat [])
(Lean.Expr.lam `_b (Lean.Expr.const `Nat []) (Lean.Expr.bvar 1) (Lean.BinderInfo.default))
(Lean.BinderInfo.default)</pre>

The body of the inner function is <code>bvar 1</code>: the variable bound one binder further
out than the nearest, which is <code>a</code>. Binder names are kept only for display: two
terms that differ only in the names of bound variables are treated as the same term.

== The monads ==

A metaprogram runs in a monad that gives it access to the state of Lean (see
[[Lean theorem prover/System/Monads and do-notation|monads and do-notation]] for monads in
general). There is a stack of four, each extending the one below it. Lean prints their
definitions.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print CoreM
#print MetaM
#print TermElabM
#print TacticM
#print CommandElabM
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">@[reducible] def Lean.Core.CoreM : Type → Type :=
ReaderT Core.Context (StateRefT' IO.RealWorld Core.State (EIO Exception))
@[reducible] def Lean.Meta.MetaM : Type → Type :=
ReaderT Meta.Context (StateRefT' IO.RealWorld Meta.State CoreM)
@[reducible] def Lean.Elab.Term.TermElabM : Type → Type :=
ReaderT Term.Context (StateRefT' IO.RealWorld Term.State MetaM)
@[reducible] def Lean.Elab.Tactic.TacticM : Type → Type :=
ReaderT Tactic.Context (StateRefT' IO.RealWorld Tactic.State TermElabM)
@[reducible] def Lean.Elab.Command.CommandElabM : Type → Type :=
ReaderT Command.Context (StateRefT' IO.RealWorld Command.State (EIO Exception))</pre>

Each layer adds a read-only context (<code>ReaderT</code>) and a mutable state
(<code>StateRefT'</code>) on top of the layer below. At the bottom, <code>EIO
Exception</code> is input and output that can fail with an exception, so every metaprogram
can do input and output.

* '''<code>CoreM</code>''' gives access to Lean's environment: what has been defined or imported at the current point.
* '''<code>MetaM</code>''' adds the metavariable context, the metavariables in existence and their assignments, and with it the operations of type inference (<code>inferType</code>), reduction (<code>whnf</code>) and definitional-equality checking (<code>isDefEq</code>).
* '''<code>TermElabM</code>''' adds the information the elaborator uses while turning syntax into terms.
* '''<code>TacticM</code>''' adds the list of current goals.<ref name="mpb">Arthur Paulino, Damiano Testa, Edward Ayers, Evgenia Karunus, Henrik Böving, Jannis Limperg, Siddhartha Gadgil and Siddharth Bhat, ''Metaprogramming in Lean 4'', online book, chapter "MetaM". [https://leanprover-community.github.io/lean4-metaprogramming-book/main/04_metam.html leanprover-community.github.io/lean4-metaprogramming-book/main/04_metam.html]</ref>

<code>CommandElabM</code>, the monad of commands, stands beside the stack and not on top of
it; a command that needs to elaborate a term enters <code>TermElabM</code> with
<code>liftTermElabM</code>, as in the second example below.

== Elaborators ==

An '''elaborator''' gives meaning to a piece of syntax by running Lean code. A term
elaborator has type <code>Syntax → Option Expr → TermElabM Expr</code>: it receives the
syntax and the expected type if one is known, and must return a <code>Lean.Expr</code>. A
command elaborator has type <code>Syntax → CommandElabM Unit</code> and acts by side
effects, such as adding constants or reporting messages.<ref name="rm-elab">"Elaborators", section 23.6 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Elaborators/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Elaborators/]</ref>
The <code>elab</code> command declares the syntax and its elaborator together.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
elab "double! " t:term : term => do
let stx ← `(2 * $t)
elabTerm stx (some (mkConst ``Nat))

#eval double! 21
</pre>

This prints <code>42</code>. The elaborator constructs syntax with a quotation,
<code>`(2 * $t)</code>, and hands it to <code>elabTerm</code> with the expected type
<code>Nat</code>. Quotations are available in every one of these monads; a quotation of a
category other than terms names it, as in <code>`(tactic| intro h)</code>. Their hygiene is
the hygiene of [[Lean theorem prover/System/Syntax extension and hygienic macros|macros]].
Unlike a macro, which can do no more with Lean's environment than check whether a name exists
and resolve names, an elaborator can consult types, the local context and the whole of Lean's
environment.<ref name="rm-macros">"Macros", section 23.5 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), subsection 23.5.2 "The Macro Monad". [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/]</ref>

A command that elaborates a term, puts it in weak head normal form and reports the result:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
elab "#whnf " t:term : command => do
liftTermElabM do
let e ← elabTerm t none
let r ← whnf e
logInfo m!"{e} reduces to {r} : {← inferType e}"

#whnf (fun (x : Nat) => x + 1) 41
#whnf (fun (x : Nat) => [x, x]) 7
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">(fun x => x + 1) 41 reduces to 42 : Nat
(fun x => [x, x]) 7 reduces to [7, 7] : List Nat</pre>

== A tactic ==

A tactic is an elaborator in <code>TacticM</code> (the
[[Lean theorem prover/System/The tactic framework|tactic framework]] describes how they are
run). This one closes the main goal with any hypothesis whose type is definitionally equal
to it, a simple form of Lean's <code>assumption</code>.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
elab "my_assumption" : tactic => do
let goal ← getMainGoal
let target ← goal.getType
for h in ← getLCtx do
if !h.isImplementationDetail && (← isDefEq h.type target) then
goal.assign h.toExpr
replaceMainGoal []
return
throwError "my_assumption: no hypothesis has type {target}"

example (p q : Prop) (hp : p) (hq : q) : p ∧ q :=
⟨by my_assumption, by my_assumption⟩
</pre>

Each goal is a metavariable, and closing it means assigning it a term: here the free
variable <code>hp</code> for the first goal and <code>hq</code> for the second. When no
hypothesis fits, the tactic fails with its own message:

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (p q : Prop) (hp : p) : q := by my_assumption
</pre>

Lean reports <code>my_assumption: no hypothesis has type q</code>.

== Metaprograms are not trusted ==

Nothing stops a tactic from assigning a goal a term of the wrong type. The assignment
operation does not check. This tactic claims to prove anything with <code>True.intro</code>,
the proof of <code>True</code>.

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
elab "cheat" : tactic => do
let goal ← getMainGoal
goal.assign (mkConst ``True.intro)
replaceMainGoal []

theorem bad : False := by cheat
</pre>

The tactic runs and reports no failure, but the theorem is refused:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">(kernel) declaration type mismatch, 'bad' has type
True
but it is expected to have type
False</pre>

The message is the Lean kernel's. When a definition or theorem is complete, the elaborator
passes it to the Lean kernel, which checks it against the rules of the type theory before it
enters Lean's environment. The reference manual states the purpose plainly: the elaborator's
output must be checked by the Lean kernel "to guard against potential bugs in
elaboration".<ref name="rm-ec">"Elaboration and Compilation", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "The Kernel". [https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/ lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/]</ref>
The elaborator, the tactic framework, the simplifier and every user's tactic are outside the
trusted part of the system. They may be wrong, and, as long as the Lean kernel's check is not
switched off, a wrong result costs a failed check, not a false theorem.

This is why metaprogramming can be open to every user. A proof assistant whose automation
had to be trusted would have to restrict who may write automation, or audit it. Lean instead
lets any file define tactics and elaborators with the same access its own have, because the
check at the end does not depend on how the term was found.

The guarantee has limits, and they are worth stating. The check covers only what reaches
the Lean kernel. The option <code>debug.skipKernelTC</code> switches it off, and code run during
elaboration can add a constant to Lean's environment without passing it to the Lean kernel;
the reference manual names both as ways of bypassing the check.<ref name="rm-validating" /> With
that option set, the <code>cheat</code> tactic above yields an accepted theorem
<code>bad : False</code>. A metaprogram runs with the full rights of input and output, and the
reference manual's guidance on validating a proof warns that tactics and other code run at
elaboration "can perform arbitrary actions when run", including, in the hostile case,
interfering with the system before any check takes place.<ref name="rm-validating">"Validating a Lean Proof", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs/]</ref>
Honest mistakes are caught by the check above. Deliberate tampering is the subject of
[[Lean theorem prover/System/Proof export and independent checkers|proof export and independent checkers]].

== Next ==

[[Lean theorem prover/System/The compiler and runtime|The compiler and runtime]] explains how
metaprograms, like all Lean programs, are compiled and run.

== References ==

<references />

Lean theorem prover/System/Syntax extension and hygienic macros

2026-10-15T19:35:13Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Syntax extension and hygienic macros}}
{{Plebeian|Lean theorem prover/Explainers/Programs and proofs in one language}}
{{Lean theorem prover map}}

Lean's grammar is not fixed. A Lean source file can add operators, notations and whole new
syntactic forms, and say what each one means by rewriting it into syntax Lean already
understands. The rewriting is done by '''macros''', and Lean's macros are '''hygienic''': a
name that a macro introduces cannot capture a name the user wrote, and a name the user wrote
cannot capture one the macro relies on. This page shows the commands, from the simplest
(<code>infixl</code>) to the most general (<code>macro_rules</code>), and what hygiene
prevents, with examples compiled by Lean 4.34.1. The design is set out by Ullrich and de
Moura.<ref name="bn">Sebastian Ullrich and Leonardo de Moura, "Beyond Notations: Hygienic Macro Expansion for Theorem Proving Languages", ''Logical Methods in Computer Science'' 18(2), 2022, article 1, 21 pp. Extended version of the paper in ''Automated Reasoning: IJCAR 2020'', Lecture Notes in Computer Science 12167, Springer, 2020, pp. 167–182 (doi:10.1007/978-3-030-51054-1_10). doi:[https://doi.org/10.46298/lmcs-18(2:1)2022 10.46298/lmcs-18(2:1)2022]; preprint [https://arxiv.org/abs/2001.10490 arXiv:2001.10490].</ref>

== Where syntax extension sits ==

Lean reads a source file one command at a time. Each command is parsed, then
[[Lean theorem prover/System/Elaboration|elaborated]] into terms of the type theory, and only
the elaborated result is passed to the Lean kernel. Macro expansion happens after parsing, as
part of elaboration: before a piece of syntax is elaborated, any macro at its outermost layer
is expanded.<ref name="rm-macros" /> A macro takes a piece of syntax and returns another piece of syntax; the
reference manual calls the expansion of a notation "a purely syntactic process that occurs
prior to elaboration or code generation".<ref name="rm-notations">"Notations", section 23.3 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Notations/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Notations/]</ref>
Whatever a macro produces is then elaborated and checked exactly as if the user had typed
it. A macro can change what is written; it cannot prove anything that the text it produces
could not prove if typed by hand.

The commands form a tower. The operator commands are shorthands for <code>notation</code>.
In Ullrich and de Moura's account, <code>notation</code> is itself a macro that generates a
<code>macro</code>, and <code>macro</code> expands into a grammar rule (<code>syntax</code>)
paired with a rewriting rule (<code>macro_rules</code>).<ref name="bn" /><ref name="rm-ops" />
In Lean 4.34.1, <code>notation</code> and <code>macro</code> are each handled by an
elaborator that produces this pair directly.<ref name="src-notation">Lean 4 source code, version 4.34.1 (2026), files <code>src/Lean/Elab/Notation.lean</code> (the functions <code>elabNotation</code> and <code>mkUnexpander</code>) and <code>src/Lean/Elab/Macro.lean</code> (the function <code>elabMacro</code>). Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Notation.lean</ref> The
<code>syntax</code> and <code>macro_rules</code> commands in turn become ordinary Lean
definitions that the parser and the macro expander consult.<ref name="bn" />

== Operators ==

The smallest extension names a binary operator.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def avg (a b : Nat) : Nat := (a + b) / 2

infixl:65 " ⊞ " => avg

#eval 2 ⊞ 4 ⊞ 10
#check fun (a b : Nat) => avg a b
</pre>

The <code>#eval</code> prints <code>6</code>: the operator associates to the left, so the
expression is <code>avg (avg 2 4) 10</code>, that is <code>avg 3 10</code>. The reference
manual gives the expansion exactly: <code>infixl:prec "op" => f</code> stands for
<code>notation:prec x:prec "op" y:prec1 => f x y</code>, where <code>prec1</code> is one more
than <code>prec</code>, so the left operand may itself be a use of the operator and the right
operand may not. A custom operator must state its precedence; there is no default.<ref name="rm-ops">"Custom Operators", section 23.1 of ''The Lean Language Reference'' (edition covering Lean 4.34.0). [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Custom-Operators/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Custom-Operators/]</ref>

The <code>#check</code> shows the other direction. Asked to print <code>avg a b</code>, Lean
prints

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">fun a b => a ⊞ b : Nat → Nat → Nat</pre>

The command has also generated an '''unexpander''', a rule used when terms are displayed. A
notation gets one when its right-hand side applies a named function and each of its term
positions occurs there exactly once; a notation that expands to an anonymous function gets
none.<ref name="rm-notations" /><ref name="rm-ops" />
The operator therefore appears in goals and error messages, not only in source text.

== Notation, syntax and macro rules ==

<code>notation</code> accepts any mixture of tokens and term positions, and its right-hand
side is a template. When a template is not enough, the two halves can be written separately.
<code>syntax</code> adds a grammar rule to a '''syntax category''' (here <code>term</code>),
and <code>macro_rules</code> says how to rewrite it.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
syntax "∑ " ident " ∈ " term ", " term : term

macro_rules
| `(∑ $i ∈ $xs, $body) => `(List.foldl (fun acc $i => acc + $body) 0 $xs)

#eval ∑ i ∈ [1, 2, 3, 4], i * i
</pre>

The output is <code>30</code>, the sum of the squares of 1 to 4. The pattern on the left of
<code>=></code> and the result on the right are '''syntax quotations''', written
<code>`(...)</code>. Inside them <code>$i</code>, <code>$xs</code> and <code>$body</code> are
'''antiquotations''': holes that match syntax in a pattern and insert it in a result. A
quotation produces syntax, not a term; it is parsed but not elaborated.<ref name="rm-macros">"Macros", section 23.5 of ''The Lean Language Reference'' (edition covering Lean 4.34.0), including 23.5.1 "Hygiene", 23.5.3 "Quotation" and 23.5.5 "Defining Macros". [https://lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/ lean-lang.org/doc/reference/4.34.0/Notations-and-Macros/Macros/]</ref>

<code>macro_rules</code> is open. More rules for the same syntax may be added later, in the
same file or another, and the most recently defined is tried first. A rule that does not
apply hands the syntax on to the next one, by throwing the exception
<code>unsupportedSyntax</code>; any other exception is reported as an error. Only the
outermost layer of syntax is expanded at a time, and nested macros are expanded when the
elaborator reaches them.<ref name="rm-macros" />

Syntax categories are not limited to terms. Commands and tactics are categories too, and a
library may declare its own with <code>declare_syntax_cat</code>. Ullrich and de Moura give an
example of why this matters: a big-operator file in Coq's Mathematical Components library
repeats twelve notations for index ranges once for each of three operators, because Coq's
notation system cannot abstract over the index syntax; with a category for index ranges,
each range form is interpreted once and every operator reuses it.<ref name="bn" />

== What hygiene prevents ==

A macro is a function on syntax, and syntax contains names. Two kinds of accident follow
from that.

The first is '''variable capture''': a binder the macro introduces captures a name the user
supplied. Ullrich and de Moura's example is a notation for constant
functions.<ref name="bn" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
notation "const" e => fun x => e

#check fun (x : Nat) => const x
#eval (fun (x : Nat) => const x) 1 2
</pre>

Read as text substitution, <code>const x</code> becomes <code>fun x => x</code>, the
identity, and the whole expression would return its second argument. Lean prints

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">fun x x_1 => x : (x : Nat) → ?m.2 x → Nat
1</pre>

The binder that the notation introduced has been renamed (Lean displays it as
<code>x_1</code>), the user's <code>x</code> still refers to the outer binder, and the
function returns its first argument. The mechanism is the '''macro scope'''. Each expansion of
a macro tags every identifier it introduces with a fresh scope, and a binder and a use of a
name match only if their tags agree.<ref name="rm-macros" /><ref name="bn" /> The user's
<code>x</code> carries no tag and the macro's carries one, so they are different names.

Hygiene can be switched off, and the same notation then captures.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option hygiene false in
notation "const'" e => fun x => e

#eval (fun (x : Nat) => const' x) 1 2
</pre>

This prints <code>2</code>, and Lean's linter warns that the outer <code>x</code> is never
referenced: the macro's binder has taken it. The summation notation above is protected in
the same way. Its accumulator is called <code>acc</code>, and a user's variable of that name
is not affected.

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#eval let acc := 100; ∑ i ∈ [1, 2, 3], acc * i
</pre>

The result is <code>600</code>. Rewritten by plain substitution, the body
<code>acc * i</code> would refer to the accumulator, which starts at 0, and the result would
be 0.

The second kind of accident runs the other way: a local name at the use site captures a
global name the macro relies on.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def double (n : Nat) : Nat := 2 * n

macro "dbl! " e:term : term => `(double $e)

#eval let double := fun (n : Nat) => n; dbl! 5
</pre>

The output is <code>10</code>, and Lean warns that the local variable <code>double</code> is
not referenced. The identifier <code>double</code> in the quotation carries the macro's scope
and the local binding at the use site does not, so the two do not match. When the quotation
<code>`(double $e)</code> was compiled, the name was also resolved to the global function and
recorded with it, so a global of the same name introduced later cannot redirect it
either.<ref name="rm-macros" /><ref name="bn" />

== Hygiene in tactics ==

Tactics form a syntax category, so a tactic can be a macro (the
[[Lean theorem prover/System/The tactic framework|tactic framework]] treats the result like
any other tactic). This one introduces a hypothesis and uses it.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
macro "intro_assumption" : tactic => `(tactic| (intro h; exact h))

example (p : Prop) : p → p := by intro_assumption
</pre>

The proof is accepted. The name <code>h</code>, however, belongs to the macro. A script that
uses a macro to introduce <code>h</code> and then refers to <code>h</code> itself fails.

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
macro "intro_hyp" : tactic => `(tactic| intro h)

example (p : Prop) : p → p := by
intro_hyp
exact h
</pre>

Lean reports <code>Unknown identifier `h`</code> at the last line. The hypothesis exists,
but under a name the user cannot type:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
macro "intro_hyp" : tactic => `(tactic| intro h)

example (p : Prop) : p → p := by
intro_hyp
trace_state
assumption
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">p : Prop
h✝ : p
⊢ p</pre>

The dagger marks an inaccessible name, and <code>assumption</code>, which does not need the
name, closes the goal. Ullrich and de Moura report that Lean 3's tactic quotations had both
faults: a short tactic script for injectivity lemmas broke when it was used from a library
for homotopy type theory that defined its own <code>propext</code> and
<code>Iff.intro</code>, and scripts could refer to names a tactic had introduced. They
describe Lean 4's tactic language as, to their knowledge, the first in an established theorem
prover to be hygienic automatically in this sense.<ref name="bn" />

== Mathematics in its own notation ==

Mathematics is written in notation that varies by field and by author, and much of it binds
variables: sums, products, integrals, set-builder notation, quantifiers over a finite set. A
fixed grammar forces a formal text away from that notation. Lean's macros let a library add
it, with three properties that matter in practice.

Binding notation is safe to define. A notation that introduces its own bound variables, such
as the sum above, does not interfere with the names its user chooses, and the user need not
know which names it uses inside. Without hygiene, every such notation would be a hazard of
the kind shown in the <code>const</code> example.

Notation is printed back. Because an unexpander is generated where possible, goals and error
messages show the notation the reader wrote, not the function it stands for.

Notation can be confined. A notation marked <code>scoped</code> is active only where its
namespace is open, so a field's notation need not occupy the grammar of every other field.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def avg (a b : Nat) : Nat := (a + b) / 2

namespace Averages
scoped infixl:65 " ⊞ " => avg
end Averages

open Averages in
#eval 2 ⊞ 4 ⊞ 10
</pre>

This prints <code>6</code>. Without the <code>open</code>, <code>⊞</code> is not part of the
grammar:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def avg (a b : Nat) : Nat := (a + b) / 2

namespace Averages
scoped infixl:65 " ⊞ " => avg
end Averages

#check (2 ⊞ 4 : Nat)
</pre>

Lean stops at the operator with the parse error <code>expected token</code>.

What notation does not do is add meaning. It changes how a statement is written and read,
and nothing that the Lean kernel checks. That is also its risk. A statement that uses
unfamiliar notation may not say what it appears to say, and the reference manual's guidance
on validating a proof names custom notation among the things to investigate when there is
doubt that a theorem states what was intended.<ref name="rm-validating">"Validating a Lean Proof", a chapter of ''The Lean Language Reference'' (edition covering Lean 4.34.0), section "Remaining Issues". [https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/ lean-lang.org/doc/reference/4.34.0/ValidatingProofs/]</ref>

A macro sees only syntax. When a translation depends on types, for example on whether an
argument is a natural number or a set, a macro cannot decide it, and an '''elaborator''' is
needed: a Lean program that runs inside the elaborator and constructs terms directly.

== Next ==

[[Lean theorem prover/System/Metaprogramming in Lean|Metaprogramming in Lean]] shows how
elaborators and tactics are written as Lean programs.
[[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]] describes a
piece of syntax that Lean translates into ordinary terms: the <code>do</code> block.

== References ==

<references />

Lean theorem prover/System/Decision procedures

2026-10-15T19:35:12Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Decision procedures}}
{{Plebeian|Lean theorem prover/Explainers/Automation and its limits|Lean theorem prover/Explainers/Computation inside proofs}}
{{Lean theorem prover map}}

A '''decision procedure''' is an algorithm that settles every question in a fixed class, answering yes or no. In Lean such an algorithm is useful only when its yes comes with evidence that the Lean kernel accepts. This page treats five tactics that automate whole classes of goals in Lean 4.34.1: <code>decide</code>, <code>omega</code>, <code>simp</code>, <code>grind</code> and <code>bv_decide</code>. For each it says what the tactic covers, what evidence it hands to the Lean kernel, and what a reader must trust beyond the Lean kernel.

== Three kinds of evidence ==

Every tactic ends by assigning a term to the goal's metavariable, as described on [[Lean theorem prover/System/The tactic framework|the tactic framework]], and the Lean kernel checks that term when the theorem is added. The procedures below differ in the shape of the term.

# '''An ordinary proof term.''' The tactic searches, then assembles a proof from library lemmas. <code>omega</code>, <code>simp</code> and <code>grind</code> work this way. The search is untrusted; only its output is checked.
# '''Proof by reflection.''' A Boolean function is written in Lean and proved correct once. The tactic reduces the goal to the claim that this function returns <code>true</code> on some input, and the Lean kernel confirms the claim by evaluating the function during its definitional equality check. <code>decide</code> works this way.
# '''An asserted evaluation.''' As in reflection, but the function is run by compiled code and its result is added to Lean's environment, its table of definitions and theorems, as a new axiom. <code>bv_decide</code> works this way. The Lean compiler then joins the trusted base.

The command <code>#print axioms</code> tells the three apart: the first two leave only Lean's standard axioms (described on [[Lean theorem prover/Foundations/The three axioms|the three axioms]]), the third leaves an extra one.

== decide ==

A proposition <code>p</code> is decidable when there is an instance of the class <code>Decidable p</code>. The class is an inductive type with two constructors, one carrying a proof of <code>p</code> and one a proof of its negation:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Decidable
#synth Decidable (∀ x : Fin 4, x.val * x.val < 10)
</pre>

Lean 4.34.1 prints:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Decidable : Prop → Type
number of parameters: 1
constructors:
Decidable.isFalse : {p : Prop} → ¬p → Decidable p
Decidable.isTrue : {p : Prop} → p → Decidable p
Nat.decidableForallFin fun x => ↑x * ↑x < 10
</pre>

Instances compose: a bounded quantifier over <code>Fin 4</code> is decidable because each instance of its body is, and instance resolution (see [[Lean theorem prover/System/Type classes and instance resolution|type classes and instance resolution]]) assembles the instance. The tactic <code>decide</code> synthesises such an instance for the goal and reduces it; if it reaches <code>isTrue h</code>, then <code>h</code> proves the goal.<ref name="src-tactics">Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Tactics.lean</code>: the documentation strings of the tactics <code>decide</code>, <code>omega</code> and <code>bv_decide</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Tactics.lean</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem small : 2 ^ 10 = 1024 ∧ 3 < 5 := by decide
#print small
#print axioms small
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem small : 2 ^ 10 = 1024 ∧ 3 < 5 :=
of_decide_eq_true (id (Eq.refl true))
'small' does not depend on any axioms
</pre>

The proof term is short because the work is moved into checking it. For <code>Eq.refl true</code> to have type <code>decide p = true</code>, the Lean kernel must reduce <code>decide p</code> to <code>true</code>, which is the computation itself. This is [[Lean theorem prover/Foundations/Definitional equality|definitional equality]] put to use. On a false proposition the same evaluation yields a refutation, and the tactic reports it:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : ∀ x : Fin 5, x.val * x.val < 10 := by decide
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: Tactic `decide` proved that the proposition
∀ (x : Fin 5), ↑x * ↑x < 10
is false
</pre>

The limits follow from the method. The goal may contain no local variables or metavariables; on <code>n + 0 = n</code> for a variable <code>n</code>, Lean says <code>Expected type must not contain free variables</code> and suggests the option <code>+revert</code>, which first moves such variables into the goal as universally quantified ones. Instances defined by well-founded recursion may not reduce, and reduction can get stuck on instances built with rewriting tactics. The option <code>decide +kernel</code> hands the reduction to the Lean kernel directly, and <code>decide +native</code> runs compiled code and admits the result through an axiom. Its documentation says this can be significantly more efficient, but comes "at the cost of increasing the size of the trusted code base".<ref name="src-tactics" />

== omega ==

<code>omega</code> proves goals in linear arithmetic over <code>Int</code> and <code>Nat</code>. It accepts hypotheses of the forms <code>x = y</code>, <code>x < y</code>, <code>x ≤ y</code> and <code>k ∣ x</code> for a literal <code>k</code>, with their negations; it splits both sides into linear combinations of atoms, and for <code>x / k</code> and <code>x % k</code> with a literal <code>k</code> it introduces a new variable together with the two inequalities that bound it.<ref name="src-tactics" /><ref name="src-omega" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem bound (x y : Nat) (h₁ : x + 2 * y ≤ 10) (h₂ : 3 < x) : y ≤ 3 := by
omega

example (a b : Int) (h : 2 * a + 1 = 2 * b) : False := by
omega

example (n : Nat) : n / 2 + n % 2 ≤ n := by
omega

#print axioms bound
</pre>

The last line prints <code>'bound' depends on axioms: [propext, Quot.sound]</code>: the proof is an ordinary term. The method is William Pugh's omega test of 1991, an extension of Fourier–Motzkin variable elimination from the reals to the integers.<ref name="pugh">William Pugh, "The Omega test: a fast and practical integer programming algorithm for dependence analysis", ''Proceedings of the 1991 ACM/IEEE Conference on Supercomputing (Supercomputing '91)'', ACM, 1991, pp. 4–13. doi:10.1145/125826.125848. Read in an expanded version whose first page states that it appeared in ''Communications of the ACM'' in August 1992, there titled "A practical algorithm for exact array dependence analysis", 35(8), pp. 102–114, doi:10.1145/135226.135233.</ref> Eliminating a variable from a set of integer inequalities yields Pugh's '''real shadow''', which may have integer points that lift to no integer solution, and his '''dark shadow''', whose integer points always lift; when the two coincide the elimination is exact.<ref name="pugh" />

Lean's implementation states its own limits. Its notes say that it follows Pugh's paper closely but leaves out the dark and grey shadows, so when the real shadow is satisfiable it fails rather than deciding. It prefers to eliminate a variable for which elimination is exact: all upper bounds, or all lower bounds, with unit coefficient. The notes record that failures from the missing shadows appear to be rare in practice.<ref name="src-omega">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/Omega.lean</code>: implementation notes of the <code>omega</code> tactic. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/Omega.lean</ref> The tactic's documentation accordingly calls it "not yet a full decision procedure".<ref name="src-tactics" /> Each derived constraint carries a record of how it was obtained, and when a contradiction appears that record is turned into the proof term.<ref name="src-omega" />

Products of variables are outside the fragment. <code>omega</code> treats <code>x * y</code> as an atom, an unknown like any other,<ref name="src-omega" /> and, on failure, prints constraints that a counterexample might satisfy:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (x y : Nat) (h : x * y = 6) : x ≤ 6 := by
omega
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: omega could not prove the goal:
a possible counterexample may satisfy the constraints
a ≥ 7
where
a := ↑x
</pre>

== simp ==

<code>simp</code> is not a decision procedure. It is a rewriting engine: the reference manual describes it as performing inside-out rewriting of terms from a database of simplification rules.<ref name="manual-simp">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "The Simplifier". https://lean-lang.org/doc/reference/4.34.0/The-Simplifier/</ref> The database is the '''simp set''': every theorem marked <code>@[simp]</code>, read as an equation to be used from left to right, together with any lemmas named in the call.<ref name="lean4-paper">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref> A goal is closed when it rewrites to <code>True</code>. The option <code>trace.Meta.Tactic.simp.rewrite</code> shows each step:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def rev : List α → List α
| [] => []
| a :: as => rev as ++ [a]

@[simp] theorem rev_nil : rev ([] : List α) = [] := rfl
@[simp] theorem rev_cons (a : α) (as : List α) :
rev (a :: as) = rev as ++ [a] := rfl

set_option trace.Meta.Tactic.simp.rewrite true in
example (a b : Nat) : rev [a, b] = [b, a] := by
simp
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
[Meta.Tactic.simp.rewrite] rev_cons:1000:
rev [a, b]
==>
rev [b] ++ [a]
[Meta.Tactic.simp.rewrite] rev_cons:1000:
rev [b]
==>
rev [] ++ [b]
[Meta.Tactic.simp.rewrite] rev_nil:1000:
rev []
==>
[]
[Meta.Tactic.simp.rewrite] List.nil_append:1000:
[] ++ [b]
==>
[b]
[Meta.Tactic.simp.rewrite] List.cons_append:1000:
[b] ++ [a]
==>
b :: ([] ++ [a])
[Meta.Tactic.simp.rewrite] List.nil_append:1000:
[] ++ [a]
==>
[a]
[Meta.Tactic.simp.rewrite] eq_self:1000:
[b, a] = [b, a]
==>
True
</pre>

The number after each lemma name is its priority. Two of the lemmas come from this page, the rest from Lean's library. The variant <code>simp?</code> reports a <code>simp only [...]</code> call naming just the lemmas used; pasted in its place, it makes the proof independent of later changes to the library's simp set. Whether <code>simp</code> succeeds depends on the simp set as much as on the goal: it answers no question by itself. Its proof is assembled from the lemmas it used and is checked by the Lean kernel like any other term.

== grind ==

<code>grind</code> is part of core Lean in version 4.34.1 and needs no import. Its documentation calls it inspired by modern SMT solvers. It keeps one shared collection of facts, groups terms known to be equal by '''congruence closure''', instantiates theorems by '''E-matching''' (matching a theorem's pattern modulo the equalities known so far), splits cases, and passes facts to specialised solvers for linear integer arithmetic, for commutative rings and fields, and for linear arithmetic (its <code>linarith</code> component).<ref name="src-grind">Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Grind/Tactics.lean</code>: the documentation string of the <code>grind</code> tactic. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Grind/Tactics.lean</ref> The reference manual states that it "produces ordinary Lean proof terms for every fact it adds".<ref name="manual-grind">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "The grind tactic". https://lean-lang.org/doc/reference/4.34.0/The--grind--tactic/</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def f (a : Nat) : Nat := a + 1
def g (a : Nat) : Nat := a - 1

@[grind =] theorem g_f (x : Nat) : g (f x) = x := by
simp [f, g]

theorem grind_demo {a b : Nat} (h : f b = a) : g a = b := by
grind

example {x y : Int} : 2 * x + 4 * y ≠ 5 := by
grind

#print axioms grind_demo
</pre>

The attribute <code>@[grind =]</code> makes the left side <code>g (f x)</code> a pattern. The goal mentions <code>g a</code>, not <code>g (f b)</code>; but <code>h</code> puts <code>a</code> and <code>f b</code> in one equality class, so the pattern matches modulo that equality and congruence closure finishes the proof. The second example, taken from the tactic's documentation, is linear integer arithmetic: <code>2 * x + 4 * y</code> is even and 5 is not. The last line prints <code>'grind_demo' depends on axioms: [propext, Classical.choice, Quot.sound]</code>, the standard three and nothing more. Its documentation warns that <code>grind</code> is not designed for problems whose search space explodes combinatorially, and points to <code>bv_decide</code> for bit-level and combinatorial problems.<ref name="src-grind" />

== bv_decide ==

<code>bv_decide</code> closes goals about fixed-width bit vectors (<code>BitVec n</code>) and <code>Bool</code>: the Lean counterpart of the SMT-LIB logic QF_BV. It needs <code>import Std.Tactic.BVDecide</code>, and on failure it prints a counterexample.<ref name="src-tactics" /> Its implementation notes give the steps. It starts a proof by contradiction, normalises the hypotheses with a simp set, and represents the problem as a Lean value of a syntax-tree type. A verified bit-blaster turns that value into an and-inverter graph and then into a formula in conjunctive normal form. The SAT solver CaDiCaL, which is shipped beside the <code>lean</code> executable, is asked for an LRAT proof that the formula is unsatisfiable. That proof is checked by an LRAT checker with a soundness proof in Lean, and the proofs so far are chained back to the goal.<ref name="src-bvdecide">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/BVDecide.lean</code>: the overview of <code>bv_decide</code>, sections "Architecture" and "Axioms". Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/BVDecide.lean</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Std.Tactic.BVDecide

theorem add_as_xor (x y : BitVec 8) :
x + y = (x ^^^ y) + ((x &&& y) <<< 1) := by
bv_decide

#print axioms add_as_xor
#print add_as_xor._native.bv_decide.ax_1_5
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
'add_as_xor' depends on axioms: [propext, Classical.choice, Quot.sound, add_as_xor._native.bv_decide.ax_1_5]
axiom add_as_xor._native.bv_decide.ax_1_5 : Std.Tactic.BVDecide.Reflect.verifyBVExpr add_as_xor._expr_def_1_1
add_as_xor._cert_def_1_1 =
true
</pre>

The output states the trust story exactly. The fourth axiom says that one Boolean function, <code>verifyBVExpr</code>, returns <code>true</code> on the encoded problem and on the certificate string the solver produced. In Lean's library, <code>verifyBVExpr</code> bit-blasts the problem and checks the certificate against the resulting formula, and the theorem <code>unsat_of_verifyBVExpr_eq_true</code> proves that a <code>true</code> result means the problem is unsatisfiable.<ref name="src-reflect">Lean 4 source code, version 4.34.1 (2026), file <code>src/Std/Tactic/BVDecide/Reflect.lean</code>: the definition <code>verifyBVExpr</code> and the theorem <code>unsat_of_verifyBVExpr_eq_true</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Std/Tactic/BVDecide/Reflect.lean</ref> So the result relies on three things: the Lean kernel, which checks the soundness theorems and the chain of reasoning around the axiom; the compiled evaluation of <code>verifyBVExpr</code>, which is what the axiom asserts; and therefore the Lean compiler that produced that code, together with any definition whose compiled form is replaced by another implementation through <code>@[implemented_by]</code>, a dependency the documentation of <code>decide +native</code> spells out for the same mechanism.<ref name="src-tactics" /> The implementation notes say so: the result of the compiled check is added as an axiom, "thus adding the Lean compiler to the trusted code base".<ref name="src-bvdecide" /> The SAT solver is not trusted. A wrong certificate makes the check return <code>false</code> and the tactic fails. The Lean kernel does not repeat the bit-level computation itself.

The reference manual's page on validating proofs records that up to version 4.28.0 every such use showed up in <code>#print axioms</code> as one shared axiom, <code>Lean.trustCompiler</code>, and that since 4.29.0 these tactics instead introduce one dedicated axiom for each computation, as above.<ref name="manual-validating">Lean Developers, ''The Lean Language Reference'', version 4.34.0, "Validating a Lean Proof". https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref> In 4.34.1 the older primitive <code>Lean.ofReduceBool</code> still exists; <code>#check @Lean.ofReduceBool</code> answers with the warning that native reduction inside the Lean kernel is deprecated. For the older mechanism the manual states that external checkers cannot check such proofs, having no access to the Lean compiler, and that proofs needing that level of checking must avoid native evaluation.<ref name="manual-validating" /> Under the newer one a checker sees, in the list of axioms, exactly which computation it is asked to take on trust. [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]] takes this up.

A false bit-vector claim is refuted with values:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Std.Tactic.BVDecide

example (x y : BitVec 4) : x * y = x + y := by
bv_decide
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: The prover found a counterexample, consider the following assignment:
x = 15#4
y = 15#4
</pre>

Indeed 15 × 15 = 225, which is 1 modulo 16, while 15 + 15 = 30, which is 14.

== Side by side ==

{| class="wikitable"
! Tactic !! Covers !! Evidence !! Trusted beyond the Lean kernel
|-
| <code>decide</code> || propositions with a <code>Decidable</code> instance that reduces || reflection, evaluated by the Lean kernel || nothing
|-
| <code>omega</code> || linear arithmetic over <code>Int</code> and <code>Nat</code> (incomplete) || ordinary proof term || nothing
|-
| <code>simp</code> || whatever the simp set rewrites to <code>True</code> || ordinary proof term || nothing
|-
| <code>grind</code> || equalities, theorem instances, case splits, arithmetic || ordinary proof term || nothing
|-
| <code>bv_decide</code> || fixed-width bit vectors and <code>Bool</code> || asserted evaluation of a verified checker || the Lean compiler and the compiled code
|}

In every row the search can be wrong without harm: a mistaken search produces a term the Lean kernel rejects, or no term. Only the last row moves part of the checking out of the Lean kernel.

== Next ==

[[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]] shows how new notation, and new tactics, are added to the language.

== References ==

<references />

Lean theorem prover/System/The tactic framework

2026-10-15T19:35:10Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The tactic framework}}
{{Plebeian|Lean theorem prover/Explainers/Tactics|Lean theorem prover/Explainers/Holes and goals}}
{{Lean theorem prover map}}

A '''tactic''' is a program that constructs part of a proof term. The '''tactic framework''' is what such programs act on: a list of goals, each one a metavariable, inside a monad that gives access to everything the elaborator can do. This page describes the framework in Lean 4.34.1: how a <code>by</code> block enters elaboration, what a goal is, the monad <code>TacticM</code>, the combinators that join tactics, a new tactic defined in three lines, and the library-search tactics <code>exact?</code> and <code>apply?</code>. The idea of a tactic goes back to the LCF system; [[Lean theorem prover/History/LCF and the tactic idea|LCF and the tactic idea]] tells that history.

== A by block is a hole ==

The reference manual states that <code>by tac</code> constructs a term of the expected type by running the tactics <code>tac</code>, and that tactics construct proof terms behind the scenes.<ref name="manual-tactics">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Tactic Proofs", with its section "Running Tactics". https://lean-lang.org/doc/reference/4.34.0/Tactic-Proofs/</ref> When the elaborator meets <code>by</code>, it does not run the tactics at once. It creates a metavariable of the expected type, of the synthetic opaque kind, and registers the tactic code to be run later.<ref name="src-termelab">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Term/TermElabM.lean</code>: the function <code>mkTacticMVar</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Term/TermElabM.lean</ref> Tactic blocks are run in the last round of pending work, after the rest of the surrounding term has been elaborated as far as it can be, so that the goal's type is as complete as possible.<ref name="src-synth">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/SyntheticMVars.lean</code>: the function <code>synthesizeSyntheticMVars</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/SyntheticMVars.lean</ref> The trace option <code>trace.Elab.step</code> shows both moments. These lines are an excerpt from the trace of <code>example (p : Prop) (hp : p) : p ∧ p := by exact ⟨hp, hp⟩</code>:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
[Elab.step] ✅️ expected type: p ∧ p, term
by exact ⟨hp, hp⟩
[Elab.step.result] ?m.1
[Elab.step] ✅️ exact ⟨hp, hp⟩
</pre>

The <code>by</code> term elaborates to the metavariable <code>?m.1</code>. Only afterwards does the tactic <code>exact</code> run, and it is the tactic that assigns <code>?m.1</code>.

== Goals are metavariables ==

The state of the tactic framework is a structure with one field, <code>goals : List MVarId</code>.<ref name="src-tactic">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Tactic/Basic.lean</code>: the definitions <code>TacticM</code>, <code>Tactic</code>, <code>getGoals</code> and <code>tryCatchRestore</code>, with the structure <code>Tactic.State</code> in <code>src/Lean/Elab/Term/TermElabM.lean</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Tactic/Basic.lean</ref> Each goal is a metavariable, with its own local context of hypotheses and its type, the statement still to be proved; the first is the '''main goal'''.<ref name="manual-tactics" /> A tactic usually acts on the main goal: it assigns that metavariable a term, which may contain new metavariables, and puts the new metavariables in the goal's place. The goal of a <code>by</code> block, and the goals made by tactics such as <code>intro</code>, are synthetic opaque, the kind that unification never assigns, because a goal counts as solved exactly when its metavariable is assigned.<ref name="src-mctx">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/MetavarContext.lean</code>: the design notes at the head of the file. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/MetavarContext.lean</ref> [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] treats these kinds.

A short tactic that reads the list makes the point concrete:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Elab Tactic in
elab "show_goals" : tactic => do
let gs ← getGoals
logInfo m!"goals: {gs.map Expr.mvar}"

example (p q : Prop) (hp : p) (hq : q) : p ∧ q := by
constructor
show_goals
all_goals assumption
</pre>

It prints <code>goals: [?left, ?right]</code>. The tactic <code>constructor</code> assigned the original goal the term <code>And.intro ?left ?right</code> and left the two new metavariables as goals, named after the arguments of <code>And.intro</code>. The built-in <code>trace_state</code> prints the same goals in the familiar form:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem and_swap (p q : Prop) (h : p ∧ q) : q ∧ p := by
constructor
trace_state
· exact h.2
· exact h.1

#print and_swap
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
case left
p q : Prop
h : p ∧ q
⊢ q

case right
p q : Prop
h : p ∧ q
⊢ p
theorem and_swap : ∀ (p q : Prop), p ∧ q → q ∧ p :=
fun p q h => ⟨h.right, h.left⟩
</pre>

The last lines are the point of the whole framework. Once every goal is assigned, the <code>by</code> block's metavariable stands for an ordinary term, and that term, not the script, is what the Lean kernel checks and what Lean's environment, its table of definitions and theorems, records. If a goal is left open, the block fails:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (p q : Prop) (hp : p) : p ∧ q := by
constructor
exact hp
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: unsolved goals
case right
p q : Prop
hp : p
⊢ q
</pre>

== The monad TacticM ==

In Lean 4.34.1 the tactic monad is defined as

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
abbrev TacticM := ReaderT Context $ StateRefT State TermElabM
</pre>

Its documentation describes it as the term elaboration monad <code>TermElabM</code> extended with the current goals and some local information, and defines a tactic as a function from syntax to an action in <code>TacticM</code>. Several tactics may be attached to one kind of syntax; they are attempted until one succeeds.<ref name="src-tactic" /> Because <code>TacticM</code> sits on top of the elaborator, a tactic can do anything the elaborator does: elaborate a term against a goal, call the unifier, search for instances, inspect and extend Lean's environment. [[Lean theorem prover/System/Monads and do-notation|Monads and do-notation]] explains the monad stack, and [[Lean theorem prover/System/Metaprogramming in Lean|metaprogramming in Lean]] shows how to write tactics against it. The paper that introduced Lean 4 stresses that tactics are implemented in Lean itself and can be added by users.<ref name="lean4-paper">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref>

None of this is trusted. A tactic may be wrong in any way: it may assign a goal an ill-typed term, or a term of the wrong type. The error surfaces when the term is checked, at the latest by the Lean kernel ([[Lean theorem prover/System/The Lean kernel|the Lean kernel]]).

== Combinators ==

Tactics are joined by combinators, themselves tactics. Their documentation strings in Lean's source give their meaning:<ref name="src-tactics">Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Tactics.lean</code>: the documentation strings and definitions of <code>all_goals</code>, <code>focus</code>, <code>first</code>, <code>try</code>, <code><;></code>, <code>repeat</code>, <code>exact?</code> and <code>apply?</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Tactics.lean</ref>

* <code>t₁ <;> t₂</code> runs <code>t₁</code> on the main goal and <code>t₂</code> on each goal it produces, collecting all the goals that result.
* <code>all_goals t</code> runs <code>t</code> on every goal and fails if it fails on any. <code>focus t</code> runs <code>t</code> on the main goal with the other goals hidden; the bullet <code>· t</code>, used in <code>and_swap</code> above and preferred by the documentation, also requires that <code>t</code> close the goal. In 4.34.1 <code>t₁ <;> t₂</code> is itself a macro built from <code>focus</code> and <code>all_goals</code>.
* <code>first | t₁ | t₂ | …</code> runs each alternative until one succeeds, and fails if none does.
* <code>try t</code> runs <code>t</code> and succeeds even if <code>t</code> fails. In 4.34.1 it is not a primitive but a macro: <code>first | t | skip</code>.
* <code>repeat t</code> applies <code>t</code> for as long as it succeeds, undoing any partial changes of the attempt that fails. If <code>t</code> never fails, <code>repeat t</code> does not stop. <code>repeat' t</code> applies <code>t</code> recursively to every goal produced.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (p q r : Prop) (hp : p) (hq : q) (hr : r) : p ∧ q ∧ r := by
constructor <;> (try constructor) <;> assumption

example (n : Nat) : n = n ∨ n = 0 := by
first
| exact Or.inr rfl
| exact Or.inl rfl
</pre>

In the second example the first alternative fails, since <code>n = 0</code> does not hold for every <code>n</code>, and <code>first</code> backtracks to the second. Before the second alternative runs, the state saved before the first is restored, metavariable assignments included: in <code>TacticM</code> the standard way of catching a failure rolls the state back.<ref name="src-tactic" />

== A new tactic in three lines ==

Since <code>try</code> is a macro, so can a user's tactic be. A '''macro''' tactic rewrites its own syntax into existing tactics, and needs no access to <code>TacticM</code> at all:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
macro "conj_close" : tactic =>
`(tactic| (repeat' constructor) <;> assumption)

theorem three (p q r : Prop) (hp : p) (hq : q) (hr : r) : (p ∧ q) ∧ r := by
conj_close

#print three
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem three : ∀ (p q r : Prop), p → q → r → (p ∧ q) ∧ r :=
fun p q r hp hq hr => ⟨⟨hp, hq⟩, hr⟩
</pre>

The new tactic <code>conj_close</code> splits nested conjunctions as far as they go and closes every resulting goal with a hypothesis. The proof term shows nothing of it. [[Lean theorem prover/System/Syntax extension and hygienic macros|Syntax extension and hygienic macros]] covers the macro system, and [[Lean theorem prover/System/Metaprogramming in Lean|metaprogramming in Lean]] the tactics that need <code>elab</code> and <code>TacticM</code>, as <code>show_goals</code> above did.

== Library search ==

Lean 4.34.1 includes two search tactics in its core. <code>exact?</code> searches Lean's environment for a definition or theorem that closes the goal with <code>exact</code>, discharging side conditions with <code>solve_by_elim</code>; <code>apply?</code> searches for one that refines the goal with <code>apply</code>.<ref name="src-tactics" /> Both report what they found as a suggestion to paste in place of the search:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (a b : Nat) : a + b = b + a := by
exact?
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Try this:
[apply] exact Nat.add_comm a b
</pre>

The suggestion is meant to replace the call. A proof that keeps <code>exact?</code> repeats the search every time the file is checked, and may find a different lemma once the library changes.

== Next ==

[[Lean theorem prover/System/Decision procedures|Decision procedures]] describes the tactics that settle whole classes of goals: <code>decide</code>, <code>omega</code>, <code>simp</code>, <code>grind</code> and <code>bv_decide</code>.

== References ==

<references />

Lean theorem prover/System/Type classes and instance resolution

2026-10-15T19:35:09Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Type classes and instance resolution}}
{{Plebeian|Lean theorem prover/Explainers/A library of mathematics}}
{{Lean theorem prover map}}

A '''type class''' in Lean is a structure whose values Lean finds by itself. Writing <code>a + b</code>, comparing two values, printing one, or treating a natural number as an integer all depend on such values, called '''instances''', which the elaborator supplies by a search called '''instance resolution''' or instance synthesis. This page shows what a class is, how the search runs in Lean 4.34.1, why it is tabled, how its inputs and outputs are controlled, and how a large mathematical library is organised around it.

== Classes are structures ==

The command <code>class</code> declares a structure and marks it for instance resolution:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class Shape (α : Type) where
area : α → Nat

#check @Shape.area
#print Shape
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@Shape.area : {α : Type} → [self : Shape α] → α → Nat
class Shape (α : Type) : Type
number of parameters: 1
fields:
Shape.area : α → Nat
constructor:
Shape.mk {α : Type} (area : α → Nat) : Shape α
</pre>

The class has one field and one constructor, like any structure. The difference is in the type of the field's accessor. Its argument <code>[self : Shape α]</code> is '''instance-implicit''': the user does not write it, and the elaborator does not find it by unification, as it would an ordinary implicit argument, but by searching the declared instances.<ref name="manual-tc">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Type Classes", and its section "Instance Synthesis". https://lean-lang.org/doc/reference/4.34.0/Type-Classes/</ref> In the logic, nothing is new: an instance is an ordinary constant, and the term the search returns is an ordinary term that the Lean kernel checks like any other.

== Instances and the search ==

An instance supplies a value of the class, possibly depending on other instances:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
structure Square where
side : Nat

instance : Shape Square where
area s := s.side * s.side

instance [Shape α] [Shape β] : Shape (α × β) where
area p := Shape.area p.1 + Shape.area p.2

set_option pp.explicit true in
#synth Shape (Square × (Square × Square))
#eval Shape.area ((⟨3⟩, ⟨4⟩) : Square × Square)
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@instShapeProd Square (Prod Square Square) instShapeSquare
(@instShapeProd Square Square instShapeSquare instShapeSquare)
25
</pre>

The command <code>#synth</code> runs the search and prints its result: a term assembled from the two instances, nested to the shape of the type. An instance with instance arguments behaves like a rule of a logic program: to obtain <code>Shape (α × β)</code>, obtain <code>Shape α</code> and <code>Shape β</code>. The paper that introduced Lean 4 describes resolution as a simple λ-Prolog interpreter whose Horn clauses are the declared instances, and states that Lean 4 indexes instances with discrimination trees.<ref name="lean4-paper">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref> The reference manual calls synthesis a recursive search procedure that either finds an instance or fails, and says that candidates are tried in order of priority, the more recent instance first among those of equal priority.<ref name="manual-tc" />

== Tabling ==

Search of this kind has two known failures. In a hierarchy of mathematical structures there are often several paths from one class to another; such '''diamonds''', stacked in towers, make naive depth-first search take time exponential in the height of the tower when a subquery fails. And useful instances can form '''cycles''', such as coercions in both directions between two types, on which naive search may loop. Daniel Selsam, Sebastian Ullrich and Leonardo de Moura named these the diamond problem and the cycle problem, reported that increasingly sophisticated uses of type classes in Lean's mathematical library had turned them into practical obstacles, and proposed '''tabled typeclass resolution''' to solve both.<ref name="selsam">Daniel Selsam, Sebastian Ullrich and Leonardo de Moura, "Tabled Typeclass Resolution", arXiv:2001.04301 [cs.PL], 2020. https://arxiv.org/abs/2001.04301</ref>

Tabling, a technique taken from logic programming, keeps a table from each subgoal met so far to the solutions already found for it, and reuses those solutions instead of searching again. The procedure keeps one search tree per distinct subgoal. '''Generator nodes''', the roots of the trees, try the instances for their subgoal one after another. '''Consumer nodes''' wait on a subgoal and are resumed whenever a new solution for it appears. The authors state that this removes the exponential blow-up from diamonds and guarantees termination under a bounded term-size assumption.<ref name="selsam" /> In Lean 4.34.1 the table's keys are subgoals in which each assignable metavariable has been replaced by a normalised name, so that <code>f ?m ?m ?n</code> becomes <code>f _tc.0 _tc.0 _tc.1</code>; the source notes that the lookup is structural, so a goal may be visited twice if two occurrences are equal only up to unfolding.<ref name="src-synth">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Meta/SynthInstance.lean</code>: the notes on tabled resolution and table keys, the function <code>generate</code>, and the notes on <code>outParam</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Meta/SynthInstance.lean</ref>

A cycle shows the difference. Each of these instances needs the other:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class R (α : Type) where

instance [R Nat] : R Int := ⟨⟩
instance [R Int] : R Nat := ⟨⟩

set_option trace.Meta.synthInstance true in
#synth R Nat
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: failed to synthesize
R Nat
[Meta.synthInstance] ❌️ R Nat
[Meta.synthInstance] ✅️ new goal R Nat
[Meta.synthInstance.instances] #[@instRNatOfInt]
[Meta.synthInstance.apply] ✅️ apply @instRNatOfInt to R Nat
[Meta.synthInstance.tryResolve] ✅️ R Nat ≟ R Nat
[Meta.synthInstance] ✅️ new goal R Int
[Meta.synthInstance.instances] #[@instRIntOfNat]
[Meta.synthInstance.apply] ✅️ apply @instRIntOfNat to R Int
[Meta.synthInstance.tryResolve] ✅️ R Int ≟ R Int
[Meta.synthInstance] result <not-available>
</pre>

The error message is shortened here by one line of hint. When the search for <code>R Int</code> asks again for <code>R Nat</code>, that goal is already in the table, so no new goal is opened; the request waits for an answer, none ever arrives, and the search ends with a failure. A naive depth-first search would loop forever.

== Inputs and outputs ==

The reference manual states that a search is attempted only when all the input parameters of the class are known. A problem with unknown inputs is '''stuck'''; it may be retried when elaboration learns more, and otherwise it fails.<ref name="manual-tc" /> A parameter marked <code>outParam</code> is not an input. It is ignored when instances are matched, and the instance found determines it.<ref name="manual-tc" /> In 4.34.1 the search replaces each output argument by a fresh metavariable before it starts and unifies the original afterwards.<ref name="src-synth" /> The arithmetic classes use this: <code>#check @HAdd</code> prints <code>HAdd : Type u_1 → Type u_2 → outParam (Type u_3) → Type (max (max u_1 u_2) u_3)</code>, so the types of the two summands select the instance and the instance fixes the type of the sum.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class Container (c : Type) (elem : outParam Type) where
first? : c → Option elem

instance : Container (List α) α := ⟨List.head?⟩

#check fun (xs : List Nat) => Container.first? xs
</pre>

This prints <code>fun xs => Container.first? xs : List Nat → Option Nat</code>: the element type was an output, read off the instance. Remove <code>outParam</code> and the same use is stuck, because the second argument is now an input and nothing determines it:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class Container' (c : Type) (elem : Type) where
first? : c → Option elem

instance : Container' (List α) α := ⟨List.head?⟩

def firstOf (xs : List Nat) := Container'.first? xs
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: typeclass instance problem is stuck
Container' (List Nat) (?m.7 xs)
</pre>

Lean's message continues with a note that the second argument contains metavariables and must be fully determined before resolution is tried. The manual also describes <code>semiOutParam</code>, a parameter that is taken into account when instances are selected but that instances must fill in.<ref name="manual-tc" />

== Default instances ==

When a search would otherwise fail without having selected an instance, the '''default instances''' of the class are tried, by priority, the more recent first among equals.<ref name="manual-tc" /> This is why <code>fun x => x + 1</code> elaborates to a function on <code>Nat</code>, as [[Lean theorem prover/System/Elaboration|elaboration]] traces in detail: the prelude makes <code>instHAdd</code> a default instance of <code>HAdd</code>, and <code>instOfNatNat</code> a default instance of <code>OfNat</code> with low priority.

== Coercions through classes ==

Coercions are instances too. When a term of one type is used where another is expected, the elaborator searches for an instance of the coercion classes, of which <code>Coe</code> is the main one, and inserts the function it finds.<ref name="manual-coe">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Coercions". https://lean-lang.org/doc/reference/4.34.0/Coercions/</ref>

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@[coe] def Square.toNat (s : Square) : Nat := s.side
instance : Coe Square Nat := ⟨Square.toNat⟩

def twice (n : Nat) : Nat := 2 * n

#check twice (⟨5⟩ : Square)
set_option pp.coercions false in
#check twice (⟨5⟩ : Square)
#eval twice (⟨5⟩ : Square)
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
twice ↑{ side := 5 } : Nat
twice { side := OfNat.ofNat 5 }.toNat : Nat
10
</pre>

The attribute <code>@[coe]</code> tells the printer to show the function as an arrow. With <code>pp.coercions</code> off, the elaborated term shows what was really inserted: a call of <code>Square.toNat</code>. The instance itself has been unfolded away, and the Lean kernel sees only the function application.

== The mathematical library's hierarchy ==

Lean's mathematical library, Mathlib, is organised around classes. A 2020 account of it, written for the Lean 3 version of the library, names, among the uses of type classes in Lean's core library: notation, such as the class behind <code>+</code>; mathematical structures, such as a ring structure on a type; coercions; and decidability of propositions. It explains that the library's classes are mostly '''semi-bundled''': the carrier type is a parameter of the class and the operations and axioms are fields. A type class problem should have essentially at most one solution and only parameters guide the search, so exposing the carrier lets the library register the canonical structure on a type. The same account calls the result a structure hierarchy rather than an algebraic one, because it extends far beyond groups and rings, and it records that diamonds are common in it.<ref name="mathlib-paper">The mathlib Community, "The Lean Mathematical Library", in ''Proceedings of the 9th ACM SIGPLAN International Conference on Certified Programs and Proofs (CPP 2020)'', ACM, 2020, pp. 367–381. doi:10.1145/3372885.3373824</ref> A 2022 study of the same library counted over 600 classes and over 8,000 instances as of February 2022, and analysed the design patterns, and the problems, that instance parameters bring at that scale.<ref name="baanen">Anne Baanen, "Use and Abuse of Instance Parameters in the Lean Mathematical Library", in ''13th International Conference on Interactive Theorem Proving (ITP 2022)'', Leibniz International Proceedings in Informatics 237, Schloss Dagstuhl, 2022, pp. 4:1–4:20. doi:10.4230/LIPIcs.ITP.2022.4</ref> Those are the conditions under which the diamond and cycle problems became urgent and tabled resolution was introduced.<ref name="selsam" /> In Lean 4 the mechanism is the one shown on this page. ''Mathematics in Lean'' devotes a chapter to building such hierarchies from classes that extend one another, starting from the observation that a commutative ring is in particular an additive group.<ref name="mil">Jeremy Avigad and Patrick Massot, ''Mathematics in Lean'', online book, chapter 8, "Hierarchies". https://leanprover-community.github.io/mathematics_in_lean/C08_Hierarchies.html</ref> This edition's code uses core Lean only, so the figures above are quoted from the cited papers, not measured here.

== Next ==

[[Lean theorem prover/System/The tactic framework|The tactic framework]] turns from the search for instances to the search for proofs.

== References ==

<references />

Lean theorem prover/System/Metavariables and unification

2026-10-15T19:35:07Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Metavariables and unification}}
{{Plebeian|Lean theorem prover/Explainers/Holes and goals|Lean theorem prover/Explainers/When Lean says no}}
{{Lean theorem prover map}}

A '''metavariable''' is a named hole in a term: a placeholder for a subterm not yet known. '''Unification''' is the search for values of metavariables that make two terms definitionally equal. Lean's elaborator, its tactic framework, its instance resolution and its simplifier all rest on these two things. This page describes them as Lean 4.34.1 implements them, explains why unification in Lean's type theory cannot be solved in general, and says what Lean does instead and what its failures mean.

== Holes with contexts ==

When the elaborator meets <code>id 5</code>, it does not yet know the implicit type argument of <code>id</code>. It creates a metavariable, written <code>?α</code> or <code>?m.7</code> in Lean's output, applies <code>id</code> to it, and continues; the numeral <code>5</code> must have type <code>?α</code>, and the instance problem it brings, <code>OfNat ?α 5</code>, later fixes <code>?α := Nat</code> through a default instance ([[Lean theorem prover/System/Elaboration|elaboration]]). A goal in a tactic proof is the same thing: an unassigned metavariable whose type is the proposition to prove.<ref name="mpbook">Arthur Paulino, Damiano Testa, Edward Ayers, Evgenia Karunus, Henrik Böving, Jannis Limperg, Siddhartha Gadgil and Siddharth Bhat, ''Metaprogramming in Lean 4'', online book, chapter "MetaM". https://leanprover-community.github.io/lean4-metaprogramming-book/main/04_metam.html</ref>

Each metavariable is declared in a '''local context''', the list of variables and hypotheses in scope where the hole was made, and it may be assigned only a term whose free variables come from that context. Lean's source writes this <code>C |- ?m : t</code>.<ref name="src-defeq">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Meta/ExprDefEq.lean</code>: the notes on pattern unification and its approximations A1 to A7. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Meta/ExprDefEq.lean</ref> The restriction is what keeps a solution from capturing a variable that did not exist where the hole was made.

The assignments live in a '''metavariable context''', separate from the terms. Assigning <code>?m</code> does not rewrite the terms that mention it; a later call to <code>instantiateMVars</code> substitutes the current assignments.<ref name="mpbook" /> A term handed to the Lean kernel must contain no metavariables at all ([[Lean theorem prover/System/The Lean kernel|the Lean kernel]]).

== Three kinds ==

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
#print Lean.MetavarKind
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Lean.MetavarKind : Type
number of parameters: 0
constructors:
Lean.MetavarKind.natural : Lean.MetavarKind
Lean.MetavarKind.synthetic : Lean.MetavarKind
Lean.MetavarKind.syntheticOpaque : Lean.MetavarKind
</pre>

The design notes in Lean's source give the rules. A '''natural''' metavariable may be assigned freely by unification; implicit arguments are of this kind. A '''synthetic''' one may be assigned by unification, but unification avoids doing so when it has a choice, because another procedure, usually instance resolution, is responsible for it and must check any value unification chose. A '''synthetic opaque''' one is never assigned by unification. Tactics such as <code>intro</code> make their new goals of this kind: a goal counts as solved when its metavariable is assigned, so unification must not close it behind the user's back.<ref name="src-mctx">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/MetavarContext.lean</code>: the design notes at the head of the file. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/MetavarContext.lean</ref>

Metavariables also carry a '''depth'''. A nested procedure, such as instance resolution called from inside unification, raises the depth of the metavariable context, and while it runs, unification does not assign metavariables of lower depth. This lets a subsidiary search create and solve its own holes without committing its caller to anything.<ref name="src-mctx" />

== Delayed assignment ==

A difficulty arises when a term containing a hole is put under a binder. Suppose <code>?m</code> may mention <code>x</code>, and the elaborator forms <code>fun x => t[?m]</code>. If <code>?m</code> is later assigned a term containing <code>x</code>, that occurrence must refer to the new bound variable. Lean handles this by creating a fresh metavariable <code>?n</code> of function type, with <code>x</code> removed from its context, and producing <code>fun x => t[?n x]</code>. For a natural or synthetic <code>?m</code> it simply assigns <code>?m := ?n x</code>. For a synthetic opaque <code>?m</code>, which may not be assigned that way, it records a '''delayed assignment''' <code>?n #[x] := ?m</code>: once <code>?m</code> receives a value with no metavariables left in it, each <code>?n r</code> is replaced by that value with <code>r</code> for <code>x</code>.<ref name="src-mctx" /> This is how a tactic block inside a <code>fun</code> can be run after the surrounding term has been closed over its variables.

== Unification ==

The unifier is Lean's definitional equality test with metavariables allowed. In the traces below it is written <code>s =?= t</code>, and it runs in the monad <code>MetaM</code> under a '''transparency''' setting that limits which definitions it may unfold, from <code>reducible</code> through <code>default</code> to <code>all</code>.<ref name="mpbook" /> First-order cases are easy. To make <code>?n + 2</code> equal to <code>5</code>, Lean solves <code>?n := 3</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem w : ∃ n : Nat, n + 2 = 5 := ⟨_, rfl⟩
#print w
</pre>

This prints <code>Exists.intro 3 rfl</code> as the proof. The hard cases have a metavariable applied to arguments, <code>?f a =?= t</code>: then <code>?f</code> stands for a function, and the problem is '''higher-order unification'''.

== Why it cannot be solved in general ==

Higher-order unification is undecidable. Gérard Huet's 1975 procedure for the typed λ-calculus is a semi-decision algorithm: it finds a unifier when one exists, but on problems with no unifier it may never stop, and Huet cites the undecidability of the problem as the reason.<ref name="huet">Gérard P. Huet, "A unification algorithm for typed λ-calculus", ''Theoretical Computer Science'' 1(1), 1975, pp. 27–57. doi:10.1016/0304-3975(75)90011-0</ref> For simply typed λ-terms it is undecidable already from order 2 upwards, a result due to Warren Goldfarb in 1981.<ref name="goldfarb">Warren D. Goldfarb, "The undecidability of the second-order unification problem", ''Theoretical Computer Science'' 13(2), 1981, pp. 225–230. doi:10.1016/0304-3975(81)90040-2. Not consulted directly; the result is stated, with this citation, in the introduction of Miller 1991.</ref> Unifiers are also not unique: <code>?f 3 =?= 3 + 3</code> is solved by <code>fun x => x + x</code>, by <code>fun x => 3 + x</code>, by <code>fun x => x + 3</code> and by the constant function returning <code>3 + 3</code>, and none is more general than the others.

Dale Miller isolated a fragment that behaves well. In a '''pattern''', a metavariable is applied only to distinct bound variables. Unification restricted to patterns is decidable and has most general unifiers whenever it has unifiers at all.<ref name="miller">Dale Miller, "A logic programming language with lambda-abstraction, function variables, and simple unification", ''Journal of Logic and Computation'' 1(4), 1991, pp. 497–536. doi:10.1093/logcom/1.4.497</ref> The solution is read off directly:

<math>?m\ a_1 \ldots a_n =^{?} t \quad\Longrightarrow\quad ?m := \lambda a_1 \ldots a_n.\ t</math>

== What Lean does ==

Lean's unifier, in <code>ExprDefEq.lean</code>, states its own version of Miller's condition. The constraint <code>?m@C a₁ … aₙ =?= t</code> is a pattern when the <code>aᵢ</code> are pairwise distinct free variables that are not local definitions and are not in <code>C</code>, when <code>t</code> uses only variables from <code>C</code> and the <code>aᵢ</code>, when every metavariable in <code>t</code> has a context that is a prefix of <code>C</code>, and when <code>?m</code> does not occur in <code>t</code>. Then <code>?m := fun a₁ … aₙ => t</code>.<ref name="src-defeq" /> The following problem is a pattern, because <code>x</code> is bound after the hole for <code>f</code> was made:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem dbl : ∃ f : Nat → Nat, ∀ x, f x = x * 2 := ⟨_, fun _ => rfl⟩
#print dbl
</pre>

The proof printed is <code>Exists.intro (fun x => x * 2) fun x => rfl</code>. With <code>set_option trace.Meta.isDefEq.assign true</code> the unifier reports the step, among 67 lines of trace:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
[Meta.isDefEq.assign] ✅️ ?m.12 x✝ := x✝ * 2
[Meta.isDefEq.assign.beforeMkLambda] ?m.12 [x✝] := x✝ * 2
[Meta.isDefEq.assign.checkTypes] ✅️ (?m.12 : Nat → Nat) := (fun x => x * 2 : Nat → Nat)
</pre>

Outside the pattern fragment Lean does not search, as Huet's procedure would. It applies workarounds and approximations, listed in the source as A1 to A7. Among them: '''first-order approximation''', which solves <code>?m a₁ … aₙ =?= f b₁ … bₖ</code> by matching the last arguments pairwise and unifying <code>?m</code> applied to the rest with <code>f</code> applied to the rest; and '''constant approximation''', which assigns <code>?m</code> a function ignoring its arguments. The notes say plainly that constant approximation may produce bad solutions, and give an example on which another of the approximations fails.<ref name="src-defeq" /> Each picks one unifier and commits to it:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem d (h : (3 : Nat) = 3) : 3 + 3 = 3 + 3 := congrArg _ h
#print d
</pre>

The conclusion of <code>congrArg</code> is <code>?f ?x = ?f ?y</code>, and the elaborator unifies it with the expected type before it looks at <code>h</code>. So the first constraint is <code>?f ?x =?= 3 + 3</code>, whose argument is itself unknown: not a pattern. The trace shows first-order approximation at work. It reads <code>3 + 3</code> as <code>HAdd.hAdd 3 3</code>, matches the last argument, <code>?x := 3</code>, and the rest, <code>?f := HAdd.hAdd 3</code>. The proof printed is <code>fun h => congrArg (HAdd.hAdd 3) h</code>: of the four solutions above, the one that reads <code>3 + x</code>.

== When it fails ==

The same approximation can choose wrongly. Here <code>?f a =?= a * 2</code> and <code>?f b =?= b * 2</code> must both hold, and <code>a</code> belongs to the context in which <code>?f</code> was made, so the first constraint is not a pattern:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (a b : Nat) (h : a = b) : a * 2 = b * 2 := congrArg _ h
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: Type mismatch
congrArg ?m.19 h
has type
?m.19 a = ?m.19 b
but is expected to have type
a * 2 = b * 2
</pre>

The trace option <code>trace.Meta.isDefEq</code> shows why. In this excerpt, lines marked … are omitted:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
[Meta.isDefEq] ❌️ a * 2 = b * 2 =?= ?m.19 a = ?m.19 b
…
[Meta.isDefEq] ✅️ a * 2 =?= ?m.19 a
[Meta.isDefEq] a * 2 [nonassignable] =?= ?m.19 a [assignable]
[Meta.isDefEq.foApprox] ?m.19 [a] := a * 2
[Meta.isDefEq] ❌️ a =?= 2
…
[Meta.isDefEq.foApprox] ?m.19 [a] := (a.mul 1).add a
[Meta.isDefEq] ✅️ a =?= a
[Meta.isDefEq] ✅️ ?m.19 =?= (a.mul 1).add
…
[Meta.isDefEq] ❌️ b * 2 =?= (a.mul 1).add b
</pre>

First-order approximation first tries to match <code>a * 2</code> against <code>?m.19 a</code> and fails on <code>a =?= 2</code>. After unfolding multiplication it succeeds, with <code>?m.19 := (a.mul 1).add</code>, a function that satisfies the first constraint and not the second. Writing the function explicitly, <code>congrArg (· * 2) h</code>, removes the higher-order problem and the proof is accepted.

A message such as <code>Type mismatch</code>, or from a tactic <code>could not unify</code>, therefore reports that the unifier returned false. That has three possible causes. The terms may differ under every assignment. The unifier may have committed to a wrong approximation, as above, or met a problem outside what it attempts. Or the transparency setting may have forbidden an unfolding that would have shown the terms equal. Only the first is a fact about the mathematics. The cure for the other two is to supply the missing information: an explicit argument, a type ascription, or a lemma that rewrites one side into the shape of the other.

== Next ==

[[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]] describes the search that fills synthetic metavariables, and [[Lean theorem prover/System/The tactic framework|the tactic framework]] the one that fills goals.

== References ==

<references />

Lean theorem prover/System/The Lean kernel

2026-10-15T19:35:06Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The Lean kernel}}
{{Plebeian|Lean theorem prover/Explainers/The small trusted core|Lean theorem prover/Explainers/What a proof assistant does}}
{{Lean theorem prover map}}

The '''Lean kernel''' is the type checker that decides whether a definition, theorem, axiom or inductive type may enter Lean's environment, its table of definitions and theorems. Everything else in Lean, from the parser to the most elaborate tactic, produces candidates; the Lean kernel accepts or refuses them. This page describes what it checks, what it never sees, how it is written, and where its trust ends, for Lean 4.34.1.

== What reaches it ==

The Lean kernel receives fully explicit terms of one data type, <code>Expr</code>. With <code>import Lean</code>, <code>#print Lean.Expr</code> lists its twelve constructors:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
#print Lean.Expr
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Lean.Expr : Type
number of parameters: 0
constructors:
Lean.Expr.bvar : Nat → Lean.Expr
Lean.Expr.fvar : Lean.FVarId → Lean.Expr
Lean.Expr.mvar : Lean.MVarId → Lean.Expr
Lean.Expr.sort : Lean.Level → Lean.Expr
Lean.Expr.const : Lean.Name → List Lean.Level → Lean.Expr
Lean.Expr.app : Lean.Expr → Lean.Expr → Lean.Expr
Lean.Expr.lam : Lean.Name → Lean.Expr → Lean.Expr → Lean.BinderInfo → Lean.Expr
Lean.Expr.forallE : Lean.Name → Lean.Expr → Lean.Expr → Lean.BinderInfo → Lean.Expr
Lean.Expr.letE : Lean.Name → Lean.Expr → Lean.Expr → Lean.Expr → Bool → Lean.Expr
Lean.Expr.lit : Lean.Literal → Lean.Expr
Lean.Expr.mdata : Lean.MData → Lean.Expr → Lean.Expr
Lean.Expr.proj : Lean.Name → Nat → Lean.Expr → Lean.Expr
</pre>

These are bound variables, free variables, metavariables, sorts, constants with universe levels, applications, functions, dependent function types, local definitions, numeric and string literals, annotations, and structure projections. The type theory they encode is described in [[Lean theorem prover/Foundations/Terms, types and judgments|terms, types and judgments]]. A term handed to the Lean kernel for addition may contain neither metavariables nor free variables: the elaborator must have solved every hole and closed every term.<ref name="src-env-cpp">Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/environment.cpp</code>: the functions <code>add_axiom</code>, <code>add_definition</code>, <code>add_theorem</code>, <code>add_opaque</code>, <code>add_mutual</code> and <code>check_constant_val</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/environment.cpp</ref>

The requests themselves form a second data type, <code>Lean.Declaration</code>, with seven constructors: an axiom, a definition, a theorem, an opaque constant, a block of mutually recursive definitions, the quotient primitives, and a block of inductive types. What the table stores, <code>Lean.ConstantInfo</code>, has eight: the same kinds, minus the mutual block, plus the constructors and recursors that the Lean kernel itself generates for each inductive type. Both are printed by <code>#print</code> in the same way as <code>Expr</code> above.

== What it checks ==

For every constant, whatever its kind, the Lean kernel checks that the name is not already taken, that no universe parameter is listed twice, that the stated type contains no metavariables or free variables, and that the type is itself well typed with a sort as its type.<ref name="src-env-cpp" /> Then it checks by kind.

'''An axiom''' is accepted once its type passes. Nothing else is checked, which is why axioms are listed by <code>#print axioms</code> and why the edition treats them on their own page, [[Lean theorem prover/Foundations/The three axioms|the three axioms]].

'''A definition, a theorem or an opaque constant''' has a value. The Lean kernel infers the value's type and asks whether it is definitionally equal to the stated type. For a theorem it also checks that the stated type is a proposition.<ref name="src-env-cpp" /> In the notation of the foundations pages, a definition <math>c : T := v</math> is accepted when

<math>\frac{\vdash T : \mathrm{Sort}\ u \qquad \vdash v : T' \qquad T' \equiv T}{c : T := v\ \ \mathrm{accepted}}</math>

where <math>\equiv</math> is definitional equality, the subject of [[Lean theorem prover/Foundations/Definitional equality|definitional equality]]. Much of the Lean kernel's work is in that last premise. Its implementation in 4.34.1 tries, in order: quick structural checks; full evaluation when the second term is the Boolean <code>true</code> and the first has no free variables, a path its source comment ties to the <code>decide</code> tactic; reduction to weak head normal form; proof irrelevance; lazy unfolding of definitions, the side with the greater definitional height first; then comparison of arguments, eta for functions, eta for structures, string literals and unit-like types.<ref name="src-tc">Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/type_checker.cpp</code>: the functions <code>is_def_eq_core</code>, <code>lazy_delta_reduction_step</code> and <code>reduce_nat</code>; with the function <code>compare</code> in <code>src/kernel/declaration.cpp</code>, which orders unfolding by definitional height. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/type_checker.cpp</ref>

A block of mutually recursive definitions is accepted only when it is marked <code>partial</code> or <code>unsafe</code>.<ref name="src-env-cpp" /> Ordinary recursive functions reach the Lean kernel already compiled into recursors, as [[Lean theorem prover/Foundations/Structural and well-founded recursion|structural and well-founded recursion]] explains, so the Lean kernel has no termination checker to trust.<ref name="manual-elab">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Elaboration and Compilation". https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref>

'''An inductive type''' is checked hardest, because its constructors and its recursor become axiom-like rules. For each constructor the Lean kernel checks that its type is well typed, that its parameters match the type's parameters, that each field lives in a universe no larger than the type's own (unless the type is a proposition), that the type being defined occurs only strictly positively, and that the constructor returns the type being defined. It then generates the recursor and its computation rules.<ref name="src-ind">Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/inductive.cpp</code>: the functions <code>check_constructors</code> and <code>check_positivity</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/inductive.cpp</ref> [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] gives the rules; here is the positivity check refusing a type that would make the logic inconsistent:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Bad where
| mk : (Bad → Nat) → Bad
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: (kernel) arg #1 of 'Bad.mk' has a non positive occurrence of the datatypes being declared
</pre>

The prefix <code>(kernel)</code> marks a message that comes from the Lean kernel and not from the elaborator.<ref name="src-message">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Message.lean</code>: the messages for <code>Kernel.Exception</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Message.lean</ref> Some checks are made twice. A constructor field in too large a universe, such as <code>mk : Type → Big</code> for <code>Big : Type</code>, is caught first by the elaborator, which gives a fuller message; the Lean kernel would refuse it too.<ref name="src-ind" />

== What it does not see ==

The Lean kernel sees no syntax, no notation, no macro, no tactic, no instance search and no coercion. It performs no unification and no termination checking.<ref name="manual-elab" /> A proof written with fifty tactic steps and the same proof written as a term reach it as the same kind of object, an <code>Expr</code>, and it cannot tell how either was found. This is the point of the design: the elaborator ([[Lean theorem prover/System/Elaboration|elaboration]]) and the tactic framework may be as clever, as large and as buggy as they like, because what they produce is checked again.

The arrangement can be tested by going around the elaborator. The following metaprogram hands the Lean kernel a theorem whose stated type is <code>False</code> and whose proof is <code>True.intro</code>:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Elab Command

#eval show CommandElabM Unit from do
let decl := Declaration.thmDecl {
name := `bogus, levelParams := [], type := mkConst ``False,
value := mkConst ``True.intro }
liftCoreM (addDecl decl)
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
error: (kernel) declaration type mismatch, 'bogus' has type
True
but it is expected to have type
False
</pre>

== Computation inside the check ==

Deciding definitional equality means running programs, so the Lean kernel contains an evaluator. Pure unfolding would make arithmetic on numerals hopeless, since <code>Nat</code> is unary in its definition. The Lean kernel therefore computes <code>Nat.add</code>, <code>Nat.sub</code>, <code>Nat.mul</code>, <code>Nat.div</code>, <code>Nat.mod</code>, <code>Nat.gcd</code>, <code>Nat.pow</code>, <code>Nat.beq</code>, <code>Nat.ble</code>, the bitwise operations and the shifts directly on literals, with the arbitrary-precision numbers of Lean's runtime.<ref name="src-tc" /> Their size is capped all the same: the Lean kernel refuses a natural-number literal, whether written in the source or produced by this arithmetic, that takes more than 128 MB, a default that the operating-system variable <code>LEAN_NAT_MAX_SIZE</code> can change.<ref name="src-natmax">Lean 4 source code, version 4.34.1 (2026), file <code>src/kernel/type_checker.cpp</code>: the constant <code>LEAN_NAT_MAX_SIZE_DEFAULT</code> (128 × 1024 × 1024 bytes), the functions <code>check_nat_size</code>, <code>infer_lit</code>, <code>reduce_nat</code> and <code>initialize_type_checker</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/kernel/type_checker.cpp</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem big : 2 ^ 64 * 2 ^ 64 = 2 ^ 128 := rfl
#print axioms big
</pre>

This prints <code>'big' does not depend on any axioms</code>. The cost is that this arithmetic, and the runtime code behind it, is part of what must be trusted.

== Its implementation ==

The reference manual states that the Lean kernel is written in C++, and that independent reimplementations exist in Rust and in Lean, the aim being to have as many implementations as possible so that they can be cross-checked against each other.<ref name="manual-elab" /> In version 4.34.1 the directory <code>src/kernel</code> of the Lean source holds 36 C++ source and header files totalling 8,071 lines, blank lines and comments included; this count was made for this page by running <code>wc -l</code> over those files as they stand at that version.<ref name="src-kernel-dir">Lean 4 source code, version 4.34.1 (2026), directory <code>src/kernel</code> (36 files <code>*.cpp</code> and <code>*.h</code>, plus <code>CMakeLists.txt</code>). Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/kernel</ref> The count is a lower bound on what is trusted, not a measure of it: those files include headers from Lean's runtime and utility libraries, for numbers, names and memory management, which the count leaves out. The largest files are the type checker (1,373 lines) and the checker for inductive types (1,417 lines). The paper that introduced Lean 4 describes the Lean kernel as relatively small.<ref name="lean4-paper">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref>

== Lean's environment ==

Lean's environment, its table of definitions and theorems, is the Lean kernel's state. In 4.34.1 the Lean structure <code>Lean.Kernel.Environment</code> maps each constant's name to its <code>ConstantInfo</code>, and its documentation says that this table contains every constant that has already been type checked by the Lean kernel, that it is never destructively updated, and that its constructor is private to protect against changes that bypass the Lean kernel.<ref name="src-env-lean">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Environment.lean</code>: the structure <code>Lean.Kernel.Environment</code>, the option <code>debug.skipKernelTC</code> and the function <code>addDeclWithoutChecking</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Environment.lean</ref> The same structure carries '''extensions''', further tables for data the Lean kernel ignores, such as simp lemmas, custom pretty printers and the compiler's intermediate code.<ref name="src-env-lean" /><ref name="manual-elab" /> Adding a constant returns a new table; nothing already accepted is changed.

== Where the trust ends ==

The checked table is only as good as the path into it. Lean 4.34.1 has an option, <code>debug.skipKernelTC</code>, whose own description warns that setting it "may compromise soundness" because proofs are then not checked by the Lean kernel, and a matching function, <code>addDeclWithoutChecking</code>.<ref name="src-env-lean" /> A Lean source file can also run arbitrary code while it is processed. The reference manual's guidance on validating proofs therefore recommends replaying the compiled files through the Lean kernel with a separate checker, and, for adversarial settings, building the proofs in a sandbox, exporting them and replaying them with the Lean kernel or an independent checker.<ref name="manual-validating">Lean Developers, ''The Lean Language Reference'', version 4.34.0, "Validating a Lean Proof". https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref> [[Lean theorem prover/System/Proof export and independent checkers|Proof export and independent checkers]] takes this up. The soundness of the type theory itself, which no checker can establish from inside, is the subject of [[Lean theorem prover/Foundations/Consistency and the metatheory|consistency and the metatheory]].

== Next ==

[[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] describes the holes the elaborator must fill before a term may reach the Lean kernel.

== References ==

<references />

Lean theorem prover/System/Elaboration

2026-10-15T19:35:04Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Elaboration}}
{{Plebeian|Lean theorem prover/Explainers/What a proof assistant does|Lean theorem prover/Explainers/When Lean says no}}
{{Lean theorem prover map}}

'''Elaboration''' is the step that turns what a person types into a term of Lean's core type theory. The typed text leaves out a great deal: the types of arguments, the instances behind notation such as <code>+</code>, conversions between number types, universe levels. The '''elaborator''' supplies all of it and produces a fully explicit term. That term then goes to the Lean kernel, which checks it. The elaborator's own reasoning is not trusted. This page follows a term from text to the Lean kernel and shows, with Lean 4.34.1's own output, what the elaborator adds.

== From text to the Lean kernel ==

Lean processes a source file one command at a time. Each command is parsed, then elaborated, and a new definition or theorem is checked by the Lean kernel and recorded in Lean's environment, its table of definitions and theorems. Each command can change how later commands are read, since a command may add new syntax.<ref name="manual-elab">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Elaboration and Compilation". https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref>

The '''parser''' turns characters into a syntax tree of type <code>Syntax</code>. The reference manual describes it as a recursive-descent parser that uses dynamic tables based on Pratt parsing, and its tables can be extended by any command.<ref name="manual-elab" /> A syntax tree records what was written, not what it means: <code>x + 1</code> parses the same whether <code>x</code> is a natural number, an integer or a matrix.

The '''elaborator''' gives the tree its meaning. Term elaborators, in the manual's words, map syntax and an optional expected type to a core language expression, and they work in a setting that provides unification, type class instance synthesis and type checking.<ref name="manual-elab" /> The result is an <code>Expr</code>, the same data type the Lean kernel checks.

== Macro expansion ==

Much of Lean's notation is defined by '''macros''': rules that rewrite one piece of syntax into another before it is given meaning. Macro expansion is not a separate pass. It is interleaved with elaboration.<ref name="manual-elab" /> In Lean 4.34.1 the main elaboration loop first asks whether a macro applies to the syntax at hand; if one does, it elaborates the expansion instead, and only otherwise does it call an elaboration function registered for that kind of syntax.<ref name="src-termelab">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/Term/TermElabM.lean</code>: the function <code>elabTermAux</code> and the type <code>SyntheticMVarKind</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/Term/TermElabM.lean</ref> The trace option <code>trace.Elab.step</code> prints each step together with the expected type at that point:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option trace.Elab.step true in
#check (3 : Nat) ≠ 4
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
3 ≠ 4 : Prop
[Elab.step] ✅️ expected type: <not-available>, term
(3 : Nat) ≠ 4
[Elab.step] ✅️ expected type: <not-available>, term
binrel% Ne✝ (3 : Nat) 4
[Elab.step] ✅️ expected type: <not-available>, term
(3 : Nat)
[Elab.step] ✅️ expected type: Type, term
Nat
[Elab.step.result] Nat
[Elab.step] ✅️ expected type: Nat, term
3
[Elab.step.result] 3
[Elab.step.result] 3
[Elab.step] ✅️ expected type: <not-available>, term
4
[Elab.step.result] 4
[Elab.step.result] 3 ≠ 4
[Elab.step.result] 3 ≠ 4
</pre>

The symbol <code>≠</code> is a macro. Its expansion, <code>binrel% Ne✝ (3 : Nat) 4</code>, hands the two sides to <code>binrel%</code>, an elaborator for binary relations. The dagger after <code>Ne</code> marks a name introduced by the macro, which text written by the user cannot capture; [[Lean theorem prover/System/Syntax extension and hygienic macros|syntax extension and hygienic macros]] explains this hygiene, which the paper introducing Lean 4 describes as capture-avoiding.<ref name="lean4-paper" /> The ascription <code>(3 : Nat)</code> passes the expected type <code>Nat</code> down to the numeral <code>3</code>.

== Expected types ==

The expected type is the elaborator's main source of information. Some notation cannot be read at all without it. The anonymous constructor <code>⟨1, 2⟩</code> names no type, so on its own it fails:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check ⟨1, 2⟩
</pre>

Lean answers <code>Invalid `⟨...⟩` notation: The expected type of this term could not be determined</code>. With an ascription, <code>#check (⟨1, 2⟩ : Nat × Nat)</code> prints <code>(1, 2) : Nat × Nat</code>: knowing the type, the elaborator finds the structure's one constructor and applies it.

== What the elaborator fills in ==

The option <code>pp.all</code> prints a term with nothing hidden: every implicit argument, every instance, every universe level. It is the way to see what the elaborator actually produced.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @id
set_option pp.all true in
#check id 5
set_option pp.all true in
#check (2 : Int) + (3 : Nat)
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@id : {α : Sort u_1} → α → α
@id.{1} Nat (@OfNat.ofNat.{0} Nat (nat_lit 5) (instOfNatNat (nat_lit 5))) : Nat
@HAdd.hAdd.{0, 0, 0} Int Int Int (@instHAdd.{0} Int Int.instAdd)
(@OfNat.ofNat.{0} Int (nat_lit 2) (@instOfNat (nat_lit 2)))
(@Nat.cast.{0} Int instNatCastInt (@OfNat.ofNat.{0} Nat (nat_lit 3) (instOfNatNat (nat_lit 3)))) : Int
</pre>

Four kinds of filling are visible.

'''Implicit arguments.''' The braces in <code>{α : Sort u_1}</code> mark an argument the user does not write. For <code>id 5</code> the elaborator creates a placeholder for <code>α</code>, a ''metavariable'', and unifies it with the type of the argument <code>5</code>, which is itself still open; it becomes <code>Nat</code> when the default instance for numerals is applied, as described under postponement below. [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] treats this machinery.

'''Universe levels.''' The universe parameter <code>u_1</code> of <code>id</code> is instantiated to <code>1</code>, since <code>Nat : Type</code> and <code>Type</code> is <code>Sort 1</code>.

'''Instances.''' A numeral is not a primitive: <code>5</code> becomes <code>OfNat.ofNat Nat 5 (instOfNatNat 5)</code>, and <code>+</code> becomes the method <code>HAdd.hAdd</code> of a type class with the instance <code>instHAdd</code> built on <code>Int.instAdd</code>. The instances are found by search; [[Lean theorem prover/System/Type classes and instance resolution|type classes and instance resolution]] describes it.

'''Coercions.''' The second summand was written as a natural number but is used where an integer is expected. The elaborator inserts <code>Nat.cast</code>, which the ordinary printer shows as <code>↑</code>. The reference manual states that a coercion is used when a term of one type appears where another is expected, and that coercions are found by type class instance synthesis.<ref name="manual-coe">Lean Developers, ''The Lean Language Reference'', version 4.34.0, chapter "Coercions". https://lean-lang.org/doc/reference/4.34.0/Coercions/</ref>

== Postponement ==

The elaborator works through a term roughly from left to right, but information often arrives late. A subterm may need a type that a later argument determines, or an instance problem may still contain unknowns. In such cases the elaborator does not fail. It puts a '''synthetic metavariable''' in place of the unfinished work and comes back to it. In Lean 4.34.1 such a placeholder has one of four kinds: an instance to be synthesised, a coercion to be inserted, a tactic block to be run, or a term whose elaboration was postponed.<ref name="src-termelab" />

The pending placeholders are resumed in a fixed order. Lean retries them while progress is being made. When none progresses, it retries without allowing further postponement, then applies '''default instances''' to instance problems still unsolved, then forces the remaining problems to succeed or report an error. Tactic blocks run last, when the rest of the term is as complete as it will get.<ref name="src-synth">Lean 4 source code, version 4.34.1 (2026), file <code>src/Lean/Elab/SyntheticMVars.lean</code>: the function <code>synthesizeSyntheticMVars</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Elab/SyntheticMVars.lean</ref>

Default instances explain a small puzzle:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check fun x => x + 1
</pre>

Lean prints <code>fun x => x + 1 : Nat → Nat</code>, although nothing in the text says <code>Nat</code>. The type of <code>x</code> is unknown, so the instance problem for <code>+</code> stays stuck through every round. At the default step, Lean's prelude marks <code>instHAdd</code> as a default instance, which makes both summands and the result share one type, and marks <code>instOfNatNat</code> as a low-priority default instance for numerals, which makes that type <code>Nat</code>.<ref name="src-prelude">Lean 4 source code, version 4.34.1 (2026), file <code>src/Init/Prelude.lean</code>: the attributes <code>@[default_instance]</code> on <code>instHAdd</code> and <code>@[default_instance 100]</code> on <code>instOfNatNat</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Prelude.lean</ref> Where no default applies, the elaborator reports the gap. Writing <code>def g := fun x => x</code> gives <code>Failed to infer type of binder `x`</code>.

== Why the elaborator is not trusted ==

The elaborator is large, it is written in Lean, and users extend it: every new macro, elaborator or tactic becomes part of it.<ref name="lean4-paper" /> The design does not ask anyone to trust it. Its output is checked by the Lean kernel, and the reference manual gives the reason: to guard against potential bugs in elaboration.<ref name="manual-elab" /> The Lean kernel does no unification of its own and no termination checking; it expects the elaborator to have done that work, and checks the explicit result.<ref name="manual-elab" /> As long as its output goes through the Lean kernel, a faulty elaborator can therefore cause a rejection, or a slow check, but not the acceptance of a false theorem. [[Lean theorem prover/System/The Lean kernel|The Lean kernel]] describes the checker.

One thing the Lean kernel cannot protect is meaning. The elaborator decides what a statement says: which instance <code>+</code> refers to, which coercion was inserted, which type a numeral was given. The Lean kernel then checks a proof of ''that'' statement. The reference manual's guidance on validating proofs makes the same separation: where there is doubt that a theorem means what it appears to mean, its statement and every definition it refers to must be examined, particularly where custom notation or type classes are involved.<ref name="manual-validating">Lean Developers, ''The Lean Language Reference'', version 4.34.0, "Validating a Lean Proof". https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref> <code>pp.all</code> and <code>#print</code> are the tools for that reading.

== Beyond terms ==

Elaboration also records what it did. Info trees relate the elaborated terms to the user's original syntax, and an editor uses them to show types on hover and goals in a proof.<ref name="manual-elab" /> Commands are elaborated too. A command elaborator may add definitions, open namespaces or declare new syntax, and these are changes to Lean's state, not terms. This extensibility, a parser, elaborator and tactic framework that users can extend from Lean itself, is a design aim stated in the abstract and the conclusion of the paper that introduced Lean 4.<ref name="lean4-paper">Leonardo de Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science 12699, Springer, 2021, pp. 625–635. doi:10.1007/978-3-030-79876-5_37</ref>

== Next ==

[[Lean theorem prover/System/The Lean kernel|The Lean kernel]] describes what happens to the elaborated term. [[Lean theorem prover/System/Metavariables and unification|Metavariables and unification]] opens up the placeholders used above.

== References ==

<references />

Lean theorem prover/Foundations/Consistency and the metatheory

2026-10-15T19:35:02Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Consistency and the metatheory}}
{{Plebeian|Lean theorem prover/Explainers/What has to be trusted}}
{{Lean theorem prover map}}

The '''metatheory''' of Lean is what can be proved ''about'' its type theory rather than
''in'' it. The central question is consistency: whether a closed proof of
<code>False</code> can ever pass Lean's kernel. The answer known today is relative, and it was proved for the type
theory of Lean 3. That theory, with its three axioms, can be interpreted in Zermelo–Fraenkel
set theory with choice (ZFC) extended by inaccessible cardinals, one axiom "there are <math>n</math> inaccessible
cardinals" for each natural number <math>n</math>, so it is consistent if that set theory
is. Several properties one might expect of a type theory fail for Lean, among them
decidability of definitional equality and normalisation, and none of these failures makes
the checker unsound. If Lean is consistent, it cannot prove its own consistency. This page sets
out each of these points and its source.

== The consistency theorem ==

Carneiro's thesis of 2019 writes down the type theory of Lean 3<ref name="lean4lean" /> in
full, including [[Lean theorem prover/Foundations/The three axioms|the three axioms]], and constructs a
set-theoretic model of it. Its conclusion, Corollary 6.8, is that Lean is consistent if ZFC
together with the axioms "there are <math>n</math> inaccessible cardinals", for every
natural number <math>n</math>, is consistent: there is no proof of <code>False</code> that
the Lean kernel verifies.<ref name="carneiro">Mario Carneiro, ''The Type Theory of Lean'', Master's thesis, Carnegie Mellon University, 2019; abstract, §1.2 (pp. 4–5), §3 (pp. 15–19), Theorem 4.1 (p. 19), Theorem 6.7 (p. 37) and Corollary 6.8 (p. 41). https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>

:<math>\mathrm{Con}\bigl(\mathrm{ZFC} + \{\exists\, n \text{ inaccessible cardinals} : n < \omega\}\bigr) \;\Rightarrow\; \mathrm{Con}(\mathrm{Lean})</math>

The model is the expected one. Types are sets and terms are their elements.
<code>Prop</code> is a two-element set whose members are the empty set and a one-element
set, so every proposition is interpreted as empty or as a one-element set, which validates
proof irrelevance. Each higher universe is interpreted inside a level of the cumulative hierarchy
cut off at an inaccessible cardinal, because universes are closed under function types and
inductive types, which makes them Grothendieck universes. Lean has a universe for every
natural number, so the full hierarchy calls for an inaccessible for each of them; a single
proof mentions only finitely many universes, which is why the hypothesis is stated one
<math>n</math> at a time. The impredicativity of <code>Prop</code> corresponds to full power
sets in ZFC.<ref name="carneiro" />

Carneiro calls the assumption optimal, for the following reason. Inside Lean one can build a
model of ZFC in each universe above the lowest, and define inaccessible cardinals in the
larger ones, so Lean proves the consistency of ZFC with any given finite number of
inaccessibles.<ref name="carneiro" />

== Relative consistency and Werner's theorem ==

The two directions were matched for the Calculus of Inductive Constructions, the theory
behind Coq, by Werner in 1997.<ref name="werner">Benjamin Werner, "Sets in types, types in sets", in Martín Abadi and Takayasu Ito (eds.), ''Theoretical Aspects of Computer Software (TACS 1997)'', Lecture Notes in Computer Science 1281, Springer, 1997, pp. 530–546. https://doi.org/10.1007/BFb0014566</ref> Writing <math>\mathrm{ZFC}_n</math>
for ZFC with <math>n</math> inaccessibles and <math>\mathrm{CIC}_n</math> for the calculus
with <math>n</math> universes, Carneiro summarises Werner's result as<ref name="carneiro" />

:<math>\mathrm{ZFC}_n \vdash \mathrm{Con}(\mathrm{CIC}_{n+1}) \qquad\qquad \mathrm{CIC}_{n+2} \vdash \mathrm{Con}(\mathrm{ZFC}_n)</math>

so that the unions over all <math>n</math> are equiconsistent. Werner's encoding of set theory in
the calculus also assumes excluded middle and a type-theoretic axiom of choice.<ref name="werner" /> Werner's construction of
set theory inside type theory has been replicated in Lean with minor changes, which gives
<math>\mathrm{Lean}_{n+2} \vdash \mathrm{Con}(\mathrm{ZFC}_n)</math>. Carneiro's model
supplies the other direction, <math>\mathrm{ZFC}_{n+1} \vdash \mathrm{Con}(\mathrm{Lean}_{n+1})</math>,
so Lean with all its universes is equiconsistent with both. He does not attempt sharp
universe bounds, and notes that matching Werner's exactly would require global choice, a
choice function on the whole set-theoretic universe, to interpret Lean's choice
axiom.<ref name="carneiro" /> Lean's consistency strength is thus that of the union of the
theories <math>\mathrm{ZFC}_n</math>.

== What fails ==

The same thesis records negative results, and later work adds one more.<ref name="carneiro" />

'''Definitional equality is undecidable, and so is type checking.''' The accessibility
predicate, together with proof irrelevance, lets a definitional-equality question encode
the halting problem. The argument is on
[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|proof irrelevance and subsingleton elimination]].

'''The checker's equality is weaker than the theory's.''' Lean's kernel implements a
decidable approximation, algorithmic equality, which is not transitive. Typing measured by
it fails subject reduction, and the reduction relation is not confluent (the Church–Rosser
property fails), so reducing both sides to normal form is not a decision procedure. A
modified reduction restores confluence at the cost of termination, enough to prove that
every term has a unique type up to definitional equality.<ref name="carneiro" />

'''Normalisation fails.''' Abel and Coquand showed that a type theory with an impredicative
<code>Prop</code> and a proof-irrelevant equality loses normalisation. One of their
counterexamples uses only <code>propext</code>, one of Lean's standard axioms, and gives a
closed proof with no weak head normal form; they note that it replays directly in Lean 3.4.2.<ref name="abel-coquand">Andreas Abel and Thierry Coquand, "Failure of normalization in impredicative type theory with proof-irrelevant propositional equality", ''Logical Methods in Computer Science'' 16(2) (2020), paper 14. https://doi.org/10.23638/LMCS-16(2:14)2020</ref> It
transcribes directly into Lean 4.34.1:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option linter.defProp false

def T : Prop := ∀ A : Prop, A → A

def delta : T → T := fun z => z (T → T) id z

def omega : T := fun A a => cast (propext ⟨fun _ => a, fun _ => id⟩ : (T → T) = A) delta

def Omega : T := delta omega

#print axioms Omega
</pre>

This prints <code>'Omega' depends on axioms: [propext]</code>. The type <code>T</code>
quantifies over all propositions, which is possible only because <code>Prop</code> is
impredicative. Given any proposition <code>A</code> and a proof <code>a</code> of it,
<code>propext</code> makes <code>T → T</code> equal to <code>A</code>, because both are
true; <code>omega</code> casts <code>delta</code> along that equation. When the cast is
used at <code>A = T → T</code> itself the two sides of the equation coincide, the cast
reduces away, and <code>delta omega</code> unfolds back to <code>delta omega</code>. Asked
to normalise the proof, Lean gives up, even with its recursion limit raised to 20,000:

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option maxRecDepth 20000 in
#reduce (proofs := true) Omega
</pre>

The error is <code>maximum recursion depth has been reached</code>. The failure reaches
beyond proofs. Carneiro's later paper on an
independent checker gives a variant in which a natural number defined by eliminating a
proof built from <code>Omega</code> sends a definitional-equality check into the same
loop:<ref name="lean4lean">Mario Carneiro, "Lean4Lean: Verifying a typechecker for Lean, in Lean", arXiv:2403.14064, version 3, 14 September 2025; abstract, §1, §3.2.1, §4.1 and §9. https://arxiv.org/abs/2403.14064</ref>

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Foo : Prop
| mk : T → Foo

def foo : Foo := Omega Foo (Foo.mk fun _ => id)

example : foo.recOn (motive := fun _ => Nat) (fun _ => 1) = 1 := by
rfl
</pre>

Lean again reports <code>maximum recursion depth has been reached</code>. Abel and Coquand
stress what is not at stake: consistency and canonicity are unaffected, and they compare the
situation to extensional type theory, which has an equality reflection rule.<ref name="abel-coquand" />

== Why the checker is still sound ==

Carneiro's argument needs one thing: whatever the checker accepts must be derivable in a
theory that has a model. He proves that algorithmic equality implies the ideal definitional
equality for well-typed terms. So if a term of type <code>False</code> passed the algorithmic
typing judgment, his description of what Lean's kernel checks, that term would have type
<code>False</code> in the ideal system, and the model would then contain
an element of the empty set. This is precisely the proof of Corollary 6.8.<ref name="carneiro" />

The failures above are therefore failures of completeness and of termination, not of
soundness. A checker that is incomplete rejects some correct terms. A checker that may not
terminate either loops or, as Lean does in the examples above, stops at a resource limit
and reports an error. Neither outcome accepts a false statement. Carneiro observes that the soundness proof of his
thesis, unlike MetaRocq's, does not depend on termination.<ref name="lean4lean" />

== Proving consistency inside Lean ==

Gödel's second incompleteness theorem sets the limit. A consistent formal system in which a
modest amount of arithmetic can be carried out cannot prove its own
consistency.<ref name="godel">Kurt Gödel, "Über formal unentscheidbare Sätze der Principia Mathematica und verwandter Systeme I", ''Monatshefte für Mathematik und Physik'' 38 (1931), 173–198. https://doi.org/10.1007/BF01700692</ref><ref name="sep-godel">Panu Raatikainen, "Gödel's Incompleteness Theorems", ''Stanford Encyclopedia of Philosophy'', substantive revision of 8 October 2025, §1 and §3. https://plato.stanford.edu/entries/goedel-incompleteness/</ref> Lean formalises far more than
that arithmetic, so if Lean is consistent, no Lean proof of "Lean is consistent" exists.
Carneiro's theorem respects the limit in the usual way: it is a proof in a different
system, ZFC with inaccessibles, and its conclusion is relative to that system's
consistency. The independent-checker project names Gödel's theorem as the reason
that nothing implying the unconditional soundness of Lean will be directly provable in Lean,
and plans to formalise Carneiro's relative consistency proof, which assumes large
cardinals.<ref name="lean4lean" />

== The theory and the implementation ==

A consistency proof covers a mathematical description of the theory, not the program that
checks it. The Lean 4 kernel extended the theory Carneiro analysed with features such as
nested inductive types and η for structures. Carneiro writes that these change the theory
enough that the 2019 proof no longer applies directly, pointing to later work that covers
some of the changes, and that some soundness bugs entered Lean's kernel during the move to
Lean 4.<ref name="lean4lean" /> One response is independent checking: a
second complete type checker written in Lean, able to check all of Mathlib, with part of it
formally verified against a formalisation of the type theory. That work has already found and
reported one soundness bug in Lean's kernel, since fixed.<ref name="lean4lean" /> The reference
manual's guide to validating proofs lists the soundness of Lean's logic among the
assumptions that remain even after the strictest checks.<ref name="refman-validating">''The Lean Language Reference'', version 4.34.0, "Validating a Lean Proof", section "Remaining Issues". https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref>
The checkers themselves are the subject of
[[Lean theorem prover/System/Proof export and independent checkers|proof export and independent checkers]].

== Next ==

[[Lean theorem prover/System/Elaboration|Elaboration]] begins the pages on how Lean works,
from the text a person types to the term the Lean kernel checks.
[[Lean theorem prover/System/The Lean kernel|The Lean kernel]] describes the program whose
soundness this page has been about.

== References ==

<references />

Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination

2026-10-15T19:35:01Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Proof irrelevance and subsingleton elimination}}
{{Plebeian|Lean theorem prover/Explainers/Two kinds of equality}}
{{Lean theorem prover map}}

Two rules govern how proofs behave in Lean. '''Definitional proof irrelevance''' makes any
two proofs of the same proposition definitionally equal. '''Restricted elimination''' allows
a proof to be taken apart to produce data only when the proposition is a
'''subsingleton''', one that by its shape can have at most one proof. The first rule says
that the content of a proof never matters; the second is what keeps that consistent. This
page states both rules, lists which propositions pass the test, explains why the test is
needed, and sets out the cost: together with the accessibility predicate, the two rules make
Lean's definitional equality undecidable.

== Definitional proof irrelevance ==

Carneiro's presentation of Lean's type theory includes the rule<ref name="carneiro">Mario Carneiro, ''The Type Theory of Lean'', Master's thesis, Carnegie Mellon University, 2019; §2.2 (pp. 6–7), §2.6.2 (pp. 10–11), §2.6.4 (p. 12), §2.8 (p. 15), §3.1 (pp. 16–17), Lemma 3.4 (pp. 18–19) and Corollary 6.8 (p. 41). https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>

:<math>\frac{\Gamma \vdash p : \mathrm{Prop} \quad \Gamma \vdash h : p \quad \Gamma \vdash h' : p}{\Gamma \vdash h \equiv h'}</math>

It is a rule of definitional equality, so the checker applies it during conversion, without
any proof term. The reference manual lists it among the defining properties of
<code>Prop</code>, beside the erasure of propositions from compiled code.<ref name="refman-props">''The Lean Language Reference'', version 4.34.0, §4.2 "Propositions". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Propositions/</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (p : Prop) (h₁ h₂ : p) : h₁ = h₂ := rfl

example (h₁ h₂ : 0 < 5) : (⟨5, h₁⟩ : {n : Nat // 0 < n}) = ⟨5, h₂⟩ := rfl

example (α : Type) (h₁ h₂ : Nonempty α) : Classical.choice h₁ = Classical.choice h₂ := rfl
</pre>

All three are accepted. The second shows the practical use: elements of a subtype are equal
as soon as their values are, whatever proofs they carry. The third shows that global choice
returns one element per type, not one per proof. Carneiro, writing in 2019, notes that Coq
then had proof irrelevance only as an axiom asserting a propositional equality, and calls
Lean's definitional version "a major departure for the theory".<ref name="carneiro" />

== Why elimination must be restricted ==

Suppose a program could inspect which constructor built a proof of a disjunction, and so
return <code>true</code> on <code>Or.inl trivial : True ∨ True</code> and <code>false</code>
on <code>Or.inr trivial</code>. Those two proofs have the same type, so proof irrelevance
makes them definitionally equal, the two results would be definitionally equal, and
<code>true = false</code> would follow by <code>rfl</code>. One of the two rules has to
give way. Lean keeps proof irrelevance and forbids the inspection: having been given a
proof, a program must not be able to tell which proof it received.<ref name="refman-ind">''The Lean Language Reference'', version 4.34.0, §4.4 "Inductive Types", subsection "Subsingleton Elimination". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/#subsingleton-elimination</ref>
Lean refuses the function:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def which (h : True ∨ True) : Bool :=
match h with
| .inl _ => true
| .inr _ => false
</pre>

The message begins <code>Tactic `cases` failed with a nested error:</code> and continues
<code>Tactic `induction` failed: recursor `Or.casesOn` can only eliminate into `Prop`</code>.
The restriction is visible in the recursors themselves. The motive of <code>Or.rec</code>
and of <code>Exists.rec</code> returns <code>Prop</code>, while the motives of
<code>True.rec</code>, <code>False.rec</code> and <code>And.rec</code> return an arbitrary
<code>Sort u_1</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @True.rec
#check @False.rec
#check @And.rec
#check @Or.rec
#check @Exists.rec
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@True.rec : {motive : True → Sort u_1} → motive True.intro → (t : True) → motive t
False.rec : (motive : False → Sort u_1) → (t : False) → motive t
@And.rec : {a b : Prop} → {motive : a ∧ b → Sort u_1} → ((left : a) → (right : b) → motive ⋯) → (t : a ∧ b) → motive t
@Or.rec : ∀ {a b : Prop} {motive : a ∨ b → Prop},
(∀ (h : a), motive ⋯) → (∀ (h : b), motive ⋯) → ∀ (t : a ∨ b), motive t
@Exists.rec : ∀ {α : Sort u_1} {p : α → Prop} {motive : Exists p → Prop},
(∀ (w : α) (h : p w), motive ⋯) → ∀ (t : Exists p), motive t
</pre>

== The rule ==

An inductive type in <code>Prop</code> may be eliminated into any universe, which is
'''large elimination''', when it is a syntactic subsingleton. The reference manual states
the test as two conditions: there is at most one constructor, and every argument of that
constructor either has a proposition as its type or is a parameter or an index of the
type.<ref name="refman-ind" /> Carneiro's formulation is that there is at most one constructor
and every non-recursive argument of it either has a proposition as its type or appears
directly in the constructor's output type.<ref name="carneiro" /> Otherwise the motive of the recursor must return
<code>Prop</code>. The test is deliberately conservative: it does not ask for a proof that
the proposition has at most one proof, only for a shape that guarantees it.<ref name="refman-ind" />

The standard cases:

* '''<code>True</code>''' has one constructor with no arguments, and '''<code>False</code>''' has none. From <code>h : False</code>, <code>h.elim</code> produces an element of any type.<ref name="refman-ind" />
* '''<code>And</code>''' has one constructor whose arguments are proofs.<ref name="refman-ind" />
* '''<code>Eq</code>''' has one constructor, <code>Eq.refl a</code>, whose argument is fixed by the type's parameters. This is why a proof of an equation can rewrite the type of data, the operation called transport on [[Lean theorem prover/Foundations/Propositional equality|propositional equality]].<ref name="refman-ind" />
* '''<code>Acc</code>''', the accessibility predicate, has one constructor <code>Acc.intro x h</code>. Its argument <code>x</code> appears in the result type <code>Acc r x</code> and its argument <code>h</code> is a proof, so it too eliminates into any universe. Carneiro singles it out as the source of proof by well-founded recursion.<ref name="carneiro" />

<code>Or</code> fails because it has two constructors. <code>Exists</code> and
<code>Nonempty</code> fail because their constructor stores a witness that is neither a
proof nor part of the type. Their proofs therefore cannot yield the witness as data; that
requires <code>Classical.choose</code>, as on
[[Lean theorem prover/Foundations/Classical logic from choice|classical logic from choice]].
Where the witness is wanted as data, the subtype <code>{x // p x}</code>, which lives in
<code>Type</code>, carries it.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def fromFalse (h : False) : Nat := h.elim

def castAlong {α β : Type} (h : α = β) (x : α) : β := h ▸ x

def bothThen {p q : Prop} (h : p ∧ q) (f : p → q → Nat) : Nat :=
match h with
| ⟨hp, hq⟩ => f hp hq

set_option pp.proofs true in
#check @Acc.rec
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@Acc.rec : {α : Sort u_2} →
{r : α → α → Prop} →
{motive : (a : α) → Acc r a → Sort u_1} →
((x : α) →
(h : ∀ (y : α), r y x → Acc r y) → ((y : α) → (a : r y x) → motive y (h y a)) → motive x (Acc.intro x h)) →
{a : α} → (t : Acc r a) → motive a t
</pre>

For subsingletons the checker also applies an extra reduction, which Carneiro calls K-like
reduction: by proof irrelevance the major premise may be replaced by the constructor, and
the ordinary computation rule then fires. It applies only when every argument of the
constructor can be read off the type, which is the reason for the shape of the
test.<ref name="carneiro" /> For <code>Eq</code> it makes transport along any proof of
<code>a = a</code> reduce to the identity.

== The cost: definitional equality is undecidable ==

Proof irrelevance and the large eliminator of <code>Acc</code> together break the
decidability of definitional equality. Carneiro's argument runs as follows.<ref name="carneiro" />
From a proof <code>a : Acc r x</code> one can project, with the eliminator, a function
giving accessibility of every smaller element; call it <code>a.inv</code>. Rebuilding with
the constructor gives a proof of the same proposition, so by proof irrelevance
<code>a</code> and <code>Acc.intro x a.inv</code> are definitionally equal:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example {α : Sort u} {r : α → α → Prop} {x : α} (a : Acc r x) :
a = Acc.intro x (fun _ h => a.inv h) := rfl
</pre>

That step turns any proof, even an opaque variable, into a constructor on which the
recursor can compute. Now take a decidable predicate <math>P</math> on the natural
numbers, such as "machine <math>M</math> runs for at least <math>n</math> steps without
halting", and a function <math>f</math> defined by recursion on <code>Acc</code> for the
relation <math>></math>, which at <math>n</math> returns a fixed value if
<math>P(n)</math> fails and otherwise calls itself at <math>n+1</math>. The relation
<math>></math> on the natural numbers is not well founded, so a hypothesis
<math>a : \mathrm{Acc}\,(>)\,0</math> is unprovable, but definitional equality is
judged in every context, inconsistent ones included. In that context each use of the
equation above lets <math>f\,0\,a</math> take one more step of the search. If
<math>P(n)</math> fails for some <math>n</math>, the search ends and <math>f\,0\,a</math> is
definitionally equal to the fixed value; if <math>P</math> holds everywhere, every term
definitionally equal to <math>f\,0\,a</math> still contains a call of <math>f</math>.
Deciding that one definitional equality would decide whether <math>M</math> halts.

Lean's checker cannot implement an undecidable relation. It implements a decidable
approximation, which Carneiro calls algorithmic equality, and the two must differ: the
chain of equalities above holds step by step, but the checker, which does not perform the
"creative" re-expansion of a normal term, does not relate its two ends. Algorithmic
equality is therefore not transitive.<ref name="carneiro" /> The reference manual records
the same fact: definitional equality as Lean checks it is reflexive and symmetric, but not
transitive.<ref name="refman-ts">''The Lean Language Reference'', version 4.34.0, §4 "The Type System" (definitional equality). https://lean-lang.org/doc/reference/4.34.0/The-Type-System/</ref> Carneiro also shows that, measured against the
algorithmic relation, typing fails subject reduction: a term can be well typed and reduce
to one that the checker rejects.<ref name="carneiro" />

None of this lets the checker accept a false theorem. Algorithmic equality implies the
ideal definitional equality for well-typed terms, so whatever the checker accepts is
derivable in the theory; Carneiro uses exactly this step in his consistency proof. The
defect is incompleteness, not unsoundness.<ref name="carneiro" />
Abel and Coquand later showed a related failure: with an impredicative <code>Prop</code>
and proof-irrelevant equality, reduction need not terminate at all.<ref name="abel-coquand">Andreas Abel and Thierry Coquand, "Failure of normalization in impredicative type theory with proof-irrelevant propositional equality", ''Logical Methods in Computer Science'' 16(2) (2020), paper 14. https://doi.org/10.23638/LMCS-16(2:14)2020</ref>
That result, and why the checker remains sound regardless, are treated on
[[Lean theorem prover/Foundations/Consistency and the metatheory|consistency and the metatheory]].
Abel and Coquand also note the other design: Agda and Coq had recently gained a proof-irrelevant universe
of strict propositions in which equality can be defined but cannot be eliminated into types
that are not themselves strict propositions, and under that restriction normalisation and
decidable type checking have been proved for the predicative case.<ref name="abel-coquand" />

== Next ==

[[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]]
asks what is known about the soundness of the whole system.

== References ==

<references />

Lean theorem prover/Foundations/Classical logic from choice

2026-10-15T19:34:59Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Classical logic from choice}}
{{Plebeian|Lean theorem prover/Explainers/What the axioms are}}
{{Lean theorem prover map}}

The rules of Lean's type theory, taken alone, are constructive: to assert <code>p ∨ ¬p</code>
is to know which of the two disjuncts holds, and for an arbitrary <code>p</code> that is not
known.<ref name="tpil-logic">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', chapter 3 "Propositions and Proofs", §3.5 "Classical Logic". https://lean-lang.org/theorem_proving_in_lean4/Propositions-and-Proofs/</ref> Lean does not add excluded middle as an axiom. It proves it, as the theorem
<code>Classical.em</code>, from the axiom of choice together with propositional and function
extensionality. The argument is known as '''Diaconescu's theorem'''. This page follows the
proof as Lean's core library carries it, then the decidability of every proposition that
follows from it, the <code>noncomputable</code> marker, and what is lost computationally.

== The statement ==

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @Classical.em
#print axioms Classical.em
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Classical.em : ∀ (p : Prop), p ∨ ¬p
'Classical.em' depends on axioms: [propext, Classical.choice, Quot.sound]
</pre>

All three axioms of [[Lean theorem prover/Foundations/The three axioms|the three axioms]]
appear. <code>Quot.sound</code> enters through <code>funext</code>, which Lean proves from
quotients.

== The argument ==

Fix a proposition <math>p</math>. Define two predicates on propositions:

:<math>U(x) \;:\equiv\; (x = \mathrm{True}) \lor p \qquad\qquad V(x) \;:\equiv\; (x = \mathrm{False}) \lor p</math>

Each is inhabited: <math>U(\mathrm{True})</math> and <math>V(\mathrm{False})</math> hold by
their left disjuncts. Choice therefore yields a proposition <math>u</math> with
<math>U(u)</math> and a proposition <math>v</math> with <math>V(v)</math>. Two facts follow.

'''First, either <math>u \neq v</math> or <math>p</math>.''' Each of <math>U(u)</math> and
<math>V(v)</math> is a disjunction, giving four cases. If either right disjunct holds,
<math>p</math> holds. In the remaining case <math>u = \mathrm{True}</math> and
<math>v = \mathrm{False}</math>, and since <math>\mathrm{True} \neq \mathrm{False}</math>,
<math>u \neq v</math>. This step is a case analysis on proofs of disjunctions, and it
produces a proposition, so it is permitted.

'''Second, <math>p</math> implies <math>u = v</math>.''' If <math>p</math> holds, both
predicates are true of every <math>x</math>, so <math>U(x)</math> and <math>V(x)</math> are
equivalent for each <math>x</math>. Propositional extensionality makes them equal for each
<math>x</math>, and function extensionality makes <math>U = V</math>. The choice function
applied to equal predicates gives equal results, so <math>u = v</math>.

Combining the two: if <math>u \neq v</math>, the second fact gives <math>\neg p</math>;
otherwise <math>p</math>. Either way <math>p \lor \neg p</math>.

The core library's proof, in <code>Init/Classical.lean</code>, follows exactly these
steps.<ref name="classical">Lean 4 source, file <code>src/Init/Classical.lean</code>, version 4.34.1: <code>Classical.em</code> ("Diaconescu's theorem"), <code>Classical.choose</code> and <code>Classical.propDecidable</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Classical.lean</ref> Below is a copy, lightly condensed, in which one case is closed
by an explicit term where the original calls <code>simp</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
open Classical in
theorem em' (p : Prop) : p ∨ ¬p :=
let U (x : Prop) : Prop := x = True ∨ p
let V (x : Prop) : Prop := x = False ∨ p
have exU : ∃ x, U x := ⟨True, Or.inl rfl⟩
have exV : ∃ x, V x := ⟨False, Or.inl rfl⟩
let u : Prop := choose exU
let v : Prop := choose exV
have u_def : U u := choose_spec exU
have v_def : V v := choose_spec exV
have not_uv_or_p : u ≠ v ∨ p :=
match u_def, v_def with
| Or.inr h, _ => Or.inr h
| _, Or.inr h => Or.inr h
| Or.inl hut, Or.inl hvf =>
Or.inl fun huv => true_ne_false (hut.symm.trans (huv.trans hvf))
have p_implies_uv : p → u = v := fun hp =>
have hpred : U = V :=
funext fun _ => propext ⟨fun _ => Or.inr hp, fun _ => Or.inr hp⟩
have h₀ : ∀ exU exV, @choose _ U exU = @choose _ V exV := by
rw [hpred]; intros; rfl
h₀ _ _
match not_uv_or_p with
| Or.inl hne => Or.inr (mt p_implies_uv hne)
| Or.inr h => Or.inl h

#print axioms em'
</pre>

The last line prints <code>'em'' depends on axioms: [propext, Classical.choice, Quot.sound]</code>.
The step <code>h₀</code> is where the choice function is shown to respect equality of
predicates. After rewriting <code>U</code> to <code>V</code>, the two sides are
<code>choose</code> applied to the same predicate and to two proofs of the same
proposition, and <code>rfl</code> closes the goal because those proofs are definitionally
equal.

== Where the strength comes from ==

The essential ingredient is not choice alone but choice combined with extensionality.
Constructive systems such as Bishop's constructive analysis and Martin-Löf's type theory
affirm a form of the axiom of choice, the statement that
<math>\forall x\, \exists y\, \phi(x,y)</math> gives a function <math>f</math> with
<math>\forall x\, \phi(x, f(x))</math>, without affirming excluded middle. Bell's survey
explains why there is no conflict. On a constructive reading that choice principle follows
from what existence means. The derivation of excluded middle needs more: besides choice, it
uses a comprehension principle and the extensionality of functions on predicates, so a
constructive system that affirms choice but not excluded middle must give up one of the two;
Bell finds a constructive justification for comprehension but none for extensionality.<ref name="sep">John L. Bell, "The Axiom of Choice", ''Stanford Encyclopedia of Philosophy'', substantive revision of 10 December 2021, §5 "The Axiom of Choice and Logic" and note 15. https://plato.stanford.edu/entries/axiom-choice/</ref> Lean asserts both. Its <code>Classical.choice</code> is a single
global choice function on all inhabited types, and <code>propext</code> with
<code>funext</code> makes it extensional. Once a choice function must give equal answers on
equivalent predicates, it can be made to decide <math>p</math>.

Diaconescu first derived excluded middle from the axiom of choice, in 1975, in a
category-theoretic setting.<ref name="diaconescu">Radu Diaconescu, "Axiom of choice and complementation", ''Proceedings of the American Mathematical Society'' 51 (1975), 176–178. https://doi.org/10.1090/S0002-9939-1975-0373893-X</ref><ref name="sep" /> Goodman and Myhill's
note of 1978 is titled "Choice implies excluded middle".<ref name="goodman-myhill">Nicolas D. Goodman and John Myhill, "Choice implies excluded middle", ''Zeitschrift für mathematische Logik und Grundlagen der Mathematik'' 24 (1978), 461. https://doi.org/10.1002/malq.19780242514</ref> Bell
traces the idea of the proof presented above, with two predicates and an extensional choice function,
to Goodman and Myhill, whose note built on Diaconescu's result.<ref name="sep" /> Lean's documentation names the theorem after
Diaconescu.<ref name="classical" />

== Decidable and propDecidable ==

The disjunction <code>p ∨ ¬p</code> is a proposition, and an inductive proposition with two
constructors can be eliminated only into propositions. A program therefore cannot branch on it. For
branching Lean uses a different type, <code>Decidable p</code>, whose two constructors carry
the same information as the two disjuncts but which lives in <code>Type</code>:<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', chapter 12 "Axioms and Computation", the introduction, §12.5 "Choice" and §12.6 "The Law of the Excluded Middle". https://lean-lang.org/theorem_proving_in_lean4/Axioms-and-Computation/</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Decidable
#check @Classical.propDecidable
#eval decide (2 < 3)
example : decide (2 < 3) = true := rfl
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Decidable : Prop → Type
number of parameters: 1
constructors:
Decidable.isFalse : {p : Prop} → ¬p → Decidable p
Decidable.isTrue : {p : Prop} → p → Decidable p
Classical.propDecidable : (a : Prop) → Decidable a
true
</pre>

An <code>if</code> expression asks for a <code>Decidable</code> instance of its condition.
For <code>2 < 3</code> the instance is an algorithm on natural numbers, so
<code>decide (2 < 3)</code> evaluates to <code>true</code>, both in compiled code and by
<code>rfl</code>. <code>Classical.propDecidable</code> supplies an instance for every
proposition. It is defined by applying <code>Classical.choice</code> to the fact, given by
<code>Classical.em</code>, that <code>Decidable a</code> is inhabited. It is a scoped
instance of low priority, active only after <code>open Classical</code>, so that where an
ordinary instance also applies, the ordinary one is tried first.<ref name="classical" />

== Noncomputable definitions ==

A definition that uses the classical instance to produce data cannot be compiled, and Lean
requires it to say so:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
open Classical in
noncomputable def classify (p : Prop) : Bool := if p then true else false

theorem classify_true : classify True = true := by
simp [classify]

#print axioms classify
#print axioms classify_true
#reduce classify True
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
'classify' depends on axioms: [propext, Classical.choice, Quot.sound]
'classify_true' depends on axioms: [propext, Classical.choice, Quot.sound]
Decidable.rec (fun h => false) (fun h => true) (Classical.choice ⋯)
</pre>

Without the marker the same definition is refused:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
open Classical in
def classify' (p : Prop) : Bool := if p then true else false
</pre>

Lean reports: <code>failed to compile definition, consider marking it as 'noncomputable'
because it depends on 'propDecidable', which is 'noncomputable'</code>.

== What is lost ==

Three things are lost when data is obtained from choice, and one is kept.

'''Evaluation.''' <code>#reduce classify True</code> stops at
<code>Classical.choice</code>, an axiom with nothing to unfold. The term is a closed
<code>Bool</code> that is neither <code>true</code> nor <code>false</code> by computation,
although <code>classify_true</code> proves that it equals <code>true</code>. ''Theorem Proving in Lean 4'' describes a
"computationally pure" fragment of Lean in which every closed term of type
<code>Nat</code> reduces to a numeral; a definition that uses choice for data lies outside
it.<ref name="tpil" />

'''Compilation.''' There is no code to generate for an axiom, so such a definition cannot
be run, as the refusal above shows.

'''Information.''' A classical existence proof does not say how to find the object, and a
function defined with <code>Classical.choose</code> does not say which object it picked.
''Theorem Proving in Lean 4'' illustrates this with a left inverse of an injective function:
a function from a classical point of view, unacceptable from a constructive one, since
there is in general no way to implement it.<ref name="tpil" />

'''What is kept''' is classical reasoning in proofs. Proofs are erased when Lean compiles a
definition, so excluded middle, proof by contradiction and the other classical principles
may be used freely to establish properties of programs that themselves compute.
''Theorem Proving in Lean 4'' puts the line exactly there: classical principles are
compatible with code generation so long as they are not used to manufacture data.<ref name="tpil" />
The <code>noncomputable</code> marker, not the axiom list, shows on which side of the line a
definition falls: a theorem proved with excluded middle lists <code>Classical.choice</code>
among its axioms, yet the programs it is about still run.

== Next ==

[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]]
explains why a proof of <code>p ∨ ¬p</code> cannot be used to branch, while a proof of an
equation can be used to cast.

== References ==

<references />

Lean theorem prover/Foundations/The three axioms

2026-10-15T19:34:58Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:The three axioms}}
{{Plebeian|Lean theorem prover/Explainers/What the axioms are}}
{{Lean theorem prover map}}

Lean's type theory, with its dependent functions, universes, inductive types and quotients,
is extended in the core library by three '''axioms''': propositional extensionality
(<code>propext</code>), the soundness of quotients (<code>Quot.sound</code>) and global
choice (<code>Classical.choice</code>). An axiom is a constant with a type and no
definition; it does not reduce, and the compiler cannot generate code for it.<ref name="refman-axioms">''The Lean Language Reference'', version 4.34.0, chapter 8 "Axioms": the introduction, §8.2 "Consistency", §8.3 "Reduction", §8.4 "Standard Axioms" and §8.5 "Displaying Axiom Dependencies". https://lean-lang.org/doc/reference/4.34.0/Axioms/</ref> Lean records, for every
definition and theorem, which axioms it depends on, and prints the list on request. This
page states the three as Lean prints them, says what each makes possible, shows the
dependency audit on examples, and sets out the further axioms that are not mathematics at
all.

== As Lean prints them ==

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print propext
#print Quot.sound
#print Classical.choice
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
axiom propext : ∀ {a b : Prop}, (a ↔ b) → a = b
axiom Quot.sound.{u} : ∀ {α : Sort u} {r : α → α → Prop} {a b : α}, r a b → Quot.mk r a = Quot.mk r b
axiom Classical.choice.{u} : {α : Sort u} → Nonempty α → α
</pre>

In Lean 4.34.1 <code>propext</code> is stated in the file <code>Init/Core.lean</code>, and
the other two in <code>Init/Prelude.lean</code>.<ref name="src">Lean 4 source, version 4.34.1: files <code>src/Init/Core.lean</code> (<code>propext</code>), <code>src/Init/Prelude.lean</code> (<code>Quot.sound</code>, <code>Classical.choice</code>, <code>sorryAx</code>) and <code>src/Init/Classical.lean</code> (the proof of <code>Classical.em</code>). Apache License 2.0. https://github.com/leanprover/lean4/tree/v4.34.1/src/Init</ref> As rules, with
<math>a, b : \mathrm{Prop}</math>:

:<math>\frac{\Gamma \vdash h : a \leftrightarrow b}{\Gamma \vdash \mathrm{propext}\,h : a = b} \qquad \frac{\Gamma \vdash p : r\,a\,b}{\Gamma \vdash \mathrm{Quot.sound}\,p : \mathrm{Quot.mk}\,r\,a = \mathrm{Quot.mk}\,r\,b} \qquad \frac{\Gamma \vdash h : \mathrm{Nonempty}\,\alpha}{\Gamma \vdash \mathrm{Classical.choice}\,h : \alpha}</math>

The first two conclude equations, which are propositions. The third concludes an element of
an arbitrary type. That difference decides how each one interacts with computation.

== What each makes possible ==

'''Propositional extensionality''' says that logically equivalent propositions are equal,
so that one may be replaced by the other in any context. The reference manual notes that
the ordinary connectives respect logical equivalence provably, without the axiom, but that
it is needed for an unknown predicate <code>P : Prop → Prop</code> applied to equivalent
arguments, and for equality between propositions itself.<ref name="refman-props">''The Lean Language Reference'', version 4.34.0, §4.2 "Propositions" (the axiom <code>propext</code> and its documentation). https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Propositions/</ref> It is
valid intuitionistically.<ref name="refman-props" /> ''Theorem Proving in Lean 4'' adds that
it agrees with set-theoretic readings in which every proposition is either empty or a
one-element set.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', chapter 12 "Axioms and Computation". https://lean-lang.org/theorem_proving_in_lean4/Axioms-and-Computation/</ref>

'''Quotient soundness''' identifies the classes of related elements in a
[[Lean theorem prover/Foundations/Quotient types|quotient type]]. It is also the only
axiom behind function extensionality, which Lean proves as a theorem from quotients; the
proof is on [[Lean theorem prover/Foundations/Propositional equality|propositional equality]]. With <code>propext</code> it gives an extensional theory of sets represented as
predicates: two predicates true of the same elements are equal.<ref name="tpil" />

'''Global choice''' turns a proof that a type is inhabited into an element of it.
<code>Nonempty α</code> is a proposition, and a proof of it carries no information about
which element exists. <code>Classical.choice</code> nevertheless returns one, and returns the
same one for any proof, since all proofs of a proposition are equal. ''Theorem Proving in
Lean 4'' derives from it the principle of indefinite description, and, with the other two
axioms, excluded middle, the decidability of every proposition and Hilbert's epsilon
operator.<ref name="tpil" /> That derivation is
[[Lean theorem prover/Foundations/Classical logic from choice|classical logic from choice]].

The first two can block evaluation in Lean's kernel, because a cast along an equation proved by
an axiom does not reduce, but they are compatible with compiled code, which erases proofs.
Choice is not: it manufactures data from a proposition, and definitions that use it for data
must be marked <code>noncomputable</code>.<ref name="tpil" />

== The audit: #print axioms ==

<code>#print axioms</code> lists every axiom a constant depends on, directly or through the
definitions and theorems it uses.<ref name="refman-axioms" /> Five small theorems show
the range from none to all three:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem two_add_two : 2 + 2 = 4 := rfl

theorem and_swap (p q : Prop) : p ∧ q ↔ q ∧ p :=
⟨fun ⟨hp, hq⟩ => ⟨hq, hp⟩, fun ⟨hq, hp⟩ => ⟨hp, hq⟩⟩

theorem and_swap_eq (p q : Prop) : (p ∧ q) = (q ∧ p) :=
propext (and_swap p q)

theorem add_zero_fun : (fun n : Nat => n + 0) = (fun n => n) :=
funext fun _ => rfl

theorem em' (p : Prop) : p ∨ ¬p := Classical.em p

#print axioms two_add_two
#print axioms and_swap
#print axioms and_swap_eq
#print axioms add_zero_fun
#print axioms em'
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
'two_add_two' does not depend on any axioms
'and_swap' does not depend on any axioms
'and_swap_eq' depends on axioms: [propext]
'add_zero_fun' depends on axioms: [Quot.sound]
'em'' depends on axioms: [propext, Classical.choice, Quot.sound]
</pre>

Here the computation checked by <code>rfl</code> and the logical equivalence need nothing, the
equation between propositions needs <code>propext</code>, and the equation between functions
needs <code>Quot.sound</code>, through <code>funext</code>. Excluded middle needs all three,
because the proof of <code>Classical.em</code> in the core library uses choice,
<code>propext</code> and <code>funext</code>.<ref name="src" />

== sorry and sorryAx ==

The term <code>sorry</code> closes any goal. It elaborates to the axiom
<code>sorryAx</code>, which inhabits every type, and so it is used for unfinished work and
never belongs in a finished proof.<ref name="refman-axioms" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print sorryAx

theorem unfinished : 1 = 2 := sorry

theorem uses_unfinished : 2 = 3 := congrArg (· + 1) unfinished

#print axioms uses_unfinished
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
axiom sorryAx.{u} : (α : Sort u) → Bool → α
'uses_unfinished' depends on axioms: [sorryAx]
</pre>

Lean warns once, with <code>declaration uses `sorry`</code>, at <code>unfinished</code>,
where <code>sorry</code> is written. The
theorem <code>uses_unfinished</code> raises no warning of its own, yet it proves a falsehood,
and only the axiom list shows why. The reference manual makes the same point about the
editor's check marks: they appear even when a dependency uses <code>sorry</code>, and
printing the axioms is what detects it.<ref name="refman-validating">''The Lean Language Reference'', version 4.34.0, "Validating a Lean Proof", sections "The Blue Double Check Marks", "Printing Axioms" and "On Lean.trustCompiler (up to Lean 4.28.0)". https://lean-lang.org/doc/reference/4.34.0/ValidatingProofs/</ref>

== Axioms that are not mathematics ==

Any user can write an axiom, and Lean accepts it. Lean cannot check that a
new axiom is consistent with the others.<ref name="refman-axioms" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
axiom everything_is_equal : ∀ (a b : Nat), a = b

theorem one_eq_two : 1 = 2 := everything_is_equal 1 2

#print axioms one_eq_two
</pre>

The last line prints <code>'one_eq_two' depends on axioms: [everything_is_equal]</code>.
The theorem is checked and accepted; the audit is what exposes its premise.

An axiom can also be harmless on its own and inconsistent with the standard three. The
reference manual's example is a "free theorem" of parametricity, which says that a function
polymorphic in the element type of a list commutes with mapping over the list. With excluded
middle every proposition is decidable, so a function can test whether its type argument is
<code>Nat</code> and behave differently when it is. That function is not parametric, and
together with the free theorem it proves <code>False</code>.<ref name="refman-axioms" />

The core library itself states three further axioms, <code>Lean.trustCompiler</code>,
<code>Lean.ofReduceBool</code> and <code>Lean.ofReduceNat</code>. The reference manual
describes them as mathematically trivial: they mark proofs that depend on the correctness of
the whole compiler rather than only on Lean's small kernel.<ref name="refman-axioms" /> The
tactic <code>native_decide</code>, which settles a decidable statement by running compiled
code, creates a dedicated axiom for each use, stating exactly the fact the compiled code
asserted:<ref name="refman-axioms" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem big : 123456 * 654321 = 80779853376 := by native_decide

#print axioms big
</pre>

Lean 4.34.1 prints <code>'big' depends on axioms: [big._native.native_decide.ax_1_1]</code>.
Such a theorem rests on the correctness of the whole compiler, not only on Lean's kernel and
the three axioms: each use of the tactic widens what has to be trusted.<ref name="refman-validating" />

== Why audit per theorem ==

The three standard axioms are, in the reference manual's words, "known to be
consistent".<ref name="refman-axioms" /> Carneiro's model of Lean's type theory in set
theory, published in 2019, covers all three axioms together;<ref name="carneiro">Mario Carneiro, ''The Type Theory of Lean'', Master's thesis, Carnegie Mellon University, 2019; abstract, §2.7 (pp. 12–13) and Corollary 6.8 (p. 41). https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref> it is described, with its limits, in
[[Lean theorem prover/Foundations/Consistency and the metatheory|consistency and the metatheory]].
Every other axiom is a premise the reader has to accept separately. The manual's guide to
validating a proof therefore asks that <code>#print axioms</code> report only
<code>propext</code>, <code>Classical.choice</code> and <code>Quot.sound</code>: a
<code>sorryAx</code> means an incomplete proof, <code>Lean.trustCompiler</code> means trust in
native evaluation, and anything else means a custom axiom on which the result is
conditional.<ref name="refman-validating" />

A list of axioms also says what kind of result a theorem is. A theorem whose list omits
<code>Classical.choice</code> uses no classical reasoning obtained from it, and one with an
empty list holds in the type theory alone. The check can be made permanent. The manual suggests pairing <code>#print axioms</code> with
<code>#guard_msgs</code>, so that a change in a library one depends on cannot silently add
an axiom:<ref name="refman-axioms" />

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
/-- info: 'two_add_two' does not depend on any axioms -/
#guard_msgs in
#print axioms two_add_two
</pre>

If the proof of <code>two_add_two</code> ever came to depend on an axiom, the message would
change, and this command would fail.

== Next ==

[[Lean theorem prover/Foundations/Classical logic from choice|Classical logic from choice]]
follows the third axiom into excluded middle.

== References ==

<references />

Lean theorem prover/Foundations/Quotient types

2026-10-15T19:34:56Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Quotient types}}
{{Plebeian|Lean theorem prover/Explainers/What the axioms are}}
{{Lean theorem prover map}}

A '''quotient type''' is a type whose elements are those of an existing type, with every
pair related by a given relation made equal. Mathematics constructs such objects constantly:
the integers modulo <math>n</math>, rational numbers as fractions up to cancellation, finite
sets as lists up to order and repetition. Lean provides quotients as a primitive of its type theory: four
constants, one axiom and one computation rule. This page sets out those rules, the
<code>Setoid</code> and <code>Quotient</code> layer built on them, a worked example, and
what the computation rule buys.

== The primitives ==

The constants are introduced early in Lean's core library by a dedicated command,
<code>init_quot</code>, not by an inductive definition.<ref name="prelude">Lean 4 source, file <code>src/Init/Prelude.lean</code>, version 4.34.1: the <code>init_quot</code> command and the documentation of <code>Quot</code>, <code>Quot.mk</code>, <code>Quot.lift</code>, <code>Quot.ind</code>, <code>Quot.sound</code> and <code>Quot.lcInv</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Prelude.lean</ref> Lean prints
them so:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Quot
#check @Quot.mk
#check @Quot.lift
#check @Quot.ind
#check @Quot.sound
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Quotient primitive Quot.{u} : {α : Sort u} → (α → α → Prop) → Sort u
@Quot.mk : {α : Sort u_1} → (r : α → α → Prop) → α → Quot r
@Quot.lift : {α : Sort u_1} →
{r : α → α → Prop} → {β : Sort u_2} → (f : α → β) → (∀ (a b : α), r a b → f a = f b) → Quot r → β
@Quot.ind : ∀ {α : Sort u_1} {r : α → α → Prop} {β : Quot r → Prop}, (∀ (a : α), β (Quot.mk r a)) → ∀ (q : Quot r), β q
@Quot.sound : ∀ {α : Sort u_1} {r : α → α → Prop} {a b : α}, r a b → Quot.mk r a = Quot.mk r b
</pre>

As rules: for any relation <math>r</math> on <math>A</math> there is a type, and every
element of <math>A</math> gives an element of it,

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \quad \Gamma \vdash r : A \to A \to \mathrm{Prop}}{\Gamma \vdash \mathrm{Quot}\,r : \mathrm{Sort}\,u} \qquad \frac{\Gamma \vdash a : A}{\Gamma \vdash \mathrm{Quot.mk}\,r\,a : \mathrm{Quot}\,r}</math>

A function out of the quotient is a function out of <math>A</math> together with a proof
that it respects <math>r</math>:

:<math>\frac{\Gamma \vdash f : A \to B \quad \Gamma \vdash h : \Pi (a\,b : A).\, r\,a\,b \to f\,a = f\,b}{\Gamma \vdash \mathrm{Quot.lift}\,f\,h : \mathrm{Quot}\,r \to B}</math>

and it computes on representatives:

:<math>\mathrm{Quot.lift}\,f\,h\,(\mathrm{Quot.mk}\,r\,a) \equiv f\,a</math>

The induction principle <code>Quot.ind</code> says that, for proving a proposition, every
element may be taken to be some <code>Quot.mk r a</code>. Finally the axiom identifies
related representatives:

:<math>\frac{\Gamma \vdash p : r\,a\,b}{\Gamma \vdash \mathrm{Quot.sound}\,p : \mathrm{Quot.mk}\,r\,a = \mathrm{Quot.mk}\,r\,b}</math>

'''Only <code>Quot.sound</code> is an axiom in any real sense.''' Carneiro observes that
<code>Quot</code>, <code>Quot.mk</code>, <code>Quot.lift</code> and the computation rule are all
satisfied by reading the quotient as <math>A</math> itself, <code>Quot.mk</code> as the
identity and <code>Quot.lift f h</code> as <code>f</code>; ''Theorem Proving in Lean 4'' notes
that <code>Quot.ind</code> holds under the same reading.<ref name="tpil" /> What that reading cannot satisfy is the identification of distinct
representatives. Because the computation rule is a reduction and not a constant, Carneiro calls
quotients a semi-built-in feature: Lean's kernel has to know about them, and they are
switched on as a whole.<ref name="carneiro">Mario Carneiro, ''The Type Theory of Lean'', Master's thesis, Carnegie Mellon University, 2019; §2.7.1 (p. 13), §2.8 (p. 15) and §3.1.1 (p. 17). https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>

The relation need not be an equivalence relation. The rules for <code>Quot</code> and
<code>Eq</code> together make equality in <code>Quot r</code> the equivalence relation
generated by <math>r</math>.<ref name="refman-quot">''The Lean Language Reference'', version 4.34.0, §4.5 "Quotients": the introduction, §4.5.5 "Logical Model", §4.5.5.2 "Quotients and Inductive Types", §4.5.6 "Quotients and Function Extensionality" and §4.5.7 "Squash Types". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Quotients/</ref>

== An example: unordered pairs ==

An unordered pair is an ordered pair taken up to swapping its components. The relation
below holds when one pair is the other reversed. It is symmetric but not reflexive, and
<code>Quot</code> does not mind.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
/-- `p` and `q` are related when `q` is `p` with its components swapped. -/
def Swapped (α : Type) (p q : α × α) : Prop := p.1 = q.2 ∧ p.2 = q.1

def UPair (α : Type) : Type := Quot (Swapped α)

def UPair.mk {α : Type} (a b : α) : UPair α := Quot.mk (Swapped α) (a, b)

theorem UPair.mk_comm {α : Type} (a b : α) : UPair.mk a b = UPair.mk b a :=
Quot.sound ⟨rfl, rfl⟩

def UPair.sum (u : UPair Nat) : Nat :=
Quot.lift (fun p => p.1 + p.2)
(fun p q (h : Swapped Nat p q) => by rw [h.1, h.2, Nat.add_comm])
u

example : UPair.sum (UPair.mk 3 4) = 7 := rfl
#eval UPair.sum (UPair.mk 3 4)

theorem UPair.sum_pos (u : UPair Nat) (h : ∀ a b, UPair.mk a b = u → 0 < a) :
0 < UPair.sum u := by
induction u using Quot.ind with
| mk p => exact Nat.lt_of_lt_of_le (h p.1 p.2 rfl) (Nat.le_add_right _ _)

#print axioms UPair.mk_comm
#print axioms UPair.sum
#print axioms UPair.sum_pos
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
7
'UPair.mk_comm' depends on axioms: [Quot.sound]
'UPair.sum' does not depend on any axioms
'UPair.sum_pos' does not depend on any axioms
</pre>

Each primitive has its part. <code>UPair.mk_comm</code> is the one statement that needs the
axiom: it asserts that two different representatives give the same element. The sum is
defined by <code>Quot.lift</code>, and the obligation it carries is the proof that swapping
the components does not change <code>p.1 + p.2</code>. A function that does not respect the
relation, such as the first component, cannot be lifted, because no such proof exists.
The <code>example</code> is closed by <code>rfl</code>: the computation rule reduces
<code>UPair.sum (UPair.mk 3 4)</code> to <code>3 + 4</code>, and then to <code>7</code>.
The theorem <code>UPair.sum_pos</code> uses <code>Quot.ind</code> to reduce a statement about
every unordered pair to one about representatives. Neither the definition nor the induction
uses an axiom; only the identification of representatives does.

== Setoid and Quotient ==

When the relation is an equivalence relation, the core library bundles it as a
'''setoid''': a type with a chosen relation and a proof that it is reflexive, symmetric and
transitive. <code>Quotient s</code> is then <code>Quot</code> applied to the setoid's
relation.<ref name="core">Lean 4 source, file <code>src/Init/Core.lean</code>, version 4.34.1: the definitions of <code>Setoid</code>, <code>Quotient</code> and <code>Quotient.exact</code>. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Core.lean</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Setoid
#print Quotient

instance parity : Setoid Nat where
r a b := a % 2 = b % 2
iseqv := ⟨fun _ => rfl, fun h => h.symm, fun h₁ h₂ => h₁.trans h₂⟩

def Mod2 : Type := Quotient parity

def Mod2.ofNat (n : Nat) : Mod2 := Quotient.mk parity n

def Mod2.isOdd : Mod2 → Bool :=
Quotient.lift (fun n => n % 2 == 1) (fun a b (h : a % 2 = b % 2) => by rw [h])

example : Mod2.ofNat 3 = Mod2.ofNat 7 := Quotient.sound rfl
example : Mod2.isOdd (Mod2.ofNat 7) = true := rfl

theorem Mod2.two_ne_three : Mod2.ofNat 2 ≠ Mod2.ofNat 3 := fun h =>
absurd (show 2 % 2 = 3 % 2 from Quotient.exact h) (by decide)

#print axioms Mod2.two_ne_three
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
class Setoid.{u} (α : Sort u) : Sort (max 1 u)
number of parameters: 1
fields:
Setoid.r : α → α → Prop
Setoid.iseqv : Equivalence Setoid.r
constructor:
Setoid.mk.{u} {α : Sort u} (r : α → α → Prop) (iseqv : Equivalence r) : Setoid α
def Quotient.{u} : {α : Sort u} → Setoid α → Sort u :=
fun {α} s => Quot Setoid.r
'Mod2.two_ne_three' depends on axioms: [propext]
</pre>

<code>Mod2</code> is the integers modulo 2, built from the natural numbers. Showing that
<code>3</code> and <code>7</code> have the same class is <code>Quotient.sound</code> applied to
a proof that <code>3 % 2 = 7 % 2</code>, which holds by computation. Showing that
<code>2</code> and <code>3</code> have different classes needs the converse, that equal
classes come from related representatives. That is <code>Quotient.exact</code>, and it is
where the equivalence relation matters. Its proof lifts the relation itself to a
proposition-valued function on pairs of classes; the obligation is that related inputs give
equal propositions, which needs propositional extensionality, and reflexivity then closes
the argument.<ref name="core" /> The output records it: the proof that two classes differ
depends on <code>propext</code>, not on <code>Quot.sound</code>.

== What the computation rule buys ==

Because <code>Quot.lift</code> reduces on <code>Quot.mk</code>, a function defined on a
quotient computes. <code>rfl</code> proves <code>UPair.sum (UPair.mk 3 4) = 7</code>, and
<code>#eval</code> runs the same function. The reference manual contrasts this with working
directly on sets of equivalence classes: functions out of such sets need non-computational
classical principles, whereas functions out of a quotient are ordinary functions that also
respect a relation.<ref name="refman-quot" /> It also notes that the quotient leaves
definitional equality untouched: two elements of a quotient are definitionally equal exactly
when their representatives are.<ref name="refman-quot" /> Elements made equal by
<code>Quot.sound</code> are equal propositionally, by a proof.

The rule is also what makes [[Lean theorem prover/Foundations/Propositional equality|function extensionality]]
a theorem. Quotienting a function type by pointwise equality and applying each class to an
argument reduces, by this rule, back to the original function. A propositional version of
the rule would not do, because using it under a binder would already need function
extensionality.<ref name="refman-quot" /> ''Theorem Proving in Lean 4'' likewise presents
function extensionality as a consequence of the quotient construction.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', chapter 12 "Axioms and Computation", §12.3 and §12.4. https://lean-lang.org/theorem_proving_in_lean4/Axioms-and-Computation/</ref>

The compiler erases <code>Quot.lift</code>. The core library carries an unsafe constant,
<code>Quot.lcInv</code>, documented as the device for doing so,<ref name="prelude" /> and the
reference manual notes that <code>Squash α</code>, the quotient of <code>α</code> by the
relation that relates everything, is represented at run time exactly as <code>α</code>
is.<ref name="refman-quot" />

== Limits ==

<code>Quot</code> is not an inductive type. In consequence, a recursive occurrence of the
type being defined may not appear inside a quotient in an inductive definition, as it may
inside a <code>List</code>:<ref name="refman-quot" />

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive SetTree (α : Type u) where
| leaf : α → SetTree α
| branch : Quot (fun (xs ys : List (SetTree α)) => True) → SetTree α
</pre>

Lean rejects it with <code>(kernel) arg #2 of 'SetTree.branch' contains a non valid occurrence
of the datatypes being declared</code>. The reference manual's remedy is to define the
type without the nested quotient and then quotient the whole type by a relation that
identifies the intended trees.<ref name="refman-quot" />

Quotients are also one of the places where the checker's algorithm and the type theory part
company. Carneiro shows that a quotient of a proposition behaves like a subsingleton
eliminator, and with it gives an instance where the checker's definitional-equality test
is not transitive.<ref name="carneiro" /> The page on
[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|proof irrelevance and subsingleton elimination]]
treats the main case of this, which comes from the accessibility predicate.

Other proof assistants make different choices. Carneiro noted in 2019 that Coq had no quotient
types with a computation rule, so that its users worked with setoids, types paired with an
equivalence relation that stands in for equality.<ref name="carneiro" />

== Next ==

[[Lean theorem prover/Foundations/The three axioms|The three axioms]] places
<code>Quot.sound</code> beside <code>propext</code> and <code>Classical.choice</code>.

== References ==

<references />

Lean theorem prover/Foundations/Propositional equality

2026-10-15T19:34:55Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Propositional equality}}
{{Plebeian|Lean theorem prover/Explainers/Two kinds of equality}}
{{Lean theorem prover map}}

'''Propositional equality''' is the proposition <code>a = b</code>. A proof of it is a term
of that type, built and used like any other proof. It is distinct from
[[Lean theorem prover/Foundations/Definitional equality|definitional equality]], which is a
judgment the checker tests by computation and which no term records. Lean defines
propositional equality as an inductive family with a single constructor. Symmetry,
transitivity, substitution and congruence are all derived from its eliminator. Function
extensionality is a theorem, proved from quotient types. Uniqueness of identity proofs
holds with no axiom at all.

== Equality as an inductive family ==

Lean's core library defines <code>Eq</code> as an inductive type in <code>Prop</code> with
one constructor, <code>Eq.refl</code>.<ref name="prelude">Lean 4 source, file <code>src/Init/Prelude.lean</code>, version 4.34.1: the definitions of <code>Eq</code>, <code>HEq</code>, <code>cast</code>, <code>congrArg</code>, <code>congr</code>, <code>congrFun</code> and <code>funext</code>, with their documentation comments. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Init/Prelude.lean</ref> Lean prints it so:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Eq
example : 2 + 2 = 4 := rfl
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Eq.{u_1} : {α : Sort u_1} → α → α → Prop
number of parameters: 2
constructors:
Eq.refl : ∀ {α : Sort u_1} (a : α), a = a
</pre>

The two parameters are the type <code>α</code> and the left-hand side <code>a</code>. The
right-hand side is an '''index''': it varies between the type and the constructor's result,
and the constructor fixes it to <code>a</code>. The constructor alone therefore proves only
statements of the form <code>a = a</code>; every other equation needs an argument that ends
in one. Written as rules, formation and introduction are

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \quad \Gamma \vdash a : A \quad \Gamma \vdash b : A}{\Gamma \vdash a = b : \mathrm{Prop}} \qquad \frac{\Gamma \vdash a : A}{\Gamma \vdash \mathrm{Eq.refl}\,a : a = a}</math>

The term <code>rfl</code> is <code>Eq.refl</code> with its argument left implicit. The
example <code>2 + 2 = 4 := rfl</code> is accepted because the checker finds
<code>2 + 2</code> and <code>4</code> definitionally equal; <code>rfl</code> then has the
type the statement asks for. Every proof by <code>rfl</code> is a definitional equality
packaged as a propositional one. Not every propositional equality is definitional: most
equations in mathematics need an argument, because no amount of computation turns one side
into the other.

== The eliminator ==

The recursor that [[Lean theorem prover/Foundations/Inductive types and recursors|every inductive type receives]]
is, for <code>Eq</code>, the principle that makes equality useful.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option pp.proofs true in
#check @Eq.rec
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@Eq.rec : {α : Sort u_2} →
{a : α} → {motive : (a_1 : α) → a = a_1 → Sort u_1} → motive a (Eq.refl a) → {a_1 : α} → (t : a = a_1) → motive a_1 t
</pre>

The motive, written <math>C</math> below, is a family over every right-hand side <code>y</code> and every
proof that <code>a = y</code>. To produce an element of <code>C b h</code> it suffices to
produce one at the constructor, <code>C a (Eq.refl a)</code>:

:<math>\frac{\Gamma \vdash C : \Pi (y : A).\, a = y \to \mathrm{Sort}\,v \quad \Gamma \vdash c : C\,a\,(\mathrm{Eq.refl}\,a) \quad \Gamma \vdash h : a = b}{\Gamma \vdash \mathrm{Eq.rec}\,c\,h : C\,b\,h}</math>

with the computation rule

:<math>\mathrm{Eq.rec}\,c\,(\mathrm{Eq.refl}\,a) \equiv c</math>

'''The motive may land in any universe, not only in <code>Prop</code>.''' A proof of an
equation can therefore change the type of a piece of data. This is unusual for a
proposition: Lean permits it only because <code>Eq</code> passes the test for subsingleton
elimination, which is the subject of
[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|proof irrelevance and subsingleton elimination]].<ref name="refman-ind">''The Lean Language Reference'', version 4.34.0, §4.4 "Inductive Types", subsection "Subsingleton Elimination" (the recursor of <code>Eq</code>). https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/#subsingleton-elimination</ref>

== Transport ==

Applying the eliminator with a motive that does not depend on the proof gives
'''transport''': from <code>h : a = b</code> and a term whose type mentions <code>a</code>,
obtain the same term at <code>b</code>. Lean's core library defines <code>Eq.subst</code>
and <code>cast</code> this way.<ref name="prelude" /> The triangle <code>h ▸ e</code> is a
macro over <code>Eq.rec</code> and <code>Eq.symm</code>: it tries both orientations of
<code>h</code>, and rewrites the expected type when there is one, otherwise the type of
<code>e</code>.<ref name="parser">Lean 4 source, file <code>src/Lean/Parser/Term.lean</code>, version 4.34.1: the documentation comment of the <code>h ▸ e</code> syntax. Apache License 2.0. https://github.com/leanprover/lean4/blob/v4.34.1/src/Lean/Parser/Term.lean</ref> With it the familiar laws of equality are one line
each:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem symm' {α : Sort u} {a b : α} (h : a = b) : b = a :=
h ▸ rfl

theorem trans' {α : Sort u} {a b c : α} (h₁ : a = b) (h₂ : b = c) : a = c :=
h₂ ▸ h₁

theorem subst' {α : Sort u} {a b : α} (p : α → Prop) (h : a = b) (ha : p a) : p b :=
h ▸ ha

theorem congrArg' {α : Sort u} {β : Sort v} {a₁ a₂ : α} (f : α → β) (h : a₁ = a₂) :
f a₁ = f a₂ :=
h ▸ rfl

def castAlong {α β : Type} (h : α = β) (x : α) : β :=
h ▸ x

#print axioms trans'
</pre>

The last command prints <code>'trans'' does not depend on any axioms</code>. Nothing beyond
the inductive definition is used. The definition <code>castAlong</code> is the case that
needs the large motive: its result is data of type <code>β</code>, obtained from data of
type <code>α</code> by a proof that the two types are equal.

== Congruence ==

The theorem <code>congrArg</code> above is the first congruence principle: equal arguments
give equal values. The core library adds <code>congrFun</code> (equal functions give equal
values at one argument) and <code>congr</code> (both at once), each proved by transport in
the same way. The library's documentation notes that tactics such as <code>congr</code>
and <code>simp</code> use <code>congrArg</code> internally to apply equalities inside
subterms.<ref name="prelude" /> <code>congrArg</code> and <code>congr</code> are stated for non-dependent functions. When the type of the
result depends on the argument, <code>f a₁</code> and <code>f a₂</code> have different
types, and the statement <code>f a₁ = f a₂</code> cannot even be formed. That case needs a
different relation.

== Heterogeneous equality ==

'''Heterogeneous equality''' relates terms whose types are not known to be definitionally
equal. It is a second inductive family, written <code>a ≍ b</code> in Lean 4.34.1:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print HEq
#check fun (n m : Nat) (x : Fin (n + m)) (y : Fin (m + n)) => x ≍ y
#check @type_eq_of_heq
#check @eq_of_heq
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive HEq.{u} : {α : Sort u} → α → {β : Sort u} → β → Prop
number of parameters: 2
constructors:
HEq.refl : ∀ {α : Sort u} (a : α), a ≍ a
fun n m x y => x ≍ y : (n m : Nat) → Fin (n + m) → Fin (m + n) → Prop
@type_eq_of_heq : ∀ {α β : Sort u_1} {a : α} {b : β}, a ≍ b → α = β
@eq_of_heq : ∀ {α : Sort u_1} {a a' : α}, a ≍ a' → a = a'
</pre>

The statement <code>x ≍ y</code> is well formed even though <code>Fin (n + m)</code> and
<code>Fin (m + n)</code> are equal only by a theorem about addition. The same statement
with <code>=</code> is rejected:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check fun (n m : Nat) (x : Fin (n + m)) (y : Fin (m + n)) => x = y
</pre>

Lean reports <code>Type mismatch</code>: <code>y</code> has type <code>Fin (m + n)</code> but
is expected to have type <code>Fin (n + m)</code>. A proof of <code>x ≍ y</code> carries a
proof that the types agree, which <code>type_eq_of_heq</code> extracts, and at a single type
it collapses to ordinary equality by <code>eq_of_heq</code>. The core library's own
documentation advises avoiding <code>HEq</code> where possible: the analogue of
<code>congr</code> fails for it, since from <code>f ≍ g</code> and <code>x ≍ y</code> it does
not follow that <code>f x ≍ g y</code>; the equality of types that <code>HEq</code> carries is
often too weak.<ref name="prelude" />

== Function extensionality ==

'''Function extensionality''' says that functions which agree at every argument are equal.
The eliminator of <code>Eq</code> offers no way to compare two lambda terms by their
values. The Lean reference manual notes that function extensionality would have to be an
axiom in Lean, were it not for quotient types, whose lifting operator has a definitional
computation rule.<ref name="refman-quot">''The Lean Language Reference'', version 4.34.0, §4.5.6 "Quotients and Function Extensionality". https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Quotients/#quotient-funext</ref> The proof in the
core library forms the quotient of the function type by pointwise equality and applies each
class to an argument:<ref name="prelude" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem funext' {α : Sort u} {β : α → Sort v} {f g : (x : α) → β x}
(h : ∀ x, f x = g x) : f = g :=
let eqv (f g : (x : α) → β x) : Prop := ∀ x, f x = g x
let app (q : Quot eqv) (x : α) : β x := Quot.lift (fun f => f x) (fun _ _ h => h x) q
congrArg app (Quot.sound h)

#print axioms funext'
#print axioms funext
</pre>
<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
'funext'' depends on axioms: [Quot.sound]
'funext' depends on axioms: [Quot.sound]
</pre>

The axiom <code>Quot.sound</code> makes the classes of <code>f</code> and <code>g</code>
equal, and <code>congrArg</code> carries that equality through <code>app</code>. The proof
type-checks only because <code>app (Quot.mk eqv f)</code> reduces, by the computation rule
for <code>Quot.lift</code>, to <code>fun x => f x</code>, which is <code>f</code> up to
η. A merely propositional computation rule would not do: rewriting under the binder would
already need function extensionality.<ref name="refman-quot" /> The axiom itself, and why
it is one, are on [[Lean theorem prover/Foundations/The three axioms|the three axioms]].

== Uniqueness of identity proofs ==

'''Uniqueness of identity proofs''' (UIP) says that any two proofs of
<code>a = b</code> are equal. Streicher's '''axiom K''' is the special case that every
proof of <code>a = a</code> is <code>Eq.refl a</code>, and the two are equivalent.<ref name="hott">The Univalent Foundations Program, ''Homotopy Type Theory: Univalent Foundations of Mathematics'', Institute for Advanced Study, 2013; Notes to Chapter 1, Example 3.1.9 and §7.2. https://homotopytypetheory.org/book/</ref>
In Lean both hold by definition:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem uip {α : Sort u} {a b : α} (h₁ h₂ : a = b) : h₁ = h₂ := rfl

theorem axiomK {α : Sort u} {a : α} (C : α → Sort v) (h : a = a) (x : C a) :
h ▸ x = x := rfl

#print axioms uip
#print axioms axiomK
</pre>

Both report that they do not depend on any axioms. The first is definitional proof
irrelevance: <code>a = b</code> is a proposition, so any two of its proofs are definitionally
equal. The second is what Carneiro calls K-like reduction: for a subsingleton eliminator,
proof irrelevance lets the major premise be replaced by the constructor, after which the
ordinary computation rule applies. For <code>Eq</code> this means that transport along
<code>h : a = a</code> reduces to the identity, whatever <code>h</code> is.<ref name="carneiro">Mario Carneiro, ''The Type Theory of Lean'', Master's thesis, Carnegie Mellon University, 2019; p. 4 (UIP and univalence), p. 12 (K-like reduction), p. 15 (proof irrelevance and axiom K in Lean and Coq). https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>
Carneiro lists proof irrelevance and axiom K among the axioms commonly added to Coq, and
observes that they hold in Lean with no axioms.<ref name="carneiro" />

Homotopy type theory takes the opposite course. It reads a proof of equality as a path,
keeps proofs of equality relevant, and treats UIP as a property some types have rather
than an axiom.<ref name="hott" /> Its univalence axiom identifies equivalent types. The
two-element type then has a non-trivial self-equality, the swap, so the universe is not a
set, and univalence is inconsistent with UIP.<ref name="hott" /><ref name="carneiro" />
Because Lean's UIP is part of definitional equality rather than an axiom that could be
left out, univalence cannot be added to Lean without making it inconsistent.

== Next ==

[[Lean theorem prover/Foundations/Quotient types|Quotient types]] treats the construction
that the proof of function extensionality used.

== References ==

<references />

Lean theorem prover/Foundations/Definitional equality

2026-10-15T19:34:53Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Definitional equality}}
{{Plebeian|Lean theorem prover/Explainers/Two kinds of equality|Lean theorem prover/Explainers/Computation inside proofs}}
{{Lean theorem prover map}}

Two terms are '''definitionally equal''' when they are equal by computation and unfolding of
definitions, without any proof. Definitional equality is not a proposition inside Lean. It is
a judgment of the theory, and Lean's kernel decides it, as far as it can, whenever it checks
a type. It is how computation enters proofs: a goal that holds by calculation is closed by
<code>rfl</code>, because the two sides are definitionally equal. This page lists the rules
that generate the relation, shows how natural-number literals are handled, describes how the
Lean kernel decides it, and states the theoretical limits: in Lean's full theory the relation
is undecidable, and the Lean kernel decides a slightly smaller one.

== The judgment and its use ==

The judgment <math>\Gamma \vdash e \equiv e'</math> says that <math>e</math> and
<math>e'</math> are definitionally equal in the context <math>\Gamma</math>. In the ideal
presentation it is an equivalence relation, closed under every term former, and generated
by the rules below.<ref name="carneiro2019">Mario Carneiro, ''The Type Theory of Lean'', MSc
thesis, Carnegie Mellon University, 2019.
https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref> It does its work
through the conversion rule of
[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]:

:<math>\frac{\Gamma \vdash e : A \qquad \Gamma \vdash A \equiv B}{\Gamma \vdash e : B}</math>

A term of one type also has every definitionally equal type. In particular, a proof of
<code>a = a</code>, which is what <code>rfl</code> is, is also a proof of <code>a = b</code>
whenever <code>a</code> and <code>b</code> are definitionally equal. Because the relation
includes reduction, types can be the result of computation.<ref name="refman-ts">''The Lean
Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, chapter 4, "The Type System".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/</ref>

== Reduction rules ==

Four reductions generate most of the relation. Each is named by a Greek letter by long
convention.<ref name="refman-ts" /><ref name="carneiro2019" />

* '''Beta''': applying an abstraction substitutes the argument, <math>(\lambda x : A.\, e)\,a \equiv e[a/x]</math>.
* '''Delta''': a defined constant equals its definition, with universe parameters instantiated, <math>c \equiv v</math> for <math>\mathrm{def}\ c := v</math>.
* '''Iota''': a recursor applied to a constructor reduces to the corresponding minor premise, as described on [[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]. A projection applied to a constructor application reduces in the same way, and so does the lifting of a function through a quotient, applied to an element of the quotient ([[Lean theorem prover/Foundations/Quotient types|Quotient types]]).
* '''Zeta''': a local definition equals its body with the value substituted, <math>(\mathrm{let}\ x := v;\ e) \equiv e[v/x]</math>.

Each holds by <code>rfl</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def sq (n : Nat) : Nat := n * n

example : (fun x : Nat => x + 1) 2 = 2 + 1 := rfl -- beta
example : sq 3 = 3 * 3 := rfl -- delta
example : Nat.rec (motive := fun _ => Bool) true (fun _ b => !b) 3 = false := rfl -- iota
example : (let x := 5; x + x) = 5 + 5 := rfl -- zeta
</pre>

The third line computes by recursion: the recursor flips a Boolean three times, starting
from <code>true</code>.

== Extensionality rules ==

Three further rules are not reductions of the left side to the right but identifications of
terms that cannot be told apart.<ref name="refman-ts" />

* '''Eta for functions''': <math>\lambda x : A.\, f\,x \equiv f</math>. A function is equal to the abstraction of its own application.
* '''Eta for structures''': for a value <math>s</math> of a structure type, a non-recursive type with no indices and exactly one constructor <math>\mathrm{mk}</math>, with fields <math>1, \ldots, n</math>, <math>s \equiv \mathrm{mk}\;(s.1)\;\ldots\;(s.n)</math>. This rule is new in the Lean 4 kernel.<ref name="lean4lean">Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean, in Lean", in ''31st International Conference on Types for Proofs and Programs (TYPES 2025)'', LIPIcs vol. 384, pp. 2:1–2:23, 2026. https://doi.org/10.4230/LIPIcs.TYPES.2025.2 (read in the version arXiv:2403.14064v2)</ref>
* '''Proof irrelevance''': any two proofs of the same proposition are definitionally equal.

:<math>\frac{\Gamma \vdash p : \mathrm{Prop} \qquad \Gamma \vdash h : p \qquad \Gamma \vdash h' : p}{\Gamma \vdash h \equiv h'}</math>

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (f : Nat → Nat) : (fun x => f x) = f := rfl -- eta, functions
example (p : Nat × Bool) : (p.1, p.2) = p := rfl -- eta, structures
example (p : Prop) (h₁ h₂ : p) : h₁ = h₂ := rfl -- proof irrelevance
</pre>

All three are accepted. None of these rules makes functions equal because they agree on all
arguments; that is the theorem <code>funext</code>, a propositional equality.<ref name="refman-fn">''The
Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.1.3,
"Extensionality".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Functions/</ref> Proof
irrelevance is the rule with the largest consequences, taken up in
[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]] and, below, as one source of undecidability.

== Natural-number literals ==

In the logic, <code>Nat</code> is the inductive type with constructors <code>zero</code> and
<code>succ</code>, so the number 1000 is <code>succ</code> applied a thousand times to
<code>zero</code>, and addition defined by recursion would take time proportional to the
size of its arguments. Lean's kernel does not compute this way. Natural-number literals are a
separate kind of term, stored as arbitrary-precision integers, and basic functions such as
addition, multiplication and comparison are evaluated on them by an arbitrary-precision
arithmetic library, usually GMP, instead of by unfolding their
definitions.<ref name="refman-nat">''The Lean Language Reference'', for Lean 4.34.0,
lean-lang.org, 2026, section 20.1, "Natural Numbers".
https://lean-lang.org/doc/reference/4.34.0/Basic-Types/Natural-Numbers/</ref><ref name="bailey">Christopher
A. Bailey, with contributions from the Lean community, ''Type Checking in Lean 4'' (online
book), chapters "Weak and strong reduction", "Definitional Equality" and "Reduction".
https://ammkrn.github.io/type_checking_in_lean4/</ref> When iota reduction needs to
see a constructor, a literal is presented as <code>zero</code> or as <code>succ</code>
applied to the literal one smaller, and literals compare equal to the corresponding
constructor terms, so the two forms remain interchangeable.<ref name="bailey" />

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem big_mul :
123456789123456789 * 987654321987654321 = 121932631356500531347203169112635269 := rfl
theorem pow_mod : 2 ^ 200 % 7 = 4 := by decide

#print axioms big_mul
#print axioms pow_mod
</pre>

Both theorems are accepted, and Lean prints
<code>'big_mul' does not depend on any axioms</code> and
<code>'pow_mod' does not depend on any axioms</code>. The 36-digit product was confirmed by
computation, not by an axiom. The price is trust: the arithmetic primitives are part of the
Lean kernel, and the reference manual notes that if they did not agree with the definitions of the
functions they replace, soundness could be undermined.<ref name="refman-nat" />

== How the Lean kernel decides it ==

The Lean kernel decides definitional equality by an algorithm that applies the rules lazily,
reducing only as far as it must.<ref name="bailey" /><ref name="lean4lean" />

'''Weak head normal form.''' The basic operation reduces a term at its head only, never
under a binder that has no argument applied to it, until no beta, iota, zeta, projection or
delta step applies at the head. The result is the term's '''weak head normal form''': a
sort, a function type, an abstraction, a literal, a constructor application, or an
application whose head is a variable or a constant that cannot be unfolded or reduced
further.<ref name="bailey" />

'''Cheap tests.''' Several tests need little or no reduction: identical terms, sorts with
equal levels, the same constant at equal universe levels, and, by proof irrelevance, two
terms whose types are the same proposition. Applications, binders and function types are
compared component by component.<ref name="bailey" />

'''Lazy delta.''' When both sides are headed by definitions, Lean's kernel does not unfold
both completely, which would be much less efficient. It unfolds step by step, choosing which side to unfold by a '''reducibility hint'''
stored with every definition: <code>opaque</code>, <code>abbrev</code>, or
<code>regular</code> with a '''definitional height''', one more than the greatest height of
the <code>regular</code> definitions its value mentions. Lean can show both the hints and the rule that uses them:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Meta

def sq (n : Nat) : Nat := n * n
def quad (n : Nat) : Nat := sq (sq n)
abbrev Sq := sq

def showHints : ReducibilityHints → String
| .opaque => "opaque"
| .abbrev => "abbrev"
| .regular h => s!"regular {h}"

#eval show MetaM Unit from do
for n in [``Nat.mul, ``sq, ``quad, ``Sq] do
let some (.defnInfo d) := (← getEnv).find? n | IO.println s!"{n}: not a definition"
IO.println s!"{n}: {showHints d.hints}"

#eval show MetaM Unit from do
IO.println ((← findDocString? (← getEnv) ``ReducibilityHints).getD "none")
</pre>

The first command prints <code>Nat.mul: regular 2</code>, <code>sq: regular 4</code>,
<code>quad: regular 5</code> and <code>Sq: abbrev</code>: <code>quad</code> is one higher
than <code>sq</code>, which it mentions. The second prints the documentation that Lean 4.34.1
carries for the hints; two passages of it read:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
* If `f` and `g` have the **same hint kind**:
- Both `.opaque` or both `.abbrev`: unfold both.
- Both `.regular`: unfold the one with the **greater** height first. If their heights are equal
(in particular, if `f` and `g` are the same definition), first try to compare their arguments
for definitional equality (short-circuiting the unfolding if they match), then unfold both.
* If `f` and `g` have **different hint kinds**: unfold the one that is *not* `.opaque`, preferring to
unfold `.abbrev` over `.regular`.
...
The hints only affect performance — they control the order in which definitions are unfolded, but
never prevent the kernel from unfolding a definition during type checking.

The `ReducibilityHints` are not related to the `@[reducible]`/`@[irreducible]`/`@[semireducible]`
attributes. Those attributes are used by the elaborator to control which definitions tactics like
`simp`, `rfl`, and `dsimp` will unfold; they do not affect the kernel.
</pre>

Unfolding the higher definition first brings it down towards the lower one, which it is
built from.<ref name="bailey" /> Because the attributes do not reach the Lean kernel, a definition marked <code>@[irreducible]</code>, such as one defined
by well-founded recursion
([[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]]), is still unfolded by the Lean kernel when a proof requires it.

'''Extensionality.''' When one side is an abstraction and the other is not, Lean's kernel
eta-expands the other side; when one side is a structure constructor application, it
compares the other side field by field through projections. Failures of the congruence step
are cached, which matters for performance.<ref name="bailey" /> Lean's kernel also has depth
and time limits on some of its operations, so many pathological checks stop with an error
instead of running for ever.<ref name="lean4lean" />

== Undecidability ==

Carneiro models what Lean's kernel checks as an '''algorithmic definitional equality''',
written <math>\Leftrightarrow</math>, and shows that it is sound: for two terms of the same
type, <math>e \Leftrightarrow e'</math> implies <math>e \equiv e'</math>.<ref name="carneiro2019" />
It is not complete, and in Lean's full theory no algorithm could be.

Carneiro proved in 2019 that definitional equality in Lean's theory is
undecidable;<ref name="carneiro2019" /> Abel and Coquand cite his proof, for the
accessibility predicate, and draw the consequence that typing is undecidable
too.<ref name="abelcoquand" /> The argument uses <code>Acc</code>, the inductive proposition behind well-founded recursion. Proof irrelevance
makes any proof <math>a</math> of <math>\mathrm{Acc}\;x</math> definitionally equal to
<math>\mathrm{intro}\;x\;(\mathrm{inv}\;a)</math>, a proof built from the constructor, where
<math>\mathrm{inv}\;a</math> extracts from <math>a</math> the accessibility of every element
below <math>x</math> in the relation. Since <code>Acc</code> has subsingleton elimination, a function into data can be
defined by recursion on such a proof, and the replacement unlocks one step of iota reduction.
Carneiro defines a function <math>f</math> that, at each step <math>n</math>, continues while a decidable
property <math>P\;n</math> holds and returns a fixed value when it fails, and takes
<math>P\;n</math> to say that a given Turing machine has not halted after <math>n</math>
steps, with the relation <math>></math> on the natural numbers. No proof that 0 is
accessible for <math>></math> can exist, but definitional equality must be decided in
every context, including one that assumes such a proof <math>a</math>. In that context the
chain

:<math>f\;0\;a \equiv f\;1\;a_1 \equiv f\;2\;a_2 \equiv \cdots</math>

in which <math>a_0 = a</math> and each <math>a_{n+1}</math> is the proof that
<math>n+1</math> is accessible which <math>\mathrm{inv}</math> extracts from
<math>a_n</math>, reaches the fixed value exactly when the machine halts. A decision procedure for
definitional equality would therefore solve the halting problem.

The algorithmic relation is therefore strictly smaller, and it is not transitive. In the
chain above it accepts
<math>f\;0\;a \Leftrightarrow f\;0\;(\mathrm{intro}\;0\;(\mathrm{inv}\;a))</math> by proof
irrelevance, and
<math>f\;0\;(\mathrm{intro}\;0\;(\mathrm{inv}\;a)) \Leftrightarrow f\;1\;a_1</math> by
reduction, when <math>P\;0</math> holds, but it does not accept the composite <math>f\;0\;a \Leftrightarrow f\;1\;a_1</math>:
<math>f\;0\;a</math> is already in normal form, so the algorithm has nothing to reduce, and the
intermediate term is a creative choice it does not make. Carneiro gives a second source of non-transitivity, quotients of
propositions, and shows that with the algorithmic relation in the conversion rule, typing
loses '''subject reduction''': a term can type-check while a term it reduces to does
not.<ref name="carneiro2019" />

Normalisation fails too. Abel and Coquand showed that a type theory with an impredicative
universe of propositions and a proof-irrelevant equality whose elimination does not inspect
the proof has terms with no normal form. Their counterexample, a version of the
self-application <math>\Omega</math>, runs in Lean 3.4.2, and using propositional
extensionality they gave a closed term, depending on Lean's standard axioms, that has no weak
head normal form at all.<ref name="abelcoquand">Andreas Abel and Thierry Coquand, "Failure
of Normalization in Impredicative Type Theory with Proof-Irrelevant Propositional Equality",
''Logical Methods in Computer Science'' 16(2), 2020.
https://doi.org/10.23638/LMCS-16(2:14)2020</ref> Carneiro reproduces it in Lean 4, with a
variant that makes a definitional-equality check on ordinary data fail to
terminate.<ref name="lean4lean" /> Lean 4.34.1 accepts the three definitions
below; asking for the normal form of <code>Om</code> does not finish:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option linter.defProp false
def True' : Prop := ∀ p : Prop, p → p

def om : True' := fun A a =>
@cast (True' → True') A
(propext ⟨fun _ => a, fun _ => id⟩)
(fun z => z (True' → True') id z)

def Om : True' := om (True' → True') id om

#reduce (proofs := true) Om
</pre>

Lean stops with <code>maximum recursion depth has been reached</code>. A recursion limit is
not itself a proof of non-termination; that <code>Om</code> has no normal form is Abel and
Coquand's theorem.

The reference manual states the position plainly. Lean's type theory lacks subject
reduction, its definitional equality is not necessarily transitive, and the type checker can
be made to run for ever. The sources are the ones described above: subsingleton elimination
and quotients of propositions, combined with definitional proof irrelevance, for the first two
properties;<ref name="carneiro2019" /> an impredicative universe of propositions with proof
irrelevance and propositional extensionality for the third.<ref name="abelcoquand" /> The
manual reports that failures of transitivity are exceedingly rare in practice, that, as far as
its authors know, non-termination has not occurred except in code written to provoke it, and
that logical soundness is not affected.<ref name="refman-kernel">''The Lean Language Reference'', for Lean 4.34.0,
lean-lang.org, 2026, section 2.3, "The Kernel".
https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref> The last point
is the one that matters for checking proofs. These properties make Lean's kernel incomplete,
not unsound: their typical effect is a true equality that the Lean kernel cannot confirm in one step,
which can often be proved instead as a chain of propositional equalities, since
propositional equality is transitive.

== Next ==

[[Lean theorem prover/Foundations/Propositional equality|Propositional equality]] treats
equality as a proposition, <code>a = b</code>, with its own rules, and its relation to the
definitional equality described here.

== References ==

<references />

Lean theorem prover/Foundations/Structural and well-founded recursion

2026-10-15T19:34:51Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Structural and well-founded recursion}}
{{Plebeian|Lean theorem prover/Explainers/Functions that always finish|Lean theorem prover/Explainers/Induction, as the machine sees it}}
{{Lean theorem prover map}}

Lean lets a function be defined by calling itself, but Lean's kernel knows nothing of
recursive definitions. Before a recursive definition reaches the Lean kernel, the elaborator
replaces the recursion by a non-recursive term built from recursors or from a well-founded
fixed-point combinator, and the fact that this translation succeeds is the proof that the
function terminates. This page explains why unrestricted recursion is not allowed, how
'''structural recursion''' is compiled through the recursor, how '''well-founded recursion'''
is compiled through <code>WellFounded.fix</code>, what <code>termination_by</code> and
<code>decreasing_by</code> control, how <code>partial</code> and <code>unsafe</code>
definitions are kept from compromising the logic, and the induction principles Lean derives from a
recursive definition.

== Why recursion must be checked ==

If any recursive equation were accepted as a definition, the logic would be inconsistent. The
equation <code>f n = f n + 1</code> would define a natural-number function with the absurd
property that a number equals its successor; and a function into the empty type
<code>Empty</code> that simply calls itself would produce an element of a type with no
elements, from which anything follows. A proof that "P holds because P holds" would be
accepted.<ref name="refman-rec">''The Lean Language Reference'', for Lean 4.34.0,
lean-lang.org, 2026, section 7.6, "Recursive Definitions".
https://lean-lang.org/doc/reference/4.34.0/Definitions/Recursive-Definitions/</ref> Lean's
logic therefore treats every function as '''total''': defined on every argument and
returning in finitely many steps.<ref name="refman-fn">''The Lean Language Reference'', for
Lean 4.34.0, lean-lang.org, 2026, section 4.1, "Functions".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Functions/</ref>

Termination is not checked by Lean's kernel, which has no termination checker; it is
guaranteed because every recursive function is elaborated into uses of primitive
recursors, which cannot loop.<ref name="refman-elab">''The Lean Language Reference'', for
Lean 4.34.0, lean-lang.org, 2026, sections 2.3, "The Kernel", and 2.4, "Elaboration
Results". https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref>
Elaboration proceeds in two phases. First the definition is elaborated as if the core
language had recursion, giving a '''pre-definition'''; the compiler generates code from
it unchanged. Then a termination analysis translates the pre-definition into a non-recursive
term for the Lean kernel. Without an explicit instruction the elaborator tries structural recursion
on each argument in turn, and then searches for a decreasing measure for well-founded
recursion.<ref name="refman-rec" /> The reference manual also describes partial fixpoints and
predicates defined as least or greatest fixed points; this page does not treat them.

== Structural recursion ==

A definition is '''structurally recursive''' when every recursive call is on a strict
sub-term of one fixed argument, the '''decreasing parameter''', as exposed by pattern
matching.<ref name="refman-rec" /> The Fibonacci function is a standard example:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def fib : Nat → Nat
| 0 => 0
| 1 => 1
| n + 2 => fib n + fib (n + 1)

#print fib
example : fib 10 = 55 := rfl
</pre>

Lean 4.34.1 prints the term the Lean kernel received:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def fib : Nat → Nat :=
fun x => Nat.brecOn x fib._f
</pre>

There is no self-reference. The recursion has become an application of
<code>Nat.brecOn</code>, and the cases of the definition are in an auxiliary function
<code>fib._f</code>.

<code>fib</code> calls itself on <code>n</code>, two steps below its argument, so the plain
recursor, whose step function sees only the result for the immediate predecessor, does not fit
directly. The elaborator uses two constructions derived from the recursor instead. For a
motive <code>C</code>, <code>Nat.below t</code> is a table holding a value of
<code>C k</code> for every <code>k</code> smaller than <code>t</code>, built as an iterated
pair; <code>Nat.brecOn</code> is a recursor whose step function receives that whole table, so
it can use the result for any smaller argument. This is '''course-of-values recursion'''.
Lean generates <code>below</code> and <code>brecOn</code> for every inductive type, following
McBride, Goguen and McKinna.<ref name="refman-ind">''The Lean Language Reference'', for Lean
4.34.0, lean-lang.org, 2026, section 4.4.3.3, "Constructions for Termination Checking".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/</ref><ref name="mgm">Conor
McBride, Healfdene Goguen and James McKinna, "A Few Constructions on Constructors", in
''Types for Proofs and Programs'' (TYPES 2004), Lecture Notes in Computer Science 3839,
Springer, 2006, pp. 186–200. https://doi.org/10.1007/11617990_12</ref>

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @Nat.brecOn
#print fib._f
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@Nat.brecOn : {motive : Nat → Sort u_1} → (t : Nat) → ((t : Nat) → Nat.below t → motive t) → motive t
@[reducible] def fib._f : (x : Nat) → Nat.below x → Nat :=
fun x f =>
(match (motive := (x : Nat) → Nat.below x → Nat) x with
| 0 => fun x => 0
| 1 => fun x => 1
| n.succ.succ => fun x => x.2.1 + x.1)
f
</pre>

In the last case the two recursive calls have become two lookups in the table:
<code>x.1</code> is the entry for <code>n + 1</code> and <code>x.2.1</code> the entry for
<code>n</code>. Because <code>brecOn</code> and <code>below</code> are themselves defined from
<code>Nat.rec</code>, the whole definition reduces by the ordinary rules of definitional
equality, which is why <code>fib 10 = 55</code> holds by <code>rfl</code>. Structurally
recursive functions compute inside Lean's kernel, and their defining equations hold
definitionally.<ref name="refman-elab" />

The analysis is syntactic, so some terminating functions fail it. A function that tests
<code>n == 0</code> and recurses on <code>n - 1</code> terminates, but <code>n - 1</code> is
not exposed as a sub-term by any pattern match, so it is not structural; such functions need
well-founded recursion.<ref name="refman-rec" /> The clause
<code>termination_by structural x</code> names the decreasing parameter explicitly and
forbids the fallback.

The term built from <code>brecOn</code> is not what runs. Compiled code is generated from the
pre-definition with ordinary recursion; the recursor-based term exists to justify
termination, not to be executed.<ref name="refman-elab" /><ref name="refman-ind" />

== Well-founded recursion ==

A relation <math>\prec</math> is '''well-founded''' when there is no infinite descending chain
<math>x_0 \succ x_1 \succ x_2 \succ \cdots</math>. Lean states this through the accessibility
predicate <code>Acc</code>, an inductive proposition: <code>x</code> is accessible when every
<code>y ≺ x</code> is accessible, and a relation is well-founded when every element is
accessible.<ref name="refman-rec" /> A function whose arguments decrease along a well-founded
relation at every recursive call can be defined with the fixed-point combinator

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @WellFounded.fix
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@WellFounded.fix : {α : Sort u_1} →
{C : α → Sort u_2} → {r : α → α → Prop} → WellFounded r → ((x : α) → ((y : α) → r y x → C y) → C x) → (x : α) → C x
</pre>

Its step function receives the current argument <code>x</code> and a function that may be
called only on arguments <code>y</code> accompanied by a proof of <code>r y x</code>.
<code>WellFounded.fix</code> is defined through an auxiliary function,
<code>WellFounded.fixF</code>, that takes the accessibility proof as an explicit argument:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print WellFounded.fixF
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def WellFounded.fixF.{u, v} : {α : Sort u} →
{r : α → α → Prop} → {C : α → Sort v} → ((x : α) → ((y : α) → r y x → C y) → C x) → (x : α) → Acc r x → C x :=
fun {α} {r} {C} F x a => Acc.rec (fun x₁ h ih => F x₁ ih) a
</pre>

Its body is one application of <code>Acc.rec</code>, the recursor of the accessibility
predicate. Well-founded recursion is therefore structural recursion again, on a proof that
the arguments decrease rather than on the data.<ref name="refman-elab" /> A
function's several arguments are packed into a single dependent pair, the relation is pulled
back from the measure with <code>invImage</code>, and each recursive call is given its proof
of decrease.<ref name="refman-rec" />

The measure is given with '''<code>termination_by</code>''' and the proofs of decrease with
'''<code>decreasing_by</code>''':

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def log2 (n : Nat) : Nat :=
if h : n < 2 then 0 else 1 + log2 (n / 2)
termination_by n
decreasing_by omega

#eval log2 1024
#print log2
</pre>

The evaluation prints <code>10</code>, and <code>#print</code> shows

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@[irreducible] def log2 : Nat → Nat :=
WellFounded.Nat.fix (fun x => x) fun n a => if h : n < 2 then 0 else 1 + a (n / 2) ⋯
</pre>

The recursive call <code>log2 (n / 2)</code> has become <code>a (n / 2) ⋯</code>, where
<code>⋯</code> stands for the proof, produced by <code>omega</code>, that
<code>n / 2 < n</code> in the branch where <code>n</code> is at least 2. Here the measure
is a natural number, and since Lean 4.27.0 such definitions use
<code>WellFounded.Nat.fix</code>, a variant whose recursion runs on a natural-number "fuel"
argument initialised from the measure, which makes the definitions easier to
evaluate.<ref name="rel427">''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org,
2026, release notes, "Lean 4.27.0", section "Language".
https://lean-lang.org/doc/reference/4.34.0/releases/v4.27.0/</ref> For other measures, such
as a pair of numbers compared lexicographically, the elaborator produces a term built on
<code>WellFounded.fix</code> directly. When <code>decreasing_by</code> is omitted a default
tactic tries to prove each obligation.<ref name="refman-rec" />

The <code>@[irreducible]</code> attribute is the visible difference from structural
recursion. Definitions by well-founded recursion are irreducible by default, so the
elaborator will not unfold them while checking definitional equality, and an equation that
would follow by computation is not accepted by <code>rfl</code>:<ref name="refman-rec" />

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : log2 8 = 3 := rfl
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Type mismatch
rfl
has type
?m.7 = ?m.7
but is expected to have type
log2 8 = 3
</pre>

The equation is still true, and Lean proves the defining equation as a theorem,
<code>log2.eq_1</code>, so that <code>simp [log2]</code> can rewrite with it and prove the
example. Even when the reductions do hold definitionally, they may be slow in the
Lean kernel, which must unfold the proof of termination along with the definition. The reference
manual's advice is to use structural recursion, where possible, for functions meant for use
in types or wherever definitional equality matters.<ref name="refman-rec" />

== Functional induction ==

A recursive definition determines an induction principle that follows its own case split and
recursive calls. Since Lean 4.8.0 the elaborator derives it automatically, as a theorem named
<code>f.induct</code> for a recursive function <code>f</code>.<ref name="rel48">''The Lean
Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, release notes, "Lean 4.8.0"
(functional induction principles) and "Lean 4.18.0" (the <code>fun_induction</code> tactic).
https://lean-lang.org/doc/reference/4.34.0/releases/v4.8.0/ and
https://lean-lang.org/doc/reference/4.34.0/releases/v4.18.0/</ref> It exists for the
structurally recursive <code>fib</code> as well as for the well-founded
<code>log2</code>:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @fib.induct
#check @log2.induct

theorem log2_le (n : Nat) : log2 n ≤ n := by
fun_induction log2 n with
| case1 n h => simp
| case2 n h ih => omega
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
fib.induct : ∀ (motive : Nat → Prop),
motive 0 → motive 1 → (∀ (n : Nat), motive n → motive (n + 1) → motive n.succ.succ) → ∀ (a : Nat), motive a
log2.induct : ∀ (motive : Nat → Prop),
(∀ (x : Nat), x < 2 → motive x) → (∀ (x : Nat), ¬x < 2 → motive (x / 2) → motive x) → ∀ (n : Nat), motive n
</pre>

Each principle has one case for each branch of its function. For <code>fib</code> the
recursive case has two induction hypotheses, one per recursive call: the two-step
induction that the definition needs, which ordinary induction on <code>Nat</code> does not
supply directly. For <code>log2</code> the recursive branch
carries an induction hypothesis for exactly the argument of the recursive call,
<code>x / 2</code>. The <code>fun_induction</code> tactic, added in Lean 4.18.0, applies it to
a goal about <code>log2 n</code>.<ref name="rel48" />

== Partial and unsafe definitions ==

Two modifiers admit definitions that are not shown to terminate, and both prevent them from
compromising proofs.<ref name="refman-rec" />

A '''<code>partial</code>''' definition is checked by the Lean kernel for type-correctness as if
recursion were allowed, and then enters the logic as an '''opaque constant''': a constant
with a type and no definition the Lean kernel may unfold. The compiler still produces ordinary
code for it.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
partial def collatz (n : Nat) : Nat :=
if n ≤ 1 then 0 else 1 + collatz (if n % 2 = 0 then n / 2 else 3 * n + 1)

#eval collatz 27
#print collatz
</pre>

Lean prints <code>111</code> and then <code>opaque collatz : Nat → Nat</code>. Whether this
function terminates on every input is the open Collatz problem. A partial function may
appear in propositions and proofs, but its equational theory is very weak: no property of its
values that depends on its definition can be proved, because the logic sees no
definition.<ref name="refman-rec" /> Even unfolding it fails:

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : collatz 1 = 0 := by unfold collatz; rfl
</pre>

Lean reports <code>Tactic `unfold` failed to unfold `collatz` in</code> followed by the goal,
<code>collatz 1 = 0</code>. For the same reason a partial function's result type must be shown to be inhabited.
Otherwise a partial function into <code>Empty</code> would be an opaque constant producing an
element of an empty type, and so a proof of anything:<ref name="refman-rec" />

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
partial def loop (n : Nat) : Empty := loop (n + 1)
</pre>

is rejected: <code>failed to compile 'partial' definition `loop`, could not prove that the
type Nat → Empty is nonempty</code>.

An '''<code>unsafe</code>''' definition has none of these restrictions. It may recurse freely,
its type need not be inhabited, and it may use operations, such as unchecked casts between
types, that break the equational theory. In exchange it may be used only by other
<code>unsafe</code> definitions, and never in a theorem:<ref name="refman-rec" />

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
unsafe def spin (n : Nat) : Empty := spin (n + 1)

theorem oops : False := (spin 0).elim
</pre>

Lean reports <code>(kernel) invalid declaration, it uses unsafe declaration 'spin'</code>.
The prefix shows that the refusal is made by Lean's kernel itself, so it does not depend on
the elaborator being correct.
<code>partial</code> and <code>unsafe</code> thus mark the boundary between Lean as a
programming language, where non-termination is a fact of life, and Lean as a logic, where it
would be a contradiction.

== Next ==

[[Lean theorem prover/Foundations/Definitional equality|Definitional equality]] describes the
computation rules that structural recursion relies on and that irreducible definitions
withhold, and how Lean's kernel decides them.

== References ==

<references />

Lean theorem prover/Foundations/Inductive types and recursors

2026-10-15T19:34:50Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Inductive types and recursors}}
{{Plebeian|Lean theorem prover/Explainers/Building things from constructors|Lean theorem prover/Explainers/Induction, as the machine sees it}}
{{Lean theorem prover map}}

Apart from universes, function types and quotient types, which are built in, every type in
Lean is an '''inductive type''' or is defined in terms of universes, functions and inductive
types.<ref name="refman-ind">''The Lean Language Reference'', for Lean 4.34.0, lean-lang.org,
2026, section 4.4, "Inductive Types".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/</ref> The
natural numbers, lists, pairs, conjunction and disjunction, equality and the existential
quantifier are all inductive types. An inductive type is given by its constructors, and from
them Lean derives one more constant, the '''recursor''', which is at once the type's induction
principle and its means of primitive recursion. This page describes what an inductive
definition adds to Lean's environment, its table of definitions and theorems; the reduction
rule that makes recursors compute; the strict positivity condition and why it is needed; and,
briefly, indexed, mutual and nested types.

== What a definition adds ==

An inductive definition names a '''type constructor''' and a list of '''constructors''':

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Nat
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Nat : Type
number of parameters: 0
constructors:
Nat.zero : Nat
Nat.succ : Nat → Nat
</pre>

The type constructor <code>Nat</code>, the constructors <code>Nat.zero</code> and
<code>Nat.succ</code>, and the recursor <code>Nat.rec</code> are new constants with no
defining term: Lean adds them as axiomatic constants.<ref name="carneiro2019">Mario
Carneiro, ''The Type Theory of Lean'', MSc thesis, Carnegie Mellon University, 2019.
https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref> The
recursor in particular has a function type but is primitive, and cannot be defined using
<code>fun</code>.<ref name="refman-ind" />
What makes them more than arbitrary axioms is that their types are computed from the
definition by a fixed scheme, and that the definition must pass checks, described below,
which guarantee that adding them cannot make the logic inconsistent. The checks are
conservative: some harmless definitions are rejected too.<ref name="refman-ind" />

Every other property of the type is derived from the recursor. Injectivity of the
constructors, the fact that distinct constructors give distinct values, case analysis and
structural recursion are theorems and definitions built from <code>Nat.rec</code>, not
further primitives.<ref name="refman-ind" />

== The recursor ==

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check Nat.rec
</pre>

Lean 4.34.1 prints

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Nat.rec.{u} {motive : Nat → Sort u} (zero : motive Nat.zero) (succ : (n : Nat) → motive n → motive n.succ) (t : Nat) :
motive t
</pre>

The arguments have standard names.<ref name="refman-ind" /><ref name="carneiro2019" />

* The '''motive''' is a family of types indexed by the inductive type, <code>motive : Nat → Sort u</code>. It says what is being constructed or proved for each number.
* There is one '''minor premise''' per constructor. The one for <code>zero</code> is a value of <code>motive zero</code>. The one for <code>succ</code> takes <code>n</code> and a value of <code>motive n</code>, the result for the recursive argument, and returns a value of <code>motive (n + 1)</code>.
* The '''major premise''' <code>t</code> is the value the recursion runs on, and the result has type <code>motive t</code>.

Because the motive may land in any universe <code>Sort u</code>, the same constant does two
jobs. With a motive into <code>Prop</code>, <code>Nat.rec</code> is mathematical induction:
the minor premises are the base case and the induction step. With a motive into
<code>Type</code>, it is primitive recursion. Both uses below are checked by the same rule:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def double (n : Nat) : Nat :=
Nat.rec (motive := fun _ => Nat) 0 (fun _ ih => ih + 2) n

#reduce double 3

theorem zero_add' (n : Nat) : 0 + n = n :=
Nat.rec (motive := fun k => 0 + k = k) rfl (fun _ ih => congrArg Nat.succ ih) n
</pre>

<code>#reduce double 3</code> prints <code>6</code>. In general the recursor's type is
determined by the constructors alone: each constructor contributes a minor premise that
assumes the motive for each of its recursive arguments.<ref name="carneiro2019" /> Dybjer
gave a general formulation of this idea for Martin-Löf's type theory, in which the
elimination and equality rules of a new type are derived from its formation and introduction
rules, and Lean's treatment of inductive types is based on his.<ref name="lean4lean">Mario Carneiro, "Lean4Lean: Verifying a
Typechecker for Lean, in Lean", in ''31st International Conference on Types for Proofs and
Programs (TYPES 2025)'', LIPIcs vol. 384, pp. 2:1–2:23, 2026.
https://doi.org/10.4230/LIPIcs.TYPES.2025.2 (read in the version arXiv:2403.14064v2)</ref><ref name="dybjer1994">Peter Dybjer, "Inductive families", ''Formal Aspects of
Computing'' 6(4), 1994, pp. 440–465. https://doi.org/10.1007/BF01211308</ref>

Lean's core has recursors but no pattern matching and no recursive definitions. Pattern
matching and recursion in source text are compiled into uses of the recursor, so the
recursor is also what guarantees that recursive functions terminate; how that is done is the
subject of [[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]].

== Iota reduction ==

A recursor applied to a constructor reduces to the corresponding minor premise, applied to
the constructor's arguments. This is
'''iota reduction''', and it is part of definitional equality. For <code>Nat</code> the two
rules are

:<math>\mathrm{Nat.rec}\;C\;z\;s\;\mathrm{zero} \equiv z \qquad \mathrm{Nat.rec}\;C\;z\;s\;(\mathrm{succ}\;n) \equiv s\;n\;(\mathrm{Nat.rec}\;C\;z\;s\;n)</math>

When a constructor has recursive arguments, the minor premise receives the recursor applied
to them, which is how recursion proceeds.<ref name="refman-ind" /><ref name="carneiro2019" />
Both rules hold by <code>rfl</code>, with the step function and the starting value left as
variables:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (z : Nat) (s : Nat → Nat → Nat) :
Nat.rec (motive := fun _ => Nat) z s 0 = z := rfl

example (z : Nat) (s : Nat → Nat → Nat) (n : Nat) :
Nat.rec (motive := fun _ => Nat) z s (n + 1)
= s n (Nat.rec (motive := fun _ => Nat) z s n) := rfl
</pre>

The second example is stated with <code>n + 1</code>, which is definitionally equal to
<code>Nat.succ n</code>. Iota
reduction is the computational content of an inductive type. Without it the recursor would
be an axiom stating that induction holds; with it, <code>double 3</code> is
<code>6</code> by calculation, and a proof by <code>rfl</code> is a computation the Lean kernel
carries out. See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

== Strict positivity ==

Not every list of constructors is acceptable. Every occurrence of the type being defined in
the type of a constructor argument must be '''strictly positive''': it may not appear to the
left of an arrow, however deeply nested, and it may appear as an argument only of the type
constructor of another inductive type.<ref name="refman-ind" /> The following definition
breaks the rule, because <code>Liar</code> appears as the domain of a function argument:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Liar where
| mk : (Liar → False) → Liar
</pre>

Lean 4.34.1 rejects it with

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
(kernel) arg #1 of 'Liar.mk' has a non positive occurrence of the datatypes being declared
</pre>

The message comes from Lean's kernel, not the elaborator: the check is part of the trusted
core.

The reason is that such a type would prove <code>False</code>. If <code>Liar</code> existed,
its constructor would give <code>mk : (Liar → False) → Liar</code>, and case analysis on its
one constructor would give a function <code>unmk : Liar → (Liar → False)</code> that returns
the function a value was built from. Those two functions are all that is needed:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example (L : Type) (mk : (L → False) → L) (unmk : L → L → False) : False :=
let notL : L → False := fun l => unmk l l
notL (mk notL)
</pre>

Lean accepts this. <code>notL</code> applies a value to itself, as in Russell's paradox, and
feeding it its own image under <code>mk</code> yields a proof of <code>False</code> with no
induction at all. Strict positivity excludes every definition of this shape. Its exclusion of
an occurrence nested under an arbitrary function, as in
<code>f (Fix f) → Fix f</code> for a parameter <code>f</code>, is needed because a suitable
<code>f</code> would rebuild the same circularity.<ref name="refman-ind" /> Dybjer's criteria
for well-formed inductive families are likewise stated for strictly positive
definitions.<ref name="dybjer1994" />

Other checks concern universes: the arguments of a constructor must live in universes no
larger than that of the type being defined, except that a type in <code>Prop</code> may take
arguments from any universe. A type in <code>Prop</code> also has a restricted recursor whose motive can only be
a proposition, unless it has at most one constructor whose arguments are all propositions,
parameters or indices; this is '''subsingleton elimination''', treated on
[[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].<ref name="refman-ind" />

== Indexed families ==

A type constructor may take two kinds of argument. '''Parameters''' are fixed across the whole
definition. '''Indices''' may differ from one constructor to another, so an indexed
definition defines a whole family of types at once, each member with its own
constructors.<ref name="refman-ind" /> Equality is the leading example:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#print Eq
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Eq.{u_1} : {α : Sort u_1} → α → α → Prop
number of parameters: 2
constructors:
Eq.refl : ∀ {α : Sort u_1} (a : α), a = a
</pre>

The type <code>α</code> and the left-hand side <code>a</code> are parameters; the right-hand
side is an index. There is one constructor, and it produces only <code>a = a</code>. The
family <code>a = b</code> is therefore inhabited exactly when <code>b</code> is
<code>a</code>, and its recursor, <code>Eq.rec</code>, is the principle of substituting equals
for equals; [[Lean theorem prover/Foundations/Propositional equality|Propositional equality]] follows it further.

A second example is a list whose length is part of its type:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Vect (α : Type u) : Nat → Type u where
| nil : Vect α 0
| cons : α → Vect α n → Vect α (n + 1)

def Vect.head : Vect α (n + 1) → α
| cons a _ => a

#eval (Vect.cons 1 (Vect.cons 2 Vect.nil)).head
#check Vect.rec
</pre>

The evaluation prints <code>1</code>. <code>Vect.head</code> needs no case for
<code>nil</code>: an argument of type <code>Vect α (n + 1)</code> cannot be <code>nil</code>,
whose index is 0, and the pattern-match compiler uses the index to see this. The recursor's
motive now takes the index as well as the value,

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Vect.rec.{u_1, u} {α : Type u} {motive : (a : Nat) → Vect α a → Sort u_1} (nil : motive 0 Vect.nil)
(cons : {n : Nat} → (a : α) → (a_1 : Vect α n) → motive n a_1 → motive (n + 1) (Vect.cons a a_1)) {a✝ : Nat}
(t : Vect α a✝) : motive a✝ t
</pre>

and each minor premise fixes the index that its constructor produces. Indexed definitions of
this kind are Dybjer's '''inductive families'''.<ref name="dybjer1994" />

== Mutual and nested types ==

Several types may be defined together in a <code>mutual</code> block, each constructor
referring to any of them; the predicates "even" and "odd" on the natural numbers are a
standard case. The recursor of a mutual group takes one motive per type and one minor
premise per constructor of every type in the group.<ref name="refman-ind" />

A '''nested''' type is one in which the type being defined occurs as an argument of another
inductive type, as in a tree whose node holds a list of subtrees:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Tree (α : Type) where
| node : α → List (Tree α) → Tree α

#check @Tree.rec
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
@Tree.rec : {α : Type} →
{motive_1 : Tree α → Sort u_1} →
{motive_2 : List (Tree α) → Sort u_1} →
((a : α) → (a_1 : List (Tree α)) → motive_2 a_1 → motive_1 (Tree.node a a_1)) →
motive_2 [] →
((head : Tree α) → (tail : List (Tree α)) → motive_1 head → motive_2 tail → motive_2 (head :: tail)) →
(t : Tree α) → motive_1 t
</pre>

The recursor has a second motive, for lists of trees, with minor premises for the empty list
and for a list cell. It has the shape of the recursor of a mutual pair of types, trees and
lists of trees, because that is how Lean's kernel justifies a nested type: it translates the
nested definition into a mutual one and accepts the original only if the translation
succeeds.<ref name="refman-ind" /> Direct support for nested types is one of the extensions of
the Lean 4 kernel over its predecessor, and Carneiro identifies it, with eta for structures,
as one of the two extensions that change the theory rather than abbreviate it.<ref name="lean4lean" />

== Where the scheme comes from ==

In the pure Calculus of Constructions, data and predicates could be represented by
higher-order quantification, an encoding that was inefficient as a program and weak as a
logic; the calculus was therefore extended with a primitive notion of inductive
definition.<ref name="pm1993">Christine Paulin-Mohring, "Inductive definitions in the
system Coq: rules and properties", in ''Typed Lambda Calculi and Applications'' (TLCA 1993),
Lecture Notes in Computer Science, Springer, 1993, pp. 328–345.
https://doi.org/10.1007/BFb0037116</ref> The result, the Calculus of Inductive
Constructions, is the theory Lean was based on when the project began in 2013.<ref name="lean4">Leonardo de
Moura and Sebastian Ullrich, "The Lean 4 Theorem Prover and Programming Language (System
Description)", in ''Automated Deduction – CADE 28'', Lecture Notes in Computer Science,
Springer, 2021, pp. 625–635. https://doi.org/10.1007/978-3-030-79876-5_37</ref> Lean's
presentation differs visibly from Coq's here: Coq's core uses primitive
<code>fix</code> and <code>match</code>, with a check that each recursive call is made on a
component produced by a <code>match</code>, while Lean's core has only recursors, and
definitions written with recursion and matching are compiled into them before the Lean kernel
sees them.<ref name="carneiro2019" /> The history is told on
[[Lean theorem prover/History/The Calculus of Constructions|The Calculus of Constructions]].

== Next ==

[[Lean theorem prover/Foundations/Structural and well-founded recursion|Structural and well-founded recursion]] shows how ordinary recursive definitions
are turned into recursor applications, and what happens when they cannot be.

== References ==

<references />

Lean theorem prover/Foundations/Universes and Prop

2026-10-15T19:34:49Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Universes and Prop}}
{{Plebeian|Lean theorem prover/Explainers/Why there is no type of all types}}
{{Lean theorem prover map}}

In Lean every type is itself a term, so every type has a type. The types of types are called
'''universes''' or '''sorts'''. They form a hierarchy: <code>Sort 0</code>,
<code>Sort 1</code>, <code>Sort 2</code> and so on, each a member of the next, with no top.
The bottom level, <code>Sort 0</code>, is <code>Prop</code>, the universe of propositions,
and it obeys different rules from the levels above it. This page sets out the hierarchy, the
rule that assigns a universe to a function type, the operation <math>\mathrm{imax}</math> that
rule needs, universe polymorphism, and the paradox that makes a hierarchy necessary.

== Sorts and their names ==

Each universe has a '''level''', and <code>Sort u</code> is the universe at level
<code>u</code>. Two abbreviations name the cases that matter in practice:
<code>Prop</code> is <code>Sort 0</code>, and <code>Type u</code> is
<code>Sort (u + 1)</code>, with <code>Type</code> alone meaning <code>Type 0</code>, that is,
<code>Sort 1</code>.<ref name="refman-univ">''The Lean Language Reference'', for Lean
4.34.0, lean-lang.org, 2026, section 4.3, "Universes".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Universes/</ref>

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check Prop
#check Type
#check Type 3
#check Sort 0
example : Sort 0 = Prop := rfl
example : Sort 1 = Type := rfl
example : Sort (3 + 1) = Type 3 := rfl
</pre>

Lean prints <code>Prop : Type</code>, <code>Type : Type 1</code>,
<code>Type 3 : Type 4</code> and <code>Prop : Type</code>, and accepts the three equations
by <code>rfl</code>: the names are notation for the same terms. The typing rule behind the
first four lines is the sort rule of
[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]],

:<math>\frac{}{\Gamma \vdash \mathrm{Sort}\,u : \mathrm{Sort}\,(u+1)}</math>

and nothing else gives a universe a type. In particular no universe is a member of itself:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : Type := Type
</pre>

Lean 4.34.1 rejects it:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Type mismatch
Type
has type
Type 1
of sort `Type 2` but is expected to have type
Type
of sort `Type 1`
</pre>

Lean's universes are also '''not cumulative''': a type in <code>Type 0</code> is not
thereby in <code>Type 1</code>, and each type has exactly one universe.<ref name="refman-univ" />
A type is moved up explicitly, by wrapping it:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : Type 1 := Nat
</pre>

fails with <code>Type mismatch</code>, reporting that <code>Nat</code> has type
<code>Type</code> but is expected to have type <code>Type 1</code>. The standard wrapper is
<code>ULift</code>, a structure with one field, <code>down</code>, whose universe parameter
says how far to lift:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check (ULift.{1} Nat)
example : Type 1 := ULift.{1} Nat
</pre>

Lean prints <code>ULift Nat : Type 1</code> and accepts the example. Coq, by contrast, has cumulative universes; Carneiro notes that
cumulativity breaks the unique-typing theorem his analysis of Lean relies on.<ref name="carneiro2019">Mario
Carneiro, ''The Type Theory of Lean'', MSc thesis, Carnegie Mellon University, 2019.
https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>

== The universe of a function type ==

A dependent function type <code>(x : A) → B</code> is a type, so it lives in some universe.
The formation rule decides which:

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \qquad \Gamma, x : A \vdash B : \mathrm{Sort}\,v}{\Gamma \vdash (x : A) \to B : \mathrm{Sort}\,(\mathrm{imax}\,u\,v)}</math>

where

:<math>\mathrm{imax}\,u\,v = \begin{cases} 0 & \text{if } v = 0 \\ \max(u, v) & \text{otherwise.} \end{cases}</math>

There are two cases.<ref name="refman-univ" /><ref name="carneiro2019" />

* '''The codomain is data''' (<math>v \geq 1</math>). The function type lives in the larger of the two universes. A type in <code>Type u</code> may only quantify over types in universes no larger than its own; this is '''predicativity'''.
* '''The codomain is a proposition''' (<math>v = 0</math>). The function type is a proposition, whatever the domain. A proposition may quantify over all propositions, or over all types at any level, and still be a proposition; this is '''impredicativity'''.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check ∀ (p : Prop), p → p
#check (α : Type) → α → α
#check (α : Type 2) → Prop
#check (n : Nat) → n = n
</pre>

The output is

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
∀ (p : Prop), p → p : Prop
(α : Type) → α → α : Type 1
Type 2 → Prop : Type 3
∀ (n : Nat), n = n : Prop
</pre>

The first statement quantifies over every proposition, including itself, and is a
proposition. The second, the type of the polymorphic identity function on
<code>Type</code>, quantifies over <code>Type</code> and so lands one level up, in
<code>Type 1</code>. The third is a function type into <code>Prop</code>, not a function type
whose values are proofs, so it is data: its codomain <code>Prop</code> lives in
<code>Sort 1</code>, and the result is in <math>\mathrm{Sort}\,(\max(4, 1)) =</math>
<code>Type 3</code>.

== Why imax ==

The two cases could be stated as two rules. A single operation on levels is needed because of
universe polymorphism. A definition may be stated for an arbitrary level variable
<code>v</code>, and the rule must give the function type a universe without knowing whether
<code>v</code> will later be 0. With <math>\max</math> alone that is impossible. The obvious
candidate, <math>\max\,u\,v</math>, goes wrong when <code>v</code> is set to 0: a
proposition that quantifies over a type in <code>Sort u</code> would land in
<math>\mathrm{Sort}\,(\max(u, 0)) = \mathrm{Sort}\,u</math> instead of in
<code>Prop</code>, and <code>Prop</code> would not be impredicative. No other expression
built from <math>\max</math> and successor does better: one that mentions <code>u</code> is
never below <code>u</code>, so it is not 0 when <code>v</code> is 0 and <code>u</code> is
not, and one that does not mention <code>u</code> cannot equal <math>\max(u, v)</math>
for every <code>u</code>. <math>\mathrm{imax}</math> is the level expression that reduces
to the right case once <code>v</code> is known.<ref name="refman-univ" />

Level expressions are built from numerals, variables, successor, <math>\max</math> and
<math>\mathrm{imax}</math>, and two levels are equal when they denote the same number under
every assignment of numbers to their variables.<ref name="carneiro2019" /> Lean will not
treat <math>\mathrm{imax}\,u\,v</math> as <math>\max\,u\,v</math>, because the two differ
when <code>v</code> is 0:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
universe u v

def Fn (α : Sort u) (β : Sort v) : Sort (imax u v) := α → β

#check Fn.{1, 0}
#check Fn.{1, 1}
#check Fn.{0, 2}
</pre>

The three instances print as <code>Fn : Type → Prop → Prop</code>,
<code>Fn : Type → Type → Type</code> and <code>Fn : Prop → Type 1 → Type 1</code>: the
same definition gives a proposition-valued result in the first case and data in the other
two. Stating the result universe as <code>Sort (max u v)</code> instead is rejected:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
universe u v

def Fn2 (α : Sort u) (β : Sort v) : Sort (max u v) := α → β
</pre>

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Type mismatch
α → β
has type
Sort (imax u v)
of sort `Type (imax u v)` but is expected to have type
Sort (max u v)
of sort `Type (max u v)`
</pre>

== Universe polymorphism ==

A definition may take '''universe parameters''', written after its name as
<code>.{u, v}</code>. It is then a schema: each use instantiates the parameters with level
expressions, and instantiations at different levels need not be definitionally
equal.<ref name="refman-univ" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
set_option pp.universes true in
#check @id
#check @id.{0}
#check List.{0}
</pre>

Lean prints <code>@id.{u_1} : {α : Sort u_1} → α → α</code>, then
<code>@id : ∀ {α : Prop}, α → α</code> for the instance at level 0, where the identity
function on proofs is itself a proof of a proposition, and <code>List : Type → Type</code>.
This is what lets one identity function, one list type and one equality serve at every
level. Without it each would have to be defined once per universe.

== Prop ==

<code>Prop</code> is the universe of propositions. Besides impredicativity, it has
properties that the levels above it lack:<ref name="refman-props">''The Lean Language
Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.2, "Propositions".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Propositions/</ref>

* '''Definitional proof irrelevance''': any two proofs of the same proposition are definitionally equal.
* '''Run-time irrelevance''': proofs are erased from compiled code.
* '''Restricted elimination''': except for a class of propositions with at most one proof, a proof cannot be used to produce data, only other proofs.
* '''Extensionality''': logically equivalent propositions are equal, by the axiom <code>propext</code>.

An impredicative universe of propositions is a feature of the Calculus of Constructions of
Coquand and Huet, and the theory implemented by Lean's kernel is a version of that
calculus.<ref name="refman-elab">''The Lean Language Reference'', for Lean 4.34.0,
lean-lang.org, 2026, section 2.3, "The Kernel".
https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref><ref name="coc">Thierry Coquand and Gérard Huet, "The calculus of
constructions", ''Information and Computation'' 76(2–3), 1988, pp. 95–120.
https://doi.org/10.1016/0890-5401(88)90005-3</ref><ref name="abelcoquand">Andreas Abel and
Thierry Coquand, "Failure of Normalization in Impredicative Type Theory with Proof-Irrelevant
Propositional Equality", ''Logical Methods in Computer Science'' 16(2), 2020.
https://doi.org/10.23638/LMCS-16(2:14)2020</ref> Its strength is real: Carneiro observes that
impredicativity corresponds, in a set-theoretic model, to having full power sets.<ref name="carneiro2019" />
The restriction on elimination is how the rules ensure that no computation can tell which
proof of a proposition it has received, as proof irrelevance
requires;<ref name="refman-subsing">''The Lean Language Reference'', for Lean 4.34.0,
lean-lang.org, 2026, section 4.4.3.1.1.1, "Subsingleton Elimination".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Inductive-Types/</ref> it is
treated on [[Lean theorem prover/Foundations/Proof irrelevance and subsingleton elimination|Proof irrelevance and subsingleton elimination]].

== Why there is a hierarchy ==

The simplest design would be a single universe containing every type, itself included:
<code>Type : Type</code>. That design is inconsistent. In 1972 Girard derived a
contradiction in a type system called System U, by formalising a paradox in the style of
Burali-Forti's paradox of the largest ordinal. The same argument shows that the first version
of Martin-Löf's type theory, which had <code>Type : Type</code>, proves falsity; in type
theory the argument is known as '''Girard's paradox'''.<ref name="nlab">nLab, "Burali-Forti's paradox", section "In type theory: Girard's
paradox", revision of 24 November 2023. https://ncatlab.org/nlab/show/Girard%27s+paradox</ref><ref name="hurkens">Antonius
J. C. Hurkens, "A simplification of Girard's paradox", in ''Typed Lambda Calculi and
Applications'' (TLCA 1995), Lecture Notes in Computer Science 902, Springer, 1995,
pp. 266–278. https://doi.org/10.1007/BFb0014058</ref> The ''Homotopy Type Theory'' book makes
the same point for a universe that contains itself: every type, including the empty one,
becomes inhabited.<ref name="hott">The Univalent Foundations Program, ''Homotopy Type
Theory: Univalent Foundations of Mathematics'', Institute for Advanced Study, 2013,
section 1.3, "Universes and families". https://homotopytypetheory.org/book/</ref>

Hurkens's paper locates the problem precisely. Higher-order logic, in which propositions may
quantify over all propositions, is consistent. Adding a single rule, which lets a type be
formed by quantifying over the sort of all types, gives the system called
<math>\lambda U^-</math>, which Coquand had already shown inconsistent; Hurkens gives a short
term in it whose type is falsity.<ref name="hurkens" /> Impredicativity for propositions
alone is therefore consistent, and adding it for types as well is not. Lean's design
follows the line exactly: <code>Prop</code> is impredicative, and every universe above it is
predicative and contained in the next. The plain-language account is
[[Lean theorem prover/Explainers/Why there is no type of all types|Why there is no type of all types]].

How strong the resulting hierarchy is, measured against set theory, is the subject of
[[Lean theorem prover/Foundations/Consistency and the metatheory|Consistency and the metatheory]].

== Next ==

[[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]] shows how every type other than universes and function types is introduced, and
how the universe rules constrain it.

== References ==

<references />

Lean theorem prover/Foundations/Dependent function types

2026-10-15T19:34:47Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Dependent function types}}
{{Plebeian|Lean theorem prover/Explainers/Propositions as types|Lean theorem prover/Explainers/Types as specifications}}
{{Lean theorem prover map}}

A '''dependent function type''' is the type of functions whose result type may vary with the
argument. In Lean it is written <code>(x : A) → B</code>, where <code>B</code> may mention
<code>x</code>, and in the literature it is often written
<math>\Pi x : A.\, B</math>. It is the only kind of function type in Lean's core theory. The
ordinary arrow <code>A → B</code>, universal quantification <code>∀ x : A, P x</code> and
implication <code>P → Q</code> are all instances of it. This page gives its rules, shows how
the familiar forms arise as special cases, and explains the implicit and instance-implicit
arguments that the elaborator adds on top of the same type.

== What the type means ==

Given a type <code>A</code> and, for each <code>a : A</code>, a type <code>B a</code>, a
function <code>f : (x : A) → B x</code> is a function that sends each <code>a : A</code> to
an element <code>f a</code> of <code>B a</code>. The type of the result depends on the
argument.<ref name="tpil">Jeremy Avigad, Leonardo de Moura, Soonho Kong and Sebastian
Ullrich, ''Theorem Proving in Lean 4'', lean-lang.org (version for Lean 4.33.0), chapter 2,
"Dependent Type Theory".
https://lean-lang.org/theorem_proving_in_lean4/Dependent-Type-Theory/</ref> Read as sets,
such a function is an element of the product <math>\prod_{a \in A} B(a)</math>, which is why
these types are also called '''dependent products''' or <math>\Pi</math>-types.<ref name="refman-fn">''The
Lean Language Reference'', for Lean 4.34.0, lean-lang.org, 2026, section 4.1, "Functions".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/Functions/</ref>

A small example: <code>Fin k</code> is the type of natural numbers less than
<code>k</code>, so a function that returns the number 0 as an element of
<code>Fin (n + 1)</code> has a different result type for every <code>n</code>.

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def zeroFin : (n : Nat) → Fin (n + 1) := fun n => ⟨0, Nat.succ_pos n⟩

#check zeroFin 4
#check zeroFin 0
</pre>

Lean 4.34.1 prints <code>zeroFin 4 : Fin (4 + 1)</code> and
<code>zeroFin 0 : Fin (0 + 1)</code>: one function, two result types.

== The rules ==

The type has the usual four kinds of rule, in the notation of
[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]].
They are Carneiro's rules for Lean, with <math>\mathrm{Sort}\,u</math> for his
<math>\mathrm{U}_u</math>; as on that page, the introduction rule also requires the domain
to be a type.<ref name="carneiro2019">Mario Carneiro, ''The Type Theory of
Lean'', MSc thesis, Carnegie Mellon University, 2019.
https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>

'''Formation.''' A dependent function type exists when its domain is a type and its codomain
is a type in the context extended by the bound variable:

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \qquad \Gamma, x : A \vdash B : \mathrm{Sort}\,v}{\Gamma \vdash (x : A) \to B : \mathrm{Sort}\,(\mathrm{imax}\,u\,v)}</math>

The universe of the result is <math>\mathrm{imax}\,u\,v</math>, which equals
<math>\max(u, v)</math> unless <math>v = 0</math>, in which case it is 0. That exception
makes a function type whose codomain is a proposition itself a proposition, whatever its
domain; why it is
needed is the subject of [[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]].

'''Introduction.''' A function is made by abstraction. If <math>A</math> is a type and
<math>e</math> has type <math>B</math> when <math>x : A</math> is assumed, then
<math>\lambda x : A.\, e</math> has the dependent function type:

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \qquad \Gamma, x : A \vdash e : B}{\Gamma \vdash \lambda x : A.\, e : (x : A) \to B}</math>

'''Elimination.''' A function is used by application, and the argument is substituted into
the result type:

:<math>\frac{\Gamma \vdash f : (x : A) \to B \qquad \Gamma \vdash a : A}{\Gamma \vdash f\,a : B[a/x]}</math>

The substitution <math>B[a/x]</math> is where dependency shows: in the example above,
<math>B</math> is <code>Fin (n + 1)</code> and applying to 4 gives
<code>Fin (4 + 1)</code>.

'''Computation and uniqueness.''' Applying an abstraction reduces by substitution, the
'''beta''' rule; and every function equals the abstraction of its own application, the
'''eta''' rule:

:<math>(\lambda x : A.\, e)\,a \equiv e[a/x] \qquad\qquad \lambda x : A.\, f\,x \equiv f</math>

Both are definitional equalities in Lean, so both can be proved by <code>rfl</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : (fun x : Nat => x + 1) 2 = 3 := rfl
example (f : Nat → Nat) : (fun x => f x) = f := rfl
</pre>

Definitional equality of functions goes no further than this. Two functions that agree on
every argument but are computed differently are not, in general, definitionally equal; that
they are equal is a theorem, <code>funext</code>, which Lean proves using quotient
types.<ref name="refman-fn" /> See [[Lean theorem prover/Foundations/Definitional equality|Definitional equality]] and [[Lean theorem prover/Foundations/Quotient types|Quotient types]].

In the core language every function takes exactly one argument. A function "of two
arguments" is a function that returns a function, and Lean's notation for several arguments
is an abbreviation for this nesting.<ref name="refman-fn" />

== The arrow is the non-dependent case ==

When <code>B</code> does not mention <code>x</code>, the type <code>(x : A) → B</code> is
written <code>A → B</code>. Nothing else changes: the core language has only one function
type, and a non-dependent function type is a dependent one whose bound variable is
unused.<ref name="refman-fn" /> Lean confirms that the two spellings denote the same type:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : ((x : Nat) → Bool) = (Nat → Bool) := rfl
</pre>

The same construction gives the logical connectives. When <code>B</code> is a proposition,
<code>(x : A) → B</code> is the proposition "for every <code>x : A</code>, <code>B</code>",
and Lean prints it with <code>∀</code>. When moreover <code>A</code> is a proposition and
<code>B</code> does not mention <code>x</code>, it is the implication <code>A → B</code>. A
proof of a universal statement is a function from instances to proofs, and using the
statement is applying the function:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem add_zero' : ∀ n : Nat, n + 0 = n := fun n => Nat.add_zero n

#check add_zero' 5
#check fun (p q : Prop) (hp : p) (_ : q) => hp
</pre>

The output is <code>add_zero' 5 : 5 + 0 = 5</code> and
<code>fun p q hp x => hp : ∀ (p q : Prop), p → q → p</code>. The second term is a proof of
the propositional tautology <math>p \to (q \to p)</math>, and its type is printed with
<code>∀</code> for the dependent binders and <code>→</code> for the others. This
correspondence between propositions and types, proofs and terms, is described in plain
language in [[Lean theorem prover/Explainers/Propositions as types|Propositions as types]].

== Implicit and instance-implicit arguments ==

A binder in a function type carries a mark saying how the elaborator should supply the
argument at a call site:<ref name="refman-fntypes">''The Lean Language Reference'', for Lean
4.34.0, lean-lang.org, 2026, section 13.2, "Function Types".
https://lean-lang.org/doc/reference/4.34.0/Terms/Function-Types/</ref>

* <code>(x : A)</code>, '''explicit''': the caller writes the argument.
* <code>{x : A}</code>, '''implicit''': the elaborator inserts a placeholder and fills it by unification, from the other arguments and the expected type.
* <code>⦃x : A⦄</code>, '''strict implicit''': as implicit, but the placeholder is inserted only once a later explicit argument is given.
* <code>[C]</code> or <code>[inst : C]</code>, '''instance implicit''': the elaborator finds the argument by type class instance synthesis ([[Lean theorem prover/System/Type classes and instance resolution|Type classes and instance resolution]]).

The mark is stored in the term as a <code>BinderInfo</code> field of the binder. It is
information for the elaborator only. It does not affect type checking or definitional
equality in the core theory, and two function types that differ only in it are
definitionally equal.<ref name="refman-fn" />

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
open Lean Meta

def double {α : Type} [inst : Add α] (x : α) : α := x + x

#check @double
#eval double 21
#eval @double Nat instAddNat 21
example : ({α : Type} → α → α) = ((α : Type) → α → α) := rfl

#eval show MetaM Unit from do
let some c := (← getEnv).find? ``double | throwError "missing"
IO.println (repr c.type)
</pre>

<code>#check @double</code> prints <code>@double : {α : Type} → [inst : Add α] → α → α</code>;
the <code>@</code> asks for every argument to be shown and accepted explicitly. Both
evaluations print <code>42</code>: in the first the elaborator found <code>α := Nat</code> by
unification and the instance <code>instAddNat</code> by synthesis; in the second both were
written out. The <code>example</code> is accepted, so an implicit and an explicit binder give
definitionally equal types. The last command prints the stored type of
<code>double</code>:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Lean.Expr.forallE
`α
(Lean.Expr.sort (Lean.Level.succ (Lean.Level.zero)))
(Lean.Expr.forallE
`inst
(Lean.Expr.app (Lean.Expr.const `Add [Lean.Level.zero]) (Lean.Expr.bvar 0))
(Lean.Expr.forallE `x (Lean.Expr.bvar 1) (Lean.Expr.bvar 2) (Lean.BinderInfo.default))
(Lean.BinderInfo.instImplicit))
(Lean.BinderInfo.implicit)
</pre>

It is three nested <code>forallE</code> binders, as for any function of three arguments; the
only trace of the braces and brackets is the last field of each binder,
<code>implicit</code>, <code>instImplicit</code> and <code>default</code>. To the core theory,
<code>double</code> is a function of three explicit arguments, the first a type and the
second a structure of operations on it.

Implicit arguments are a convenience, and they can fail. When nothing determines an implicit
argument, the elaborator reports it rather than guessing:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
def nothing := List.nil
</pre>

Lean 4.34.1 reports <code>don't know how to synthesize implicit argument `α`</code>, showing
the partial term <code>@List.nil ?m.3</code>, in which <code>?m.3</code> is the unfilled
placeholder: no element type for the empty list was given or can be inferred.

== Polymorphism ==

Because a domain may itself be a universe, the same type expresses polymorphism. The
identity function is a single term of type <code>{α : Sort u} → α → α</code>:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check @id
</pre>

Lean prints <code>@id : {α : Sort u_1} → α → α</code>. Its first argument is a type, and the type of its
second argument depends on the first. There is no separate mechanism for generic functions:
a generic function is a dependent function whose first argument is a type. Quantifying over
types this way raises the question of what universe the function type itself lives in, which
is answered by the <math>\mathrm{imax}</math> in the formation rule and taken up on the next
page.

== Next ==

[[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]] explains the
universe levels in the formation rule, the impredicativity of <code>Prop</code>, and why
there is no type of all types.

== References ==

<references />

Lean theorem prover/Foundations/Terms, types and judgments

2026-10-15T19:34:46Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Terms, types and judgments}}
{{Plebeian|Lean theorem prover/Explainers/Checking instead of convincing|Lean theorem prover/Explainers/Propositions as types}}
{{Lean theorem prover map}}

Lean's logic is a dependent type theory. Everything in it, a number, a function, a type, a
proposition, a proof, is a '''term''', and the theory consists of rules that say which terms
have which types. This page sets out the basic statement the rules are about, the typing
judgment; the contexts it is made in; the small term language that Lean's kernel actually
receives; the way that language writes bound variables; and the difference between checking
a type and inferring one. The later Foundations pages add one feature at a time to what is
set out here.

== The typing judgment ==

The basic statement of the theory is the '''typing judgment'''

:<math>\Gamma \vdash e : A</math>

read "in the context <math>\Gamma</math>, the term <math>e</math> has type <math>A</math>".
A '''context''' is a list of variables with their types,
<math>x_1 : A_1, \ldots, x_n : A_n</math>, in which each type may mention the variables
before it. A term is '''well-typed''' when some judgment of this form can be derived for it,
and only well-typed terms have a meaning.<ref name="refman-ts">''The Lean Language
Reference'', for Lean 4.34.0, lean-lang.org, 2026, chapter 4, "The Type System".
https://lean-lang.org/doc/reference/4.34.0/The-Type-System/</ref>

A judgment is not a proposition inside the theory. It is a statement about the theory, made
by its rules. A '''derivation''' is a finite tree of rule applications whose root is the
judgment in question. Lean does not store derivations. Its terms carry enough information,
binder types included, for a derivation to be reconstructed from the term alone, so the term
itself is the evidence; this is what makes a proof term something an independent program can
check.<ref name="refman-ts" />

Two further judgments travel with the first. <math>\Gamma \vdash e \equiv e'</math> says that
two terms are '''definitionally equal''': equal by computation, without proof. And
<math>\Gamma\ \mathrm{ok}</math> says that a context is well formed. A precise presentation
of all three for Lean, with every rule written out, is Carneiro's thesis ''The Type Theory of
Lean''.<ref name="carneiro2019">Mario Carneiro, ''The Type Theory of Lean'', MSc thesis,
Carnegie Mellon University, 2019. https://github.com/digama0/lean-type-theory/releases/tag/v1.0</ref>
The thesis describes Lean 3. The Lean 4 kernel extends that theory with natural-number
literals, nested inductive types, primitive projections and eta for structures. Carneiro
notes that two of these, nested inductive types and eta for structures, change the theory
enough that the 2019 soundness proof does not apply to Lean 4 directly.<ref name="lean4lean">Mario Carneiro, "Lean4Lean: Verifying a Typechecker for Lean,
in Lean", in ''31st International Conference on Types for Proofs and Programs (TYPES 2025)'',
LIPIcs vol. 384, pp. 2:1–2:23, 2026. https://doi.org/10.4230/LIPIcs.TYPES.2025.2 (read in
the version arXiv:2403.14064v2)</ref>

== Contexts ==

A context is built one variable at a time, and each new variable must be given a type:

:<math>\frac{}{\cdot\ \mathrm{ok}} \qquad \frac{\Gamma\ \mathrm{ok} \qquad \Gamma \vdash A : \mathrm{Sort}\,u}{\Gamma, x : A\ \mathrm{ok}}</math>

The empty context is well formed, and a well-formed context may be extended by <math>x : A</math> when
<math>A</math> is itself a well-typed term whose type is a universe,
<math>\mathrm{Sort}\,u</math>. Universes are the subject of
[[Lean theorem prover/Foundations/Universes and Prop|Universes and Prop]]; here it is enough
that "<math>A</math> has type <math>\mathrm{Sort}\,u</math> for some <math>u</math>" is what
"<math>A</math> is a type" means. A variable then has the type the context gives it:

:<math>\frac{(x : A) \in \Gamma}{\Gamma \vdash x : A}</math>

This is the form of the variable rule that Carneiro shows can take the place of a separate
weakening rule.<ref name="carneiro2019" />

== The core term language ==

Lean's surface syntax, with its notation, implicit arguments, pattern matching and tactics,
is not what the Lean kernel checks. The elaborator translates it into a much smaller language,
and that smaller language is the data type <code>Lean.Expr</code>. Lean can print its own
definition:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
import Lean
#print Lean.Expr
</pre>

Lean 4.34.1 prints twelve constructors:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
inductive Lean.Expr : Type
number of parameters: 0
constructors:
Lean.Expr.bvar : Nat → Lean.Expr
Lean.Expr.fvar : Lean.FVarId → Lean.Expr
Lean.Expr.mvar : Lean.MVarId → Lean.Expr
Lean.Expr.sort : Lean.Level → Lean.Expr
Lean.Expr.const : Lean.Name → List Lean.Level → Lean.Expr
Lean.Expr.app : Lean.Expr → Lean.Expr → Lean.Expr
Lean.Expr.lam : Lean.Name → Lean.Expr → Lean.Expr → Lean.BinderInfo → Lean.Expr
Lean.Expr.forallE : Lean.Name → Lean.Expr → Lean.Expr → Lean.BinderInfo → Lean.Expr
Lean.Expr.letE : Lean.Name → Lean.Expr → Lean.Expr → Lean.Expr → Bool → Lean.Expr
Lean.Expr.lit : Lean.Literal → Lean.Expr
Lean.Expr.mdata : Lean.MData → Lean.Expr → Lean.Expr
Lean.Expr.proj : Lean.Name → Nat → Lean.Expr → Lean.Expr
</pre>

Read as a grammar, they are:

* '''<code>bvar</code>''': a bound variable, written as a number (next section).
* '''<code>fvar</code>''': a free variable, named by a unique identifier. The Lean kernel creates these itself when it works under a binder; they do not occur in terms submitted to it.<ref name="lean4lean" />
* '''<code>mvar</code>''': a metavariable, a hole the elaborator has yet to fill. Terms sent to the Lean kernel contain none.<ref name="lean4lean" /> Metavariables belong to [[Lean theorem prover/System/Metavariables and unification|metavariables and unification]].
* '''<code>sort</code>''': a universe <math>\mathrm{Sort}\,u</math>, for a universe level <math>u</math>.
* '''<code>const</code>''': a constant, that is, a definition, theorem, axiom, inductive type, constructor or recursor in Lean's environment, its table of definitions and theorems, together with the universe levels at which it is used.
* '''<code>app</code>''': application of a function to one argument. A function of several arguments is applied one argument at a time.
* '''<code>lam</code>''': a function abstraction, <math>\lambda x : A.\, e</math>, with the binder's name, its type and its body.
* '''<code>forallE</code>''': a dependent function type, <math>(x : A) \to B</math>. Implication, universal quantification and ordinary function types are all this one constructor ([[Lean theorem prover/Foundations/Dependent function types|Dependent function types]]).
* '''<code>letE</code>''': a local definition, <math>\mathrm{let}\ x : A := v;\ e</math>.
* '''<code>lit</code>''': a natural-number literal or a string literal, stored directly rather than as a chain of constructors.
* '''<code>mdata</code>''': annotations for the elaborator and printer, which the Lean kernel ignores.
* '''<code>proj</code>''': the <math>i</math>-th field of a value of a structure type.

The names stored in <code>lam</code>, <code>forallE</code> and <code>letE</code>, and the
<code>BinderInfo</code> that marks an argument implicit or explicit, matter only to the
elaborator and the printer; they play no part in type checking.<ref name="lean4lean" />

== Bound variables and de Bruijn indices ==

The Lean kernel does not identify a bound variable by its name. It uses a '''de Bruijn index''':
the number of binders between the variable's occurrence and the binder that introduces
it, so that the nearest binder has index 0; de Bruijn's own numbering also counted the
introducing binder, and so started at 1.<ref name="debruijn1972">N. G. de Bruijn, "Lambda calculus notation with nameless
dummies, a tool for automatic formula manipulation, with application to the Church-Rosser
theorem", ''Indagationes Mathematicae (Proceedings)'' 75(5), 1972, pp. 381–392.
https://doi.org/10.1016/1385-7258(72)90034-0</ref> Lean can show the term it stores for a
small definition:

<pre class="lean lean-cont" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
open Lean Meta

def apply1 (x : Nat) (f : Nat → Nat) : Nat := f x

#eval show MetaM Unit from do
let some e := (← getEnv).find? ``apply1 |>.bind (·.value?) | throwError "no value"
IO.println (repr e)
</pre>

The output is

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Lean.Expr.lam
`x
(Lean.Expr.const `Nat [])
(Lean.Expr.lam
`f
(Lean.Expr.forallE
(Lean.Name.mkNum `a._@._internal._hyg 0)
(Lean.Expr.const `Nat [])
(Lean.Expr.const `Nat [])
(Lean.BinderInfo.default))
(Lean.Expr.app (Lean.Expr.bvar 0) (Lean.Expr.bvar 1))
(Lean.BinderInfo.default))
(Lean.BinderInfo.default)
</pre>

The body <code>f x</code> has become <code>app (bvar 0) (bvar 1)</code>: index 0 is the
nearest enclosing binder, <code>f</code>, and index 1 the next one out, <code>x</code>. The
names <code>x</code> and <code>f</code> survive only as labels on the binders. The type
<code>Nat → Nat</code> appears as a <code>forallE</code> whose bound variable has an internal
name and is never used: an ordinary function type is a dependent function type that does not
depend.

Indices make two terms that differ only in the names of bound variables the same data apart
from those labels, which comparison ignores, so renaming never has to be checked, and substitution cannot capture a variable by
accident. When the Lean kernel needs to work under a binder it replaces the bound variable by a
fresh free variable carrying the binder's type, does its work, and abstracts the free
variable back into an index afterwards. This mixture of indices for bound variables and
names for free ones is called the '''locally nameless''' representation.<ref name="lean4lean" /><ref name="bailey">Christopher
A. Bailey, with contributions from the Lean community, ''Type Checking in Lean 4'' (online
book), chapters "Type Inference" and "Declarations".
https://ammkrn.github.io/type_checking_in_lean4/</ref>

== The rules ==

With contexts and terms in place, the typing rules for the base language are short. Each is
written with its premises above the line and its conclusion below. They follow the variant
of Carneiro's presentation that has no weakening rule, with <math>\mathrm{Sort}\,u</math> for
his <math>\mathrm{U}_u</math>. In that variant the variable and universe rules apply in any
context, and the constant rule is written here in the same way; that the context is well
formed is checked separately, by the two rules above, and a typing judgment counts only when
its context is well formed.<ref name="carneiro2019" /> Without
weakening, a well-typed body no longer shows that the type of its binder is a type, so the
abstraction rule here also requires <math>A : \mathrm{Sort}\,u</math>, as Lean's kernel
does.<ref name="lean4lean" />

:<math>\frac{}{\Gamma \vdash \mathrm{Sort}\,u : \mathrm{Sort}\,(u+1)} \qquad \frac{c.\{\bar u\} : A \text{ is in Lean's environment}}{\Gamma \vdash c.\{\bar \ell\} : A[\bar\ell/\bar u]}</math>

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \qquad \Gamma, x : A \vdash B : \mathrm{Sort}\,v}{\Gamma \vdash (x : A) \to B : \mathrm{Sort}\,(\mathrm{imax}\,u\,v)}</math>

:<math>\frac{\Gamma \vdash A : \mathrm{Sort}\,u \qquad \Gamma, x : A \vdash e : B}{\Gamma \vdash \lambda x : A.\, e : (x : A) \to B} \qquad \frac{\Gamma \vdash f : (x : A) \to B \qquad \Gamma \vdash a : A}{\Gamma \vdash f\,a : B[a/x]}</math>

:<math>\frac{\Gamma \vdash v : A \qquad \Gamma \vdash e[v/x] : B}{\Gamma \vdash (\mathrm{let}\ x : A := v;\ e) : B} \qquad \frac{\Gamma \vdash e : A \qquad \Gamma \vdash A \equiv B}{\Gamma \vdash e : B}</math>

The first says each universe lives in the next. The second lets a constant be used at any
instance <math>\bar\ell</math> of its universe parameters <math>\bar u</math>. The next three
are the formation, introduction and elimination rules of the dependent function type, taken
up in [[Lean theorem prover/Foundations/Dependent function types|Dependent function types]].
The let rule types the body with the value substituted for the variable, so the body may
rely on what the variable stands for. The last, the '''conversion rule''', says that a term
of type <math>A</math> also has every type definitionally equal to <math>A</math>. Conversion
is where computation enters typing, and it is the subject of
[[Lean theorem prover/Foundations/Definitional equality|Definitional equality]].

Literals and projections add rules of the same kind: a natural-number literal has
type <code>Nat</code>, a string literal has type <code>String</code>, and a projection has
the type of the field it selects. Inductive types add their type formers, constructors and
recursors as constants, each with its own type
([[Lean theorem prover/Foundations/Inductive types and recursors|Inductive types and recursors]]).

== Checking against inference ==

There are two ways to use the rules. '''Type inference''' takes a context and a term and
computes a type for it. '''Type checking''' takes a context, a term and a proposed type, and
decides whether the term has that type.

Lean's kernel is built around inference. For an application <code>f a</code> it infers the
type of <code>f</code>, reduces that type until a function type <math>(x : A) \to B</math>
appears, infers the type of <code>a</code>, asks whether that type is definitionally equal to
<math>A</math>, and returns <math>B[a/x]</math>. Checking a definition or theorem with stated
type <math>T</math> and value <math>v</math> is done the same way: the Lean kernel infers the type
of <math>v</math> and asks whether it is definitionally equal to <math>T</math>. For a theorem
this comparison is the heart of proof checking: the inferred type is what the proof actually proves, and
the comparison confirms that it is what was claimed.<ref name="bailey" /> The Lean kernel's
inference function also has a mode that skips the checks and only computes a type, for terms
already known to be well typed.<ref name="lean4lean" />

The elaborator uses both directions. <code>#check</code> asks it to infer:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#check fun (n : Nat) => n + 1
#check (fun n => n + 1 : Int → Int)
#check let x := 2; x * x
#check (Prod.mk 1 true).2
</pre>

Lean prints <code>fun n => n + 1 : Nat → Nat</code>, then <code>fun n => n + 1 : Int → Int</code>,
then <code>let x := 2; x * x : Nat</code> (over two lines) and <code>(1, true).snd : Bool</code>.
The second term is the same text as the first, but the ascription <code>(… : Int → Int)</code>
gives the elaborator an '''expected type''' to check against, and it uses that type to decide
what <code>n</code> and <code>+</code> mean.<ref name="tpil">Jeremy Avigad, Leonardo de Moura,
Soonho Kong and Sebastian Ullrich, ''Theorem Proving in Lean 4'', lean-lang.org (version for
Lean 4.33.0), chapter 2, "Dependent Type Theory".
https://lean-lang.org/theorem_proving_in_lean4/Dependent-Type-Theory/</ref> When an expected
type and an inferred type disagree, elaboration fails:

<pre class="lean lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
example : Bool := (3 : Nat)
</pre>

Lean reports:

<pre class="lean-output" style="background: #ffffff; border: 1px dashed #a2a9b1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
Type mismatch
3
has type
Nat
but is expected to have type
Bool
</pre>

The message names both sides of the comparison: the type inferred for the term and the type
it was checked against.

== What the judgment leaves out ==

The core language has no implicit arguments, no type classes, no pattern matching, no
recursive definitions and no tactics. All of these are features of the elaborator, which
translates them into the terms above before the Lean kernel sees anything; a recursive function,
for instance, usually reaches the Lean kernel as an application of a recursor or of a well-founded
fixed-point combinator.<ref name="refman-elab">''The Lean Language Reference'', for Lean
4.34.0, lean-lang.org, 2026, sections 2.3, "The Kernel", and 2.4, "Elaboration Results".
https://lean-lang.org/doc/reference/4.34.0/Elaboration-and-Compilation/</ref> The division
of labour is described on [[Lean theorem prover/System/Elaboration|Elaboration]] and
[[Lean theorem prover/System/The Lean kernel|The Lean kernel]].

The rules also leave open how <math>\Gamma \vdash A \equiv B</math> is decided. In Lean's full
theory that relation is undecidable, so the Lean kernel decides a slightly smaller relation;
[[Lean theorem prover/Foundations/Definitional equality|Definitional equality]] gives the
details and the sources.<ref name="carneiro2019" />

== Next ==

[[Lean theorem prover/Foundations/Dependent function types|Dependent function types]] takes
the three function rules above and shows what they give: implication, universal
quantification and polymorphism, all as one construction.

== References ==

<references />

Lean theorem prover/Explainers/Lean and physics

2026-10-15T19:34:45Z

PMA Publisher: Published from the Principia Machina source

{{DISPLAYTITLE:Lean and physics}}
{{Lean theorem prover map}}

A proof checker can do one thing for physics: check that a conclusion follows from
stated assumptions. It cannot check that the assumptions describe the world. This page says what that
division means in practice, how real numbers, units and approximations enter a formal statement,
and what has been done in Lean on physics so far. It closes with this wiki's own physics.

== A derivation, as Lean sees it ==

A derivation in physics starts from laws and assumptions and arrives at a result. In Lean the
laws and assumptions become hypotheses, the result becomes the statement, and the derivation
becomes the proof. Here a body is assumed to move at a constant speed <code>v</code>, and the
theorem says how far it moves between two times:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
theorem displacement (x : Int → Int) (x₀ v : Int)
(law : ∀ t, x t = x₀ + v * t) (t₁ t₂ : Int) :
x t₂ - x t₁ = v * (t₂ - t₁) := by
rw [law t₂, law t₁]
grind
</pre>

Lean accepts it. What it has checked is a conditional: if the position <code>x</code> follows
the law named <code>law</code>, then the displacement is speed times elapsed time. It has not
checked that any body moves that way. Whether one does is a question for measurement, and no
proof can answer it. (The example uses whole numbers so that it runs in Lean without any library;
the same statement over the real numbers needs Mathlib.)

The project this wiki records puts the point in one line: Lean proves the model, not the world
(see [[Principia Machina/Lean transition|the move to Lean]]).

== What Lean can and cannot check ==

Lean can check that every step of a derivation is valid, that no case is skipped, and that the
assumptions used are exactly the ones stated. An assumption that a written derivation uses without
saying so becomes, in Lean, a hypothesis that must be written down, or else the proof fails.

Lean cannot check three things. It cannot check that the assumptions are true of nature; that is
what experiments are for. It cannot check that the symbols stand for the things they are meant to,
that <code>x</code> really is a position measured from a chosen point; that link between the
mathematics and the world is made by people. And it cannot check that the statement proved is the
one that was wanted (see [[Lean theorem prover/Explainers/Stating the right thing|stating the right thing]]).

== Real numbers ==

Physics is written over the real numbers, and core Lean has none (see
[[Lean theorem prover/Explainers/A library of mathematics|a library of mathematics]]). Mathlib
defines them as classes of Cauchy sequences of rational numbers, sequences whose terms get and
stay arbitrarily close to one another.<ref name="real">Mathlib, source file <code>Mathlib/Basic/Real/Basic.lean</code>, module documentation "Real numbers from Cauchy sequences". [https://github.com/leanprover-community/mathlib4/blob/master/Mathlib/Basic/Real/Basic.lean github.com/leanprover-community/mathlib4], consulted 14 October 2026.</ref>
These are the exact real numbers of mathematics, not the rounded numbers a computer calculates
with. A theorem about real numbers therefore says nothing by itself about the rounding errors of a
numerical simulation. Connecting the two takes a further statement, one that bounds the error.

== Units ==

On paper, units are checked by hand. In Lean they can be made part of the types, so that adding a
length to a time is refused before any proof begins. A small version:

<pre class="lean" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
structure Metres where
val : Int

structure Seconds where
val : Int

instance : Add Metres := ⟨fun a b => ⟨a.val + b.val⟩⟩

def d : Metres := ⟨3⟩
def t : Seconds := ⟨2⟩

#eval (d + d).val
</pre>

Lean prints <code>6</code>: two lengths add. A length and a time do not:

<pre class="lean lean-cont lean-fails" style="background: #f8f9fa; border: 1px solid #c8ccd1; padding: 0.6em; margin: 0.3em 0; font-size: 0.85em; line-height: 1.35; overflow-x: auto; white-space: pre;">
#eval (d + t).val
</pre>

Lean answers: failed to synthesize instance of type class, naming the missing addition of
<code>Metres</code> and <code>Seconds</code>. A fuller treatment exists. A 2025 preprint formalised
dimensional analysis in Lean: a dimension is a map from base dimensions to their exponents, dimensions
form a group under multiplication, physical quantities pair a value with a dimension, and the
framework covers SI units, fundamental constants and the Buckingham Pi theorem, with the
Lennard-Jones potential as a worked case.<ref name="dims">Maxwell P. Bobbin, Colin Jones, John Velkey and Tyler R. Josephson, "Formalizing dimensional analysis using the Lean theorem prover", arXiv:2509.13142, 16 September 2025. [https://arxiv.org/abs/2509.13142 arxiv.org/abs/2509.13142]</ref>

== Approximations ==

Physics leans on approximations: small angles, weak fields, slow speeds. The sign "≈" means
nothing to Lean. An approximation has to be stated as an exact claim, usually an inequality with an
explicit bound on the error, or a statement about a limit. Writing it out that way shows what the
approximation actually assumes: how small the angle must be, and how large the error can then get.
That can be harder than the derivation it serves, and it is part of what formal proof adds.

== Physics in Lean so far ==

In 2024 Joseph Tooby-Smith introduced '''HepLean''', a project to formalise high energy physics in
Lean 4, with first examples from flavour physics (CKM matrices), local anomaly cancellation and
Higgs physics. Its stated aims include making results easier to find, helping new results to be
found by artificial intelligence and automated methods, making the mathematical checking of papers easier, and new ways of
teaching.<ref name="heplean">Joseph Tooby-Smith, "HepLean: Digitalising high energy physics", ''Computer Physics Communications'' 308 (2025), article 109457. [https://doi.org/10.1016/j.cpc.2024.109457 doi:10.1016/j.cpc.2024.109457]; preprint arXiv:2405.08863.</ref>
HepLean was renamed PhysLean and later merged with Lean-QuantumInfo, a library for quantum
information, to form '''Physlib''', an open-source community project under the Apache 2.0 licence
that depends on Mathlib. Its core library holds reviewed formalisations; a separate area with
lighter review accepts larger and faster contributions, including some generated by AI.<ref name="physlib">''Physlib'' (README). [https://github.com/leanprover-community/physlib github.com/leanprover-community/physlib], consulted 14 October 2026; also [https://physlib.io physlib.io].</ref>

Formalisation has also found a mistake. In 2026 Tooby-Smith formalised a widely cited paper of 2006,
by Maniatis, von Manteuffel, Nachtmann and Nagel, on the stability of the two-Higgs-doublet
potential, and found an error in its arguments that invalidates its main theorem on stability. He
suggests that this may be the first non-trivial error in a physics paper found through
formalisation.<ref name="2hdm">Joseph Tooby-Smith, "Formalizing the stability of the two Higgs doublet model potential into Lean: identifying an error in the literature", arXiv:2603.08139, version 2, 20 April 2026. [https://arxiv.org/abs/2603.08139 arxiv.org/abs/2603.08139]</ref>
[[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]] describes this work further.

== This wiki's physics ==

The physics editions on this wiki, [[Hamilton's principle]], [[Noether's theorems]] and
[[On Physical Lines of Force]], are written in ordinary mathematics and prose, not in Lean.
The framework this wiki records is moving to Lean (see
[[Lean theorem prover/Applications/Principia Machina|Principia Machina]]). Its own account notes
that physics over the real numbers needs Mathlib, which it has not yet chosen to adopt
(see [[Principia Machina/Lean transition|the move to Lean]]).

== Next ==

[[Lean theorem prover/Foundations/Terms, types and judgments|Terms, types and judgments]]
begins the technical pages, on the type theory that Lean checks.
[[Lean theorem prover/Applications/Physics in Lean|Physics in Lean]] describes the formal physics
done in Lean so far.

== References ==

<references />