Lean
A guided introduction to Lean for theorem proving, formalization, and proof engineering.
80 notes
A guided introduction to Lean for theorem proving, formalization, and proof engineering.
This book is a working manual for the Lean proof assistant.
Rewriting failures in Lean usually come from a small set of recurring issues.
Rewriting is most effective when guided by a small set of consistent strategies.
Rewriting can target either the goal or the local context.
The `conv` tactic provides fine-grained control over rewriting.
Pattern matching performs case analysis by selecting a branch based on the shape of a value.
Reasoning often alternates between propositional equality `a = b` and boolean equality `a == b`.
In Lean, propositions live in `Prop`, a universe where proof irrelevance holds.
Equality between functions requires a different treatment than equality between values.
Structures package multiple fields into a single value.
Equalities are often too strict.
Rewriting systems can diverge if rules are poorly oriented or interact cyclically.
When types depend on values, rewriting affects both terms and their types.
Substitution is the direct elimination of equalities from the context.
Rewriting becomes more subtle when the target term appears inside a binder.
Complex equalities are rarely achieved in a single step.
Lemmas provide reusable equalities that drive most rewriting.
In most proofs, equalities come from the local context.
Case analysis splits a goal according to the structure of a value.
The behavior of `simp` depends entirely on the set of rewrite rules it uses.
The tactic `simp` performs normalization by repeated rewriting using a curated set of lemmas.
Rewriting is the primary way to apply propositional equalities in Lean.
Equality becomes useful when it propagates through larger expressions.
Propositional equality in Lean is generated from a small set of core operations.
Propositional equality is the explicit notion of equality in Lean.
Definitional equality is the built-in notion of equality used by the kernel of Lean.
This chapter isolates the operational core of reasoning in Type Theory as implemented by Lean: equality and its use as a transport mechanism.
Lean proofs fail in predictable ways.
Lean provides automation to reduce routine proof steps.
Rewriting with equality is one of the most frequent operations in Lean.
Backward reasoning starts from the goal and reduces it to simpler subgoals.
Forward reasoning starts from the assumptions in the local context and derives new facts until the goal becomes immediate.
An assumption is a local term that Lean may use to solve the current goal or produce another proof.
The local context is the list of variables, hypotheses, instances, and intermediate facts available at a point in a proof.
Names in Lean carry meaning.
A Lean proof should expose the shape of the argument.
Every logical connective in Lean has two sides.
Case analysis is the proof pattern for using data that has more than one possible constructor.
Proof by contradiction is a classical proof pattern.
Lean is constructive by default.
A universal statement asserts that a property holds for every element of a type.
An existential statement says that some object exists with a given property.
Equality supports two structural operations: reversing direction (symmetry) and chaining steps (transitivity).
Rewriting is the main way to use equality in Lean.
Equality expresses that two terms are identical.
`True` is the proposition that always has a proof.
`False` is the proposition with no constructors.
Negation represents "not".
Disjunction represents "or".
Conjunction represents "and".
Implication is the first logical connective to understand in Lean because it is also the ordinary function type.
Lean identifies propositions with types and proofs with terms.
This chapter introduces the proof layer of Lean.
A minimal working example is the smallest complete Lean fragment that demonstrates a definition, theorem, error, or technique.
Lean is normally developed inside an editor with live feedback.
Lean development is interactive.
Imports control what a Lean file can see.
Lean’s error messages report failed constraints during elaboration.
Lean development is driven by goals.
Lean proofs are terms.
Tactic mode is an interactive way to build proofs.
A structure is a type whose values are built from named fields.
Inductive types define data by listing its constructors.
Pattern matching defines functions by cases on the shape of their inputs.
Rewriting replaces one expression with another using an equality.
Type checking is the primary feedback mechanism in Lean.
Lean can execute many expressions during development.
Lean files serve two readers at once: the compiler and the human maintainer.
Lean notation is ordinary syntax attached to ordinary declarations.
Lean functions often contain arguments that the user does not write.
Functions are the main form of computation in Lean.
Lean is a dependently typed system.
Lean treats a theorem as a named proof.
A definition introduces a named term together with its type.
Lean code is built from expressions.
Lean organizes code as a hierarchy of modules.
Lean development is organized around projects.
Lean is distributed as a small toolchain rather than as a single editor plugin.
This chapter establishes the operational model of the Lean system.