`.\n\n ```lean\n example (g : Nat → Nat → Nat)\n (h₁ : ∀ x, x ≠ 0 → g x x = 1)\n (h₂ : x ≠ 0)\n : g x x + x = 1 + x := by\n conv =>\n lhs\n arg 1\n rw [h₁]\n . skip\n . apply h₂\n ```\n"
},
{
"path": "book/TPiL/DependentTypeTheory.lean",
"content": "import VersoManual\n\nimport TPiL.Examples\n\nopen TPiL\n\nopen Verso.Genre Manual\n\n#doc (Manual) \"Dependent Type Theory\" =>\n%%%\ntag := \"dependent-type-theory\"\nhtmlSplit := .never\n%%%\n\nDependent type theory is a powerful and expressive language, allowing\nyou to express complex mathematical assertions, write complex hardware\nand software specifications, and reason about both of these in a\nnatural and uniform way. Lean is based on a version of dependent type\ntheory known as the _Calculus of Constructions_, with a countable\nhierarchy of non-cumulative universes and inductive types. By the end\nof this chapter, you will understand much of what this means.\n\n# Simple Type Theory\n%%%\ntag := \"simple-type-theory\"\n%%%\n\n“Type theory” gets its name from the fact that every expression has an\nassociated _type_. For example, in a given context, {lit}`x + 0` may\ndenote a natural number and {lit}`f` may denote a function on the natural\nnumbers. For those who like precise definitions, a Lean natural number\nis an arbitrary-precision unsigned integer.\n\nHere are some examples of how you can declare objects in Lean and\ncheck their types.\n\n```lean\n/- Define some constants. -/\n\ndef m : Nat := 1 -- m is a natural number\ndef n : Nat := 0\ndef b1 : Bool := true -- b1 is a Boolean\ndef b2 : Bool := false\n\n/- Check their types. -/\n\n#check m -- m : Nat\n#check n\n#check n + 0 -- n + 0 : Nat\n#check m * (n + 0) -- m * (n + 0) : Nat\n#check b1 -- b1 : Bool\n-- \"&&\" is the Boolean and\n#check b1 && b2 -- b1 && b2 : Bool\n-- Boolean or\n#check b1 || b2 -- b1 || b2 : Bool\n-- Boolean \"true\"\n#check true -- Bool.true : Bool\n\n/- Evaluate -/\n\n#eval 5 * 4 -- 20\n#eval m + 2 -- 3\n#eval b1 && b2 -- false\n```\n\nAny text between {lit}`/-` and {lit}`-/` constitutes a comment block that is\nignored by Lean. Similarly, two dashes {lean}`--` indicate that the rest of\nthe line contains a comment that is also ignored. Comment blocks can\nbe nested, making it possible to “comment out” chunks of code, just as\nin many programming languages.\n\nThe {kw}`def` keyword declares new constant symbols into the\nworking environment. In the example above, {leanRef}`def m : Nat := 1`\ndefines a new constant {leanRef}`m` of type {lean}`Nat` whose value is {leanRef}`1`.\nThe {kw}`#check` command asks Lean to report their\ntypes; in Lean, auxiliary commands that query the system for\ninformation typically begin with the hash (#) symbol.\nThe {kw}`#eval` command asks Lean to evaluate the given expression.\nYou should try\ndeclaring some constants and type checking some expressions on your\nown. Declaring new objects in this manner is a good way to experiment\nwith the system.\n\n:::setup\n```\nvariable (a b : Type)\n```\nWhat makes simple type theory powerful is that you can build new types\nout of others. For example, if {lean}`a` and {lean}`b` are types, {lean}`a -> b`\ndenotes the type of functions from {lean}`a` to {lean}`b`, and {lean}`a × b`\ndenotes the type of pairs consisting of an element of {lean}`a` paired\nwith an element of {lean}`b`, also known as the _Cartesian product_. Note\nthat {lit}`×` is a Unicode symbol. The judicious use of Unicode improves\nlegibility, and all modern editors have great support for it. In the\nLean standard library, you often see Greek letters to denote types,\nand the Unicode symbol {lit}`→` as a more compact version of {lit}`->`.\n:::\n\n```lean (check := false)\n#check Nat → Nat -- type the arrow as “\\to” or \"\\r\"\n#check Nat -> Nat -- alternative ASCII notation\n\n#check Nat × Nat -- type the product as \"\\times\"\n#check Prod Nat Nat -- alternative notation\n\n#check Nat → Nat → Nat\n#check Nat → (Nat → Nat) -- same type as above\n\n#check Nat × Nat → Nat\n#check (Nat → Nat) → Nat -- a \"functional\"\n```\n```lean\n#check Nat.succ -- Nat.succ (n : Nat) : Nat\n#check (0, 1) -- (0, 1) : Nat × Nat\n#check Nat.add -- Nat.add : Nat → Nat → Nat\n\n#check Nat.succ 2 -- Nat.succ 2 : Nat\n#check Nat.add 3 -- Nat.add 3 : Nat → Nat\n#check Nat.add 5 2 -- Nat.add 5 2 : Nat\n#check (5, 9).1 -- (5, 9).fst : Nat\n#check (5, 9).2 -- (5, 9).snd : Nat\n\n#eval Nat.succ 2 -- 3\n#eval Nat.add 5 2 -- 7\n#eval (5, 9).1 -- 5\n#eval (5, 9).2 -- 9\n```\n\nOnce again, you should try some examples on your own.\n\nLet's take a look at some basic syntax. You can enter the Unicode\narrow {lit}`→` by typing {kbd}`\\to` or {kbd}`\\r` or {kbd}`\\->`. You can also use the\nASCII alternative {lit}`->`, so the expressions {lean}`Nat -> Nat` and {lean}`Nat → Nat`\nmean the same thing. Both expressions denote the type of\nfunctions that take a natural number as input and return a natural\nnumber as output. The Unicode symbol {lit}`×` for the Cartesian product\nis entered as {kbd}`\\times`. You will generally use lower-case Greek\nletters like {lit}`α`, {lit}`β`, and {lit}`γ` to range over types. You can\nenter these particular ones with {kbd}`\\a`, {kbd}`\\b`, and {kbd}`\\g`.\n\n::::setup\n```\nvariable (α β : Type) (f : α → β) (x : α) (m n : Nat) (p : Nat × Nat)\n```\nThere are a few more things to notice here. First, the application of\na function {lean}`f` to a value {lean}`x` is denoted {lean}`f x` (e.g., {lean}`Nat.succ 2`).\nSecond, when writing type expressions, arrows associate to the _right_; for\nexample, the type of {lean}`Nat.add` is {lean}`Nat → Nat → Nat` which is equivalent\nto {lean}`Nat → (Nat → Nat)`. Thus you can\nview {lean}`Nat.add` as a function that takes a natural number and returns\nanother function that takes a natural number and returns a natural\nnumber. In type theory, this is generally more convenient than\nwriting {lean}`Nat.add` as a function that takes a pair of natural numbers as\ninput and returns a natural number as output. For example, it allows\nyou to “partially apply” the function {lean}`Nat.add`. The example above shows\nthat {lean}`Nat.add 3` has type {lean}`Nat → Nat`, that is, {lean}`Nat.add 3` returns a\nfunction that “waits” for a second argument, {lean}`n`, which is then\nequivalent to writing {lean}`Nat.add 3 n`.\n:::comment\n```\n\n```\n:::\n\n\nYou have seen that if you have {lean}`m : Nat` and {lean}`n : Nat`, then\n{lean}`(m, n)` denotes the ordered pair of {lean}`m` and {lean}`n` which is of\ntype {lean}`Nat × Nat`. This gives you a way of creating pairs of natural\nnumbers. Conversely, if you have {lean}`p : Nat × Nat`, then you can write\n{lean}`p.1 : Nat` and {lean}`p.2 : Nat`. This gives you a way of extracting\nits two components.\n::::\n\n# Types as objects\n%%%\ntag := \"types-as-objects\"\n%%%\n\nOne way in which Lean's dependent type theory extends simple type\ntheory is that types themselves—entities like {lean}`Nat` and {lean}`Bool`—are first-class citizens, which is to say that they themselves are\nobjects. For that to be the case, each of them also has to have a\ntype.\n\n```lean\n#check Nat\n#check Bool\n#check Nat → Bool\n#check Nat × Bool\n#check Nat → Nat\n#check Nat × Nat → Nat\n#check Nat → Nat → Nat\n#check Nat → (Nat → Nat)\n#check Nat → Nat → Bool\n#check (Nat → Nat) → Nat\n```\n\nYou can see that each one of the expressions above is an object of\ntype {lean}`Type`. You can also declare new constants for types:\n\n```lean\ndef α : Type := Nat\ndef β : Type := Bool\ndef F : Type → Type := List\ndef G : Type → Type → Type := Prod\n\n#check α -- α : Type\n#check F α -- F α : Type\n#check F Nat -- F Nat : Type\n#check G α -- G α : Type → Type\n#check G α β -- G α β : Type\n#check G α Nat -- G α Nat : Type\n```\n\nAs the example above suggests, you have already seen an example of a function of type\n{lean}`Type → Type → Type`, namely, the Cartesian product {lean}`Prod`:\n\n```lean\ndef α : Type := Nat\ndef β : Type := Bool\n\n#check Prod α β -- α × β : Type\n#check α × β -- α × β : Type\n\n#check Prod Nat Nat -- Nat × Nat : Type\n#check Nat × Nat -- Nat × Nat : Type\n```\n\n:::leanFirst\nHere is another example: given any type {leanRef}`α`, the type {leanRef}`List α`\ndenotes the type of lists of elements of type {leanRef}`α`.\n\n```lean\ndef α : Type := Nat\n\n#check List α -- List α : Type\n#check List Nat -- List Nat : Type\n```\n:::\n\nGiven that every expression in Lean has a type, it is natural to ask:\nwhat type does {lean}`Type` itself have?\n\n```lean\n#check Type -- Type : Type 1\n```\n\nYou have actually come up against one of the most subtle aspects of\nLean's typing system. Lean's underlying foundation has an infinite\nhierarchy of types:\n\n```lean\n#check Type -- Type : Type 1\n#check Type 1 -- Type 1 : Type 2\n#check Type 2 -- Type 2 : Type 3\n#check Type 3 -- Type 3 : Type 4\n#check Type 4 -- Type 4 : Type 5\n```\n\n:::setup\n```\nuniverse n\nvariable (n : Nat)\n```\nThink of {lean}`Type 0` as a universe of “small” or “ordinary” types.\n{lean}`Type 1` is then a larger universe of types, which contains {lean}`Type 0`\nas an element, and {lean}`Type 2` is an even larger universe of types,\nwhich contains {lean}`Type 1` as an element. The list is infinite:\nthere is a {lean}`Type n` for every natural number {lean}`n`. {lean}`Type` is\nan abbreviation for {lean}`Type 0`:\n:::\n\n```lean\n#check Type\n#check Type 0\n```\n\n\nThe following table may help concretize the relationships being discussed.\nMovement along the x-axis represents a change in the universe, while movement\nalong the y-axis represents a change in what is sometimes referred to as\n“degree”.\n\n:::table\n\n*\n * sort\n * {lean}`Prop` ({lean}`Sort 0`)\n * {lean}`Type` ({lean}`Sort 1`)\n * {lean}`Type 1` ({lean}`Sort 2`)\n * {lean}`Type 2` ({lean}`Sort 3`)\n * ...\n\n*\n * type\n * {lean}`True`\n * {lean}`Bool`\n * {lean}`Nat -> Type`\n * {lean}`Type -> Type 1`\n * ...\n\n*\n * term\n * {lean}`True.intro`\n * {lean}`true`\n * {lean}`fun n => Fin n`\n * {lean}`fun (_ : Type) => Type`\n * ...\n\n:::\n\n:::setup\n\n```\nuniverse u\nvariable (α : Type u)\n```\n\nSome operations, however, need to be _polymorphic_ over type\nuniverses. For example, {lean}`List α` should make sense for any type\n{lean}`α`, no matter which type universe {lean}`α` lives in. This explains the\ntype signature of the function {lean}`List`:\n\n\n```lean\n#check List -- List.{u} (α : Type u) : Type u\n```\n\nHere {lit}`u` is a variable ranging over type levels. The output of the\n{kw}`#check` command means that whenever {lean}`α` has type {lean}`Type u`,\n{lean}`List α` also has type {lean}`Type u`. The function {lean}`Prod` is\nsimilarly polymorphic:\n:::\n\n```lean\n#check Prod -- Prod.{u, v} (α : Type u) (β : Type v) : Type (max u v)\n```\n\nTo define polymorphic constants, Lean allows you to\ndeclare universe variables explicitly using the {kw}`universe` command:\n\n```lean\nuniverse u\n\ndef F (α : Type u) : Type u := Prod α α\n\n#check F -- F.{u} (α : Type u) : Type u\n```\n\n:::leanFirst\nYou can avoid the {kw}`universe` command by providing the universe parameters when defining {leanRef}`F`:\n\n```lean\ndef F.{u} (α : Type u) : Type u := Prod α α\n\n#check F -- F.{u} (α : Type u) : Type u\n```\n:::\n\n# Function Abstraction and Evaluation\n%%%\ntag := \"function-abstraction-and-evaluation\"\n%%%\n\nLean provides a {kw}`fun` (or {kw}`λ`) keyword to create a function\nfrom an expression as follows:\n\n```lean\n#check fun (x : Nat) => x + 5 -- fun x => x + 5 : Nat → Nat\n-- λ and fun mean the same thing\n#check λ (x : Nat) => x + 5 -- fun x => x + 5 : Nat → Nat\n```\n\nThe type {lean}`Nat` can be inferred in this example:\n```lean\n#check fun x => x + 5 -- fun x => x + 5 : Nat → Nat\n#check λ x => x + 5 -- fun x => x + 5 : Nat → Nat\n```\n\nYou can evaluate a lambda function by passing the required parameters:\n\n```lean\n#eval (λ x : Nat => x + 5) 10 -- 15\n```\n\n:::setup\n```\nvariable {x : α} {t : β}\n```\n\nCreating a function from another expression is a process known as\n_lambda abstraction_. Suppose you have the variable {lean}`x : α` and you can\nconstruct an expression {lean}`t : β`, then the expression {lean}`fun (x : α) => t`,\nor, equivalently, {lean}`λ (x : α) => t`, is an object of type {lean}`α → β`. Think of\nthis as the function from {lean}`α` to {lean}`β` which maps\nany value {leanRef}`x` to the value {leanRef}`t`.\n:::\n\nHere are some more examples\n\n```lean\n#check fun x : Nat => fun y : Bool => if not y then x + 1 else x + 2\n#check fun (x : Nat) (y : Bool) => if not y then x + 1 else x + 2\n#check fun x y => if not y then x + 1 else x + 2 -- fun x y => if (!y) = true then x + 1 else x + 2 : Nat → Bool → Nat\n```\n\nLean interprets the final three examples as the same expression; in\nthe last expression, Lean infers the type of {leanRef}`x` and {leanRef}`y` from the\nexpression {leanRef}`if not y then x + 1 else x + 2`.\n\nSome mathematically common examples of operations of functions can be\ndescribed in terms of lambda abstraction:\n\n```lean\ndef f (n : Nat) : String := toString n\ndef g (s : String) : Bool := s.length > 0\n\n#check fun x : Nat => x -- fun x => x : Nat → Nat\n#check fun x : Nat => true -- fun x => true : Nat → Bool\n#check fun x : Nat => g (f x) -- fun x => g (f x) : Nat → Bool\n#check fun x => g (f x) -- fun x => g (f x) : Nat → Bool\n```\n\nThink about what these expressions mean. The expression\n{lean}`fun x : Nat => x` denotes the identity function on {lean}`Nat`, the\nexpression {lean}`fun x : Nat => true` denotes the constant function that\nalways returns {lean}`true`, and {leanRef}`fun x : Nat => g (f x)` denotes the\ncomposition of {leanRef}`f` and {leanRef}`g`. You can, in general, leave off the\ntype annotation and let Lean infer it for you. So, for example, you\ncan write {leanRef}`fun x => g (f x)` instead of {leanRef}`fun x : Nat => g (f x)`.\n\n:::leanFirst\nYou can pass functions as parameters and by giving them names {leanRef}`f`\nand {leanRef}`g` you can then use those functions in the implementation:\n\n```lean\n#check fun (g : String → Bool) (f : Nat → String) (x : Nat) => g (f x)\n```\n:::\n\nYou can also pass types as parameters:\n\n```lean\n#check fun (α β γ : Type) (g : β → γ) (f : α → β) (x : α) => g (f x)\n```\nThe last expression, for example, denotes the function that takes\nthree types, {leanRef}`α`, {leanRef}`β`, and {leanRef}`γ`, and two functions, {leanRef}`g : β → γ`\nand {leanRef}`f : α → β`, and returns the composition of {leanRef}`g` and {leanRef}`f`.\n(Making sense of the type of this function requires an understanding\nof _dependent products_, which will be explained below.)\n\n:::setup\n```\nvariable (α : Type) (t : β)\n-- Avoid warnings\naxiom whatever : α\ndef b : γ := whatever\n```\n\nThe general form of a lambda expression is {lean}`fun (x : α) => t`, where\nthe variable {leanRef}`x` is a “bound variable”: it is really a placeholder,\nwhose “scope” does not extend beyond the expression {leanRef}`t`. For\nexample, the variable {lit}`b` in the expression {lean}`fun (b : β) (x : α) => b`\nhas nothing to do with the constant {lean}`b` declared earlier. In fact,\nthe expression denotes the same function as {lean}`fun (u : β) (z : α) => u`.\n\n\nFormally, expressions that are the same up to a renaming of bound\nvariables are called _alpha equivalent_, and are considered “the\nsame.” Lean recognizes this equivalence.\n:::\n\n:::setup\n```\nvariable (t : α → β) (s : α)\n```\nNotice that applying a term {lean}`t : α → β` to a term {lean}`s : α` yields\nan expression {lean}`t s : β`. Returning to the previous example and\nrenaming bound variables for clarity, notice the types of the\nfollowing expressions:\n:::\n\n```lean\n#check (fun x : Nat => x) 1 -- (fun x => x) 1 : Nat\n#check (fun x : Nat => true) 1 -- (fun x => true) 1 : Bool\n\ndef f (n : Nat) : String := toString n\ndef g (s : String) : Bool := s.length > 0\n\n#check\n (fun (α β γ : Type) (u : β → γ) (v : α → β) (x : α) => u (v x)) Nat String Bool g f 0\n```\n\nAs expected, the expression {lean}`(fun x : Nat => x) 1` has type {lean}`Nat`.\nIn fact, more should be true: applying the expression {lean}`(fun x : Nat => x)` to\n{lean}`1` should “return” the value {lean}`1`. And, indeed, it does:\n\n```lean\n#eval (fun x : Nat => x) 1 -- 1\n#eval (fun x : Nat => true) 1 -- true\n```\n\nYou will see later how these terms are evaluated. For now, notice that\nthis is an important feature of dependent type theory: every term has\na computational behavior, and supports a notion of _normalization_. In\nprinciple, two terms that reduce to the same value are called\n_definitionally equal_. They are considered “the same” by Lean's type\nchecker, and Lean does its best to recognize and support these\nidentifications.\n\nLean is a complete programming language. It has a compiler that\ngenerates a binary executable and an interactive interpreter. You can\nuse the command {kw}`#eval` to execute expressions, and it is the\npreferred way of testing your functions.\n\n:::comment\n```\n\n```\n:::\n\n# Definitions\n%%%\ntag := \"definitions\"\n%%%\n\nRecall that the {kw}`def` keyword provides one important way of declaring new named\nobjects.\n\n```lean\ndef double (x : Nat) : Nat :=\n x + x\n```\n\nThis might look more familiar to you if you know how functions work in\nother programming languages. The name {leanRef}`double` is defined as a\nfunction that takes an input parameter {leanRef}`x` of type {lean}`Nat`, where the\nresult of the call is {leanRef}`x + x`, so it is returning type {lean}`Nat`. You\ncan then invoke this function using:\n\n```lean\ndef double (x : Nat) : Nat :=\n x + x\n-----\n#eval double 3 -- 6\n```\n\nIn this case you can think of {kw}`def` as a kind of named {kw}`fun`.\nThe following yields the same result:\n\n```lean\ndef double : Nat → Nat :=\n fun x => x + x\n\n#eval double 3 -- 6\n```\n\nYou can omit the type declarations when Lean has enough information to\ninfer it. Type inference is an important part of Lean:\n\n```lean\ndef double :=\n fun (x : Nat) => x + x\n```\n\nThe general form of a definition is {lit}`def foo : α := bar` where\n{lit}`α` is the type returned from the expression {lit}`bar`. Lean can\nusually infer the type {lit}`α`, but it is often a good idea to write it\nexplicitly. This clarifies your intention, and Lean will flag an\nerror if the right-hand side of the definition does not have a matching\ntype.\n\nThe right hand side {lit}`bar` can be any expression, not just a lambda.\nSo {kw}`def` can also be used to simply name a value like this:\n\n```lean\ndef pi := 3.141592654\n```\n\n{kw}`def` can take multiple input parameters. Let's create one\nthat adds two natural numbers:\n\n```lean\ndef add (x y : Nat) :=\n x + y\n\n#eval add 3 2 -- 5\n```\n\nThe parameter list can be separated like this:\n\n```lean\ndef double (x : Nat) : Nat :=\n x + x\n-----\ndef add (x : Nat) (y : Nat) :=\n x + y\n\n#eval add (double 3) (7 + 9) -- 22\n```\n\nNotice here we called the {leanRef}`double` function to create the first\nparameter to {leanRef}`add`.\n\nYou can use other more interesting expressions inside a {kw}`def`:\n\n```lean\ndef greater (x y : Nat) :=\n if x > y then x\n else y\n```\n\nYou can probably guess what this one will do.\n\nYou can also define a function that takes another function as input.\nThe following calls a given function twice passing the output of the\nfirst invocation to the second:\n\n```lean\ndef double (x : Nat) : Nat :=\n x + x\n-----\ndef doTwice (f : Nat → Nat) (x : Nat) : Nat :=\n f (f x)\n\n#eval doTwice double 2 -- 8\n```\n\nNow to get a bit more abstract, you can also specify arguments that\nare like type parameters:\n\n```lean\ndef compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n```\n\nThis means {leanRef}`compose` is a function that takes any two functions as input\narguments, so long as those functions each take only one input.\nThe type algebra {leanRef}`β → γ` and {leanRef}`α → β` means it is a requirement\nthat the type of the output of the second function must match the\ntype of the input to the first function—which makes sense, otherwise\nthe two functions would not be composable.\n\n{leanRef}`compose` also takes a 3rd argument of type {leanRef}`α` which\nit uses to invoke the second function (locally named {leanRef}`f`) and it\npasses the result of that function (which is type {leanRef}`β`) as input to the\nfirst function (locally named {leanRef}`g`). The first function returns a type\n{leanRef}`γ` so that is also the return type of the {leanRef}`compose` function.\n\n{leanRef}`compose` is also very general in that it works over any type\n{leanRef}`α β γ`. This means {leanRef}`compose` can compose just about any 2 functions\nso long as they each take one parameter, and so long as the type of\noutput of the second matches the input of the first. For example:\n\n```lean\ndef compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\ndef double (x : Nat) : Nat :=\n x + x\n-----\ndef square (x : Nat) : Nat :=\n x * x\n\n#eval compose Nat Nat Nat double square 3 -- 18\n```\n\n# Local Definitions\n%%%\ntag := \"local-definitions\"\n%%%\n\n:::setup\n```\nvariable (t1 : α) (t2 : β)\n```\n\nLean also allows you to introduce “local” definitions using the\n{kw}`let` keyword. The expression {lean}`let a := t1; t2` is\ndefinitionally equal to the result of replacing every occurrence of\n{leanRef}`a` in {leanRef}`t2` by {leanRef}`t1`.\n:::\n\n```lean\n#check let y := 2 + 2; y * y -- let y := 2 + 2; y * y : Nat\n#eval let y := 2 + 2; y * y -- 16\n\ndef twice_double (x : Nat) : Nat :=\n let y := x + x; y * y\n\n#eval twice_double 2 -- 16\n```\n\n:::setup\n```\ndef twice_double (x : Nat) : Nat :=\n let y := x + x; y * y\n\nvariable (x : Nat)\n```\n\nHere, {lean}`twice_double x` is definitionally equal to the term {lean}`(x + x) * (x + x)`.\n\n:::\n\nYou can combine multiple assignments by chaining {kw}`let` statements:\n\n```lean\n#check let y := 2 + 2; let z := y + y; z * z\n#eval let y := 2 + 2; let z := y + y; z * z -- 64\n```\n\nThe {lit}`;` can be omitted when a line break is used.\n```lean\ndef t (x : Nat) : Nat :=\n let y := x + x\n y * y\n```\n\n::::leanFirst\n:::setup\n```\nvariable (t1 : α) (t2 : β)\n```\n\nNotice that the meaning of the expression {lean}`let a := t1; t2` is very\nsimilar to the meaning of {lean}`(fun a => t2) t1`, but the two are not\nthe same. In the first expression, you should think of every instance\nof {leanRef (in:=\"let a := t1; t2\")}`a` in {leanRef (in:=\"let a := t1; t2\")}`t2` as a syntactic abbreviation for {leanRef (in:=\"let a := t1; t2\")}`t1`. In the\nsecond expression, {leanRef (in:=\"(fun a => t2) t1\")}`a` is a variable, and the expression\n{leanRef (in:=\"(fun a => t2) t1\")}`fun a => t2` has to make sense independently of the value of {leanRef (in:=\"(fun a => t2) t1\")}`a`.\nThe {kw}`let` construct is a stronger means of abbreviation, and there\nare expressions of the form {lean}`let a := t1; t2` that cannot be\nexpressed as {lean}`(fun a => t2) t1`. As an exercise, try to understand\nwhy the definition of {leanRef}`foo` below type checks, but the definition of\n{lit}`bar` does not.\n:::\n\n```lean\ndef foo := let a := Nat; fun x : a => x + 2\n/-\n def bar := (fun a => fun x : a => x + 2) Nat\n-/\n```\n::::\n\n# Variables and Sections\n%%%\ntag := \"variables-and-sections\"\n%%%\n\nConsider the following three function definitions:\n```lean\ndef compose (α β γ : Type) (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n\ndef doTwice (α : Type) (h : α → α) (x : α) : α :=\n h (h x)\n\ndef doThrice (α : Type) (h : α → α) (x : α) : α :=\n h (h (h x))\n```\n\nLean provides you with the {kw}`variable` command to make such\ndeclarations look more compact:\n\n```lean\nvariable (α β γ : Type)\n\ndef compose (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n\ndef doTwice (h : α → α) (x : α) : α :=\n h (h x)\n\ndef doThrice (h : α → α) (x : α) : α :=\n h (h (h x))\n```\nYou can declare variables of any type, not just {lean}`Type` itself:\n```lean\nvariable (α β γ : Type)\nvariable (g : β → γ) (f : α → β) (h : α → α)\nvariable (x : α)\n\ndef compose := g (f x)\ndef doTwice := h (h x)\ndef doThrice := h (h (h x))\n\n#print compose\n#print doTwice\n#print doThrice\n```\nPrinting them out shows that all three groups of definitions have\nexactly the same effect.\n\nThe {kw}`variable` command instructs Lean to insert the declared\nvariables as bound variables in definitions that refer to them by\nname. Lean is smart enough to figure out which variables are used\nexplicitly or implicitly in a definition. You can therefore proceed as\nthough {leanRef}`α`, {leanRef}`β`, {leanRef}`γ`, {leanRef}`g`, {leanRef}`f`, {leanRef}`h`, and {leanRef}`x` are fixed\nobjects when you write your definitions, and let Lean abstract the\ndefinitions for you automatically.\n\nWhen declared in this way, a variable stays in scope until the end of\nthe file you are working on. Sometimes, however, it is useful to limit\nthe scope of a variable. For that purpose, Lean provides the notion of\na {kw}`section`:\n\n```lean\nsection useful\n variable (α β γ : Type)\n variable (g : β → γ) (f : α → β) (h : α → α)\n variable (x : α)\n\n def compose := g (f x)\n def doTwice := h (h x)\n def doThrice := h (h (h x))\nend useful\n```\n\nWhen the section is closed, the variables go out of scope, and cannot\nbe referenced any more.\n\nYou do not have to indent the lines within a section. Nor do you have\nto name a section, which is to say, you can use an anonymous\n{kw}`section` / {kw}`end` pair. If you do name a section, however, you\nhave to close it using the same name. Sections can also be nested,\nwhich allows you to declare new variables incrementally.\n\n# Namespaces\n%%%\ntag := \"namespaces\"\n%%%\n\nLean provides you with the ability to group definitions into nested,\nhierarchical _namespaces_:\n\n```lean\nnamespace Foo\n def a : Nat := 5\n def f (x : Nat) : Nat := x + 7\n\n def fa : Nat := f a\n def ffa : Nat := f (f a)\n\n #check a\n #check f\n #check fa\n #check ffa\n #check Foo.fa\nend Foo\n\n-- #check a -- error\n-- #check f -- error\n#check Foo.a\n#check Foo.f\n#check Foo.fa\n#check Foo.ffa\n\nopen Foo\n\n#check a\n#check f\n#check fa\n#check Foo.fa\n```\n\nWhen you declare that you are working in the namespace {leanRef}`Foo`, every\nidentifier you declare has a full name with prefix “{lit}`Foo.`”. Within\nthe namespace, you can refer to identifiers by their shorter names,\nbut once you end the namespace, you have to use the longer names.\nUnlike {kw}`section`, namespaces require a name. There is only one\nanonymous namespace at the root level.\n\nThe {leanRef}`open` command brings the shorter names into the current\ncontext. Often, when you import a module, you will want to open one or\nmore of the namespaces it contains, to have access to the short\nidentifiers. But sometimes you will want to leave this information\nprotected by a fully qualified name, for example, when they conflict\nwith identifiers in another namespace you want to use. Thus namespaces\ngive you a way to manage names in your working environment.\n\nFor example, Lean groups definitions and theorems involving lists into\na namespace {lit}`List`.\n```lean\n#check List.nil\n#check List.cons\n#check List.map\n```\n:::leanFirst\nThe command {leanRef}`open List` allows you to use the shorter names:\n```lean\nopen List\n\n#check nil\n#check cons\n#check map\n```\n:::\nLike sections, namespaces can be nested:\n```lean\nnamespace Foo\n def a : Nat := 5\n def f (x : Nat) : Nat := x + 7\n\n def fa : Nat := f a\n\n namespace Bar\n def ffa : Nat := f (f a)\n\n #check fa\n #check ffa\n end Bar\n\n #check fa\n #check Bar.ffa\nend Foo\n\n#check Foo.fa\n#check Foo.Bar.ffa\n\nopen Foo\n\n#check fa\n#check Bar.ffa\n```\nNamespaces that have been closed can later be reopened, even in another file:\n\n```lean\nnamespace Foo\n def a : Nat := 5\n def f (x : Nat) : Nat := x + 7\n\n def fa : Nat := f a\nend Foo\n\n#check Foo.a\n#check Foo.f\n\nnamespace Foo\n def ffa : Nat := f (f a)\nend Foo\n```\n\nLike sections, nested namespaces have to be closed in the order they\nare opened. Namespaces and sections serve different purposes:\nnamespaces organize data and sections declare variables for insertion\nin definitions. Sections are also useful for delimiting the scope of\ncommands such as {kw}`set_option` and {kw}`open`.\n\nIn many respects, however, a {kw}`namespace`{lit}` ... `{kw}`end` block behaves the\nsame as a {kw}`section`{lit}` ... `{kw}`end` block. In particular, if you use the\n{kw}`variable` command within a namespace, its scope is limited to the\nnamespace. Similarly, if you use an {kw}`open` command within a\nnamespace, its effects disappear when the namespace is closed.\n\n# What makes dependent type theory dependent?\n%%%\ntag := \"what-makes-dependent-type-theory-dependent\"\n%%%\n\n:::setup\n```\nvariable (α : Type) (n : Nat)\n```\n\nThe short explanation is that types can depend on parameters. You\nhave already seen a nice example of this: the type {lean}`List α` depends\non the argument {lean}`α`, and this dependence is what distinguishes\n{lean}`List Nat` and {lean}`List Bool`. For another example, consider the\ntype {lean}`Vector α n`, the type of vectors of elements of {lean}`α` of\nlength {lean}`n`. This type depends on _two_ parameters: the type of the\nelements in the vector ({lean}`α : Type`) and the length of the vector\n{lean}`n : Nat`.\n:::\n\n::::setup\n```\ndef cons (α : Type) (a : α) (as : List α) : List α :=\n List.cons a as\nvariable (α : Type) (a : α) (as : List α)\n```\n:::leanFirst\n\nSuppose you wish to write a function {leanRef}`cons` which inserts a new\nelement at the head of a list. What type should {leanRef}`cons` have? Such a\nfunction is _polymorphic_: you expect the {leanRef}`cons` function for\n{lean}`Nat`, {lean}`Bool`, or an arbitrary type {leanRef}`α` to behave the same way.\nSo it makes sense to take the type to be the first argument to\n{leanRef}`cons`, so that for any type, {lean}`α`, {lean}`cons α` is the insertion\nfunction for lists of type {lean}`α`. In other words, for every {lean}`α`,\n{lean}`cons α` is the function that takes an element {lean}`a : α` and a list\n{lean}`as : List α`, and returns a new list, so you have {lean}`cons α a as : List α`.\n\nIt is clear that {lean}`cons α` should have type {lean}`α → List α → List α`.\nBut what type should {leanRef}`cons` have? A first guess might be\n{lean}`Type → α → List α → List α`, but, on reflection, this does not make\nsense: the {leanRef}`α` in this expression does not refer to anything,\nwhereas it should refer to the argument of type {lean}`Type`. In other\nwords, _assuming_ {lean}`α : Type` is the first argument to the function,\nthe type of the next two elements are {lean}`α` and {lean}`List α`. These\ntypes vary depending on the first argument, {leanRef}`α`.\n\n```lean\ndef cons (α : Type) (a : α) (as : List α) : List α :=\n List.cons a as\n\n#check cons Nat -- cons Nat : Nat → List Nat → List Nat\n#check cons Bool -- cons Bool : Bool → List Bool → List Bool\n#check cons -- cons (α : Type) (a : α) (as : List α) : List α\n```\n:::\n::::\n\n:::setup\n```\nvariable (α : Type) (β : α → Type) (a : α) (f : (a : α) → β a)\n```\n\nThis is an instance of a _dependent function type_, or *dependent\narrow type*. Given {lean}`α : Type` and {lean}`β : α → Type`, think of {lean}`β`\nas a family of types over {lean}`α`, that is, a type {lean}`β a` for each\n{lean}`a : α`. In that case, the type {lean}`(a : α) → β a` denotes the type\nof functions {lean}`f` with the property that, for each {lean}`a : α`, {lean}`f a`\nis an element of {lean}`β a`. In other words, the type of the value\nreturned by {lean}`f` depends on its input.\n:::\n\n:::setup\n```\nvariable (α : Type) (β : Type) (a : α) (f : (a : α) → β a)\n```\nNotice that {lean}`(a : α) → β` makes sense for any expression {lean}`β : Type`.\nWhen the value of {lean}`β` depends on {leanRef}`a` (as does, for\nexample, the expression {leanRef}`β a` in the previous paragraph),\n{leanRef}`(a : α) → β` denotes a dependent function type. When {lean}`β` doesn't\ndepend on {leanRef}`a`, {leanRef}`(a : α) → β` is no different from the type\n{lean}`α → β`. Indeed, in dependent type theory (and in Lean), {lean}`α → β`\nis just notation for {lean}`(a : α) → β` when {lean}`β` does not depend on {leanRef (in := \"a : α\")}`a`.\n:::\n\nReturning to the example of lists, you can use the command {kw}`#check` to\ninspect the type of the following {lean}`List` functions. The {lit}`@` symbol\nand the difference between the round and curly braces will be\nexplained momentarily.\n\n```lean\n#check @List.cons -- @List.cons : {α : Type u_1} → α → List α → List α\n#check @List.nil -- @List.nil : {α : Type u_1} → List α\n#check @List.length -- @List.length : {α : Type u_1} → List α → Nat\n#check @List.append -- @List.append : {α : Type u_1} → List α → List α → List α\n```\n\n:::setup\n```\nvariable (α : Type) (β : α → Type) (a : α) (b : β a)\n```\nJust as dependent function types {lean}`(a : α) → β a` generalize the\nnotion of a function type {leanRef}`α → β` by allowing {leanRef (in := \"α → β\")}`β` to depend on\n{lean}`a`, dependent Cartesian product types {lean}`(a : α) × β a` generalize\nthe Cartesian product {lit}`α × β` in the same way. Dependent products\nare also called _sigma_ types, and you can also write them as\n{lean}`Σ a : α, β a`. You can use {lean (type := \"(a : α) × β a\")}`⟨a, b⟩` or {lean}`Sigma.mk a b` to create a\ndependent pair. The {lit}`⟨` and {lit}`⟩` characters may be typed with\n{kbd}`\\langle` and {kbd}`\\rangle` or {kbd}`\\<` and {kbd}`\\>`, respectively.\n:::\n\n```lean\nuniverse u v\n\ndef f (α : Type u) (β : α → Type v) (a : α) (b : β a) : (a : α) × β a :=\n ⟨a, b⟩\n\ndef g (α : Type u) (β : α → Type v) (a : α) (b : β a) : Σ a : α, β a :=\n Sigma.mk a b\n\ndef h1 (x : Nat) : Nat :=\n (f Type (fun α => α) Nat x).2\n\n#eval h1 5 -- 5\n\ndef h2 (x : Nat) : Nat :=\n (g Type (fun α => α) Nat x).2\n\n#eval h2 5 -- 5\n```\nThe functions {leanRef}`f` and {leanRef}`g` above denote the same function.\n\n\n# Implicit Arguments\n%%%\ntag := \"implicit-arguments\"\n%%%\n\nSuppose we have an implementation of lists as:\n\n```lean\nuniverse u\ndef Lst (α : Type u) : Type u := List α\ndef Lst.cons (α : Type u) (a : α) (as : Lst α) : Lst α := List.cons a as\ndef Lst.nil (α : Type u) : Lst α := List.nil\ndef Lst.append (α : Type u) (as bs : Lst α) : Lst α := List.append as bs\n-----\n#check Lst -- Lst.{u} (α : Type u) : Type u\n#check Lst.cons -- Lst.cons.{u} (α : Type u) (a : α) (as : Lst α) : Lst α\n#check Lst.nil -- Lst.nil.{u} (α : Type u) : Lst α\n#check Lst.append -- Lst.append.{u} (α : Type u) (as bs : Lst α) : Lst α\n```\n\nThen, you can construct lists of {lean}`Nat` as follows:\n\n```lean\nuniverse u\ndef Lst (α : Type u) : Type u := List α\ndef Lst.cons (α : Type u) (a : α) (as : Lst α) : Lst α := List.cons a as\ndef Lst.nil (α : Type u) : Lst α := List.nil\ndef Lst.append (α : Type u) (as bs : Lst α) : Lst α := List.append as bs\n-----\n#check Lst.cons Nat 0 (Lst.nil Nat)\n\ndef as : Lst Nat := Lst.nil Nat\ndef bs : Lst Nat := Lst.cons Nat 5 (Lst.nil Nat)\n\n#check Lst.append Nat as bs\n```\n:::setup\n```\ndef Lst (α : Type u) : Type u := List α\nvariable (α : Type)\n```\nBecause the constructors are polymorphic over types, we have to insert\nthe type {lean}`Nat` as an argument repeatedly. But this information is\nredundant: one can infer the argument {leanRef}`α` in\n{leanRef}`Lst.cons Nat 5 (Lst.nil Nat)` from the fact that the second argument, {leanRef}`5`, has\ntype {lean}`Nat`. One can similarly infer the argument in {leanRef}`Lst.nil Nat`, not\nfrom anything else in that expression, but from the fact that it is\nsent as an argument to the function {leanRef}`Lst.cons`, which expects an element\nof type {lean}`Lst α` in that position.\n:::\n\nThis is a central feature of dependent type theory: terms carry a lot\nof information, and often some of that information can be inferred\nfrom the context. In Lean, one uses an underscore, {lit}`_`, to specify\nthat the system should fill in the information automatically. This is\nknown as an “implicit argument.”\n\n```lean\nuniverse u\ndef Lst (α : Type u) : Type u := List α\ndef Lst.cons (α : Type u) (a : α) (as : Lst α) : Lst α := List.cons a as\ndef Lst.nil (α : Type u) : Lst α := List.nil\ndef Lst.append (α : Type u) (as bs : Lst α) : Lst α := List.append as bs\n#check Lst\n#check Lst.cons\n#check Lst.nil\n#check Lst.append\n-----\n#check Lst.cons _ 0 (Lst.nil _)\n\ndef as : Lst Nat := Lst.nil _\ndef bs : Lst Nat := Lst.cons _ 5 (Lst.nil _)\n\n#check Lst.append _ as bs -- Lst.append Nat as bs : Lst Nat\n```\n\nIt is still tedious, however, to type all these underscores. When a\nfunction takes an argument that can generally be inferred from\ncontext, Lean allows you to specify that this argument should, by\ndefault, be left implicit. This is done by putting the arguments in\ncurly braces, as follows:\n\n```lean\nuniverse u\ndef Lst (α : Type u) : Type u := List α\n\ndef Lst.cons {α : Type u} (a : α) (as : Lst α) : Lst α := List.cons a as\ndef Lst.nil {α : Type u} : Lst α := List.nil\ndef Lst.append {α : Type u} (as bs : Lst α) : Lst α := List.append as bs\n\n#check Lst.cons 0 Lst.nil\n\ndef as : Lst Nat := Lst.nil\ndef bs : Lst Nat := Lst.cons 5 Lst.nil\n\n#check Lst.append as bs\n```\n\nAll that has changed are the braces around {leanRef}`α : Type u` in the\ndeclaration of the variables. We can also use this device in function\ndefinitions:\n\n```lean\nuniverse u\ndef ident {α : Type u} (x : α) := x\n```\n\nChecking the type of {leanRef}`ident` requires wrapping it in parentheses to avoid having its signature shown:\n```lean\nuniverse u\ndef ident {α : Type u} (x : α) := x\n---------\n#check (ident) -- ident : ?m.22 → ?m.22\n#check ident 1 -- ident 1 : Nat\n#check ident \"hello\" -- ident \"hello\" : String\n#check @ident -- @ident : {α : Type u_1} → α → α\n```\n\nThe makes the first argument to {leanRef}`ident` implicit. Notationally,\nthis hides the specification of the type, making it look as though\n{leanRef}`ident` simply takes an argument of any type. In fact, the function\n{lean}`id` is defined in the standard library in exactly this way. We have\nchosen a nontraditional name here only to avoid a clash of names.\n\nVariables can also be specified as implicit when they are declared with\nthe {kw}`variable` command:\n\n```lean\nuniverse u\n\nsection\n variable {α : Type u}\n variable (x : α)\n def ident := x\nend\n\n#check ident\n#check ident 4\n#check ident \"hello\"\n```\n\nThis definition of {leanRef}`ident` here has the same effect as the one\nabove.\n\nLean has very complex mechanisms for instantiating implicit arguments,\nand we will see that they can be used to infer function types,\npredicates, and even proofs. The process of instantiating these\n“holes,” or “placeholders,” in a term is often known as\n_elaboration_. The presence of implicit arguments means that at times\nthere may be insufficient information to fix the meaning of an\nexpression precisely. An expression like {lean}`id` or {lean}`List.nil` is\nsaid to be _polymorphic_, because it can take on different meanings in\ndifferent contexts.\n\n:::setup\n```\nvariable (T : Type) (e : T)\n```\n\nOne can always specify the type {lean}`T` of an expression {lean}`e` by\nwriting {lean}`(e : T)`. This instructs Lean's elaborator to use the value\n{lean}`T` as the type of {lean}`e` when trying to resolve implicit\narguments. In the second pair of examples below, this mechanism is\nused to specify the desired types of the expressions {lean}`id` and\n{lean}`List.nil`:\n:::\n\n```lean\n#check (List.nil) -- [] : List ?m.2\n#check (id) -- id : ?m.1 → ?m.1\n\n#check (List.nil : List Nat) -- [] : List Nat\n#check (id : Nat → Nat) -- id : Nat → Nat\n```\n\nNumerals are overloaded in Lean, but when the type of a numeral cannot\nbe inferred, Lean assumes, by default, that it is a natural number. So\nthe expressions in the first two {kw}`#check` commands below are\nelaborated in the same way, whereas the third {kw}`#check` command\ninterprets {lean (type := \"Int\")}`2` as an integer.\n\n```lean\n#check 2 -- 2 : Nat\n#check (2 : Nat) -- 2 : Nat\n#check (2 : Int) -- 2 : Int\n```\n\n:::setup\n```\nvariable (foo : {α : Type} → α → β)\n```\n\nSometimes, however, we may find ourselves in a situation where we have\ndeclared an argument to a function to be implicit, but now want to\nprovide the argument explicitly. If {lean}`foo` is such a function, the\nnotation {lean}`@foo` denotes the same function with all the arguments\nmade explicit.\n:::\n\n```lean\n#check @id -- @id : {α : Sort u_1} → α → α\n#check @id Nat -- id : Nat → Nat\n#check @id Bool -- id : Bool → Bool\n\n#check @id Nat 1 -- id 1 : Nat\n#check @id Bool true -- id true : Bool\n```\n\nNotice that now the first {kw}`#check` command gives the type of the\nidentifier, {leanRef}`id`, without inserting any placeholders. Moreover, the\noutput indicates that the first argument is implicit.\n"
},
{
"path": "book/TPiL/Examples.lean",
"content": "import SubVerso.Examples\nimport Lean.Data.NameMap\nimport Lean.DocString.Syntax\nimport VersoManual\nimport Verso.Code.HighlightedToTex\n\nopen Lean (NameMap MessageSeverity)\nopen Lean.Doc.Syntax\n\nnamespace TPiL\n\nopen Verso Doc Elab Genre.Manual ArgParse Code Highlighted WebAssets Output Html Log Code External\nopen SubVerso.Highlighting\nopen SubVerso.Examples.Messages\nopen Lean\nopen Std\n\nexport Verso.Code.External (lit)\n\nprivate def projectDir : System.FilePath := \"../examples/\"\n\ndef alphabet := \"abcdefghijklmnopqrstuvwxyz0123456789\"\n\ndef hashString (n : UInt64) : String := Id.run do\n let mut n : Nat := n.toNat\n let mut out : String := \"Example\" -- always start with a letter\n while n > 0 do\n out := out.push ({ byteIdx := n % 36 : String.Pos.Raw} |>.get! alphabet )\n n := n / 36\n return out\n\nsection\nopen System\nopen SubVerso.Module\n\nvariable [Monad m] [MonadError m] [MonadLiftT BaseIO m] [MonadLiftT IO m] [MonadFinally m]\nvariable [MonadTrace m] [AddMessageContext m] [MonadOptions m] [MonadAlwaysExcept ε m]\n\ndef extractFile (contents : String) (suppressNamespaces : Option String) : m (Array ModuleItem) := do\n let codeHash := hash contents\n let modBase := hashString codeHash\n let filename := modBase ++ \".lean\"\n let mod := \"Examples.\" ++ modBase\n let jsonFile := s!\"{modBase}.json\"\n\n let jsonPath := (projectDir / \"Examples\" / jsonFile)\n let jsonExists : Bool ←\n if (← jsonPath.pathExists) then (IO.FS.readFile jsonPath) <&> (!·.isEmpty)\n else pure false\n\n unless jsonExists do\n IO.FS.writeFile (projectDir / \"Examples\" / filename) contents\n\n -- Validate that the path is really a Lean project\n let lakefile := projectDir / \"lakefile.lean\"\n let lakefile' := projectDir / \"lakefile.toml\"\n if !(← lakefile.pathExists) && !(← lakefile'.pathExists) then\n throwError m!\"Neither {lakefile} nor {lakefile'} exist, couldn't load project\"\n let toolchainfile := projectDir / \"lean-toolchain\"\n let toolchain ← do\n if !(← toolchainfile.pathExists) then\n throwError m!\"File {toolchainfile} doesn't exist, couldn't load project\"\n pure (← IO.FS.readFile toolchainfile).trimAscii.copy\n\n -- Kludge: remove variables introduced by Lake. Clearing out DYLD_LIBRARY_PATH and\n -- LD_LIBRARY_PATH is useful so the version selected by Elan doesn't get the wrong shared\n -- libraries.\n let lakeVars :=\n #[\"LAKE\", \"LAKE_HOME\", \"LAKE_PKG_URL_MAP\",\n \"LEAN_SYSROOT\", \"LEAN_AR\", \"LEAN_PATH\", \"LEAN_SRC_PATH\",\n \"LEAN\", \"ELAN\", \"ELAN_HOME\", \"LEAN_GITHASH\",\n \"ELAN_TOOLCHAIN\", \"DYLD_LIBRARY_PATH\", \"LD_LIBRARY_PATH\"]\n\n\n let toolchainFile ← IO.FS.Handle.mk toolchainfile .read\n toolchainFile.lock (exclusive := true)\n try\n let cmd := \"elan\"\n\n let runCmd' (args : Array String) : m Unit := do\n let res ← IO.Process.output {\n cmd, args, cwd := projectDir\n -- Unset Lake's environment variables\n env := lakeVars.map (·, none)\n }\n if res.exitCode != 0 then reportFail projectDir cmd args res\n\n let runCmd (trace : MessageData) (args : Array String) : m Unit :=\n withTraceNode `Elab.Verso.Code.External.loadModule (fun _ => pure trace) (runCmd' args)\n\n runCmd m!\"loadModuleContent': building subverso\" #[\"run\", \"--install\", toolchain, \"lake\", \"build\", \"subverso-extract-mod\"]\n\n runCmd m!\"loadModuleContent': building example project's module\" #[\"run\", \"--install\", toolchain, \"lake\", \"build\", \"+\" ++ mod]\n\n let suppressArgs :=\n if let some nss := suppressNamespaces then\n nss |>.splitToList (· == ' ') |>.filter (!String.isEmpty ·) |>.map (#[\"--suppress-namespace\", ·]) |>.toArray |>.flatten\n else #[]\n\n withTraceNode `Elab.Verso.Code.External.loadModule (fun _ => pure m!\"loadModuleContent': extracting '{mod}'\") do\n let args :=\n #[\"run\", \"--install\", toolchain, \"lake\", \"exe\", \"subverso-extract-mod\"] ++\n suppressArgs ++\n #[mod, \"Examples/\" ++ jsonFile]\n runCmd' args\n finally\n toolchainFile.unlock\n\n let jsonString ← IO.FS.readFile (projectDir / \"Examples\" / jsonFile)\n\n let .ok json := Json.parse jsonString\n | if jsonString.isEmpty then\n throwError s!\"Expected JSON in {projectDir / \"Examples\" / jsonFile}, got empty output\"\n else\n throwError s!\"Expected JSON in {projectDir / \"Examples\" / jsonFile}, got {jsonString}\"\n match Module.fromJson? json with\n | .error err =>\n throwError s!\"Couldn't parse JSON from output file: {err}\\nIn:\\n{json}\"\n | .ok m => pure m.items\n\nwhere\n decorateOut (name : String) (out : String) : String :=\n if out.isEmpty then \"\" else s!\"\\n{name}:\\n{out}\\n\"\n reportFail {α} (projectDir : FilePath) (cmd : String) (args : Array String) (res : IO.Process.Output) : m α := do\n throwError (\"Build process failed.\" ++\n \"\\nCWD: \" ++ projectDir.toString ++\n \"\\nCommand: \" ++ cmd ++\n \"\\nArgs: \" ++ repr args ++\n \"\\nExit code: \" ++ toString res.exitCode ++\n \"\\nstdout: \" ++ res.stdout ++\n \"\\nstderr: \" ++ res.stderr)\n\nend\n\nopen Std.Iterators in\nprivate def hasAtLeastM [Monad m] [Iterator α m β] [Productive α m] (it : IterM (α := α) m β) : Nat → m Bool\n | 0 => pure true\n | n + 1 => do\n match (← it.step).inflate with\n | .done .. => pure false\n | .skip it' .. => hasAtLeastM it' (n + 1)\n | .yield it' .. => hasAtLeastM it' n\ntermination_by n => (n, it.finitelyManySkips)\n\nopen Std.Iterators in\nprivate def hasAtLeast [Iterator α Id β] [Productive α Id] (it : Iter (α := α) β) (n : Nat) : Bool :=\n hasAtLeastM it.toIterM n\n\ndef splitExample (code : Highlighted) : Option Highlighted × Highlighted := Id.run do\n let lines := code.lines\n let mut out := .empty\n for h : i in [0:lines.size] do\n let line := lines[i]\n if isSplit line then\n return (some out, lines.extract (i+1) lines.size |>.foldl (init := .empty) (· ++ ·))\n out := out ++ line\n return (none, out)\nwhere\n isSplit (line : Highlighted) : Bool :=\n let trimmed := line.toString.trimAscii\n hasAtLeast trimmed.positions 4 && trimmed.all (· == '-')\n\npartial def hlIsWs (hl : Highlighted) : Bool :=\n match hl with\n | .text s | .unparsed s => s.all Char.isWhitespace\n | .seq xs => xs.all hlIsWs\n | .span _ x | .tactics _ _ _ x => hlIsWs x\n | .point .. => true\n | .token .. => false\n\n\nsection\n\nopen SubVerso.Module\n\nprivate inductive LineType where\n | whitespace\n | split\n | other\n\nprivate def lineType (line : Highlighted) : LineType :=\n let trimmed := line.toString.trimAscii\n if trimmed.isEmpty then .whitespace\n else if hasAtLeast trimmed.positions 4 && trimmed.all (· == '-') then .split\n else .other\n\n\ndef detachPrefix (code : Array ModuleItem) : Option (Array ModuleItem) × Array ModuleItem := Id.run do\n let mut out : Array ModuleItem := #[]\n for h : i in [0:code.size] do\n let lines := code[i].code.lines\n -- Check for pre-split\n for h : j in [0:lines.size] do\n match lineType lines[j] with\n | .whitespace => continue\n | .other => break -- not a pre-split\n | .split =>\n let leadingWs := lines.extract 0 j\n let pre := out.modify (out.size - 1) (fun c => {c with code := c.code ++ .seq leadingWs})\n return (pre, #[{code[i] with code := .seq <| lines.extract (j+1)}] ++ code.extract (i + 1) code.size)\n -- Check for post-split\n for h : j in [0:lines.size] do\n let j' := lines.size - (j + 1)\n have : j' < lines.size := by\n have : j < lines.size := by get_elem_tactic\n omega\n match lineType lines[j'] with\n | .whitespace => continue\n | .other => break -- not a post-split\n | .split =>\n let trailingWs := lines.extract (j' + 1) lines.size\n let thisItem := { code[i] with code := lines.extract 0 j' |>.foldl (init := .empty) (· ++ ·) }\n let nextItem? := code[i + 1]? |>.map (fun c => {c with code := Highlighted.seq trailingWs ++ c.code})\n return (out.push thisItem, nextItem?.toArray ++ code.extract (i + 2) code.size)\n -- No split here\n out := out.push code[i]\n -- No split anywhere\n return (none, out)\n\ndef detachSuffix (code : Array ModuleItem) : Array ModuleItem × Option (Array ModuleItem) := Id.run do\n let mut out : Array ModuleItem := #[]\n for h : i in [0:code.size] do\n let i := code.size - (i + 1)\n have : i < code.size := by\n rename_i i' _ _\n have : i' < code.size := by get_elem_tactic\n omega\n let lines := code[i].code.lines\n -- Check for post-split\n for h : j in [0:lines.size] do\n let j' := lines.size - (j + 1)\n have : j' < lines.size := by\n have : j < lines.size := by get_elem_tactic\n omega\n match lineType lines[j'] with\n | .whitespace => continue\n | .other => break -- not a post-split\n | .split =>\n let trailingWs := lines.extract (j' + 1) lines.size\n let thisItem := { code[i] with code := lines.extract 0 j' |>.foldl (init := .empty) (· ++ ·) }\n let nextItem? := if i > 0 then some {code[i - 1] with code := Highlighted.seq trailingWs ++ code[i-1].code} else none\n return (nextItem?.toArray ++ code.extract (i + 2) code.size, out.push thisItem |>.reverse)\n -- Check for pre-split\n for h : j in [0:lines.size] do\n match lineType lines[j] with\n | .whitespace => continue\n | .other => break -- not a pre-split\n | .split =>\n let leadingWs := lines.extract 0 j\n return (code.extract 0 i |>.modify (i-1) (fun c => {c with code := c.code ++ .seq leadingWs}), some (out.push {code[i] with code := .seq (lines.extract (j+1))} |>.reverse))\n -- No split here\n out := out.push code[i]\n -- No split anywhere\n return (out.reverse, none)\n\ndef splitExample' (code : Array ModuleItem) : Option (Array ModuleItem) × Array ModuleItem × Option (Array ModuleItem) :=\n let (pre, code) := detachPrefix code\n let (code, suffix) := detachSuffix code\n (pre, code, suffix)\n\nend\n\ndef copyButtonCss : String :=\nr#\"\n\n.tpil-code-container {\n position: relative;\n margin: 20px 0;\n}\n\n.copy-btn,\n.toggle-btn {\n position: absolute;\n top: 0px;\n background: inherit;\n color: black;\n border: none;\n border-radius: 4px;\n cursor: pointer;\n font-size: 12px;\n display: flex;\n align-items: center;\n opacity: 0.7;\n transition: opacity 0.2s;\n padding: 8px;\n}\n\n.copy-btn:hover,\n.toggle-btn:hover {\n opacity: 1;\n background: #555;\n}\n\n.copy-btn {\n right: 10px;\n gap: 5px;\n}\n\n.toggle-btn {\n right: 45px; /* Position to the left of copy button */\n}\n\n.copy-btn.copied {\n background: #28a745;\n}\n\n.copy-icon,\n.toggle-icon {\n width: 14px;\n height: 14px;\n}\n\n.hidden {\n display: grid;\n grid-template-rows: 1fr;\n transition: grid-template-rows 0.3s ease-out, opacity 0.2s ease-out, margin 0.3s ease-out;\n opacity: 0.8;\n}\n\n.tpil-hide-prefix .hidden {\n grid-template-rows: 0fr;\n opacity: 0;\n margin: 0;\n}\n\n.hidden > .hl.lean {\n overflow: hidden;\n margin-bottom: 0;\n}\n\"#\n\ndef copyButtonJs : String :=\nr#\"\nfunction addToggleButtonToElement(elementId, className = 'tpil-hide-prefix') {\n const element = document.getElementById(elementId);\n if (!element) {\n console.error(`Element with ID '${elementId}' not found`);\n return false;\n }\n\n // Create container wrapper if it doesn't exist\n let container = element.parentElement;\n if (!container.classList.contains('code-container')) {\n container = document.createElement('div');\n container.className = 'code-container';\n container.classList.toggle(className);\n\n // Insert container before element\n element.parentNode.insertBefore(container, element);\n\n // Move element into container\n container.appendChild(element);\n }\n\n // Remove existing toggle button if present\n const existingBtn = container.querySelector('.toggle-btn');\n if (existingBtn) {\n existingBtn.remove();\n }\n\n // Create toggle button\n const toggleBtn = document.createElement('button');\n toggleBtn.className = 'toggle-btn';\n toggleBtn.title = 'Show hidden lines';\n toggleBtn.innerHTML = `\n \n `;\n\n // Add click event listener\n toggleBtn.addEventListener('click', () => {\n container.classList.toggle(className);\n\n // Update icon based on state\n const isHidden = container.classList.contains(className);\n toggleBtn.innerHTML = !isHidden ? `\n \n ` : `\n \n `;\n toggleBtn.title = isHidden ? 'Show hidden lines' : 'Hide lines';\n });\n\n // Position toggle button to the left of copy button if it exists\n const copyBtn = container.querySelector('.copy-btn');\n if (copyBtn) {\n container.insertBefore(toggleBtn, copyBtn);\n } else {\n container.appendChild(toggleBtn);\n }\n\n return true;\n}\n\nfunction addCopyButtonToElement(elementId, codeText) {\n const element = document.getElementById(elementId);\n if (!element) {\n console.error(`Element with ID '${elementId}' not found`);\n return false;\n }\n\n // Create container wrapper if it doesn't exist\n let container = element.parentElement;\n if (!container.classList.contains('code-container')) {\n container = document.createElement('div');\n container.className = 'tpil-code-container';\n\n // Insert container before element\n element.parentNode.insertBefore(container, element);\n\n // Move element into container\n container.appendChild(element);\n }\n\n // Remove existing copy button if present\n const existingBtn = container.querySelector('.copy-btn');\n if (existingBtn) {\n existingBtn.remove();\n }\n\n // Create copy button\n const copyBtn = document.createElement('button');\n copyBtn.className = 'copy-btn';\n copyBtn.title = 'Copy to clipboard';\n copyBtn.innerHTML = `\n \n `;\n\n // Add click event listener\n copyBtn.addEventListener('click', async () => {\n try {\n // Copy the provided code text to clipboard\n await navigator.clipboard.writeText(codeText);\n\n // Show success feedback\n const originalText = copyBtn.innerHTML;\n copyBtn.innerHTML = `\n \n Copied!\n `;\n copyBtn.classList.add('copied');\n\n // Reset after 2 seconds\n setTimeout(() => {\n copyBtn.innerHTML = originalText;\n copyBtn.classList.remove('copied');\n }, 2000);\n\n } catch (err) {\n // Fallback for older browsers\n fallbackCopyTextToClipboard(codeText);\n\n // Show feedback\n copyBtn.textContent = 'Copied!';\n setTimeout(() => {\n copyBtn.innerHTML = `\n \n `;\n }, 2000);\n }\n });\n\n // Add button to container\n container.appendChild(copyBtn);\n return true;\n}\n\n// Fallback function for older browsers\nfunction fallbackCopyTextToClipboard(text) {\n const textArea = document.createElement('textarea');\n textArea.value = text;\n textArea.style.position = 'fixed';\n textArea.style.left = '-999999px';\n textArea.style.top = '-999999px';\n document.body.appendChild(textArea);\n textArea.focus();\n textArea.select();\n\n try {\n document.execCommand('copy');\n } catch (err) {\n console.error('Fallback: Oops, unable to copy', err);\n }\n\n document.body.removeChild(textArea);\n}\n\n// Expose API function globally\nwindow.addCopyButtonToElement = addCopyButtonToElement;\nwindow.addToggleButtonToElement = addToggleButtonToElement;\n\"#\n\ndef examplesCss := r#\"\n.example {\n margin-left: 0.75em;\n}\n.example .hl.lean.block {\n margin: 0;\n}\n.example .information pre {\n margin: 0 0 0.25em 0;\n}\n\"#\n\ndef tpilBlock (block : BlockDescr) : BlockDescr :=\n { block with\n extraJsFiles :=\n block.extraJsFiles\n |>.insert { filename := \"copybutton.js\", contents := copyButtonJs, sourceMap? := none }\n extraCssFiles :=\n block.extraCssFiles\n |>.insert { filename := \"copybutton.css\", contents := copyButtonCss }\n |>.insert { filename := \"examples.css\", contents := examplesCss }\n\n }\n\ndef tpilInline (inline : InlineDescr) : InlineDescr :=\n { inline with\n extraJsFiles :=\n inline.extraJsFiles\n |>.insert {filename := \"copybutton.js\", contents := copyButtonJs, sourceMap? := none}\n extraCssFiles :=\n inline.extraCssFiles\n |>.insert { filename := \"copybutton.css\", contents := copyButtonCss }\n |>.insert { filename := \"examples.css\", contents := examplesCss }\n }\n\nstructure ExampleItem where\n code : Highlighted\n output : Option Highlighted.Message\n trailing : String\nderiving ToJson, FromJson, Repr, Quote\n\ndef verbatimBlock (cmd : Highlighted) : TeX :=\n let contents := cmd.trimOneTrailingNl.trimOneLeadingNl.toVerbatimTeX\n .seq #[.raw s!\"\\\\begin\\{LeanVerbatim}[vspace=0pt]\\n\", contents, .raw \"\\n\\\\end{LeanVerbatim}\\n\"]\n\nblock_extension Block.lean\n (allowToggle : Bool)\n (pre : Option Highlighted)\n (code : Array ExampleItem)\n (post : Option Highlighted)\n (goalVisibility : HighlightHtmlM.VisibleProofStates := .none)\n via withHighlighting, tpilBlock where\n data :=\n let defined : Array (Name × String) := code.flatMap (definedNames ·.code)\n .arr #[.bool allowToggle, toJson pre, toJson code, toJson post, toJson goalVisibility, toJson defined]\n traverse id data _ := do\n let .arr #[_allowToggle, _pre, _code, _post, _visibility, definesJson] := data\n | logError s!\"Expected array for Lean block, got {data.compress}\"; return none\n match FromJson.fromJson? definesJson with\n | .error err =>\n logError <| \"Failed to deserialize code config during traversal:\" ++ err\n return none\n | .ok (defines : Array (Name × String)) =>\n for (d, s) in defines do\n if d.isAnonymous then continue\n let d := d.toString\n let path ← (·.path) <$> read\n let _ ← externalTag id path d\n let context := (← read).headers.map (·.titleString)\n modify (·.saveDomainObject exampleDomain d id)\n if let some link := (← get).externalTags[id]? then\n modify (·.modifyDomainObjectData exampleDomain d fun v =>\n let v := if let .obj _ := v then v else .obj {}\n v.setObjVal! link.link (json%{\"context\": $context, \"display\": $s}))\n pure none\n toTeX :=\n open Verso.Output.TeX in\n open Verso.Doc.TeX in\n some <| fun _ _ _ data _ => do\n let .arr #[.bool _allowToggle, hlPreJson, hlJson, hlPostJson, goalVisibilityJson, _defs] := data\n | logError \"Expected five-element JSON for Lean code\"\n pure .empty\n let pre ←\n match FromJson.fromJson? (α := Option Highlighted) hlPreJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code intro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let code ←\n match FromJson.fromJson? (α := Array ExampleItem) hlJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let _post ←\n match FromJson.fromJson? (α := Option Highlighted) hlPostJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code outro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let _visibility ←\n match FromJson.fromJson? (α := HighlightHtmlM.VisibleProofStates) goalVisibilityJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code outro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let codeIndent := code.foldl (init := pre.map (·.indentation)) (fun i? y => i?.map (min · y.1.indentation)) |>.getD 0\n let mut codeTeX : TeX := .empty\n\n for ⟨cmd, out?, ws⟩ in code do\n let cmd := cmd.deIndent codeIndent\n codeTeX := codeTeX ++ verbatimBlock cmd\n if let some msg := out? then\n codeTeX := codeTeX ++ (← msg.toTeX)\n unless ws.isEmpty do\n codeTeX := codeTeX ++ (← (Highlighted.text ws).toTeX)\n\n pure codeTeX\n\n extraJsFiles := .ofList [{ filename := \"copybutton.js\", contents := copyButtonJs, sourceMap? := none }]\n extraCssFiles := .ofList [\n { filename := \"copybutton.css\", contents := copyButtonCss },\n { filename := \"examples.css\", contents := examplesCss }\n ]\n toHtml :=\n open Verso.Output.Html in\n some <| fun _ _ _ data _ => do\n let .arr #[.bool allowToggle, hlPreJson, hlJson, hlPostJson, goalVisibilityJson, _defs] := data\n | HtmlT.logError \"Expected five-element JSON for Lean code\"\n pure .empty\n let pre ←\n match FromJson.fromJson? (α := Option Highlighted) hlPreJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code intro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let code ←\n match FromJson.fromJson? (α := Array ExampleItem) hlJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let post ←\n match FromJson.fromJson? (α := Option Highlighted) hlPostJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code outro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let visibility ←\n match FromJson.fromJson? (α := HighlightHtmlM.VisibleProofStates) goalVisibilityJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code outro block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n\n let codeIndent := code.foldl (init := pre.map (·.indentation)) (fun i? y => i?.map (min · y.1.indentation)) |>.getD 0\n\n let mut codeHtml : Html := .empty\n let mut codeString := \"\"\n\n if allowToggle then\n if let some p := pre then\n let p := p.deIndent codeIndent\n let inner ←\n withDefinitionsAsTargets false <|\n withVisibleProofStates visibility <|\n p.trimOneLeadingNl |>.blockHtml \"examples\" (trim := false) (g := Verso.Genre.Manual)\n codeHtml := codeHtml ++ {{ {{ inner }}
}}\n codeString := codeString ++ p.toString\n\n for ⟨cmd, out?, ws⟩ in code do\n let cmd := cmd.deIndent codeIndent\n let moreCode ←\n withDefinitionsAsTargets true <|\n withVisibleProofStates visibility <|\n cmd.trimOneLeadingNl |>.blockHtml \"examples\" (trim := false) (g := Verso.Genre.Manual)\n codeHtml := codeHtml ++ moreCode\n codeString := codeString ++ cmd.toString\n if let some msg := out? then\n let msgHtml ← msg.toHtml (g := Verso.Genre.Manual) []\n codeHtml := codeHtml ++ {{{{msgHtml}}}}\n unless ws.isEmpty do\n codeHtml := codeHtml ++ (← (Highlighted.text ws).blockHtml \"examples\" (trim := false) (g := Verso.Genre.Manual))\n\n if allowToggle then\n if let some p := post then\n let p := p.deIndent codeIndent\n let inner ←\n withDefinitionsAsTargets false <|\n withVisibleProofStates visibility <|\n p.trimOneLeadingNl |>.blockHtml \"examples\" (trim := false) (g := Verso.Genre.Manual)\n codeHtml := codeHtml ++ {{ {{ inner }}
}}\n codeString := codeString ++ p.toString\n\n let i ← uniqueId (g := Verso.Genre.Manual)\n let toCopy := (pre.map (·.toString)).getD \"\" ++ codeString\n let mut script := s!\"addCopyButtonToElement({i.quote}, {toCopy.quote});\"\n if allowToggle && (pre.isSome || post.isSome) then\n script := script ++ s!\"\\naddToggleButtonToElement({i.quote});\"\n\n return {{\n {{codeHtml}}
\n \n }}\n\nblock_extension Block.leanAnchor (code : Highlighted) (completeCode : String)\n via withHighlighting, tpilBlock where\n data := .arr #[toJson code, toJson completeCode]\n traverse _ _ _ := pure none\n toTeX :=\n open Verso.Output.TeX in\n open Verso.Doc.TeX in\n some <| fun _ _ _ data _ => do\n let .arr #[hlJson, completeCodeJson] := data\n | logError \"Expected two-element JSON for Lean code\"\n pure .empty\n let code ←\n match FromJson.fromJson? (α := Highlighted) hlJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code block while rendering TeX: \" ++ err\n return .empty\n | .ok hl => pure hl\n let _completeCode ←\n match FromJson.fromJson? (α := String) completeCodeJson with\n | .error err =>\n logError <| \"Couldn't deserialize Lean code string while rendering TeX: \" ++ err\n return .empty\n | .ok hl => pure hl\n\n let code := code.deIndent code.indentation\n pure (verbatimBlock code)\n\n toHtml :=\n open Verso.Output.Html in\n some <| fun _ _ _ data _ => do\n let .arr #[hlJson, completeCodeJson] := data\n | HtmlT.logError \"Expected two-element JSON for Lean code\"\n pure .empty\n let code ←\n match FromJson.fromJson? (α := Highlighted) hlJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code block while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n let completeCode ←\n match FromJson.fromJson? (α := String) completeCodeJson with\n | .error err =>\n HtmlT.logError <| \"Couldn't deserialize Lean code string while rendering HTML: \" ++ err\n return .empty\n | .ok hl => pure hl\n\n let code := code.deIndent code.indentation\n\n let codeHtml : Html := (← code.blockHtml \"examples\" (trim := false) (g := Verso.Genre.Manual))\n\n let i ← uniqueId (g := Verso.Genre.Manual)\n let mut script := s!\"addCopyButtonToElement({i.quote}, {completeCode.quote});\"\n\n return {{\n {{codeHtml}}
\n \n }}\n\ndef proofStateStyle := r#\"\n.hl.lean.proof-state-view {\n white-space: collapse;\n margin-left: 0.75em;\n}\n.hl.lean.proof-state-view .hypothesis {\n display: table !important;\n border-spacing: 0 0.2rem;\n border-collapse: separate;\n}\n.hl.lean.proof-state-view .tactic-state {\n display: block;\n left: 0;\n padding: 0;\n border: none;\n}\n\n.hl.lean.proof-state-view .tactic-state:has(.goal + .goal) {\n display: flex;\n flex-wrap: wrap;\n gap: 2rem;\n justify-content: space-evenly;\n width: 100%;\n}\n.hl.lean.proof-state-view .tactic-state .goal {\n margin: 0 !important;\n align-self: flex-start;\n width: fit-content;\n}\n\"#\n\nblock_extension Block.goals (goals : Array (Highlighted.Goal Highlighted))\n via withHighlighting, tpilBlock where\n data := toJson goals\n traverse _ _ _ := pure none\n toTeX :=\n open Verso.Output.TeX in\n open Verso.Doc.TeX in\n some <| fun _ _ _ data _ => do\n let goals ←\n match fromJson? (α := Array (Highlighted.Goal Highlighted)) data with\n | .ok v => pure v\n | .error e =>\n logError <| \"Failed to deserialize proof state: \" ++ e\n return .empty\n -- TODO: lay these out side-by-side\n pure <| .seq (← goals.mapM (·.toTeX))\n extraCssFiles := .ofList [{ filename := \"proof-state.css\", contents := proofStateStyle }]\n toHtml :=\n open Verso.Output.Html in\n some <| fun _ _ _ data _ => do\n let goals ←\n match fromJson? (α := Array (Highlighted.Goal Highlighted)) data with\n | .ok v => pure v\n | .error e =>\n HtmlT.logError <| \"Failed to deserialize proof state: \" ++ e\n return .empty\n pure {{\n \n \n {{← if goals.isEmpty then\n pure {{\"All goals completed! 🐙\"}}\n else\n withCollapsedSubgoals (g := Verso.Genre.Manual) .never <|\n .seq <$> (goals.mapIdxM (fun i x => x.toHtml (·.toHtml) i))}}\n \n
\n }}\n\ninline_extension Inline.goal (goal : Highlighted.Goal Highlighted)\n via withHighlighting, tpilInline where\n data := toJson goal\n traverse _ _ _ := pure none\n toTeX :=\n open Verso.Doc.TeX in\n open Verso.Output.TeX in\n some <| fun _ _ data _ => do\n let goal ←\n match fromJson? (α := Highlighted.Goal Highlighted) data with\n | .ok v => pure v\n | .error e =>\n logError <| \"Failed to deserialize proof goal: \" ++ e\n return .empty\n verbatimInline (goal.name.getD \"\")\n\n toHtml :=\n open Verso.Output.Html in\n some <| fun _ _ data _ => do\n let goal ←\n match fromJson? (α := Highlighted.Goal Highlighted) data with\n | .ok v => pure v\n | .error e =>\n HtmlT.logError <| \"Failed to deserialize proof goal: \" ++ e\n return .empty\n pure {{\n \n \n {{goal.name |>.getD \"\"}}\n \n {{← goal.toHtml (g := Verso.Genre.Manual) (·.toHtml) 0}}\n \n \n \n }}\n\ndef kbdCSS := r#\"\ncode.unicode-abbrev {\n background-color: #eee;\n border-radius: 3px;\n border: 1px solid #ccc;\n white-space: nowrap;\n}\n\nkbd {\n white-space: nowrap;\n}\n\nkbd > code {\n background-color: #eee;\n border-radius: 3px;\n border: 1px solid #b4b4b4;\n box-shadow:\n 0 1px 1px rgba(0, 0, 0, 0.2),\n 0 2px 0 0 rgba(255, 255, 255, 0.7) inset;\n color: #333;\n display: inline-block;\n font-size: 0.85em;\n font-weight: 700;\n line-height: 1;\n padding: 2px 4px;\n white-space: nowrap;\n vertical-align: middle;\n}\n\"#\n\ninline_extension Inline.kbd (items : Array String) where\n data := toJson items\n traverse _ _ _ := pure none\n toTeX :=\n open Verso.Output.TeX in\n open Verso.Doc.TeX in\n let verb (s : String) : TeX := .seq #[.raw \"\\\\verb|\", .raw s, raw \"|\"] -- Fails if s contains \"|\"\n let verbs (ss : List String) : TeX := List.intersperse (TeX.text \" \") (ss.map verb)\n some <| fun _ _ data _ => do\n let items ←\n match fromJson? (α := Array String) data with\n | .ok v => pure v\n | .error e =>\n logError <| \"Failed to deserialize keyboard shortcut: \" ++ e\n return .empty\n if let #[item] := items then\n if item.startsWith \"\\\\\" then\n pure (verb item)\n else\n let items : List String := item.toList.map fun c => s!\"{c}\"\n pure (verbs items)\n else\n pure (verbs items.toList)\n\n extraCss := [kbdCSS]\n toHtml :=\n open Verso.Output.Html in\n some <| fun _ _ data _ => do\n let items ←\n match fromJson? (α := Array String) data with\n | .ok v => pure v\n | .error e =>\n HtmlT.logError <| \"Failed to deserialize keyboard shortcut: \" ++ e\n return .empty\n if let #[item] := items then\n if item.startsWith \"\\\\\" then\n pure {{{{item}}}}\n else\n let items : Array Html := item.toList.toArray.map fun c => {{{{s!\"{c}\"}}}}\n pure {{{{items}}}}\n else\n let items : Array Html := items.map (fun (s : String) => {{s!\"{s}\"}})\n pure {{{{items}}}}\n\nprivate def oneCodeStr [Monad m] [MonadError m] (inlines : Array (TSyntax `inline)) : m StrLit := do\n let #[code] := inlines\n | (if inlines.size == 0 then (throwError ·) else (throwErrorAt (mkNullNode inlines) ·)) \"Expected one code element\"\n let `(inline|code($code)) := code\n | throwErrorAt code \"Expected a code element\"\n return code\n\nprivate def codeStrs [Monad m] [MonadError m] (inlines : Array (TSyntax `inline)) : m (Array StrLit) := do\n let mut out := #[]\n for i in inlines do\n match i with\n | `(inline|code($code)) =>\n out := out.push code\n | `(inline|$s:str) =>\n unless s.getString.all (·.isWhitespace) do\n throwErrorAt s \"Expected a code literal\"\n | other => throwErrorAt other \"Expected a code literal\"\n return out\n\n\nstructure Kept (α : Type u) where\n values : Array α\n next : Nat\n in_bounds : next < values.size\nderiving Repr\n\ninstance [Inhabited α] : Inhabited (Kept α) where\n default := ⟨#[default], 0, by simp⟩\n\ndef Kept.add (kept : Kept α) (val : α) : Kept α where\n values := kept.values.set kept.next val (h := kept.in_bounds)\n next := if kept.next = 0 then kept.values.size - 1 else kept.next - 1\n in_bounds := by\n have := kept.in_bounds\n rw [Array.size_set]\n split <;> omega\n\ninstance [Monad m] : ForM m (Kept α) α where\n forM kept f := do\n for h : i in [kept.next:kept.values.size] do\n f kept.values[i]\n for h : i in [0:kept.next] do\n have := kept.in_bounds\n have : i < kept.next := by get_elem_tactic\n f kept.values[i]\n\ninstance [Monad m] : ForIn m (Kept α) α := ⟨ForM.forIn⟩\n\ninitialize recentHighlightsExt : EnvExtension (Kept Highlighted) ←\n registerEnvExtension (pure ⟨.replicate 12 .empty, 0, by simp⟩)\n\n/--\nA mapping from anchor names to the corresponding code. Each code element is paired with it's\nde-anchored context for copy-paste purposes.\n-/\ninitialize savedAnchorExt : EnvExtension (HashMap String (Highlighted × String)) ←\n registerEnvExtension (pure {})\n\n\ndef allProofInfo (hl : Highlighted) : Array Highlighted :=\n go #[] hl\nwhere\n go (acc : Array Highlighted) : Highlighted → Array Highlighted\n | .seq xs =>\n xs.foldl (init := acc) go\n | .span _ x => go acc x\n | .tactics gs _ _ x => gs.foldl (init := (go acc x)) (fromGoal · ·)\n | .point .. | .text .. | .token .. | .unparsed .. => acc\n fromGoal (acc : Array Highlighted) (g : Highlighted.Goal Highlighted) :=\n g.hypotheses.foldl (init := acc.push g.conclusion) fun acc ⟨xs, hl⟩ =>\n let names : Highlighted := xs.foldl (init := .empty) fun hl tok =>\n if hl.isEmpty then .token tok\n else hl ++ .text \" \" ++ .token tok\n acc.push (names ++ .text \" \" ++ .token ⟨.unknown, \":\"⟩ ++ .text \" \" ++ hl)\n\n\ndef saveBackref (hl : Highlighted) : DocElabM Unit := do\n -- Construct a document with all the proof states in it, so references can target them but they\n -- don't eat up individual slots in the history ring\n let hl := allProofInfo hl |>.foldl (init := hl) (· ++ .text \"\\n\" ++ ·)\n\n modifyEnv (recentHighlightsExt.modifyState · (·.add hl))\n\nstructure ProofState where\n goals : Array (Highlighted.Goal Highlighted)\n start : Nat\n stop : Nat\n «syntax» : Highlighted\nderiving Repr\n\ninitialize proofStatesExt : EnvExtension (HashMap String ProofState) ←\n registerEnvExtension (pure {})\n\n/-- Extracts all messages from the given code. -/\ndef allInfo (hl : Highlighted) : Array (Highlighted.Message × Option Highlighted) :=\n match hl with\n | .seq xs => xs.flatMap allInfo\n | .point k str => #[(⟨k, str⟩, none)]\n | .tactics _ _ _ x => allInfo x\n | .span infos x => (infos.map fun (k, str) => (⟨k, str⟩, some x)) ++ allInfo x\n | .text .. | .token .. | .unparsed .. => #[]\n\ndef trailingText (hl : Highlighted) : Highlighted × String :=\n match hl with\n | .seq xs => Id.run do\n let mut txt := \"\"\n for h : i in [0:xs.size] do\n let i' := xs.size - (i + 1)\n have : i < xs.size := by get_elem_tactic\n have : i' < xs.size := by grind\n let (hl', txt') := trailingText xs[i']\n txt := txt' ++ txt\n if hl'.isEmpty then continue\n else return (.seq (xs.extract 0 i' |>.push hl'), txt)\n return (.empty, txt)\n | .point .. | .token .. => (hl, \"\")\n | .tactics i s e hl' =>\n let (hl', txt) := trailingText hl'\n (.tactics i s e hl', txt)\n | .span i hl' =>\n let (hl', txt) := trailingText hl'\n (.span i hl', txt)\n | .text txt | .unparsed txt => (.empty, txt)\n\nprivate def commentContents (s : String) : Option (String × String) :=\n let s := s.trimAsciiStart\n if s.startsWith \"--\" then\n let s := s.dropWhile (· == '-') |>.trimAsciiStart\n let ws := s.takeEndWhile (·.isWhitespace)\n some (s.dropEnd ws.positions.count |>.copy, ws.copy)\n else\n none\n\n/--\nExtracts a trailing comment from code, if present.\n\nReturns the code along with the comment and its trailing whitespace.\n-/\ndef trailingComment (hl : Highlighted) : Highlighted × Option (String × String) :=\n let x := trailingText hl\n match commentContents x.2 with\n | some txt' => (x.1, some txt')\n | none => (hl, none)\n\n\nsection\n\ninductive ShowProofStates where\n | none\n | named (which : Array String)\n | all\n\nstructure LeanConfig where\n checkOutput : Bool\n suppressNamespaces : Option String\n allowVisible : Bool\n showProofStates : ShowProofStates\n «show» : Bool\n\nvariable [Monad m] [MonadError m ] [MonadLiftT CoreM m]\n\ninstance : FromArgVal ShowProofStates m where\n fromArgVal := {\n description := \"`all`, `none`, or a string literal\",\n signature := .String ∪ .Ident\n get := fun\n | .name x =>\n match x.getId with\n | `all => pure .all\n | `none => pure .none\n | _ => do\n let h ← MessageData.hint m!\"Use 'all', 'none', or a string\" #[\"all\", \"none\", \"NAME1 NAME2 ...\".quote] (ref? := x)\n throwErrorAt x m!\"Expected 'all' or 'none' or a string literal\\n{h}\"\n | .str s => pure <| .named <| (s.getString.splitOn \" \").toArray\n | .num n => do\n let h ← MessageData.hint m!\"Use 'all', 'none', or a string\" #[\"all\", \"none\", \"NAME1 NAME2 ...\".quote] (ref? := n)\n throwErrorAt n m!\"Expected 'all' or 'none' or a string literal\\n{h}\"\n }\n\ninstance : FromArgs LeanConfig m where\n fromArgs :=\n LeanConfig.mk <$>\n .namedD `check .bool true <*>\n .named `suppressNamespaces .string true <*>\n .namedD `allowVisible .bool true <*>\n .namedD' `showProofStates .none <*>\n .namedD' `show .true\n\nstructure SavedLeanConfig where\n name : Option Ident\n suppressNamespaces : Option String\n\ninstance : FromArgs SavedLeanConfig m where\n fromArgs :=\n SavedLeanConfig.mk <$>\n (some <$> .positional `name .ident <|> pure none) <*>\n .named `suppressNamespaces .string true\n\nend\n\ndef isNewline (hl : Highlighted) : Bool :=\n match hl with\n | .text str | .unparsed str => str == \"\\n\"\n | .token .. => false\n | .seq xs => Id.run do\n for h : i in [0:xs.size] do\n if xs[i].isEmpty then continue\n else if isNewline xs[i] then return xs.extract (i+1) |>.all (·.isEmpty)\n else return false\n return false\n | .tactics _ _ _ x | .span _ x => isNewline x\n | .point .. => false\n\n\n\nopen SubVerso.Module in\n/--\nLeading anchor comments are always incorrect. They probably result from Lean placing them with the\n_next_ command, so we should move them back up before processing them.\n-/\ndef fixupAnchorComments (items : Array ModuleItem) : Array ModuleItem := Id.run do\n let mut out := #[]\n let mut prev? : Option ModuleItem := none\n\n for i in items do\n let mut i := i\n if prev?.isSome then\n let mut lines := i.code.lines\n while h : lines.size > 0 do\n if isNewline lines[0] || (proofState? lines[0].toString |>.isOk) then\n prev? := prev?.map (fun i => {i with code := i.code ++ lines[0]})\n lines := lines.drop 1\n else break\n i := {i with code := .seq lines}\n if let some prev := prev? then\n out := out.push prev\n prev? := some i\n if let some prev := prev? then\n out := out.push prev\n\n return out\n\nprivate def showGoals (goals : Array (Highlighted.Goal Highlighted)) : MessageData := Id.run do\n if goals.isEmpty then return m!\"No goals\"\n let mut out := m!\"\"\n for g in goals do\n if let some n := g.name then\n out := out ++ m!\"case {n}\\n\"\n for ⟨xs, h⟩ in g.hypotheses do\n let xs := \" \".intercalate (xs.toList.map (fun ⟨_, x⟩ => x))\n out := out ++ m!\"{xs} : {h.toString}\\n\"\n out := out ++ m!\" {g.goalPrefix} {g.conclusion.toString}\\n\\n\"\n pure out\n\n@[code_block_expander lean]\ndef lean : CodeBlockExpander\n | args, code => do\n let {checkOutput, suppressNamespaces, allowVisible, showProofStates, «show»} ← parseThe LeanConfig args\n let mut showProofStates := showProofStates\n let codeStr := code.getString\n let contents ← extractFile codeStr suppressNamespaces\n let contents := contents.filter (!·.code.isEmpty)\n let (pre, mid, post) := splitExample' contents\n let mid := fixupAnchorComments mid\n let pre : Option Highlighted := pre.map fun p => p.foldl (init := .empty) fun acc c => acc ++ c.code\n let mut toShow : Array ExampleItem := #[]\n let mut visibility : HighlightHtmlM.VisibleProofStates :=\n match showProofStates with\n | .none => .none\n | .all => .all\n | .named _ => .states #[]\n for item in mid do\n let code ←\n match item.code.anchored (textAnchors := false) with\n | .ok a =>\n for (k, v) in a.proofStates.toArray do\n if let .tactics goals start stop hl := v then\n logSilentInfo m!\"Proof state {k} on `{v.toString}`:\\n{showGoals goals}\"\n modifyEnv (proofStatesExt.modifyState · (·.insert k ⟨goals, start, stop, hl⟩))\n if let (.states ss, .named xs) := (visibility, showProofStates) then\n if k ∈ xs then\n visibility := .states (ss.push (start, stop))\n showProofStates := .named (xs.filter (· ≠ k))\n else throwError \"Unexpected syntax for proof state '{k}':{indentD <| repr v}\"\n pure a.code\n | .error e =>\n throwError \"Error while extracting proof states:{indentD e}\"\n let item := {item with code}\n match item.kind with\n | ``Lean.Parser.Command.check | ``Lean.Parser.Command.eval | ``Lean.reduceCmd | ``Lean.Parser.Command.check_failure\n | ``Lean.Parser.Command.print | ``Lean.Parser.Command.printAxioms | ``Lean.Parser.Command.printEqns\n | ``Lean.guardMsgsCmd =>\n let info? : Option Highlighted.Message := allInfo item.code |>.firstM fun (msg, hl?) =>\n if hl? matches some (.token ⟨.keyword .., _⟩) then some msg else none\n if let some msg := info? then\n if let (code, some (comment, ws)) := trailingComment item.code then\n let txt := msg.toString\n if checkOutput && !eqMessages comment txt then\n throwError \"Mismatch! Expected {comment} but got {txt}\"\n toShow := toShow.push ⟨code, some msg, dropOneNl ws⟩\n else\n let (code', ws) := trailingText item.code\n toShow := toShow.push ⟨code', some msg, dropOneNl ws⟩\n else toShow := toShow.push ⟨item.code, none, \"\"⟩\n | _ => toShow := toShow.push ⟨item.code, none, \"\"⟩\n let post : Option Highlighted := post.map fun p => p.foldl (init := .empty) fun acc c => acc ++ c.code\n let visible := .seq <| toShow.map (·.1)\n saveBackref visible\n for (msg, _) in allInfo visible do\n logSilentInfo msg.toString\n if let .named xs := showProofStates then\n unless xs.isEmpty do\n logWarning m!\"Unused proof state names: {m!\", \".joinSep (xs.map (m!\"'{·}'\")).toList}\"\n if «show» then\n return #[← ``(Block.other (Block.lean $(quote allowVisible) $(quote pre) $(quote toShow) $(quote post) $(quote visibility)) #[])]\n else\n return #[]\nwhere\n eqMessages (s1 s2 : String) := SubVerso.Examples.Messages.messagesMatch (s1.replace \"\\n\" \" \") (s2.replace \"\\n\" \" \")\n dropOneNl (s : String) : String :=\n if s.back == '\\n' then (s.dropEnd 1).copy else s\n\n\n@[code_block_expander save]\ndef save : CodeBlockExpander\n | args, code => do\n let {name, suppressNamespaces} ← parseThe SavedLeanConfig args\n let codeStr := code.getString\n let contents ← extractFile codeStr suppressNamespaces\n let contents : Highlighted := .seq <| contents.map (·.code)\n match contents.anchored with\n | .error e => throwError s!\"Error extracting anchors: {e}\"\n | .ok {anchors, proofStates, code} =>\n let codeStr := code.toString\n for (k, v) in anchors.toArray do\n logSilentInfo m!\"Anchor {k}:\\n{v.toString}\"\n modifyEnv (savedAnchorExt.modifyState · (·.insert k (v, codeStr)))\n for (k, v) in proofStates.toArray do\n if let .tactics goals start stop hl := v then\n logSilentInfo m!\"Proof state {k} on `{v.toString}`:\\n{showGoals goals}\"\n modifyEnv (proofStatesExt.modifyState · (·.insert k ⟨goals, start, stop, hl⟩))\n if let some x := name then\n modifyEnv (savedAnchorExt.modifyState · (·.insert x.getId.toString (code, codeStr)))\n pure #[]\n\n@[code_block_expander savedAnchor]\ndef savedAnchor : CodeBlockExpander\n | args, code => do\n let name ← ArgParse.run (.positional `name .ident) args\n let env ← getEnv\n let some (hl, complete) := (savedAnchorExt.getState env)[name.getId.toString]?\n | throwErrorAt name m!\"Not found: '{name.getId}'\"\n discard <| ExpectString.expectString \"code\" code hl.toString\n saveBackref hl\n return #[← ``(Block.other (Block.leanAnchor $(quote hl) $(quote complete)) #[])]\n\nsection\n\nstructure ProofStateConfig where\n name : StrLit\n\nstructure GoalConfig where\n name : StrLit\n\nvariable [Monad m] [MonadError m ] [MonadLiftT CoreM m]\n\nprivate def strOrName : ValDesc m StrLit where\n description := \"identifier or string literal\"\n signature := .Ident ∪ .String\n get\n | .name x => pure <| Syntax.mkStrLit x.getId.toString (info := x.raw.getHeadInfo)\n | .str s => pure s\n | .num n => throwErrorAt n \"Expected identifier or string literal\"\n\ninstance : FromArgs ProofStateConfig m where\n fromArgs := ProofStateConfig.mk <$> .positional `name strOrName\n\ninstance : FromArgs GoalConfig m where\n fromArgs := GoalConfig.mk <$> .positional `name strOrName\n\nend\n\n@[code_block_expander proofState]\ndef proofState : CodeBlockExpander\n | args, code => do\n let {name} ← parseThe ProofStateConfig args\n let some {goals, ..} := (proofStatesExt.getState (← getEnv))[name.getString]?\n | let allStates := (proofStatesExt.getState (← getEnv)).keys\n let h ←\n if allStates.isEmpty then\n pure <| MessageData.hint' \"Name a proof state with a suitable PROOF_STATE: comment\"\n else\n MessageData.hint \"Use a proof state name:\" (allStates.toArray.map ({suggestion := .string ·})) (ref? := some name)\n logErrorAt name m!\"Not found: {name.getString}\\n{h}\"\n return #[← ``(sorry)]\n let mut goalView := \"\"\n for g in goals do\n goalView := goalView ++ g.toString ++ \"\\n\\n\"\n goalView := goalView.trimAsciiEnd.copy ++ \"\\n\"\n _ ← ExpectString.expectString \"proof\" code goalView\n return #[← ``(Block.other (Block.goals $(quote goals)) #[])]\n\n@[role_expander goal]\ndef goal : RoleExpander\n | args, inls => do\n let {name} ← parseThe GoalConfig args\n let caseTag ← oneCodeStr inls\n let some {goals, ..} := (proofStatesExt.getState (← getEnv))[name.getString]?\n | logErrorAt name m!\"Not found: {name.getString}\"\n return #[← ``(sorry)]\n let goal? := goals.find? fun\n | {name := some x, ..} => caseTag.getString == x\n | _ => false\n let some goal := goal?\n | let validTags := goals.filterMap (·.name)\n let h ←\n if validTags.isEmpty then\n pure <| MessageData.hint' m!\"\"\n else\n MessageData.hint m!\"Use a case label:\" (validTags.map ({suggestion := .string ·})) (ref? := some caseTag)\n logErrorAt caseTag m!\"Not found: {caseTag.getString}\\n{h}\"\n return #[← ``(sorry)]\n return #[← ``(Inline.other (Inline.goal $(quote goal)) #[])]\n\nstructure Helper where\n highlight (term : String) (type? : Option String) : IO Highlighted\n command (cmd : String) : IO Highlighted\n signature (code : String) : IO Highlighted\n name (code : String) : IO Highlighted\n\nopen System in\nopen SubVerso.Helper in\ndef Helper.fromModule (setup : String) : IO Helper := do\n let codeHash := hash setup\n let modBase := \"Interact\" ++ hashString codeHash\n let filename := modBase ++ \".lean\"\n let mod := \"Examples.\" ++ modBase\n\n -- Validate that the path is really a Lean project\n let lakefile := projectDir / \"lakefile.lean\"\n let lakefile' := projectDir / \"lakefile.toml\"\n if !(← lakefile.pathExists) && !(← lakefile'.pathExists) then\n throw <| .userError s!\"Neither {lakefile} nor {lakefile'} exist, couldn't load project\"\n let toolchainfile := projectDir / \"lean-toolchain\"\n let toolchain ← do\n if !(← toolchainfile.pathExists) then\n throw <| .userError s!\"File {toolchainfile} doesn't exist, couldn't load project\"\n pure (← IO.FS.readFile toolchainfile).trimAscii.copy\n\n IO.FS.writeFile (projectDir / \"Examples\" / filename) setup\n\n -- Kludge: remove variables introduced by Lake. Clearing out DYLD_LIBRARY_PATH and\n -- LD_LIBRARY_PATH is useful so the version selected by Elan doesn't get the wrong shared\n -- libraries.\n let lakeVars :=\n #[\"LAKE\", \"LAKE_HOME\", \"LAKE_PKG_URL_MAP\",\n \"LEAN_SYSROOT\", \"LEAN_AR\", \"LEAN_PATH\", \"LEAN_SRC_PATH\",\n \"LEAN_GITHASH\",\n \"ELAN_TOOLCHAIN\", \"DYLD_LIBRARY_PATH\", \"LD_LIBRARY_PATH\"]\n\n let cmd := \"elan\"\n\n let toolchainFile ← IO.FS.Handle.mk toolchainfile .read\n toolchainFile.lock (exclusive := true)\n try\n let args := #[\"run\", \"--install\", toolchain, \"lake\", \"build\", \"subverso-helper\"]\n let res ← IO.Process.output {\n cmd, args, cwd := projectDir\n -- Unset Lake's environment variables\n env := lakeVars.map (·, none)\n }\n if res.exitCode != 0 then reportFail projectDir cmd args res\n finally\n toolchainFile.unlock\n\n let setupFile ← IO.FS.Handle.mk (projectDir / \"Examples\" / filename) .read\n setupFile.lock (exclusive := true)\n try\n let args := #[\"run\", \"--install\", toolchain, \"lake\", \"env\", \"subverso-helper\", mod]\n let (hlTm, hlCmd, hlSig, hlName) ← do\n let (procIn, proc) ← do\n let proc ← IO.Process.spawn {\n cmd, args, cwd := projectDir\n -- Unset Lake's environment variables\n env := lakeVars.map (·, none)\n stdin := .piped\n stdout := .piped\n stderr := .inherit\n }\n proc.takeStdin\n let mutex ← Std.Mutex.new (IO.FS.Stream.ofHandle procIn, IO.FS.Stream.ofHandle proc.stdout)\n let hlTm := fun (tm : String) (ty? : Option String) => show IO Highlighted from do\n mutex.atomically do\n let (procIn, procOut) ← get\n if let some code ← proc.tryWait then\n throw <| .userError s!\"Process terminated: {code}\"\n send procIn (Request.term tm ty?)\n match (← receiveThe Response procOut) with\n | some (.result (.highlighted hl)) => pure hl\n | some (.error code e more) =>\n let mut msg := s!\"{e} ({code}).\"\n if let some details := more then\n msg := msg ++ s!\" Details:\\n {details}\"\n throw <| .userError msg\n | none => throw <| .userError \"Helper process no longer running\"\n let hlCmd := fun (cmd : String) => show IO Highlighted from do\n mutex.atomically do\n let (procIn, procOut) ← get\n if let some code ← proc.tryWait then\n throw <| .userError s!\"Process terminated: {code}\"\n send procIn (Request.command cmd)\n match (← receiveThe Response procOut) with\n | some (.result (.highlighted hl)) => pure hl\n | some (.error code e more) =>\n let mut msg := s!\"{e} ({code}).\"\n if let some details := more then\n msg := msg ++ s!\" Details:\\n {details}\"\n throw <| .userError msg\n | none => throw <| .userError \"Helper process no longer running\"\n let hlSig := fun (cmd : String) => show IO Highlighted from do\n mutex.atomically do\n let (procIn, procOut) ← get\n if let some code ← proc.tryWait then\n throw <| .userError s!\"Process terminated: {code}\"\n send procIn (Request.signature cmd)\n match (← receiveThe Response procOut) with\n | some (.result (.highlighted hl)) => pure hl\n | some (.error code e more) =>\n let mut msg := s!\"{e} ({code}).\"\n if let some details := more then\n msg := msg ++ s!\" Details:\\n {details}\"\n throw <| .userError msg\n | none => throw <| .userError \"Helper process no longer running\"\n let hlName := fun (cmd : String) => show IO Highlighted from do\n mutex.atomically do\n let (procIn, procOut) ← get\n if let some code ← proc.tryWait then\n throw <| .userError s!\"Process terminated: {code}\"\n send procIn (Request.name cmd)\n match (← receiveThe Response procOut) with\n | some (.result (.highlighted hl)) => pure hl\n | some (.error code e more) =>\n let mut msg := s!\"{e} ({code}).\"\n if let some details := more then\n msg := msg ++ s!\" Details:\\n {details}\"\n throw <| .userError msg\n | none => throw <| .userError \"Helper process no longer running\"\n pure (hlTm, hlCmd, hlSig, hlName)\n\n return Helper.mk hlTm hlCmd hlSig hlName\n finally\n setupFile.unlock\nwhere\n decorateOut (name : String) (out : String) : String :=\n if out.isEmpty then \"\" else s!\"\\n{name}:\\n{out}\\n\"\n\n reportFail {α} (projectDir : FilePath) (cmd : String) (args : Array String) (res : IO.Process.Output) : IO α := do\n IO.eprintln <|\n \"Build process failed.\" ++\n \"\\nCWD: \" ++ projectDir.toString ++\n \"\\nCommand: \" ++ cmd ++\n \"\\nArgs: \" ++ repr args ++\n \"\\nExit code: \" ++ toString res.exitCode ++\n \"\\nstdout: \" ++ res.stdout ++\n \"\\nstderr: \" ++ res.stderr\n\n throw <| .userError <|\n \"Build process failed.\" ++\n decorateOut \"stdout\" res.stdout ++\n decorateOut \"stderr\" res.stderr\n\ninitialize helperExt : EnvExtension (Option Helper) ←\n registerEnvExtension (pure none)\n\ninitialize defaultHelperExt : EnvExtension (Option Helper) ←\n registerEnvExtension (pure none)\n\n@[directive_expander setup]\ndef setup : DirectiveExpander\n | args, contents => do\n ArgParse.done.run args\n if h : contents.size < 1 then\n throwError \"Expected a setup code block\"\n else\n let first := contents[0]\n let contents := contents.extract 1 contents.size\n let `(block|``` | $setupCode ```) := first\n | throwErrorAt first \"Expected undecorated code block\"\n if helperExt.getState (← getEnv) |>.isSome then\n throwError \"Already highlighting Lean\"\n let helper ← Helper.fromModule setupCode.getString\n modifyEnv fun env => helperExt.setState env (some helper)\n try\n contents.mapM elabBlock\n finally\n modifyEnv fun env => helperExt.setState env none\n\n\ndef prioritizedElab [Monad m] (prioritize : α → m Bool) (act : α → m β) (xs : Array α) : m (Array β) := do\n let mut out := #[]\n let mut later := #[]\n for h:i in [0:xs.size] do\n let x := xs[i]\n if ← prioritize x then\n out := out.push (i, (← act x))\n else later := later.push (i, x)\n for (i, x) in later do\n out := out.push (i, (← act x))\n out := out.qsort (fun (i, _) (j, _) => i < j)\n return out.map (·.2)\n\nopen Lean Elab in\ndef isLeanBlock : TSyntax `block → CoreM Bool\n | `(block|```$nameStx:ident $_args*|$_contents:str```) => do\n let name ← realizeGlobalConstNoOverloadWithInfo nameStx\n return name == ``TPiL.lean || name == `TPiL.signature || name == `TPiL.savedAnchor\n | _ => pure false\n\n\n/--\nElaborates Lean blocks first, maintaining the order of blocks. This makes their code available for `leanRef`.\n-/\n@[directive_expander leanFirst]\ndef leanFirst : DirectiveExpander\n | args, contents => do\n ArgParse.done.run args\n\n -- Elaborate Lean blocks first, so inlines in prior blocks can refer to them\n prioritizedElab (isLeanBlock ·) elabBlock contents\n\n\n@[code_block_expander setup]\ndef setupCode : CodeBlockExpander\n | args, code => do\n ArgParse.done.run args\n let helper ← Helper.fromModule code.getString\n modifyEnv fun env => defaultHelperExt.setState env (some helper)\n return #[]\n\n@[directive_expander comment]\ndef comment : DirectiveExpander\n | _, _ => pure #[]\n\n@[directive_expander TODO]\ndef TODO : DirectiveExpander\n | _, _ => pure #[]\n\n@[role_expander TODO]\ndef TODOinline : RoleExpander\n | _, _ => pure #[]\n\n@[role_expander kw]\ndef kw : RoleExpander\n | args, inls => do\n ArgParse.done.run args\n let kw ← oneCodeStr inls\n let hl : Highlighted := .token ⟨.keyword none none none, kw.getString⟩ -- TODO kw xref\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote kw.getString)])]\n\n@[role_expander attr]\ndef attr : RoleExpander\n | args, inls => do\n ArgParse.done.run args\n let kw ← oneCodeStr inls\n let hl : Highlighted := .token ⟨.keyword none none none, kw.getString⟩ -- TODO attr xref\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote kw.getString)])]\n\n\n@[role_expander tactic]\ndef tactic : RoleExpander\n | args, inls => do\n ArgParse.done.run args\n let kw ← oneCodeStr inls\n let hl : Highlighted := .token ⟨.keyword none none none, kw.getString⟩ -- TODO kw xref\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote kw.getString)])]\n\n@[role_expander kbd]\ndef kbd : RoleExpander\n | args, inls => do\n ArgParse.done.run args\n let kbd ← codeStrs inls\n return #[← ``(Inline.other (Inline.kbd $(quote <| kbd.map (·.getString))) #[])]\n\n@[role_expander option]\ndef option : RoleExpander\n | args, inls => do\n ArgParse.done.run args\n let kw ← oneCodeStr inls\n return #[← ``(Inline.code $(quote kw.getString))]\n\n\ndef currentHelper : DocElabM Helper := do\n if let some h := helperExt.getState (← getEnv) then pure h\n else if let some h := defaultHelperExt.getState (← getEnv) then pure h\n else\n let helper ← Helper.fromModule s!\"-- EMPTY for {← getMainModule}\\n\"\n modifyEnv fun env => defaultHelperExt.setState env (some helper)\n pure helper\n\ndef multiVar? (str : String) : Option (Array String × String) := do\n let mut out := #[]\n let mut str := str.trimAscii\n repeat\n let pref1 := str.takeWhile alpha\n let length1 := pref1.positions.count\n if length1 < 1 then failure\n str := str.drop length1\n let pref2 := str.takeWhile (fun c => alpha c || c.isDigit)\n let length2 := pref2.positions.count\n str := str.drop length2\n let pref := pref1.copy ++ pref2.copy\n let c := str.startPos.get?\n if pref.length > 0 && (c.isEqSome ' ' || c.isEqSome ':') then\n out := out.push pref\n str := str.dropWhile (· == ' ')\n else failure\n\n if str.startPos.get? |>.isEqSome ':' then\n str := str.drop 1\n str := str.dropWhile (· == ' ')\n if str.isEmpty then failure\n return (out, str.copy)\n failure\nwhere\n alpha c := c.isAlpha || c ∈ ['α', 'β', 'γ']\n\ndef highlightInline (code : String) (type? : Option String := none) : DocElabM Highlighted := do\n let helper ← currentHelper\n try\n if type?.isSome then throwError \"failed\"\n let some (vars, type) := multiVar? code\n | throwError \"failed\"\n let mut out : Highlighted := .empty\n for v in vars do\n out := out ++ (← helper.highlight v (some type)) ++ .text \" \"\n out := out ++ .text \": \"\n out := out ++ (← helper.highlight type none)\n pure out\n catch e1 =>\n try\n let codeStr := \"(\\n\" ++ code ++ \"\\n)\"\n let hl ← helper.highlight codeStr type?\n pure (hl.lines.extract 1 (hl.lines.size - 1) |> Highlighted.seq)\n catch e2 =>\n throwError \"Failed to highlight code. Errors:{indentD e1.toMessageData}\\nand:{indentD e2.toMessageData}\"\n\ndef highlightCommand (code : String) : DocElabM Highlighted := do\n let helper ← currentHelper\n helper.command code\n\ndef highlightSignature (code : String) : DocElabM Highlighted := do\n let helper ← currentHelper\n helper.signature code\n\ndef highlightName (code : String) : DocElabM Highlighted := do\n let helper ← currentHelper\n helper.name code\n\n@[role_expander lean]\ndef leanInline : RoleExpander\n | args, inls => do\n let type? ← ArgParse.run (.named `type .string true) args\n let code ← oneCodeStr inls\n let codeStr := code.getString\n\n try\n let hl ← highlightInline codeStr type?\n\n saveBackref hl\n\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote hl.toString)])]\n catch\n | .error refStx e =>\n logErrorAt refStx e\n return #[← ``(sorry)]\n | e => throw e\n\n@[role_expander name]\ndef name : RoleExpander\n | args, inls => do\n let show? ← ArgParse.run (.named `show .string true) args\n let code ← oneCodeStr inls\n let codeStr := code.getString\n\n try\n let hl ← highlightName codeStr\n let hl :=\n if let some s := show? then\n if let .token ⟨k, _⟩ := hl then\n .token ⟨k, s⟩\n else hl\n else hl\n\n saveBackref hl\n match hl with\n | .token ⟨k, _⟩ =>\n match k with\n | .const _ sig doc? _ =>\n Hover.addCustomHover code <|\n s!\"```\\n{sig}\\n```\\n\" ++\n (doc?.map (\"\\n\\n***\\n\\n\" ++ ·) |>.getD \"\")\n | .var _ sig =>\n Hover.addCustomHover code <|\n s!\"```\\n{sig}\\n```\\n\"\n | _ => pure ()\n | _ => pure ()\n\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote hl.toString)])]\n catch\n | .error refStx e =>\n logErrorAt refStx e\n return #[← ``(sorry)]\n | e => throw e\n\n\n@[role_expander leanCommand]\ndef leanCommand : RoleExpander\n | args, inls => do\n let type? ← ArgParse.done.run args\n let code ← oneCodeStr inls\n let codeStr := code.getString\n\n try\n let hl ← highlightCommand codeStr\n\n saveBackref hl\n for (msg, _) in allInfo hl do\n let k := match msg.severity with | .info => \"info\" | .error => \"error\" | .warning => \"warning\"\n logSilentInfo m!\"{k}: {msg.toString}\"\n\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote hl.toString)])]\n catch\n | .error refStx e =>\n logErrorAt refStx e\n return #[← ``(sorry)]\n | e => throw e\n\n\n@[code_block_expander leanCommand]\ndef leanCommandBlock : CodeBlockExpander\n | args, code => do\n let type? ← ArgParse.done.run args\n let codeStr := code.getString\n\n try\n let hl ← highlightCommand codeStr\n\n saveBackref hl\n for (msg, _) in allInfo hl do\n let k := match msg.severity with | .info => \"info\" | .error => \"error\" | .warning => \"warning\"\n logSilentInfo m!\"{k}: {msg.toString}\"\n\n return #[← ``(Block.other (Block.lean false none #[ExampleItem.mk $(quote hl) none \"\"] none) #[])]\n catch\n | .error refStx e =>\n logErrorAt refStx e\n return #[← ``(sorry)]\n | e => throw e\n\n\n@[code_block_expander signature]\ndef signature : CodeBlockExpander\n | args, code => do\n let type? ← ArgParse.done.run args\n let codeStr := code.getString\n\n try\n let hl ← highlightSignature codeStr\n\n saveBackref hl\n for (msg, _) in allInfo hl do\n let k := match msg.severity with | .info => \"info\" | .error => \"error\" | .warning => \"warning\"\n logSilentInfo m!\"{k}: {msg.toString}\"\n\n return #[← ``(Block.other (Block.lean false none #[ExampleItem.mk $(quote hl) none \"\"] none) #[])]\n catch\n | .error refStx e =>\n logErrorAt refStx e\n return #[← ``(sorry)]\n | e => throw e\n\n\n@[role_expander leanRef]\ndef leanRef : RoleExpander\n | args, inls => do\n let in? ← ArgParse.run (.named `in .string true) args\n let code ← oneCodeStr inls\n let codeStr := code.getString\n\n for prev in recentHighlightsExt.getState (← getEnv) do\n if let some «in» := in? then\n if let some hl := prev.matchingExpr? «in» then\n if let some hl := hl.matchingExpr? codeStr then\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote hl.toString)])]\n else break\n else if let some hl := prev.matchingExpr? codeStr then\n return #[← ``(Inline.other (Inline.lean $(quote hl) {}) #[Inline.code $(quote hl.toString)])]\n\n throwError \"Not found: '{codeStr}'\"\n\n@[role_expander empty]\ndef empty : RoleExpander\n | args, _inls => do\n ArgParse.done.run args\n return #[]\n\nprivate def keywords := [\n \"#print\", \"#eval\", \"#print axioms\", \"#reduce\", \"#check\",\n \"noncomputable\", \"protected\", \"partial\",\n \"import\", \"export\", \"local\",\n \"def\", \"example\", \"instance\", \"macro_rules\", \"axiom\", \"if\", \"then\", \"else\", \"show\", \"have\", \"calc\",\n \"universe\", \"section\", \"end\", \"variable\", \"open\", \"set_option\",\n \"let\", \"fun\"\n]\n\nprivate def tactics := [\n \"if\", \"then\", \"else\", \"show\", \"have\", \"calc\", \"simp\", \"rw\",\n \"let\", \"fun\", \"<;>\"\n]\n\n\nprivate def leanLits := [\n \"→\", \"->\", \";\", \"×\", \".\", \"_\", \"⟨\", \"⟩\"\n]\n\n\nopen MessageData (hint) in\n/--\nInternal detail of suggestion mechanism.\n-/\n@[inline_expander Lean.Doc.Syntax.code]\nprivate def suggest : InlineExpander\n | `(inline| code( $str )) => do\n let str' := str.getString\n\n -- unless verso.examples.suggest.get (← getOptions) do\n -- -- Delegate to the next handler\n -- Elab.throwUnsupportedSyntax\n if str' ∈ keywords then\n let h ← hint m!\"Add the `kw` role:\" #[\"{kw}`\" ++ str' ++ \"`\"]\n logWarning <| m!\"Code element could be a keyword.\" ++ h\n else if str'.startsWith \"\\\\\" then\n let h ← hint m!\"Add the `kbd` role:\" #[\"{kbd}`\" ++ str' ++ \"`\"]\n logWarning <| m!\"Code element could be a Unicode abbreviation.\" ++ h\n else if (← getOptionDecls).any (fun x _ => x.toString == str'.trimAscii) then\n let h ← hint m!\"Add the `option` role:\" #[\"{option}`\" ++ str' ++ \"`\"]\n logWarning <| m!\"Code element could be a compiler option.\" ++ h\n else\n let mut suggs : Array Meta.Hint.Suggestion := #[]\n let mut exns := #[]\n try\n let _ ← highlightInline str'\n suggs := suggs.push <| \"{lean}`\" ++ str' ++ \"`\"\n catch e =>\n exns := exns.push e\n if str' ∈ tactics then\n suggs := suggs.push <| \"{tactic}`\" ++ str' ++ \"`\"\n\n for prev in recentHighlightsExt.getState (← getEnv) do\n if let some _ := prev.matchingExpr? str' then\n suggs := suggs.push <| \"{leanRef}`\" ++ str' ++ \"`\"\n break\n if str' ∈ leanLits then\n suggs := suggs.push <| \"{lit}`\" ++ str' ++ \"`\"\n\n for (name, {goals := gs, ..}) in proofStatesExt.getState (← getEnv) do\n let name := if name.any (·.isWhitespace) then name.quote else name\n if gs.any (·.name |>.isEqSome str') then\n suggs := suggs.push <| \"{goal \" ++ name ++ \"}`\" ++ str' ++ \"`\"\n\n if suggs.isEmpty then\n let h ← hint m!\"Add the `lit` role to indicate that it denotes literal characters:\" #[\"{lit}`\" ++ str' ++ \"`\"]\n logWarning <| m!\"Code element is missing a role, and can't be Lean code:{m!\"\\nand\\n\".joinSep (exns.map (indentD ·.toMessageData) |>.toList)}\" ++ h\n else\n let h ← hint m!\"Add a `lean` role:\" suggs\n logWarning <| m!\"Code element could be highlighted.\" ++ h\n\n\n return (← ``(Inline.code $(quote str.getString)))\n | _ => Elab.throwUnsupportedSyntax\n"
},
{
"path": "book/TPiL/InductionAndRecursion.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre\nopen Verso.Genre.Manual hiding tactic\nopen TPiL\n\n#doc (Manual) \"Induction and Recursion\" =>\n%%%\ntag := \"induction-and-recursion\"\n%%%\n\nIn the previous chapter, we saw that inductive definitions provide a\npowerful means of introducing new types in Lean. Moreover, the\nconstructors and the recursors provide the only means of defining\nfunctions on these types. By the {tech}[propositions-as-types] correspondence,\nthis means that induction is the fundamental method of proof.\n\nLean provides natural ways of defining recursive functions, performing\npattern matching, and writing inductive proofs. It allows you to\ndefine a function by specifying equations that it should satisfy, and\nit allows you to prove a theorem by specifying how to handle various\ncases that can arise. Behind the scenes, these descriptions are\n“compiled” down to primitive recursors, using a procedure that we\nrefer to as the “equation compiler.” The equation compiler is not part\nof the trusted code base; its output consists of terms that are\nchecked independently by the kernel.\n\n# Pattern Matching\n%%%\ntag := \"pattern-matching\"\n%%%\n\nThe interpretation of schematic patterns is the first step of the\ncompilation process. We have seen that the {lit}`casesOn` recursor can\nbe used to define functions and prove theorems by cases, according to\nthe constructors involved in an inductively defined type. But\ncomplicated definitions may use several nested {lit}`casesOn`\napplications, and may be hard to read and understand. Pattern matching\nprovides an approach that is more convenient, and familiar to users of\nfunctional programming languages.\n\n:::setup\n```\nopen Nat\nvariable (x : Nat)\n```\n\nConsider the inductively defined type of natural numbers. Every\nnatural number is either {lean}`zero` or {lean}`succ x`, and so you can define\na function from the natural numbers to an arbitrary type by specifying\na value in each of those cases:\n:::\n\n```lean\nset_option linter.unusedVariables false\n--------\nopen Nat\n\ndef sub1 : Nat → Nat\n | zero => zero\n | succ x => x\n\ndef isZero : Nat → Bool\n | zero => true\n | succ x => false\n```\n\nThe equations used to define these functions hold definitionally:\n\n```lean\nopen Nat\ndef sub1 : Nat → Nat\n | zero => zero\n | succ x => x\ndef isZero : Nat → Bool\n | zero => true\n | succ x => false\n------\nexample : sub1 0 = 0 := rfl\nexample (x : Nat) : sub1 (succ x) = x := rfl\n\nexample : isZero 0 = true := rfl\nexample (x : Nat) : isZero (succ x) = false := rfl\n\nexample : sub1 7 = 6 := rfl\nexample (x : Nat) : isZero (x + 3) = false := rfl\n```\n\nInstead of {leanRef}`zero` and {leanRef}`succ`, we can use more familiar notation:\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef sub1 : Nat → Nat\n | 0 => 0\n | x + 1 => x\n\ndef isZero : Nat → Bool\n | 0 => true\n | x + 1 => false\n```\n\nBecause addition and the zero notation have been assigned the\n{attr}`[match_pattern]` attribute, they can be used in pattern matching. Lean\nsimply normalizes these expressions until the constructors {leanRef}`zero`\nand {leanRef}`succ` are exposed.\n\nPattern matching works with any inductive type, such as products and option types:\n\n```lean\ndef swap : α × β → β × α\n | (a, b) => (b, a)\n\ndef foo : Nat × Nat → Nat\n | (m, n) => m + n\n\ndef bar : Option Nat → Nat\n | some n => n + 1\n | none => 0\n```\n\nHere we use it not only to define a function, but also to carry out a\nproof by cases:\n\n```lean\nnamespace Hidden\n------\ndef not : Bool → Bool\n | true => false\n | false => true\n\ntheorem not_not : ∀ (b : Bool), not (not b) = b\n | true => show not (not true) = true from rfl\n | false => show not (not false) = false from rfl\n------\nend Hidden\n```\n\nPattern matching can also be used to destruct inductively defined propositions:\n\n```lean\nexample (p q : Prop) : p ∧ q → q ∧ p\n | And.intro h₁ h₂ => And.intro h₂ h₁\n\nexample (p q : Prop) : p ∨ q → q ∨ p\n | Or.inl hp => Or.inr hp\n | Or.inr hq => Or.inl hq\n```\n\nThis provides a compact way of unpacking hypotheses that make use of logical connectives.\n\nIn all these examples, pattern matching was used to carry out a single\ncase distinction. More interestingly, patterns can involve nested\nconstructors, as in the following examples.\n\n```lean\ndef sub2 : Nat → Nat\n | 0 => 0\n | 1 => 0\n | x + 2 => x\n```\n\nThe equation compiler first splits on cases as to whether the input is\n{leanRef}`zero` or of the form {leanRef}`succ x`. It then does a case split on\nwhether {leanRef}`x` is of the form {leanRef}`zero` or {leanRef}`succ x`. It determines\nthe necessary case splits from the patterns that are presented to it,\nand raises an error if the patterns fail to exhaust the cases. Once\nagain, we can use arithmetic notation, as in the version below. In\neither case, the defining equations hold definitionally.\n\n```lean\ndef sub2 : Nat → Nat\n | 0 => 0\n | 1 => 0\n | x+2 => x\n------\nexample : sub2 0 = 0 := rfl\nexample : sub2 1 = 0 := rfl\nexample : sub2 (x+2) = x := rfl\n\nexample : sub2 5 = 3 := rfl\n```\n\n:::setup\n```\ndef sub2 : Nat → Nat\n | 0 => 0\n | 1 => 0\n | x + 2 => x\n```\nYou can write {leanCommand}`#print sub2` to see how the function was compiled to\nrecursors. (Lean will tell you that {leanRef}`sub2` has been defined in terms\nof an internal auxiliary function, {lean}`sub2.match_1`, but you can print\nthat out too.) Lean uses these auxiliary functions to compile {kw}`match` expressions.\nActually, the definition above is expanded to\n:::\n```lean\ndef sub2 : Nat → Nat :=\n fun x =>\n match x with\n | 0 => 0\n | 1 => 0\n | x + 2 => x\n```\n\nHere are some more examples of nested pattern matching:\n\n```lean\nset_option linter.unusedVariables false\n--------\nexample (p q : α → Prop) :\n (∃ x, p x ∨ q x) →\n (∃ x, p x) ∨ (∃ x, q x)\n | Exists.intro x (Or.inl px) => Or.inl (Exists.intro x px)\n | Exists.intro x (Or.inr qx) => Or.inr (Exists.intro x qx)\n\ndef foo : Nat × Nat → Nat\n | (0, n) => 0\n | (m+1, 0) => 1\n | (m+1, n+1) => 2\n```\n\nThe equation compiler can process multiple arguments sequentially. For\nexample, it would be more natural to define the previous example as a\nfunction of two arguments:\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef foo : Nat → Nat → Nat\n | 0, n => 0\n | m + 1, 0 => 1\n | m + 1, n + 1 => 2\n```\n\nHere is another example:\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef bar : List Nat → List Nat → Nat\n | [], [] => 0\n | a :: as, [] => a\n | [], b :: bs => b\n | a :: as, b :: bs => a + b\n```\n\nNote that the patterns are separated by commas.\n\nIn each of the following examples, splitting occurs on only the first\nargument, even though the others are included among the list of\npatterns.\n\n```lean\nset_option linter.unusedVariables false\nnamespace Hidden\n------\ndef and : Bool → Bool → Bool\n | true, a => a\n | false, _ => false\n\ndef or : Bool → Bool → Bool\n | true, _ => true\n | false, a => a\n\ndef cond : Bool → α → α → α\n | true, x, y => x\n | false, x, y => y\n------\nend Hidden\n```\n\nNotice also that, when the value of an argument is not needed in the\ndefinition, you can use an underscore instead. This underscore is\nknown as a _wildcard pattern_, or an _anonymous variable_. In contrast\nto usage outside the equation compiler, here the underscore does _not_\nindicate an implicit argument. The use of underscores for wildcards is\ncommon in functional programming languages, and so Lean adopts that\nnotation. The section on {ref \"wildcards-and-overlapping-patterns\"}[wildcards and overlapping patterns]\nexpands on the notion of a wildcard, and the description of {ref \"inaccessible-patterns\"}[inaccessible patterns] explains how\nyou can use implicit arguments in patterns as well.\n\n::::setup\n```\nset_option linter.unusedVariables false\n--------\ndef tail : List α → List α\n | [] => []\n | a :: as => as\n```\n\n:::leanFirst\nAs described in {ref \"inductive-types\"}[Inductive Types],\ninductive data types can depend on parameters. The following example defines\nthe {name}`tail` function using pattern matching. The argument {leanRef}`α : Type u`\nis a parameter and occurs before the colon to indicate it does not participate in the pattern matching.\nLean also allows parameters to occur after the {leanRef}`:`, but pattern matching on them requires an explicit {leanRef}`match`.\n\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef tail1 {α : Type u} : List α → List α\n | [] => []\n | a :: as => as\n\ndef tail2 : {α : Type u} → List α → List α\n | α, [] => []\n | α, a :: as => as\n```\n:::\n::::\n\nDespite the different placement of the parameter {leanRef}`α` in these two\nexamples, in both cases it is treated in the same way, in that it does\nnot participate in a case split.\n\nLean can also handle more complex forms of pattern matching, in which\narguments to dependent types pose additional constraints on the\nvarious cases. Such examples of _dependent pattern matching_ are\nconsidered in the section on {ref \"dependent-pattern-matching\"}[dependent pattern matching].\n\n# Wildcards and Overlapping Patterns\n%%%\ntag := \"wildcards-and-overlapping-patterns\"\n%%%\n\nConsider one of the examples from the last section:\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef foo : Nat → Nat → Nat\n | 0, n => 0\n | m + 1, 0 => 1\n | m + 1, n + 1 => 2\n```\n\nAn alternative presentation is:\n\n```lean\nset_option linter.unusedVariables false\n--------\ndef foo : Nat → Nat → Nat\n | 0, n => 0\n | m, 0 => 1\n | m, n => 2\n```\n\nIn the second presentation, the patterns overlap; for example, the\npair of arguments {lit}`0, 0` matches all three cases. But Lean handles\nthe ambiguity by using the first applicable equation, so in this example\nthe net result is the same. In particular, the following equations hold\ndefinitionally:\n\n```lean\ndef foo : Nat → Nat → Nat\n | 0, n => 0\n | m, 0 => 1\n | m, n => 2\n------\nexample : foo 0 0 = 0 := rfl\nexample : foo 0 (n + 1) = 0 := rfl\nexample : foo (m + 1) 0 = 1 := rfl\nexample : foo (m + 1) (n + 1) = 2 := rfl\n```\n\nSince the values of {leanRef (in:=\"m, n\")}`m` and {leanRef (in:=\"m, n\")}`n` are not needed, we can just as well use wildcard patterns instead.\n\n```lean\ndef foo : Nat → Nat → Nat\n | 0, _ => 0\n | _, 0 => 1\n | _, _ => 2\n```\n\nYou can check that this definition of {leanRef}`foo` satisfies the same\ndefinitional identities as before.\n\n:::setup\n```\nvariable (α : Type u) (a : α)\n```\n\nSome functional programming languages support _incomplete\npatterns_. In these languages, the interpreter produces an exception\nor returns an arbitrary value for incomplete cases. We can simulate\nthe arbitrary value approach using the {lean}`Inhabited` type\nclass. Roughly, an element of {lean}`Inhabited α` is a witness to the fact\nthat there is an element of {lean}`α`; in {ref \"type-classes\"}[the chapter on type classes]\nwe will see that Lean can be instructed that suitable\nbase types are inhabited, and can automatically infer that other\nconstructed types are inhabited. On this basis, the\nstandard library provides a default element, {lean}`default`, of\nany inhabited type.\n\nWe can also use the type {lean}`Option α` to simulate incomplete patterns.\nThe idea is to return {lean}`some a` for the provided patterns, and use\n{lean (type:=\"Option α\")}`none` for the incomplete cases. The following example demonstrates\nboth approaches.\n:::\n\n```lean\ndef f1 : Nat → Nat → Nat\n | 0, _ => 1\n | _, 0 => 2\n | _, _ => default -- the \"incomplete\" case\n\nexample : f1 0 0 = 1 := rfl\nexample : f1 0 (a+1) = 1 := rfl\nexample : f1 (a+1) 0 = 2 := rfl\nexample : f1 (a+1) (b+1) = default := rfl\n\ndef f2 : Nat → Nat → Option Nat\n | 0, _ => some 1\n | _, 0 => some 2\n | _, _ => none -- the \"incomplete\" case\n\nexample : f2 0 0 = some 1 := rfl\nexample : f2 0 (a+1) = some 1 := rfl\nexample : f2 (a+1) 0 = some 2 := rfl\nexample : f2 (a+1) (b+1) = none := rfl\n```\n\nThe equation compiler is clever. If you leave out any of the cases in\nthe following definition, the error message will let you know what has\nnot been covered.\n\n```lean\ndef bar : Nat → List Nat → Bool → Nat\n | 0, _, false => 0\n | 0, b :: _, _ => b\n | 0, [], true => 7\n | a+1, [], false => a\n | a+1, [], true => a + 1\n | a+1, b :: _, _ => a + b\n```\n\nIt will also use an {kw}`if`{lit}` ... `{kw}`then`{lit}` ... `{kw}`else` instead of a {lit}`casesOn` in appropriate situations.\n\n```lean\nset_option pp.proofs true\n-------\ndef foo : Char → Nat\n | 'A' => 1\n | 'B' => 2\n | _ => 3\n\n#print foo.match_1\n```\n\n# Structural Recursion and Induction\n%%%\ntag := \"structural-recursion-and-induction\"\n%%%\n\nWhat makes the equation compiler powerful is that it also supports\nrecursive definitions. In the next three sections, we will describe,\nrespectively:\n\n- structurally recursive definitions\n- well-founded recursive definitions\n- mutually recursive definitions\n\nGenerally speaking, the equation compiler processes input of the following form:\n\n```\ndef foo (a : α) : (b : β) → γ\n | [patterns₁] => t₁\n ...\n | [patternsₙ] => tₙ\n```\n\nHere {lit}`(a : α)` is a sequence of parameters, {lit}`(b : β)` is the\nsequence of arguments on which pattern matching takes place, and {lit}`γ`\nis any type, which can depend on {lit}`a` and {lit}`b`. Each line should\ncontain the same number of patterns, one for each element of {lit}`β`. As we\nhave seen, a pattern is either a variable, a constructor applied to\nother patterns, or an expression that normalizes to something of that\nform (where the non-constructors are marked with the {attr}`[match_pattern]`\nattribute). The appearances of constructors prompt case splits, with\nthe arguments to the constructors represented by the given\nvariables. In the section on {ref \"dependent-pattern-matching\"}[dependent pattern matching],\nwe will see that some explicit terms in patterns are forced into a particular form\nin order to make an expression type check, though they do not play a\nrole in pattern matching. These are called “{deftech}[inaccessible patterns]” for\nthat reason. But we will not need to use such inaccessible patterns\nbefore covering {ref \"dependent-pattern-matching\"}[dependent pattern matching].\n\nAs we saw in the last section, the terms {lit}`t₁, ..., tₙ` can make use\nof any of the parameters {lit}`a`, as well as any of the variables that\nare introduced in the corresponding patterns. What makes recursion and\ninduction possible is that they can also involve recursive calls to\n{lit}`foo`. In this section, we will deal with _structural recursion_, in\nwhich the arguments to {lit}`foo` occurring on the right-hand side of the\n{lit}`=>` are subterms of the patterns on the left-hand side. The idea is\nthat they are structurally smaller, and hence appear in the inductive\ntype at an earlier stage. Here are some examples of structural\nrecursion from the last chapter, now defined using the equation\ncompiler:\n\n```lean\nopen Nat\ndef add : Nat → Nat → Nat\n | m, zero => m\n | m, succ n => succ (add m n)\n\ntheorem add_zero (m : Nat) : add m zero = m := rfl\ntheorem add_succ (m n : Nat) : add m (succ n) = succ (add m n) := rfl\n\ntheorem zero_add : ∀ n, add zero n = n\n | zero => rfl\n | succ n => congrArg succ (zero_add n)\n\ndef mul : Nat → Nat → Nat\n | n, zero => zero\n | n, succ m => add (mul n m) n\n```\n\nThe proof of {leanRef}`zero_add` makes it clear that proof by induction is\nreally a form of recursion in Lean.\n\nThe example above shows that the defining equations for {leanRef}`add` hold\ndefinitionally, and the same is true of {leanRef}`mul`. The equation compiler\ntries to ensure that this holds whenever possible, as is the case with\nstraightforward structural induction. In other situations, however,\nreductions hold only _propositionally_, which is to say, they are\nequational theorems that must be applied explicitly. The equation\ncompiler generates such theorems internally. They are not meant to be\nused directly by the user; rather, the {tactic}`simp` tactic\nis configured to use them when necessary. The following\nproof of {leanRef}`zero_add` works this way:\n\n```lean\nopen Nat\ndef add : Nat → Nat → Nat\n | m, zero => m\n | m, succ n => succ (add m n)\n-----\ntheorem zero_add : ∀ n, add zero n = n\n | zero => by simp [add]\n | succ n => by simp [add, zero_add]\n```\n\nAs with definition by pattern matching, parameters to a structural\nrecursion or induction may appear before the colon. Such parameters\nare simply added to the local context before the definition is\nprocessed. For example, the definition of addition may also be written\nas follows:\n\n```lean\nopen Nat\ndef add (m : Nat) : Nat → Nat\n | zero => m\n | succ n => succ (add m n)\n```\n\nYou can also write the example above using {kw}`match`.\n\n```lean\nopen Nat\ndef add (m n : Nat) : Nat :=\n match n with\n | zero => m\n | succ n => succ (add m n)\n```\n\n:::leanFirst\nA more interesting example of structural recursion is given by the Fibonacci function {leanRef}`fib`.\n\n```lean\ndef fib : Nat → Nat\n | 0 => 1\n | 1 => 1\n | n+2 => fib (n+1) + fib n\n\nexample : fib 0 = 1 := rfl\n\nexample : fib 1 = 1 := rfl\n\nexample : fib (n + 2) = fib (n + 1) + fib n := rfl\n\nexample : fib 7 = 21 := rfl\n```\n:::\n:::setup\n```\nvariable (n : Nat)\nopen Nat\n```\n\nHere, the value of the {leanRef}`fib` function at {leanRef}`n + 2` (which is\ndefinitionally equal to {lean}`succ (succ n)`) is defined in terms of the\nvalues at {leanRef}`n + 1` (which is definitionally equivalent to {lean}`succ n`)\nand the value at {leanRef}`n`. This is a notoriously inefficient way of\ncomputing the Fibonacci function, however, with an execution time that\nis exponential in {lean}`n`. Here is a better way:\n:::\n\n```lean\ndef fibFast (n : Nat) : Nat :=\n (loop n).2\nwhere\n loop : Nat → Nat × Nat\n | 0 => (0, 1)\n | n+1 => let p := loop n; (p.2, p.1 + p.2)\n\n#eval fibFast 100 -- 573147844013817084101\n```\n\nHere is the same definition using a {kw}`let rec` instead of a {kw}`where`.\n\n```lean\ndef fibFast (n : Nat) : Nat :=\n let rec loop : Nat → Nat × Nat\n | 0 => (0, 1)\n | n+1 => let p := loop n; (p.2, p.1 + p.2)\n (loop n).2\n```\n\nIn both cases, Lean generates the auxiliary function {lit}`fibFast.loop`.\n\n:::leanFirst\nTo handle structural recursion, the equation compiler uses\n_course-of-values_ recursion, using constants {lit}`below` and {lit}`brecOn`\nthat are automatically generated with each inductively defined\ntype. You can get a sense of how it works by looking at the types of\n{leanRef}`Nat.below` and {leanRef}`Nat.brecOn`:\n\n```lean\nvariable (C : Nat → Type u)\n\n#check (@Nat.below C : Nat → Type u)\n\n#reduce @Nat.below C (3 : Nat)\n\n#check (@Nat.brecOn C : (n : Nat) → ((n : Nat) → @Nat.below C n → C n) → C n)\n```\n:::\n:::setup\n```\nvariable (C : Nat → Type u) (n : Nat)\n```\nThe type {lean}`@Nat.below C (3 : Nat)` is a data structure that stores elements of {lean}`C 0`, {lean}`C 1`, and {lean}`C 2`.\nThe course-of-values recursion is implemented by {name}`Nat.brecOn`. It enables us to define the value of a dependent\nfunction of type {lean}`(n : Nat) → C n` at a particular input {lean}`n` in terms of all the previous values of the function,\npresented as an element of {lean}`@Nat.below C n`.\n:::\n\n:::leanFirst\nThe use of course-of-values recursion is one of the techniques the equation compiler uses to justify to\nthe Lean kernel that a function terminates. It does not affect the code generator which compiles recursive\nfunctions as other functional programming language compilers. Recall that {kw}`#eval`{lit}` ` {leanRef}`fib`{lit}` ` is exponential in {lit}``.\nOn the other hand, {kw}`#reduce`{lit}` `{leanRef}`fib`{lit}` ` is efficient because it uses the definition sent to the kernel that\nis based on the {lit}`brecOn` construction.\n\n```lean\ndef fib : Nat → Nat\n | 0 => 1\n | 1 => 1\n | n+2 => fib (n+1) + fib n\n\n-- Slow:\n-- #eval fib 50\n-- Fast:\n#reduce fib 50\n\n#print fib\n```\n:::\n\n:::leanFirst\nAnother good example of a recursive definition is the list {leanRef}`append` function.\n\n```lean\ndef append : List α → List α → List α\n | [], bs => bs\n | a::as, bs => a :: append as bs\n\nexample : append [1, 2, 3] [4, 5] = [1, 2, 3, 4, 5] := rfl\n```\n:::\n\nHere is another: it adds elements of the first list to elements of the second list, until one of the two lists runs out.\n\n```lean\ndef listAdd [Add α] : List α → List α → List α\n | [], _ => []\n | _, [] => []\n | a :: as, b :: bs => (a + b) :: listAdd as bs\n\n#eval listAdd [1, 2, 3] [4, 5, 6, 6, 9, 10] -- [5, 7, 9]\n```\n\nYou are encouraged to experiment with similar examples in the exercises below.\n\n# Local recursive declarations\n%%%\ntag := \"local-recursive-declarations\"\n%%%\n\nYou can define local recursive declarations using the {kw}`let rec` keyword.\n\n```lean\ndef replicate (n : Nat) (a : α) : List α :=\n let rec loop : Nat → List α → List α\n | 0, as => as\n | n+1, as => loop n (a::as)\n loop n []\n\n#check @replicate.loop -- @replicate.loop : {α : Type u_1} → α → Nat → List α → List α\n```\n\nLean creates an auxiliary declaration for each {leanRef}`let rec`. In the example above,\nit created the declaration {leanRef}`replicate.loop` for the {leanRef}`let rec loop` occurring at {leanRef}`replicate`.\nNote that, Lean “closes” the declaration by adding any local variable occurring in the\n{leanRef}`let rec` declaration as additional parameters. For example, the local variable {leanRef}`a` occurs\nat {leanRef}`let rec loop`.\n\n\nYou can also use {leanRef}`let rec` in tactic mode and for creating proofs by induction.\n\n```lean\ndef replicate (n : Nat) (a : α) : List α :=\n let rec loop : Nat → List α → List α\n | 0, as => as\n | n+1, as => loop n (a::as)\n loop n []\n------\ntheorem length_replicate (n : Nat) (a : α) :\n (replicate n a).length = n := by\n let rec aux (n : Nat) (as : List α) :\n (replicate.loop a n as).length = n + as.length := by\n match n with\n | 0 => simp [replicate.loop]\n | n+1 => simp +arith [replicate.loop, aux n]\n exact aux n []\n```\n\nYou can also introduce auxiliary recursive declarations using {kw}`where` clause after your definition.\nLean converts them into a {kw}`let rec`.\n\n```lean\ndef replicate (n : Nat) (a : α) : List α :=\n loop n []\nwhere\n loop : Nat → List α → List α\n | 0, as => as\n | n+1, as => loop n (a::as)\n\ntheorem length_replicate (n : Nat) (a : α) :\n (replicate n a).length = n := by\n exact aux n []\nwhere\n aux (n : Nat) (as : List α) :\n (replicate.loop a n as).length = n + as.length := by\n match n with\n | 0 => simp [replicate.loop]\n | n+1 => simp +arith [replicate.loop, aux n]\n```\n\n# Well-Founded Recursion and Induction\n%%%\ntag := \"well-founded-recursion-and-induction\"\n%%%\n\nWhen structural recursion cannot be used, we can prove termination using well-founded recursion.\nWe need a well-founded relation and a proof that each recursive application is decreasing with respect to\nthis relation. Dependent type theory is powerful enough to encode and justify\nwell-founded recursion. Let us start with the logical background that\nis needed to understand how it works.\n\n:::setup\n```\nvariable (α : Type u) (a : α) (r : α → α → Prop)\n```\n\nLean's standard library defines two predicates, {lean}`Acc r a` and\n{lean}`WellFounded r`, where {lean}`r` is a binary relation on a type {lean}`α`,\nand {lean}`a` is an element of type {lean}`α`.\n:::\n\n```lean\nvariable (α : Sort u)\nvariable (r : α → α → Prop)\n\n#check (Acc r : α → Prop)\n#check (WellFounded r : Prop)\n```\n\n```lean (show := false)\nvariable {α : Sort u} (x y : α)\nvariable {r : α → α → Prop}\n\nexample : Acc r x = ∀ y, r y x → Acc r y := by\n simp only [eq_iff_iff]\n constructor\n . intro ⟨_, hAcc⟩\n assumption\n . intro h\n constructor\n assumption\n\ndef r' : α → α → Prop := fun x y => True\ninfix:50 \" ≺ \" => r'\nexample : y ≺ x := True.intro\nexample := WellFounded r\n```\n\n\nThe first, {leanRef}`Acc`, is an inductively defined predicate. According to\nits definition, {leanRef}`Acc r x` is equivalent to\n{leanRef}`∀ y, r y x → Acc r y`. If you think of {leanRef}`r y x` as denoting a kind of order relation\n{leanRef}`y ≺ x`, then {leanRef}`Acc r x` says that {leanRef}`x` is accessible from below,\nin the sense that all its predecessors are accessible. In particular,\nif {leanRef}`x` has no predecessors, it is accessible. Given any type {leanRef}`α`,\nwe should be able to assign a value to each accessible element of\n{leanRef}`α`, recursively, by assigning values to all its predecessors first.\n\n\n\nThe statement that {leanRef}`r` is well-founded, denoted {leanRef}`WellFounded r`,\nis exactly the statement that every element of the type is\naccessible. By the above considerations, if {leanRef}`r` is a well-founded\nrelation on a type {leanRef}`α`, we should have a principle of well-founded\nrecursion on {leanRef}`α`, with respect to the relation {leanRef}`r`. And, indeed,\nwe do: the standard library defines {name}`WellFounded.fix`, which serves\nexactly that purpose.\n\n```lean\nnoncomputable\ndef f {α : Sort u}\n (r : α → α → Prop)\n (h : WellFounded r)\n (C : α → Sort v)\n (F : (x : α) → ((y : α) → r y x → C y) → C x) :\n (x : α) → C x :=\nWellFounded.fix h F\n```\n\nThere is a long cast of characters here, but the first block we have\nalready seen: the type, {leanRef}`α`, the relation, {leanRef}`r`, and the\nassumption, {leanRef}`h`, that {leanRef}`r` is well-founded. The variable {leanRef}`C`\nrepresents the motive of the recursive definition: for each element\n{leanRef}`x : α`, we would like to construct an element of {leanRef}`C x`. The\nfunction {leanRef}`F` provides the inductive recipe for doing that: it tells\nus how to construct an element {leanRef}`C x`, given elements of {leanRef}`C y` for\neach predecessor {leanRef}`y` of {leanRef}`x`.\n\n:::setup\n```\nvariable {x y : α} (C : α → Sort v) (r : α → α → Prop)\n\n```\n\nNote that {name}`WellFounded.fix` works equally well as an induction\nprinciple. It says that if {leanRef}`≺` is well-founded and you want to prove\n{lean}`∀ x, C x`, it suffices to show that for an arbitrary {lean}`x`, if we\nhave {lean}`∀ y, r y x → C y`, then we have {lean}`C x`.\n:::\n\nIn the example above we use the modifier {leanRef}`noncomputable` because the code\ngenerator currently does not support {name}`WellFounded.fix`. The function\n{name}`WellFounded.fix` is another tool Lean uses to justify that a function\nterminates.\n\nLean knows that the usual order {lit}`<` on the natural numbers is well\nfounded. It also knows a number of ways of constructing new well\nfounded orders from others, for example, using lexicographic order.\n\nHere is essentially the definition of division on the natural numbers that is found in the standard library.\n\n```lean\n------\nopen Nat\n\ntheorem div_lemma {x y : Nat} : 0 < y ∧ y ≤ x → x - y < x :=\n fun h => sub_lt (Nat.lt_of_lt_of_le h.left h.right) h.left\n\ndef div.F (x : Nat) (f : (x₁ : Nat) → x₁ < x → Nat → Nat) (y : Nat) : Nat :=\n if h : 0 < y ∧ y ≤ x then\n f (x - y) (div_lemma h) y + 1\n else\n zero\n\nnoncomputable def div := WellFounded.fix (measure id).wf div.F\n\n#reduce div 8 2 -- 4\n```\n\n:::TODO\nMissing HL for example\n:::\nThe definition is somewhat inscrutable. Here the recursion is on\n{leanRef (in:=\"def div.F (x\")}`x`, and {lit}`div.F x f : Nat → Nat` returns the “divide by {leanRef}`y`”\nfunction for that fixed {leanRef (in:=\"def div.F (x\")}`x`. You have to remember that the second\nargument to {leanRef}`div.F`, the recipe for the recursion, is a function\nthat is supposed to return the divide by {leanRef}`y` function for all values\n{leanRef}`x₁` smaller than {leanRef}`x`.\n\nThe elaborator is designed to make definitions like this more\nconvenient. It accepts the following:\n\n```lean\ndef div (x y : Nat) : Nat :=\n if h : 0 < y ∧ y ≤ x then\n have : x - y < x := Nat.sub_lt (Nat.lt_of_lt_of_le h.1 h.2) h.1\n div (x - y) y + 1\n else\n 0\n```\n\nWhen Lean encounters a recursive definition, it first\ntries structural recursion, and only when that fails, does it fall\nback on well-founded recursion. Lean uses the tactic {tactic}`decreasing_tactic`\nto show that the recursive applications are smaller. The auxiliary\nproposition {leanRef}`x - y < x` in the example above should be viewed as a hint\nfor this tactic.\n\nThe defining equation for {leanRef}`div` does _not_ hold definitionally, but\nwe can unfold {leanRef}`div` using the {tactic}`unfold` tactic. We use {ref \"conv\"}[{tactic}`conv`] to select which\n{leanRef}`div` application we want to unfold.\n\n```lean\ndef div (x y : Nat) : Nat :=\n if h : 0 < y ∧ y ≤ x then\n have : x - y < x := Nat.sub_lt (Nat.lt_of_lt_of_le h.1 h.2) h.1\n div (x - y) y + 1\n else\n 0\n------\nexample (x y : Nat) :\n div x y =\n if 0 < y ∧ y ≤ x then\n div (x - y) y + 1\n else 0 := by\n -- unfold occurrence in the left-hand-side of the equation:\n conv => lhs; unfold div\n rfl\n\nexample (x y : Nat) (h : 0 < y ∧ y ≤ x) :\n div x y = div (x - y) y + 1 := by\n conv => lhs; unfold div\n simp [h]\n```\n\n:::leanFirst\nThe following example is similar: it converts any natural number to a\nbinary expression, represented as a list of 0's and 1's. We have to\nprovide evidence that the recursive call is\ndecreasing, which we do here with a {leanRef}`sorry`. The {leanRef}`sorry` does not\nprevent the interpreter from evaluating the function successfully,\nbut {leanRef}`#eval!` must be used instead of {kw}`#eval` when a term contains {leanRef}`sorry`.\n\n```lean\ndef natToBin : Nat → List Nat\n | 0 => [0]\n | 1 => [1]\n | n + 2 =>\n have : (n + 2) / 2 < n + 2 := sorry\n natToBin ((n + 2) / 2) ++ [n % 2]\n\n#eval! natToBin 1234567\n```\n:::\n\n:::leanFirst\nAs a final example, we observe that Ackermann's function can be\ndefined directly, because it is justified by the well-foundedness of\nthe lexicographic order on the natural numbers. The {leanRef}`termination_by` clause\ninstructs Lean to use a lexicographic order. This clause is actually mapping\nthe function arguments to elements of type {lean}`Nat × Nat`. Then, Lean uses typeclass\nresolution to synthesize an element of type {lean}`WellFoundedRelation (Nat × Nat)`.\n\n```lean\ndef ack : Nat → Nat → Nat\n | 0, y => y+1\n | x+1, 0 => ack x 1\n | x+1, y+1 => ack x (ack (x+1) y)\ntermination_by x y => (x, y)\n```\n:::\n\nIn many cases, Lean can automatically determine an appropriate lexicographical order.\nAckermann's function is one such case, so the {leanRef}`termination_by` clause is optional:\n\n```lean\ndef ack : Nat → Nat → Nat\n | 0, y => y+1\n | x+1, 0 => ack x 1\n | x+1, y+1 => ack x (ack (x+1) y)\n```\n\n:::setup\n```\nvariable {α : Type u} {β : Type v}\n```\n\nNote that a lexicographic order is used in the example above because the instance\n{lean}`WellFoundedRelation (α × β)` uses a lexicographic order. Lean also defines the instance\n\n```lean\ninstance (priority := low) [SizeOf α] : WellFoundedRelation α :=\n sizeOfWFRel\n```\n:::\n\n:::leanFirst\nIn the following example, we prove termination by showing that {leanRef}`as.size - i` is decreasing\nin the recursive application.\n\n```lean\ndef takeWhile (p : α → Bool) (as : Array α) : Array α :=\n go 0 #[]\nwhere\n go (i : Nat) (r : Array α) : Array α :=\n if h : i < as.size then\n let a := as[i]\n if p a then\n go (i+1) (r.push a)\n else\n r\n else\n r\n termination_by as.size - i\n```\n:::\nNote that, auxiliary function {leanRef}`go` is recursive in this example, but {leanRef}`takeWhile` is not.\nOnce again, Lean can automatically recognize this pattern, so the {leanRef}`termination_by` clause is unnecessary:\n```lean\ndef takeWhile (p : α → Bool) (as : Array α) : Array α :=\n go 0 #[]\nwhere\n go (i : Nat) (r : Array α) : Array α :=\n if h : i < as.size then\n let a := as[i]\n if p a then\n go (i+1) (r.push a)\n else\n r\n else\n r\n```\n\n:::leanFirst\nBy default, Lean uses the tactic {tactic}`decreasing_tactic` to prove recursive applications are decreasing. The modifier {leanRef}`decreasing_by` allows us to provide our own tactic. Here is an example.\n\n```lean\ntheorem div_lemma {x y : Nat} : 0 < y ∧ y ≤ x → x - y < x :=\n fun ⟨ypos, ylex⟩ => Nat.sub_lt (Nat.lt_of_lt_of_le ypos ylex) ypos\n\ndef div (x y : Nat) : Nat :=\n if h : 0 < y ∧ y ≤ x then\n div (x - y) y + 1\n else\n 0\ndecreasing_by apply div_lemma; assumption\n```\n:::\n\nNote that {leanRef}`decreasing_by` is not replacement for {leanRef}`termination_by`, they complement each other. {leanRef}`termination_by` is used to specify a well-founded relation, and {leanRef}`decreasing_by` for providing our own tactic for showing recursive applications are decreasing. In the following example, we use both of them.\n\n```lean\ndef ack : Nat → Nat → Nat\n | 0, y => y+1\n | x+1, 0 => ack x 1\n | x+1, y+1 => ack x (ack (x+1) y)\ntermination_by x y => (x, y)\ndecreasing_by\n -- unfolds well-founded recursion auxiliary definitions:\n all_goals simp_wf\n · apply Prod.Lex.left; simp +arith\n · apply Prod.Lex.right; simp +arith\n · apply Prod.Lex.left; simp +arith\n```\n\n:::leanFirst\nWe can use {leanRef}`decreasing_by sorry` to instruct Lean to “trust” us that the function terminates.\n\n```lean\ndef natToBin : Nat → List Nat\n | 0 => [0]\n | 1 => [1]\n | n + 2 => natToBin ((n + 2) / 2) ++ [n % 2]\ndecreasing_by sorry\n\n#eval! natToBin 1234567\n```\n:::\n\n:::leanFirst\nRecall that using {leanRef}`sorry` is equivalent to using a new axiom, and should be avoided. In the following example, we used the {leanRef}`sorry` to prove {leanRef}`False`.\nThe command {leanRef}`#print axioms unsound` shows that {leanRef}`unsound` depends on the unsound axiom {lean}`sorryAx` used to implement {leanRef}`sorry`.\n\n```lean\ndef unsound (x : Nat) : False :=\n unsound (x + 1)\ndecreasing_by sorry\n\n#check unsound 0\n-- `unsound 0` is a proof of `False`\n\n#print axioms unsound -- 'unsound' depends on axioms: [sorryAx]\n```\n:::\n\n:::setup\n```\nvariable {α : Type w} {β : Type u} {γ : Type v} {G : Prop}\n```\n\nSummary:\n\n- If there is no {leanRef}`termination_by`, a well-founded relation is derived (if possible) by selecting an argument and then using typeclass resolution to synthesize a well-founded relation for this argument's type.\n\n- If {leanRef}`termination_by` is specified, it maps the arguments of the function to a type {lean}`α` and type class resolution is again used. Recall that, the default instance for {lean}`β × γ` is a lexicographic order based on the well-founded relations for {lean}`β` and {lean}`γ`.\n\n- The default well-founded relation instance for {lean}`Nat` is {lean (type := \"Nat → Nat → Prop\")}`(· < ·)`.\n\n- By default, the tactic {tactic}`decreasing_tactic` is used to show that recursive applications are smaller with respect to the selected well-founded relation. If {tactic}`decreasing_tactic` fails, the error message includes the remaining goal {lit}`... |- G`. Note that, the {tactic}`decreasing_tactic` uses {tactic}`assumption`. So, you can include a {kw}`have`-expression to prove goal {lean}`G`. You can also provide your own tactic using {kw}`decreasing_by`.\n:::\n\n# Functional Induction\n%%%\ntag := \"functional-induction\"\n%%%\n\nLean generates bespoke induction principles for recursive functions. These induction principles follow the recursive structure of the function's definition, rather than the structure of the datatype. Proofs about functions typically follow the recursive structure of the function itself, so these induction principles allow statements about the function to be proved more conveniently.\n\n:::leanFirst\nFor example, using the functional induction principle for {leanRef}`ack` to prove that the result is always greater than {leanRef}`0` requires one case for each arm of the pattern match in {leanRef}`ack`:\n\n```lean\ndef ack : Nat → Nat → Nat\n | 0, y => y+1\n | x+1, 0 => ack x 1\n | x+1, y+1 => ack x (ack (x+1) y)\n\ntheorem ack_gt_zero : ack n m > 0 := by\n fun_induction ack with\n | case1 y =>\n-- ^ PROOF_STATE: case1\n simp\n | case2 x ih =>\n-- ^ PROOF_STATE: case2\n exact ih\n | case3 x y ih1 ih2 =>\n-- ^ PROOF_STATE: case3\n simp [ack, *]\n```\n:::\n\nIn {goal case1}`case1`, the goal is:\n```proofState case1\ncase case1\ny : Nat\n⊢ y + 1 > 0\n```\nThe {leanRef}`y + 1` in the goal corresponds to the value returned in the first case of {leanRef}`ack`.\n\nIn {goal case2}`case2`, the goal is:\n```proofState case2\ncase case2\nx : Nat\nih : ack x 1 > 0\n⊢ ack x 1 > 0\n```\nThe {leanRef}`ack x 1` in the goal corresponds to the value of {leanRef}`ack` applied to the pattern variables {leanRef}`x + 1` and {leanRef}`0` returned in the second case of {leanRef}`ack`.\nThis term is automatically simplified to the right-hand side.\nHappily, the inductive hypothesis {leanRef}`ih : ack x 1 > 0` corresponds to the recursive call, which is exactly the answer returned in this case.\n\nIn {goal case3}`case3`, the goal is:\n```proofState case3\ncase case3\nx : Nat\ny : Nat\nih1 : ack (x + 1) y > 0\nih2 : ack x (ack (x + 1) y) > 0\n⊢ ack x (ack (x + 1) y) > 0\n```\nThe {leanRef}`ack x (ack (x + 1) y)` in the goal corresponds to the value returned in the third case of {leanRef}`ack`, when {leanRef}`ack` applied to {leanRef}`x + 1` and {leanRef}`y + 1` has been reduced.\nThe inductive hypotheses {leanRef}`ih1 : ack (x + 1) y > 0` and {leanRef}`ih2 : ack x (ack (x + 1) y) > 0` correspond to the recursive calls, with {leanRef}`ih1` matching the nested recursive call.\nOnce again, the induction hypothesis is suitable.\n\nUsing {leanRef}`fun_induction ack` results in goals and induction hypotheses that match the recursive structure of {leanRef}`ack`. As a result, the proof can be a single line:\n```lean\ndef ack : Nat → Nat → Nat\n | 0, y => y+1\n | x+1, 0 => ack x 1\n | x+1, y+1 => ack x (ack (x+1) y)\n-------------\ntheorem ack_gt_zero : ack n m > 0 := by\n fun_induction ack <;> simp [*, ack]\n```\n\n:::leanFirst\nThere is also a {leanRef}`fun_cases` tactic which is analogous to the {tactic}`cases` tactic.\nIt generates a case for each branch in a function's control flow.\nBoth it and {leanRef}`fun_induction` additionally provide assumptions that rule out the paths that were not taken.\n\nThis function {leanRef}`f` represents a five-way Boolean disjunction:\n```lean\ndef f : Bool → Bool → Bool → Bool → Bool → Bool\n | true, _, _, _ , _ => true\n | _, true, _, _ , _ => true\n | _, _, true, _ , _ => true\n | _, _, _, true, _ => true\n | _, _, _, _, x => x\n\n```\n\nTo prove that it is disjunction, the last case requires knowledge that none of the arguments are {leanRef}`true`.\nThis knowledge is provided by the tactic:\n```lean\ndef f : Bool → Bool → Bool → Bool → Bool → Bool\n | true, _, _, _ , _ => true\n | _, true, _, _ , _ => true\n | _, _, true, _ , _ => true\n | _, _, _, true, _ => true\n | _, _, _, _, x => x\n------\ntheorem f_or : f b1 b2 b3 b4 b5 = (b1 || b2 || b3 || b4 || b5) := by\n fun_cases f\n-- ^ PROOF_STATE: fOrAll\n all_goals sorry\n```\n:::\n\nEach case includes an assumption that rules out the prior cases:\n\n```proofState fOrAll\ncase case1\nb2 : Bool\nb3 : Bool\nb4 : Bool\nb5 : Bool\n⊢ true = (true || b2 || b3 || b4 || b5)\n\ncase case2\nb1 : Bool\nb3 : Bool\nb4 : Bool\nb5 : Bool\nx✝ : b1 = true → False\n⊢ true = (b1 || true || b3 || b4 || b5)\n\ncase case3\nb1 : Bool\nb2 : Bool\nb4 : Bool\nb5 : Bool\nx✝¹ : b1 = true → False\nx✝ : b2 = true → False\n⊢ true = (b1 || b2 || true || b4 || b5)\n\ncase case4\nb1 : Bool\nb2 : Bool\nb3 : Bool\nb5 : Bool\nx✝² : b1 = true → False\nx✝¹ : b2 = true → False\nx✝ : b3 = true → False\n⊢ true = (b1 || b2 || b3 || true || b5)\n\ncase case5\nb1 : Bool\nb2 : Bool\nb3 : Bool\nb4 : Bool\nb5 : Bool\nx✝³ : b1 = true → False\nx✝² : b2 = true → False\nx✝¹ : b3 = true → False\nx✝ : b4 = true → False\n⊢ b5 = (b1 || b2 || b3 || b4 || b5)\n```\n\n:::leanFirst\nThe {leanRef}`simp_all` tactic, which simplifies all the assumptions and the goal together, can dispatch all cases:\n```lean\ndef f : Bool → Bool → Bool → Bool → Bool → Bool\n | true, _, _, _ , _ => true\n | _, true, _, _ , _ => true\n | _, _, true, _ , _ => true\n | _, _, _, true, _ => true\n | _, _, _, _, x => x\n------\ntheorem f_or : f b1 b2 b3 b4 b5 = (b1 || b2 || b3 || b4 || b5) := by\n fun_cases f <;> simp_all\n```\n:::\n\n\n# Mutual Recursion\n%%%\ntag := \"mutual-recursion\"\n%%%\n\nLean also supports mutual recursive definitions. The syntax is similar to that for mutual inductive types. Here is an example:\n\n```lean\nmutual\n def even : Nat → Bool\n | 0 => true\n | n+1 => odd n\n\n def odd : Nat → Bool\n | 0 => false\n | n+1 => even n\nend\n\nexample : even (a + 1) = odd a := by\n simp [even]\n\nexample : odd (a + 1) = even a := by\n simp [odd]\n\ntheorem even_eq_not_odd : ∀ a, even a = not (odd a) := by\n intro a; induction a\n . simp [even, odd]\n . simp [even, odd, *]\n```\n\nWhat makes this a mutual definition is that {leanRef}`even` is defined recursively in terms of {leanRef}`odd`, while {leanRef}`odd` is defined recursively in terms of {leanRef}`even`. Under the hood, this is compiled as a single recursive definition. The internally defined function takes, as argument, an element of a sum type, either an input to {leanRef}`even`, or an input to {leanRef}`odd`. It then returns an output appropriate to the input. To define that function, Lean uses a suitable well-founded measure. The internals are meant to be hidden from users; the canonical way to make use of such definitions is to use {leanRef}`simp` (or {tactic}`unfold`), as we did above.\n\n:::leanFirst\nMutual recursive definitions also provide natural ways of working with mutual and nested inductive types. Recall the definition of {leanRef}`Even` and {leanRef}`Odd` as mutual inductive predicates as presented before.\n\n```lean\nmutual\n inductive Even : Nat → Prop where\n | even_zero : Even 0\n | even_succ : ∀ n, Odd n → Even (n + 1)\n\n inductive Odd : Nat → Prop where\n | odd_succ : ∀ n, Even n → Odd (n + 1)\nend\n```\n:::\n\n:::leanFirst\nThe constructors, {leanRef}`even_zero`, {leanRef}`even_succ`, and {leanRef}`odd_succ` provide positive means for showing that a number is even or odd. We need to use the fact that the inductive type is generated by these constructors to know that zero is not odd, and that the latter two implications reverse. As usual, the constructors are kept in a namespace that is named after the type being defined, and the command {leanRef}`open Even Odd` allows us to access them more conveniently.\n\n```lean\nmutual\n inductive Even : Nat → Prop where\n | even_zero : Even 0\n | even_succ : ∀ n, Odd n → Even (n + 1)\n inductive Odd : Nat → Prop where\n | odd_succ : ∀ n, Even n → Odd (n + 1)\nend\n------\nopen Even Odd\n\ntheorem not_odd_zero : ¬ Odd 0 :=\n fun h => nomatch h\n\ntheorem even_of_odd_succ : ∀ n, Odd (n + 1) → Even n\n | _, odd_succ n h => h\n\ntheorem odd_of_even_succ : ∀ n, Even (n + 1) → Odd n\n | _, even_succ n h => h\n```\n:::\n\nFor another example, suppose we use a nested inductive type to define a set of terms inductively, so that a term is either a constant (with a name given by a string), or the result of applying a constant to a list of constants.\n\n```lean\ninductive Term where\n | const : String → Term\n | app : String → List Term → Term\n```\n\nWe can then use a mutual recursive definition to count the number of constants occurring in a term, as well as the number occurring in a list of terms.\n\n```lean\ninductive Term where\n | const : String → Term\n | app : String → List Term → Term\n------\nnamespace Term\n\nmutual\n def numConsts : Term → Nat\n | const _ => 1\n | app _ cs => numConstsLst cs\n\n def numConstsLst : List Term → Nat\n | [] => 0\n | c :: cs => numConsts c + numConstsLst cs\nend\n\ndef sample := app \"f\" [app \"g\" [const \"x\"], const \"y\"]\n\n#eval numConsts sample\n\nend Term\n```\n\n:::leanFirst\nAs a final example, we define a function {leanRef}`replaceConst a b e` that replaces a constant {leanRef (in := \"replaceConst a b e\")}`a` with {leanRef (in := \"replaceConst a b e\")}`b` in a term {leanRef (in := \"replaceConst a b e\")}`e`, and then prove the number of constants is the same. Note that, our proof uses mutual recursion (aka induction).\n\n```lean\ninductive Term where\n | const : String → Term\n | app : String → List Term → Term\nnamespace Term\nmutual\n def numConsts : Term → Nat\n | const _ => 1\n | app _ cs => numConstsLst cs\n def numConstsLst : List Term → Nat\n | [] => 0\n | c :: cs => numConsts c + numConstsLst cs\nend\n------\nmutual\n def replaceConst (a b : String) : Term → Term\n | const c => if a == c then const b else const c\n | app f cs => app f (replaceConstLst a b cs)\n\n def replaceConstLst (a b : String) : List Term → List Term\n | [] => []\n | c :: cs => replaceConst a b c :: replaceConstLst a b cs\nend\n\nmutual\n theorem numConsts_replaceConst (a b : String) (e : Term) :\n numConsts (replaceConst a b e) = numConsts e := by\n match e with\n | const c =>\n simp [replaceConst]; split <;> simp [numConsts]\n | app f cs =>\n simp [replaceConst, numConsts, numConsts_replaceConstLst a b cs]\n\n theorem numConsts_replaceConstLst (a b : String) (es : List Term) :\n numConstsLst (replaceConstLst a b es) = numConstsLst es := by\n match es with\n | [] => simp [replaceConstLst, numConstsLst]\n | c :: cs =>\n simp [replaceConstLst, numConstsLst, numConsts_replaceConst a b c,\n numConsts_replaceConstLst a b cs]\nend\n```\n:::\n\n# Dependent Pattern Matching\n%%%\ntag := \"dependent-pattern-matching\"\n%%%\n\n\n::::setup\n```\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\n\ndef map (f : α → β) : Vect α n → Vect β n\n | .nil => .nil\n | .cons x xs => .cons (f x) (map f xs)\n\ndef zip : Vect α n → Vect β n → Vect (α × β) n\n | .nil, .nil => .nil\n | .cons x xs, .cons y ys => .cons (x, y) (zip xs ys)\n\ndef unzip : Vect (α × β) n → (Vect α n × Vect β n)\n | .nil => (.nil, .nil)\n | .cons (x, y) xys =>\n let (xs, ys) := unzip xys\n (.cons x xs, .cons y ys)\n\ndef tail : Vect α (n + 1) → Vect α n\n | .cons x xs => xs\n\nvariable {v : Vect α (n + 1)}\nopen Vect\n```\n\n:::leanFirst\nAll the examples of pattern matching we considered in the section on\n{ref \"pattern-matching\"}[pattern matching] can easily be written using {lit}`casesOn`\nand {lit}`recOn`. However, this is often not the case with indexed\ninductive families such as {leanRef}`Vect α n`, since case splits impose\nconstraints on the values of the indices. Without the equation\ncompiler, we would need a lot of boilerplate code to define very\nsimple functions such as {lean}`map`, {lean}`zip`, and {lean}`unzip` using\nrecursors. To understand the difficulty, consider what it would take\nto define a function {lean}`tail` which takes a vector\n{lean}`v : Vect α (n + 1)` and deletes the first element.\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n + 1)\n```\n:::\n\n\n\nA first thought might be to use the {name}`Vect.casesOn` function:\n\n```signature\nVect.casesOn.{u, v}\n {α : Type v} {motive : (a : Nat) → Vect α a → Sort u}\n {a : Nat}\n (t : Vect α a)\n (nil : motive 0 nil)\n (cons : (a : α) → {n : Nat} → (a_1 : Vect α n) →\n motive (n + 1) (cons a a_1)) :\n motive a t\n```\n\n\nBut what value should we return in the {name}`nil` case? Something funny\nis going on: if {lean}`v` has type {lean}`Vect α (n + 1)`, it _can't_ be\n{name}`nil`, but it is not clear how to tell that to {name}`Vect.casesOn`.\n\n::::\n\nOne solution is to define an auxiliary function:\n\n```lean\nset_option linter.unusedVariables false\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef tailAux (v : Vect α m) : m = n + 1 → Vect α n :=\n Vect.casesOn (motive := fun x _ => x = n + 1 → Vect α n) v\n (fun h : 0 = n + 1 => Nat.noConfusion h)\n (fun (a : α) (m : Nat) (as : Vect α m) =>\n fun (h : m + 1 = n + 1) =>\n Nat.noConfusion h (fun h1 : m = n => h1 ▸ as))\n\ndef tail (v : Vect α (n+1)) : Vect α n :=\n tailAux v rfl\n-----\nend Vect\n```\n\nIn the {leanRef}`nil` case, {leanRef (in := \"m = n + 1\")}`m` is instantiated to {leanRef}`0`, and\n{leanRef}`Nat.noConfusion` makes use of the fact that {leanRef}`0 = n + 1` cannot\noccur. Otherwise, {leanRef}`v` is of the form {lit}`cons `{leanRef}`a`{lit}` `{leanRef}`as`, and we can simply\nreturn {leanRef}`as`, after casting it from a vector of length {leanRef (in := \"m + 1 = n + 1\")}`m` to a\nvector of length {leanRef (in := \"m + 1= n + 1\")}`n`.\n\nThe difficulty in defining {leanRef}`tail` is to maintain the relationships between the indices.\nThe hypothesis {leanRef}`m = n + 1` in {leanRef}`tailAux` is used to communicate the relationship\nbetween {leanRef (in:=\"m = n + 1\")}`n` and the index associated with the minor premise.\nMoreover, the {leanRef}`0 = n + 1` case is unreachable, and the canonical way to discard such\na case is to use {leanRef}`Nat.noConfusion`.\n\n:::leanFirst\nThe {leanRef}`tail` function is, however, easy to define using recursive\nequations, and the equation compiler generates all the boilerplate\ncode automatically for us. Here are a number of similar examples:\n\n```lean\nset_option linter.unusedVariables false\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef head : {n : Nat} → Vect α (n+1) → α\n | n, cons a as => a\n\ndef tail : {n : Nat} → Vect α (n+1) → Vect α n\n | n, cons a as => as\n\ntheorem eta : ∀ {n : Nat} (v : Vect α (n+1)), cons (head v) (tail v) = v\n | n, cons a as => rfl\n\ndef map (f : α → β → γ) : {n : Nat} → Vect α n → Vect β n → Vect γ n\n | 0, nil, nil => nil\n | n+1, cons a as, cons b bs => cons (f a b) (map f as bs)\n\ndef zip : {n : Nat} → Vect α n → Vect β n → Vect (α × β) n\n | 0, nil, nil => nil\n | n+1, cons a as, cons b bs => cons (a, b) (zip as bs)\n------\nend Vect\n```\n:::\n\nNote that we can omit recursive equations for “unreachable” cases such\nas {leanRef}`head`{lit}` `{leanRef}`nil`. The automatically generated definitions for indexed\nfamilies are far from straightforward. For example:\n\n```lean\nset_option linter.unusedVariables false\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n-------\ndef zipWith (f : α → β → γ) : {n : Nat} → Vect α n → Vect β n → Vect γ n\n | 0, nil, nil => nil\n | n+1, cons a as, cons b bs => cons (f a b) (zipWith f as bs)\n\n#print zipWith\n#print zipWith.match_1\n------\nend Vect\n```\n\n:::setup\n```\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\n```\n\nThe {leanRef}`zipWith` function is even more tedious to define by hand than the\n{leanRef}`tail` function. We encourage you to try it, using {name}`Vect.recOn`,\n{name}`Vect.casesOn` and {name}`Vect.noConfusion`.\n:::\n\n# Inaccessible Patterns\n%%%\ntag := \"inaccessible-patterns\"\n%%%\n\nSometimes an argument in a dependent matching pattern is not essential\nto the definition, but nonetheless has to be included to specialize\nthe type of the expression appropriately. Lean allows users to mark\nsuch subterms as _inaccessible_ for pattern matching. These\nannotations are essential, for example, when a term occurring in the\nleft-hand side is neither a variable nor a constructor application,\nbecause these are not suitable targets for pattern matching. We can\nview such inaccessible patterns as “don't care” components of the\npatterns. You can declare a subterm inaccessible by writing\n{lit}`.(t)`. If the inaccessible pattern can be inferred, you can also write\n{lit}`_`.\n\n:::leanFirst\nThe following example, we declare an inductive type that defines the\nproperty of “being in the image of {leanRef (in := \"(f :\")}`f`”. You can view an element of\nthe type {leanRef}`ImageOf f b` as evidence that {leanRef (in := \"ImageOf f b\")}`b` is in the image of\n{leanRef (in := \"ImageOf f b\")}`f`, whereby the constructor {leanRef}`imf` is used to build such\nevidence. We can then define any function {leanRef (in := \"inverse {f\")}`f` with an “inverse”\nwhich takes anything in the image of {leanRef (in := \"inverse {f\")}`f` to an element that is\nmapped to it. The typing rules forces us to write {leanRef (in := \".(f a)\")}`f a` for the\nfirst argument, but this term is neither a variable nor a constructor\napplication, and plays no role in the pattern-matching definition. To\ndefine the function {leanRef}`inverse` below, we _have to_ mark {leanRef (in := \".(f a)\")}`f a`\ninaccessible.\n\n```lean\ninductive ImageOf {α β : Type u} (f : α → β) : β → Type u where\n | imf : (a : α) → ImageOf f (f a)\n\nopen ImageOf\n\ndef inverse {f : α → β} : (b : β) → ImageOf f b → α\n | .(f a), imf a => a\n\ndef inverse' {f : α → β} : (b : β) → ImageOf f b → α\n | _, imf a => a\n```\n:::\n\nIn the example above, the inaccessible annotation makes it clear that\n{leanRef (in := \".(f a)\")}`f` is _not_ a pattern matching variable.\n\n:::leanFirst\nInaccessible patterns can be used to clarify and control definitions that\nmake use of dependent pattern matching. Consider the following\ndefinition of the function {leanRef}`Vect.add`, which adds two vectors of\nelements of a type, assuming that type has an associated addition\nfunction:\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\n\ndef Vect.add [Add α] : {n : Nat} → Vect α n → Vect α n → Vect α n\n | 0, nil, nil => nil\n | n+1, cons a as, cons b bs => cons (a + b) (add as bs)\n```\n:::\n\nThe argument {leanRef}`{n : Nat}` appear after the colon, because it cannot\nbe held fixed throughout the definition. When implementing this\ndefinition, the equation compiler starts with a case distinction as to\nwhether the first argument is {leanRef}`0` or of the form {leanRef}`n+1`. This is\nfollowed by nested case splits on the next two arguments, and in each\ncase the equation compiler rules out the cases are not compatible with\nthe first pattern.\n\nBut, in fact, a case split is not required on the first argument; the\n{lit}`casesOn` eliminator for {leanRef}`Vect` automatically abstracts this\nargument and replaces it by {leanRef}`0` and {leanRef}`n + 1` when we do a case\nsplit on the second argument. Using inaccessible patterns, we can prompt\nthe equation compiler to avoid the case split on {leanRef}`n`.\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef add [Add α] : {n : Nat} → Vect α n → Vect α n → Vect α n\n | .(_), nil, nil => nil\n | .(_), cons a as, cons b bs => cons (a + b) (add as bs)\n-------\nend Vect\n```\n\nMarking the position as an inaccessible pattern tells the\nequation compiler first, that the form of the argument should be\ninferred from the constraints posed by the other arguments, and,\nsecond, that the first argument should _not_ participate in pattern\nmatching.\n\nThe inaccessible pattern {leanRef}`.(_)` can be written as {lit}`_` for convenience.\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef add [Add α] : {n : Nat} → Vect α n → Vect α n → Vect α n\n | _, nil, nil => nil\n | _, cons a as, cons b bs => cons (a + b) (add as bs)\n-------\nend Vect\n```\n\nAs we mentioned above, the argument {leanRef}`{n : Nat}` is part of the\npattern matching, because it cannot be held fixed throughout the\ndefinition. Rather than requiring that these discriminants be provided explicitly, Lean implicitly includes\nthese extra discriminants automatically for us.\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef add [Add α] {n : Nat} : Vect α n → Vect α n → Vect α n\n | nil, nil => nil\n | cons a as, cons b bs => cons (a + b) (add as bs)\n-------\nend Vect\n```\n\nWhen combined with the _auto bound implicits_ feature, you can simplify\nthe declare further and write:\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef add [Add α] : Vect α n → Vect α n → Vect α n\n | nil, nil => nil\n | cons a as, cons b bs => cons (a + b) (add as bs)\n-------\nend Vect\n```\n\nUsing these new features, you can write the other vector functions defined\nin the previous sections more compactly as follows:\n\n```lean\nset_option linter.unusedVariables false\ninductive Vect (α : Type u) : Nat → Type u\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n+1)\nnamespace Vect\n------\ndef head : Vect α (n+1) → α\n | cons a as => a\n\ndef tail : Vect α (n+1) → Vect α n\n | cons a as => as\n\ntheorem eta : (v : Vect α (n+1)) → cons (head v) (tail v) = v\n | cons a as => rfl\n\ndef map (f : α → β → γ) : Vect α n → Vect β n → Vect γ n\n | nil, nil => nil\n | cons a as, cons b bs => cons (f a b) (map f as bs)\n\ndef zip : Vect α n → Vect β n → Vect (α × β) n\n | nil, nil => nil\n | cons a as, cons b bs => cons (a, b) (zip as bs)\n-------\nend Vect\n```\n\n# Match Expressions\n%%%\ntag := \"match-expressions\"\n%%%\n\nLean also provides a compiler for {kw}`match`-{kw}`with` expressions found in\nmany functional languages:\n\n```lean\nset_option linter.unusedVariables false\n------\ndef isNotZero (m : Nat) : Bool :=\n match m with\n | 0 => false\n | n + 1 => true\n```\n\nThis does not look very different from an ordinary pattern matching\ndefinition, but the point is that a {kw}`match` can be used anywhere in\nan expression, and with arbitrary arguments.\n\n```lean\nset_option linter.unusedVariables false\n-------\ndef isNotZero (m : Nat) : Bool :=\n match m with\n | 0 => false\n | n + 1 => true\n\ndef filter (p : α → Bool) : List α → List α\n | [] => []\n | a :: as =>\n match p a with\n | true => a :: filter p as\n | false => filter p as\n\nexample : filter isNotZero [1, 0, 0, 3, 0] = [1, 3] := rfl\n```\n\nHere is another example:\n\n```lean\ndef foo (n : Nat) (b c : Bool) :=\n 5 + match n - 5, b && c with\n | 0, true => 0\n | m + 1, true => m + 7\n | 0, false => 5\n | m + 1, false => m + 3\n\n#eval foo 7 true false\n\nexample : foo 7 true false = 9 := rfl\n```\n\nLean uses the {kw}`match` construct internally to implement pattern-matching in all parts of the system.\nThus, all four of these definitions have the same net effect:\n\n```lean\ndef bar₁ : Nat × Nat → Nat\n | (m, n) => m + n\n\ndef bar₂ (p : Nat × Nat) : Nat :=\n match p with\n | (m, n) => m + n\n\ndef bar₃ : Nat × Nat → Nat :=\n fun (m, n) => m + n\n\ndef bar₄ (p : Nat × Nat) : Nat :=\n let (m, n) := p; m + n\n```\n\nThese variations are equally useful for destructing propositions:\n\n```lean\nvariable (p q : Nat → Prop)\n\nexample : (∃ x, p x) → (∃ y, q y) → ∃ x y, p x ∧ q y\n | ⟨x, px⟩, ⟨y, qy⟩ => ⟨x, y, px, qy⟩\n\nexample (h₀ : ∃ x, p x) (h₁ : ∃ y, q y)\n : ∃ x y, p x ∧ q y :=\n match h₀, h₁ with\n | ⟨x, px⟩, ⟨y, qy⟩ => ⟨x, y, px, qy⟩\n\nexample : (∃ x, p x) → (∃ y, q y) → ∃ x y, p x ∧ q y :=\n fun ⟨x, px⟩ ⟨y, qy⟩ => ⟨x, y, px, qy⟩\n\nexample (h₀ : ∃ x, p x) (h₁ : ∃ y, q y)\n : ∃ x y, p x ∧ q y :=\n let ⟨x, px⟩ := h₀\n let ⟨y, qy⟩ := h₁\n ⟨x, y, px, qy⟩\n```\n\n\n# Exercises\n%%%\ntag := none\n%%%\n\n```setup\n\nopen List\n\nvariable {xs : List α} {n : Nat}\n\n```\n\n1. Open a namespace {lit}`Hidden` to avoid naming conflicts, and use the\n equation compiler to define addition, multiplication, and\n exponentiation on the natural numbers. Then use the equation\n compiler to derive some of their basic properties.\n\n2. Similarly, use the equation compiler to define some basic\n operations on lists (like the {lean}`reverse` function) and prove\n theorems about lists by induction (such as the fact that\n {lean}`reverse (reverse xs) = xs` for any list {lean}`xs`).\n\n3. Define your own function to carry out course-of-value recursion on\n the natural numbers. Similarly, see if you can figure out how to\n define {name}`WellFounded.fix` on your own.\n\n4. Following the examples in the section on {ref \"dependent-pattern-matching\"}[dependent pattern matching],\n define a function that will append two vectors.\n This is tricky; you will have to define an auxiliary function.\n\n5. :::leanFirst\n\n Consider the following type of arithmetic expressions. The idea is\n that {leanRef}`var`{lit}` `{lean}`n` is a variable, {lit}`vₙ`, and {leanRef}`const`{lit}` `{lean}`n` is the\n constant whose value is {lean}`n`.\n\n ```lean\n inductive Expr where\n | const : Nat → Expr\n | var : Nat → Expr\n | plus : Expr → Expr → Expr\n | times : Expr → Expr → Expr\n deriving Repr\n\n open Expr\n\n def sampleExpr : Expr :=\n plus (times (var 0) (const 7)) (times (const 2) (var 1))\n ```\n :::\n\n Here {leanRef}`sampleExpr` represents {lit}`(v₀ * 7) + (2 * v₁)`.\n\n :::leanFirst\n Write a function that evaluates such an expression, evaluating each {leanRef}`var n` to {leanRef}`v n`.\n\n ```lean\n inductive Expr where\n | const : Nat → Expr\n | var : Nat → Expr\n | plus : Expr → Expr → Expr\n | times : Expr → Expr → Expr\n deriving Repr\n open Expr\n def sampleExpr : Expr :=\n plus (times (var 0) (const 7)) (times (const 2) (var 1))\n ------\n def eval (v : Nat → Nat) : Expr → Nat\n | const n => sorry\n | var n => v n\n | plus e₁ e₂ => sorry\n | times e₁ e₂ => sorry\n\n def sampleVal : Nat → Nat\n | 0 => 5\n | 1 => 6\n | _ => 0\n\n -- Try it out. You should get 47 here.\n -- #eval eval sampleVal sampleExpr\n ```\n :::\n\n :::leanFirst\n Implement “constant fusion,” a procedure that simplifies subterms like\n {lean}`5 + 7` to {lean}`12`. Using the auxiliary function {leanRef}`simpConst`,\n define a function “fuse”: to simplify a plus or a times, first\n simplify the arguments recursively, and then apply {leanRef}`simpConst` to\n try to simplify the result.\n\n ```lean\n inductive Expr where\n | const : Nat → Expr\n | var : Nat → Expr\n | plus : Expr → Expr → Expr\n | times : Expr → Expr → Expr\n deriving Repr\n open Expr\n def eval (v : Nat → Nat) : Expr → Nat\n | const n => sorry\n | var n => v n\n | plus e₁ e₂ => sorry\n | times e₁ e₂ => sorry\n ------\n def simpConst : Expr → Expr\n | plus (const n₁) (const n₂) => const (n₁ + n₂)\n | times (const n₁) (const n₂) => const (n₁ * n₂)\n | e => e\n\n def fuse : Expr → Expr := sorry\n\n theorem simpConst_eq (v : Nat → Nat)\n : ∀ e : Expr, eval v (simpConst e) = eval v e :=\n sorry\n\n theorem fuse_eq (v : Nat → Nat)\n : ∀ e : Expr, eval v (fuse e) = eval v e :=\n sorry\n ```\n :::\n\n The last two theorems show that the definitions preserve the value.\n"
},
{
"path": "book/TPiL/InductiveTypes.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre\nopen Verso.Genre.Manual hiding tactic\nopen TPiL\n\n#doc (Manual) \"Inductive Types\" =>\n%%%\ntag := \"inductive-types\"\n%%%\n\n:::setup\n```\nvariable {α : Sort u} {β : Sort v}\n```\n\n\nWe have seen that Lean's formal foundation includes basic types,\n{lean}`Prop`, {lean}`Type 0`, {lean}`Type 1`, {lean}`Type 2`, ..., and allows for the formation of\ndependent function types, {lean}`(x : α) → β`. In the examples, we have\nalso made use of additional types like {lean}`Bool`, {lean}`Nat`, and {lean}`Int`,\nand type constructors, like {lean}`List`, and product, {lit}`×`. In fact, in\nLean's library, every concrete type other than the universes and every\ntype constructor other than dependent arrows is an instance of a general family of\ntype constructions known as _inductive types_. It is remarkable that\nit is possible to construct a substantial edifice of mathematics based\non nothing more than the type universes, dependent arrow types, and inductive\ntypes; everything else follows from those.\n:::\n\nIntuitively, an inductive type is built up from a specified list of\nconstructors. In Lean, the syntax for specifying such a type is as\nfollows:\n\n:::setup\n```\nvariable {α β ω : Type}\n\ninductive Foo where\n | constructor₁ : α → Foo\n | constructor₂ : β → Foo\n | constructorₙ : ω → Foo\n\n```\n\n```\ninductive Foo where\n | constructor₁ : ... → Foo\n | constructor₂ : ... → Foo\n ...\n | constructorₙ : ... → Foo\n```\n\nThe intuition is that each constructor specifies a way of building new\nobjects of {lean}`Foo`, possibly from previously constructed values. The\ntype {lean}`Foo` consists of nothing more than the objects that are\nconstructed in this way.\n\n\n\nWe will see below that the arguments of the constructors can include\nobjects of type {lean}`Foo`, subject to a certain “positivity” constraint,\nwhich guarantees that elements of {lean}`Foo` are built from the bottom\nup. Roughly speaking, each {lit}`...` can be any arrow type constructed from\n{lean}`Foo` and previously defined types, in which {lean}`Foo` appears, if at\nall, only as the “target” of the dependent arrow type.\n:::\n\nWe will provide a number of examples of inductive types. We will also\nconsider slight generalizations of the scheme above, to mutually\ndefined inductive types, and so-called _inductive families_.\n\nAs with the logical connectives, every inductive type comes with\nintroduction rules, which show how to construct an element of the\ntype, and elimination rules, which show how to “use” an element of the\ntype in another construction. The analogy to the logical connectives\nshould not come as a surprise; as we will see below, they, too, are\nexamples of inductive type constructions. You have already seen the\nintroduction rules for an inductive type: they are just the\nconstructors that are specified in the definition of the type. The\nelimination rules provide for a principle of recursion on the type,\nwhich includes, as a special case, a principle of induction as well.\n\nIn the next chapter, we will describe Lean's function definition\npackage, which provides even more convenient ways to define functions\non inductive types and carry out inductive proofs. But because the\nnotion of an inductive type is so fundamental, we feel it is important\nto start with a low-level, hands-on understanding. We will start with\nsome basic examples of inductive types, and work our way up to more\nelaborate and complex examples.\n\n# Enumerated Types\n%%%\ntag := \"enumerated-types\"\n%%%\n\nThe simplest kind of inductive type is a type with a finite, enumerated list of elements.\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n```\n\nThe {kw}`inductive` command creates a new type, {leanRef}`Weekday`. The\nconstructors all live in the {lit}`Weekday` namespace.\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n------\n#check Weekday.sunday\n\n#check Weekday.monday\n\nopen Weekday\n\n#check sunday\n\n#check monday\n```\n\nYou can omit {leanRef}`: Weekday` when declaring the {leanRef}`Weekday` inductive type.\n\n```lean\ninductive Weekday where\n | sunday\n | monday\n | tuesday\n | wednesday\n | thursday\n | friday\n | saturday\n```\n\n:::setup\n```\ninductive Weekday where\n | sunday\n | monday\n | tuesday\n | wednesday\n | thursday\n | friday\n | saturday\n```\n\nThink of {leanRef}`sunday`, {leanRef}`monday`, ... , {leanRef}`saturday` as\nbeing distinct elements of {leanRef}`Weekday`, with no other distinguishing\nproperties. The elimination principle, {name}`Weekday.rec`, is defined\nalong with the type {leanRef}`Weekday` and its constructors. It is also known\nas a _recursor_, and it is what makes the type “inductive”: it allows\nus to define a function on {leanRef}`Weekday` by assigning values\ncorresponding to each constructor. The intuition is that an inductive\ntype is exhaustively generated by the constructors, and has no\nelements beyond those they construct.\n\n```signature\nWeekday.rec.{u} {motive : Weekday → Sort u}\n (sunday : motive Weekday.sunday)\n (monday : motive Weekday.monday)\n (tuesday : motive Weekday.tuesday)\n (wednesday : motive Weekday.wednesday)\n (thursday : motive Weekday.thursday)\n (friday : motive Weekday.friday)\n (saturday : motive Weekday.saturday)\n (t : Weekday) :\n motive t\n```\n\n:::\n\n:::leanFirst\nWe will use the {kw}`match` expression to define a function from {leanRef}`Weekday`\nto the natural numbers:\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n------\nopen Weekday\n\ndef numberOfDay (d : Weekday) : Nat :=\n match d with\n | sunday => 1\n | monday => 2\n | tuesday => 3\n | wednesday => 4\n | thursday => 5\n | friday => 6\n | saturday => 7\n\n#eval numberOfDay Weekday.sunday -- 1\n\n#eval numberOfDay Weekday.monday -- 2\n\n#eval numberOfDay Weekday.tuesday -- 3\n```\n\nWhen using Lean's logic, the {kw}`match` expression is compiled using the _recursor_ {leanRef}`Weekday.rec` generated when\nyou declare the inductive type. This ensures that the resulting term is well-defined in the type theory. For compiled code,\n{kw}`match` is compiled as in other functional programming languages.\n:::\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n------\nopen Weekday\n\ndef numberOfDay (d : Weekday) : Nat :=\n match d with\n | sunday => 1\n | monday => 2\n | tuesday => 3\n | wednesday => 4\n | thursday => 5\n | friday => 6\n | saturday => 7\n\nset_option pp.all true\n#print numberOfDay\n\n#print numberOfDay.match_1\n\n#print Weekday.casesOn\n\n#check @Weekday.rec\n```\n\n:::leanFirst\nWhen declaring an inductive datatype, you can use {leanRef}`deriving Repr` to instruct\nLean to generate a function that converts {leanRef}`Weekday` objects into text.\nThis function is used by the {kw}`#eval` command to display {leanRef}`Weekday` objects.\nIf no {lean}`Repr` exists, {kw}`#eval` attempts to derive one on the spot.\n\n```lean\ninductive Weekday where\n | sunday\n | monday\n | tuesday\n | wednesday\n | thursday\n | friday\n | saturday\nderiving Repr\n\nopen Weekday\n\n#eval tuesday -- Weekday.tuesday\n```\n:::\n\nIt is often useful to group definitions and theorems related to a\nstructure in a namespace with the same name. For example, we can put\nthe {leanRef}`numberOfDay` function in the {lit}`Weekday` namespace. We are\nthen allowed to use the shorter name when we open the namespace.\n\n:::leanFirst\nWe can define functions from {leanRef}`Weekday` to {leanRef}`Weekday`:\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n deriving Repr\n------\nnamespace Weekday\ndef next (d : Weekday) : Weekday :=\n match d with\n | sunday => monday\n | monday => tuesday\n | tuesday => wednesday\n | wednesday => thursday\n | thursday => friday\n | friday => saturday\n | saturday => sunday\n\ndef previous (d : Weekday) : Weekday :=\n match d with\n | sunday => saturday\n | monday => sunday\n | tuesday => monday\n | wednesday => tuesday\n | thursday => wednesday\n | friday => thursday\n | saturday => friday\n\n#eval next (next tuesday) -- Weekday.thursday\n\n#eval next (previous tuesday) -- Weekday.tuesday\n\nexample : next (previous tuesday) = tuesday :=\n rfl\n\nend Weekday\n```\n:::\n\n:::leanFirst\nHow can we prove the general theorem that {leanRef}`next (previous d) = d`\nfor any Weekday {leanRef}`d`? You can use {kw}`match` to provide a proof of the claim for each\nconstructor:\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n deriving Repr\nnamespace Weekday\ndef next (d : Weekday) : Weekday :=\n match d with\n | sunday => monday\n | monday => tuesday\n | tuesday => wednesday\n | wednesday => thursday\n | thursday => friday\n | friday => saturday\n | saturday => sunday\ndef previous (d : Weekday) : Weekday :=\n match d with\n | sunday => saturday\n | monday => sunday\n | tuesday => monday\n | wednesday => tuesday\n | thursday => wednesday\n | friday => thursday\n | saturday => friday\n------\ntheorem next_previous (d : Weekday) : next (previous d) = d :=\n match d with\n | sunday => rfl\n | monday => rfl\n | tuesday => rfl\n | wednesday => rfl\n | thursday => rfl\n | friday => rfl\n | saturday => rfl\n```\n:::\n\nUsing a tactic proof, we can be even more concise:\n\n```lean\ninductive Weekday where\n | sunday : Weekday\n | monday : Weekday\n | tuesday : Weekday\n | wednesday : Weekday\n | thursday : Weekday\n | friday : Weekday\n | saturday : Weekday\n deriving Repr\nnamespace Weekday\ndef next (d : Weekday) : Weekday :=\n match d with\n | sunday => monday\n | monday => tuesday\n | tuesday => wednesday\n | wednesday => thursday\n | thursday => friday\n | friday => saturday\n | saturday => sunday\ndef previous (d : Weekday) : Weekday :=\n match d with\n | sunday => saturday\n | monday => sunday\n | tuesday => monday\n | wednesday => tuesday\n | thursday => wednesday\n | friday => thursday\n | saturday => friday\n------\ntheorem next_previous (d : Weekday) : next (previous d) = d := by\n cases d <;> rfl\n```\n\n{ref \"tactics-for-inductive-types\"}[Tactics for Inductive Types] below will introduce additional\ntactics that are specifically designed to make use of inductive types.\n\nNotice that, under the {tech}[propositions-as-types] correspondence, we can\nuse {kw}`match` to prove theorems as well as define functions. In other\nwords, under the {tech}[propositions-as-types] correspondence, the proof by\ncases is a kind of definition by cases, where what is being “defined”\nis a proof instead of a piece of data.\n\nThe {lean}`Bool` type in the Lean library is an instance of\nenumerated type.\n\n```lean\nnamespace Hidden\n------\ninductive Bool where\n | false : Bool\n | true : Bool\n------\nend Hidden\n```\n\n(To run these examples, we put them in a namespace called {lit}`Hidden`,\nso that a name like {leanRef}`Bool` does not conflict with the {lean}`Bool` in\nthe standard library. This is necessary because these types are part\nof the Lean “prelude” that is automatically imported when the system\nis started.)\n\n\nAs an exercise, you should think about what the introduction and\nelimination rules for these types do. As a further exercise, we\nsuggest defining boolean operations {lean}`and`, {lean}`or`, {lean}`not` on the\n{leanRef}`Bool` type, and verifying common identities. Note that you can define a\nbinary operation like {leanRef}`and` using {kw}`match`:\n\n```lean\nnamespace Hidden\n------\ndef and (a b : Bool) : Bool :=\n match a with\n | true => b\n | false => false\n-------\nend Hidden\n```\n\nSimilarly, most identities can be proved by introducing suitable {kw}`match`, and then using {lean}`rfl`.\n\n# Constructors with Arguments\n%%%\ntag := \"constructors-with-arguments\"\n%%%\n\n:::setup\n```\nvariable (α : Type u) (β : Type v) (a : α) (b : β)\n```\n\n\nEnumerated types are a very special case of inductive types, in which\nthe constructors take no arguments at all. In general, a\n“construction” can depend on data, which is then represented in the\nconstructed argument. Consider the definitions of the product type and\nsum type in the library:\n\n```lean\nnamespace Hidden\n------\ninductive Prod (α : Type u) (β : Type v)\n | mk : α → β → Prod α β\n\ninductive Sum (α : Type u) (β : Type v) where\n | inl : α → Sum α β\n | inr : β → Sum α β\n-------\nend Hidden\n```\n\nConsider what is going on in these examples.\nThe product type has one constructor, {lean}`Prod.mk`,\nwhich takes two arguments. To define a function on {leanRef}`Prod α β`, we\ncan assume the input is of the form {lean}`Prod.mk a b`, and we have to\nspecify the output, in terms of {leanRef}`a` and {leanRef}`b`. We can use this to\ndefine the two projections for {leanRef}`Prod`. Remember that the standard\nlibrary defines notation {lean}`α × β` for {leanRef}`Prod α β` and {lean}`(a, b)` for\n{lean}`Prod.mk a b`.\n\n```lean\nnamespace Hidden\ninductive Prod (α : Type u) (β : Type v)\n | mk : α → β → Prod α β\n------\ndef fst {α : Type u} {β : Type v} (p : Prod α β) : α :=\n match p with\n | Prod.mk a b => a\n\ndef snd {α : Type u} {β : Type v} (p : Prod α β) : β :=\n match p with\n | Prod.mk a b => b\n--------\nend Hidden\n```\n\nThe function {leanRef}`fst` takes a pair, {leanRef}`p`. The {kw}`match` interprets\n{leanRef}`p` as a pair, {leanRef}`Prod.mk a b`. Recall also from {ref \"dependent-type-theory\"}[Dependent Type Theory]\nthat to give these definitions the greatest generality possible, we allow\nthe types {leanRef}`α` and {leanRef}`β` to belong to any universe.\n\n:::\n:::setup\n```\nuniverse u_2 u_3 u_1\nvariable (b : Bool) {α : Type u} {t1 t2 : α}\n```\n\nHere is another example where we use the recursor {lean (type := \"{α : Type u_2} → {β : Type u_3} → {motive : α × β → Sort u_1} → (t : α × β) → ((fst : α) → (snd : β) → motive (fst, snd)) → motive t\")}`Prod.casesOn` instead\nof {kw}`match`.\n\n```lean\ndef prod_example (p : Bool × Nat) : Nat :=\n Prod.casesOn (motive := fun _ => Nat) p\n (fun b n => cond b (2 * n) (2 * n + 1))\n\n#eval prod_example (true, 3)\n\n#eval prod_example (false, 3)\n```\n\nThe argument {leanRef}`motive` is used to specify the type of the object you want to\nconstruct, and it is a function because it may depend on the pair.\nThe {leanRef}`cond` function is a boolean conditional: {lean}`cond b t1 t2`\nreturns {lean}`t1` if {lean}`b` is true, and {lean}`t2` otherwise.\nThe function {leanRef}`prod_example` takes a pair consisting of a boolean,\n{leanRef}`b`, and a number, {leanRef}`n`, and returns either {leanRef}`2 * n` or {leanRef}`2 * n + 1`\naccording to whether {leanRef}`b` is true or false.\n:::\n\n:::setup\n```\nopen Sum\nvariable {α : Type u} {β : Type v} (a : α) (b : β)\n```\n\nIn contrast, the sum type has _two_ constructors, {lean}`inl` and {lean}`inr`\n(for “insert left” and “insert right”), each of which takes _one_\n(explicit) argument. To define a function on {lean}`Sum α β`, we have to\nhandle two cases: either the input is of the form {lean}`inl a`, in which\ncase we have to specify an output value in terms of {leanRef}`a`, or the\ninput is of the form {lean}`inr b`, in which case we have to specify an\noutput value in terms of {leanRef}`b`.\n\n```lean\ndef sum_example (s : Sum Nat Nat) : Nat :=\n Sum.casesOn (motive := fun _ => Nat) s\n (fun n => 2 * n)\n (fun n => 2 * n + 1)\n\n#eval sum_example (Sum.inl 3)\n\n#eval sum_example (Sum.inr 3)\n```\n\n:::\n\n:::setup\n```\nopen Sum\nvariable (n : Nat)\n```\n\nThis example is similar to the previous one, but now an input to\n{leanRef}`sum_example` is implicitly either of the form {lean}`inl n` or {lean}`inr n`.\nIn the first case, the function returns {lean}`2 * n`, and the second\ncase, it returns {lean}`2 * n + 1`.\n\n:::\n\n:::setup\n```\nvariable {α β : Type} {a : α} {b : β}\nopen Sum\n```\n\n\nNotice that the product type depends on parameters {lean}`α β : Type`\nwhich are arguments to the constructors as well as {lean}`Prod`. Lean\ndetects when these arguments can be inferred from later arguments to a\nconstructor or the return type, and makes them implicit in that case.\n\nIn {ref \"defining-the-natural-numbers\"}[Defining the Natural Numbers]\nwe will see what happens when the\nconstructor of an inductive type takes arguments from the inductive\ntype itself. What characterizes the examples we consider in this\nsection is that each constructor relies only on previously specified types.\n\nNotice that a type with multiple constructors is disjunctive: an\nelement of {lean}`Sum α β` is either of the form {lean}`inl a` _or_ of the\nform {lean}`inl b`. A constructor with multiple arguments introduces\nconjunctive information: from an element {lean}`Prod.mk a b` of\n{lean}`Prod α β` we can extract {leanRef}`a` _and_ {leanRef}`b`. An arbitrary inductive type can\ninclude both features, by having any number of constructors, each of\nwhich takes any number of arguments.\n\n:::\n\nAs with function definitions, Lean's inductive definition syntax will\nlet you put named arguments to the constructors before the colon:\n\n```lean\nnamespace Hidden\n------\ninductive Prod (α : Type u) (β : Type v) where\n | mk (fst : α) (snd : β) : Prod α β\n\ninductive Sum (α : Type u) (β : Type v) where\n | inl (a : α) : Sum α β\n | inr (b : β) : Sum α β\n-------\nend Hidden\n```\n\nThe results of these definitions are essentially the same as the ones given earlier in this section.\n\nA type, like {leanRef}`Prod`, that has only one constructor is purely\nconjunctive: the constructor simply packs the list of arguments into a\nsingle piece of data, essentially a tuple where the type of subsequent\narguments can depend on the type of the initial argument. We can also\nthink of such a type as a “record” or a “structure”. In Lean, the\nkeyword {kw}`structure` can be used to define such an inductive type as\nwell as its projections, at the same time.\n\n```lean\nnamespace Hidden\n------\nstructure Prod (α : Type u) (β : Type v) where\n mk ::\n fst : α\n snd : β\n-------\nend Hidden\n```\n\nThis example simultaneously introduces the inductive type, {leanRef}`Prod`,\nits constructor, {leanRef}`mk`, the usual eliminators ({lit}`rec` and\n{lit}`recOn`), as well as the projections, {leanRef}`fst` and {leanRef}`snd`, as\ndefined above.\n\nIf you do not name the constructor, Lean uses {lit}`mk` as a default. For\nexample, the following defines a record to store a color as a triple\nof RGB values:\n\n```lean\nstructure Color where\n red : Nat\n green : Nat\n blue : Nat\nderiving Repr\n\ndef yellow := Color.mk 255 255 0\n\n#eval Color.red yellow\n```\n\nThe definition of {leanRef}`yellow` forms the record with the three values\nshown, and the projection {leanRef}`Color.red` returns the red component.\n\nThe {kw}`structure` command is especially useful for defining algebraic\nstructures, and Lean provides substantial infrastructure to support\nworking with them. Here, for example, is the definition of a\nsemigroup:\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc : ∀ a b c, mul (mul a b) c = mul a (mul b c)\n```\n\nWe will see more examples in the chapter on {ref \"structures-and-records\"}[structures and records].\n\n:::leanFirst\nWe have already discussed the dependent product type {leanRef}`Sigma`:\n\n```lean\nnamespace Hidden\n------\ninductive Sigma {α : Type u} (β : α → Type v) where\n | mk : (a : α) → β a → Sigma β\n-------\nend Hidden\n```\n:::\n\nTwo more examples of inductive types in the library are the following:\n\n```lean\nnamespace Hidden\n------\ninductive Option (α : Type u) where\n | none : Option α\n | some : α → Option α\n\ninductive Inhabited (α : Type u) where\n | mk : α → Inhabited α\n-------\nend Hidden\n```\n\n:::setup\n```\nvariable {α : Type u} {β : Type v} {γ : Type u'} (b : β) (f : α → Option β) (a : α)\n```\n\nIn the semantics of dependent type theory, there is no built-in notion\nof a partial function. Every element of a function type {lean}`α → β` or a\ndependent function type {lean}`(a : α) → β` is assumed to have a value\nat every input. The {lean}`Option` type provides a way of representing partial functions. An\nelement of {lean}`Option β` is either {lean}`none` or of the form {lean}`some b`,\nfor some value {lean}`b : β`. Thus we can think of an element {lean}`f` of the\ntype {lean}`α → Option β` as being a partial function from {lean}`α` to {lean}`β`:\nfor every {lean}`a : α`, {lean}`f a` either returns {lean (type := \"Option β\")}`none`, indicating\n{lean}`f a` is “undefined”, or {lean}`some b`.\n\nAn element of {lean}`Inhabited α` is simply a witness to the fact that\nthere is an element of {lean}`α`. Later, we will see that {lean}`Inhabited` is\nan example of a _type class_ in Lean: Lean can be instructed that\nsuitable base types are inhabited, and can automatically infer that\nother constructed types are inhabited on that basis.\n\nAs exercises, we encourage you to develop a notion of composition for\npartial functions from {lean}`α` to {lean}`β` and {lean}`β` to {lean}`γ`, and show\nthat it behaves as expected. We also encourage you to show that\n{lean}`Bool` and {lean}`Nat` are inhabited, that the product of two inhabited\ntypes is inhabited, and that the type of functions to an inhabited\ntype is inhabited.\n\n:::\n\n# Inductively Defined Propositions\n%%%\ntag := \"inductively-defined-propositions\"\n%%%\n\nInductively defined types can live in any type universe, including the\nbottom-most one, {lean}`Prop`. In fact, this is exactly how the logical\nconnectives are defined.\n\n```lean\nnamespace Hidden\n------\ninductive False : Prop\n\ninductive True : Prop where\n | intro : True\n\ninductive And (a b : Prop) : Prop where\n | intro : a → b → And a b\n\ninductive Or (a b : Prop) : Prop where\n | inl : a → Or a b\n | inr : b → Or a b\n-------\nend Hidden\n```\n\n:::setup\n```\nvariable (p : Prop) (hp : p) (α : Type u) (β : Type v)\n```\n\nYou should think about how these give rise to the introduction and\nelimination rules that you have already seen. There are rules that\ngovern what the eliminator of an inductive type can eliminate _to_,\nthat is, what kinds of types can be the target of a recursor. Roughly\nspeaking, what characterizes inductive types in {lean}`Prop` is that one\ncan only eliminate to other types in {lean}`Prop`. This is consistent with\nthe understanding that if {lean}`p : Prop`, an element {lean}`hp : p` carries\nno data. There is a small exception to this rule, however, which we\nwill discuss below, in {ref \"inductive-families\"}[Inductive Families].\n\n\nEven the existential quantifier is inductively defined:\n\n```lean\nnamespace Hidden\n------\ninductive Exists {α : Sort u} (p : α → Prop) : Prop where\n | intro (w : α) (h : p w) : Exists p\n-------\nend Hidden\n```\n\nKeep in mind that the notation {lean}`∃ x : α, p` is syntactic sugar for {lean}`Exists (fun x : α => p)`.\n\n\nThe definitions of {lean}`False`, {lean}`True`, {lean}`And`, and {lean}`Or` are\nperfectly analogous to the definitions of {lean}`Empty`, {lean}`Unit`,\n{lean}`Prod`, and {lean}`Sum`. The difference is that the first group yields\nelements of {lean}`Prop`, and the second yields elements of {lean}`Type u` for\nsome {leanRef}`u`. In a similar way, {leanRef}`∃ x : α, p` is a {lean}`Prop`-valued\nvariant of {lean}`Σ x : α, β`.\n\n:::\n\n::::setup\n```\nvariable (α : Type u) (β : Type v) (p : Prop)\n```\n\nThis is a good place to mention another inductive type, denoted\n{lean}`{x : α // p}`, which is sort of a hybrid between\n{lean}`∃ x : α, p` and {lean}`Σ x : α, β`.\n\n```lean\nnamespace Hidden\n------\ninductive Subtype {α : Type u} (p : α → Prop) where\n | mk : (x : α) → p x → Subtype p\n-------\nend Hidden\n```\n::::\n::::setup\n```\nvariable {α : Type u} {p : α → Prop}\n```\n\n:::leanFirst\nIn fact, in Lean, {leanRef}`Subtype` is defined using the structure command:\n\n```lean\nnamespace Hidden\n------\nstructure Subtype {α : Sort u} (p : α → Prop) where\n val : α\n property : p val\n-------\nend Hidden\n```\n\n\nThe notation {lean}`{x : α // p x}` is syntactic sugar for {lean}`Subtype (fun x : α => p x)`.\nIt is modeled after subset notation in set theory: the idea is that {leanRef}`{x : α // p x}`\ndenotes the collection of elements of {leanRef}`α` that have property {leanRef}`p`.\n:::\n\n::::\n\n# Defining the Natural Numbers\n%%%\ntag := \"defining-the-natural-numbers\"\n%%%\n\nThe inductively defined types we have seen so far are “flat”:\nconstructors wrap data and insert it into a type, and the\ncorresponding recursor unpacks the data and acts on it. Things get\nmuch more interesting when the constructors act on elements of the\nvery type being defined. A canonical example is the type {lean}`Nat` of\nnatural numbers:\n\n```lean\nnamespace Hidden\n------\ninductive Nat where\n | zero : Nat\n | succ : Nat → Nat\n-------\nend Hidden\n```\n\n:::setup\n```\nopen Nat\nvariable {motive : Nat → Sort u} {f : (n : Nat) → motive n} {n : Nat}\n```\n\nThere are two constructors. We start with {lean}`zero : Nat`; it takes\nno arguments, so we have it from the start. In contrast, the\nconstructor {lean}`succ` can only be applied to a previously constructed\n{lean}`Nat`. Applying it to {lean}`zero` yields {lean}`succ zero : Nat`. Applying\nit again yields {lean}`succ (succ zero) : Nat`, and so on. Intuitively,\n{lean}`Nat` is the “smallest” type with these constructors, meaning that\nit is exhaustively (and freely) generated by starting with {lean}`zero`\nand applying {lean}`succ` repeatedly.\n\n\nAs before, the recursor for {lean}`Nat` is designed to define a dependent\nfunction {lean}`f` from {lean}`Nat` to any domain, that is, an element {lean}`f`\nof {lean}`(n : Nat) → motive n` for some {lean}`motive : Nat → Sort u`.\nIt has to handle two cases: the case where the input is {lean}`zero`, and the case where\nthe input is of the form {lean}`succ n` for some {lean}`n : Nat`. In the first\ncase, we simply specify a target value with the appropriate type, as\nbefore. In the second case, however, the recursor can assume that a\nvalue of {lean}`f` at {lean}`n` has already been computed. As a result, the\nnext argument to the recursor specifies a value for {lean}`f (succ n)` in\nterms of {lean}`n` and {lean}`f n`. If we check the type of the recursor,\nyou find the following:\n:::\n\n```signature\nNat.rec.{u} :\n {motive : Nat → Sort u} →\n (zero : motive Nat.zero) →\n (succ : (n : Nat) → motive n → motive (Nat.succ n)) →\n (t : Nat) → motive t\n```\n\nThe implicit argument, {leanRef}`motive`, is the codomain of the function being defined.\nIn type theory it is common to say {leanRef}`motive` is the _motive_ for the elimination/recursion,\nsince it describes the kind of object we wish to construct.\nThe next two arguments specify how to compute the zero and successor cases, as described above.\nThey are also known as the _minor premises_.\nFinally, the {leanRef}`t : Nat` is the input to the function. It is also known as the _major premise_.\n\nThe {name}`Nat.recOn` is similar to {name}`Nat.rec` but the major premise occurs before the minor premises.\n\n```signature\nNat.recOn.{u} :\n {motive : Nat → Sort u} →\n (t : Nat) →\n (zero : motive Nat.zero) →\n (succ : ((n : Nat) → motive n → motive (Nat.succ n))) →\n motive t\n```\n\n:::setup\n```\ndef add (m n : Nat) : Nat :=\n match n with\n | Nat.zero => m\n | Nat.succ n => Nat.succ (add m n)\nvariable {n m : Nat}\nopen Nat\n```\n\nConsider, for example, the addition function {lean}`add m n` on the\nnatural numbers. Fixing {lean}`m`, we can define addition by recursion on\n{lean}`n`. In the base case, we set {lean}`add m zero` to {lean}`m`. In the\nsuccessor step, assuming the value {lean}`add m n` is already determined,\nwe define {lean}`add m (succ n)` to be {lean}`succ (add m n)`.\n:::\n\n```lean\nnamespace Hidden\n------\ninductive Nat where\n | zero : Nat\n | succ : Nat → Nat\nderiving Repr\n\ndef add (m n : Nat) : Nat :=\n match n with\n | Nat.zero => m\n | Nat.succ n => Nat.succ (add m n)\n\nopen Nat\n\n#eval add (succ (succ zero)) (succ zero)\n-------\nend Hidden\n```\n\n\nIt is useful to put such definitions into a namespace, {lean}`Nat`. We can\nthen go on to define familiar notation in that namespace. The two\ndefining equations for addition now hold definitionally:\n\n```lean\nnamespace Hidden\ninductive Nat where\n | zero : Nat\n | succ : Nat → Nat\nderiving Repr\n------\nnamespace Nat\n\ndef add (m n : Nat) : Nat :=\n match n with\n | Nat.zero => m\n | Nat.succ n => Nat.succ (add m n)\n\ninstance : Add Nat where\n add := add\n\ntheorem add_zero (m : Nat) : m + zero = m := rfl\ntheorem add_succ (m n : Nat) : m + succ n = succ (m + n) := rfl\n\nend Nat\n-------\nend Hidden\n```\n\nWe will explain how the {kw}`instance` command works in\nthe {ref \"type-classes\"}[Type Classes] chapter. In the examples below, we will use\nLean's version of the natural numbers.\n\n::::leanFirst\n\n:::setup\n```\nvariable {n : Nat} {motive : Nat → Sort u} {ih : motive n}\n```\n\nProving a fact like {lean}`0 + n = n`, however, requires a proof by induction.\nAs observed above, the induction principle is just a special case of the recursion principle,\nwhen the codomain {lean}`motive n` is an element of {lean}`Prop`. It represents the familiar\npattern of an inductive proof: to prove {lean}`∀ n, motive n`, first prove {lean}`motive 0`,\nand then, for arbitrary {lean}`n`, assume {lean}`ih : motive n` and prove {lean}`motive (n + 1)`.\n:::\n\n```lean\nnamespace Hidden\n------\nopen Nat\n\ntheorem zero_add (n : Nat) : 0 + n = n :=\n Nat.recOn (motive := fun x => 0 + x = x)\n n\n (show 0 + 0 = 0 from rfl)\n (fun (n : Nat) (ih : 0 + n = n) =>\n show 0 + (n + 1) = n + 1 from\n calc 0 + (n + 1)\n _ = (0 + n) + 1 := rfl\n _ = n + 1 := by rw [ih])\n-------\nend Hidden\n```\n\n::::\n\nNotice that, once again, when {name}`Nat.recOn` is used in the context of\na proof, it is really the induction principle in disguise. The\n{tactic}`rw` and {tactic}`simp` tactics tend to be very effective in proofs\nlike these. In this case, each can be used to reduce the proof to:\n\n\n```lean\nnamespace Hidden\n------\nopen Nat\n\ntheorem zero_add (n : Nat) : 0 + n = n :=\n Nat.recOn (motive := fun x => 0 + x = x) n\n rfl\n (fun n ih => by simp [ih])\n-------\nend Hidden\n```\n\n:::setup\n```\nvariable (m n k : Nat)\n```\n\nAs another example, let us prove the associativity of addition,\n{lean}`∀ m n k, m + n + k = m + (n + k)`.\n(The notation {leanRef}`+`, as we have defined it, associates to the left, so {leanRef}`m + n + k` is really {lean}`(m + n) + k`.)\nThe hardest part is figuring out which variable to do the induction on. Since addition is defined by recursion on the second argument,\n{leanRef (in := \"n k,\")}`k` is a good guess, and once we make that choice the proof almost writes itself:\n:::\n\n```lean\nnamespace Hidden\n------\nopen Nat\ntheorem add_assoc (m n k : Nat) : m + n + k = m + (n + k) :=\n Nat.recOn (motive := fun k => m + n + k = m + (n + k)) k\n (show m + n + 0 = m + (n + 0) from rfl)\n (fun k (ih : m + n + k = m + (n + k)) =>\n show m + n + (k + 1) = m + (n + (k + 1)) from\n calc m + n + (k + 1)\n _ = (m + n + k) + 1 := rfl\n _ = (m + (n + k)) + 1 := by rw [ih]\n _ = m + ((n + k) + 1) := rfl\n _ = m + (n + (k + 1)) := rfl)\n-------\nend Hidden\n```\n\nOnce again, you can reduce the proof to:\n\n```lean\nopen Nat\ntheorem add_assoc (m n k : Nat) : m + n + k = m + (n + k) :=\n Nat.recOn (motive := fun k => m + n + k = m + (n + k)) k\n rfl\n (fun k ih => by simp [add_succ (m + n) k, ih]; rfl)\n```\n\nSuppose we try to prove the commutativity of addition. Choosing induction on the second argument, we might begin as follows:\n\n```lean\nopen Nat\ntheorem add_comm (m n : Nat) : m + n = n + m :=\n Nat.recOn (motive := fun x => m + x = x + m) n\n (show m + 0 = 0 + m by rw [Nat.zero_add, Nat.add_zero])\n (fun (n : Nat) (ih : m + n = n + m) =>\n show m + succ n = succ n + m from\n calc m + succ n\n _ = succ (m + n) := rfl\n _ = succ (n + m) := by rw [ih]\n _ = succ n + m := sorry)\n```\n\nAt this point, we see that we need another supporting fact, namely, that {leanRef}`succ (n + m)`{lit}` = `{leanRef}`succ n + m`.\nYou can prove this by induction on {leanRef}`m`:\n\n```lean\nopen Nat\n\ntheorem succ_add (n m : Nat) : succ n + m = succ (n + m) :=\n Nat.recOn (motive := fun x => succ n + x = succ (n + x)) m\n (show succ n + 0 = succ (n + 0) from rfl)\n (fun (m : Nat) (ih : succ n + m = succ (n + m)) =>\n show succ n + succ m = succ (n + succ m) from\n calc succ n + succ m\n _ = succ (succ n + m) := rfl\n _ = succ (succ (n + m)) := by rw [ih]\n _ = succ (n + succ m) := rfl)\n```\n\nYou can then replace the {leanRef}`sorry` in the previous proof with {leanRef}`succ_add`. Yet again, the proofs can be compressed:\n\n```lean\nnamespace Hidden\ninductive Nat where\n | zero : Nat\n | succ : Nat → Nat\nderiving Repr\n\ndef add (m n : Nat) : Nat :=\n match n with\n | Nat.zero => m\n | Nat.succ n => Nat.succ (add m n)\n\ninstance : Add Nat where\n add := add\n\nnamespace Nat\ntheorem add_zero (m : Nat) : m + zero = m := rfl\n\ntheorem add_succ (m n : Nat) : m + succ n = succ (m + n) := rfl\n\ntheorem zero_add (n : Nat) : zero + n = n :=\n Nat.recOn (motive := fun x => zero + x = x) n\n rfl\n (fun n ih => by simpa [add_zero, add_succ])\n\nend Nat\n------\nopen Nat\ntheorem succ_add (n m : Nat) : succ n + m = succ (n + m) :=\n Nat.recOn (motive := fun x => succ n + x = succ (n + x)) m\n rfl\n (fun m ih => by simpa [add_succ (succ n)])\n\ntheorem add_comm (m n : Nat) : m + n = n + m :=\n Nat.recOn (motive := fun x => m + x = x + m) n\n (by simp [add_zero, zero_add])\n (fun m ih => by simp_all [succ_add, add_succ])\n-------\nend Hidden\n```\n\n# Other Recursive Data Types\n%%%\ntag := \"other-recursive-data-types\"\n%%%\n\n:::leanFirst\nLet us consider some more examples of inductively defined types. For\nany type, {leanRef}`α`, the type {leanRef}`List α` of lists of elements of {leanRef}`α` is\ndefined in the library.\n\n```lean\nnamespace Hidden\n------\ninductive List (α : Type u) where\n | nil : List α\n | cons (h : α) (t : List α) : List α\n\nnamespace List\n\ndef append (as bs : List α) : List α :=\n match as with\n | nil => bs\n | cons a as => cons a (append as bs)\n\ntheorem nil_append (as : List α) : append nil as = as :=\n rfl\n\ntheorem cons_append (a : α) (as bs : List α) :\n append (cons a as) bs = cons a (append as bs) :=\n rfl\n\nend List\n-------\nend Hidden\n```\n\nA list of elements of type {leanRef}`α` is either the empty list, {leanRef}`nil`, or\nan element {leanRef}`h : α` followed by a list {leanRef}`t : List α`.\nThe first element, {leanRef}`h`, is commonly known as the “head” of the list,\nand the remainder, {leanRef}`t`, is known as the “tail.”\n:::\n\nAs an exercise, prove the following:\n\n```lean\nnamespace Hidden\ninductive List (α : Type u) where\n| nil : List α\n| cons : α → List α → List α\nnamespace List\ndef append (as bs : List α) : List α :=\n match as with\n | nil => bs\n | cons a as => cons a (append as bs)\ntheorem nil_append (as : List α) : append nil as = as :=\n rfl\ntheorem cons_append (a : α) (as bs : List α)\n : append (cons a as) bs = cons a (append as bs) :=\n rfl\n------\ntheorem append_nil (as : List α) :\n append as nil = as :=\n sorry\n\ntheorem append_assoc (as bs cs : List α) :\n append (append as bs) cs = append as (append bs cs) :=\n sorry\n-------\nend List\nend Hidden\n```\n\n:::setup\n```\nuniverse u\ndef length : {α : Type u} → List α → Nat := List.length\ndef append : {α : Type u} → List α → List α → List α := List.append\nvariable (as bs : List α)\n```\n\nTry also defining the function {lean}`length : {α : Type u} → List α → Nat` that returns the length of a list,\nand prove that it behaves as expected (for example, {lean}`length (append as bs) = length as + length bs`).\n:::\n\nFor another example, we can define the type of binary trees:\n\n```lean\ninductive BinaryTree where\n | leaf : BinaryTree\n | node : BinaryTree → BinaryTree → BinaryTree\n```\n\nIn fact, we can even define the type of countably branching trees:\n\n```lean\ninductive CBTree where\n | leaf : CBTree\n | sup : (Nat → CBTree) → CBTree\n\nnamespace CBTree\n\ndef succ (t : CBTree) : CBTree :=\n sup (fun _ => t)\n\ndef toCBTree : Nat → CBTree\n | 0 => leaf\n | n+1 => succ (toCBTree n)\n\ndef omega : CBTree :=\n sup toCBTree\n\nend CBTree\n```\n\n# Tactics for Inductive Types\n%%%\ntag := \"tactics-for-inductive-types\"\n%%%\n\nGiven the fundamental importance of inductive types in Lean, it should\nnot be surprising that there are a number of tactics designed to work\nwith them effectively. We describe some of them here.\n\n:::setup\n```\nvariable {x : InductiveType}\n```\n\nThe {tactic}`cases` tactic works on elements of an inductively defined type,\nand does what the name suggests: it decomposes the element according\nto each of the possible constructors. In its most basic form, it is\napplied to an element {lean}`x` in the local context. It then reduces the\ngoal to cases in which {lean}`x` is replaced by each of the constructions.\n:::\n\n```lean\nexample (p : Nat → Prop)\n (hz : p 0) (hs : ∀ n, p (Nat.succ n)) :\n ∀ n, p n := by\n intro n\n cases n\n . exact hz\n--^ PROOF_STATE: A\n . apply hs\n--^ PROOF_STATE: B\n```\n\nIn the first branch, the proof state is:\n```proofState A\ncase zero\np : Nat → Prop\nhz : p 0\nhs : ∀ (n : Nat), p n.succ\n⊢ p 0\n```\nIn the second branch, it is:\n```proofState B\ncase succ\np : Nat → Prop\nhz : p 0\nhs : ∀ (n : Nat), p n.succ\nn✝ : Nat\n⊢ p (n✝ + 1)\n```\n\n:::leanFirst\nThere are extra bells and whistles. For one thing, {leanRef}`cases` allows\nyou to choose the names for each alternative using a\n{leanRef}`with` clause. In the next example, for example, we choose the name\n{leanRef}`m` for the argument to {leanRef}`succ`, so that the second case refers to\n{leanRef}`succ m`. More importantly, the cases tactic will detect any items\nin the local context that depend on the target variable. It reverts\nthese elements, does the split, and reintroduces them. In the example\nbelow, notice that the hypothesis {leanRef}`h : n ≠ 0` becomes {leanRef}`h : 0 ≠ 0`\nin the first branch, and {leanRef}`h : m + 1 ≠ 0` in the second.\n\n```lean (showProofStates := \"C D\")\nopen Nat\n\nexample (n : Nat) (h : n ≠ 0) : succ (pred n) = n := by\n cases n with\n | zero =>\n -- ^ PROOF_STATE: C\n apply absurd rfl h\n | succ m =>\n -- ^ PROOF_STATE: D\n rfl\n```\n:::\n\nNotice that {leanRef}`cases` can be used to produce data as well as prove propositions.\n\n```lean\ndef f (n : Nat) : Nat := by\n cases n; exact 3; exact 7\n\nexample : f 0 = 3 := rfl\nexample : f 5 = 7 := rfl\n```\n\nOnce again, cases will revert, split, and then reintroduce dependencies in the context.\n\n```lean\ndef Tuple (α : Type) (n : Nat) :=\n { as : List α // as.length = n }\n\ndef f {n : Nat} (t : Tuple α n) : Nat := by\n cases n; exact 3; exact 7\n\ndef myTuple : Tuple Nat 3 :=\n ⟨[0, 1, 2], rfl⟩\n\nexample : f myTuple = 7 :=\n rfl\n```\n\nHere is an example of multiple constructors with arguments.\n\n```lean\ninductive Foo where\n | bar1 : Nat → Nat → Foo\n | bar2 : Nat → Nat → Nat → Foo\n\ndef silly (x : Foo) : Nat := by\n cases x with\n | bar1 a b => exact b\n | bar2 c d e => exact e\n```\n\nThe alternatives for each constructor don't need to be solved\nin the order the constructors were declared.\n\n```lean\ninductive Foo where\n | bar1 : Nat → Nat → Foo\n | bar2 : Nat → Nat → Nat → Foo\n------\ndef silly (x : Foo) : Nat := by\n cases x with\n | bar2 c d e => exact e\n | bar1 a b => exact b\n```\n\n:::leanFirst\nThe syntax of the {leanRef}`with` is convenient for writing structured proofs.\nLean also provides a complementary {leanRef}`case` tactic, which allows you to focus on goal\nassign variable names.\n\n```lean\ninductive Foo where\n | bar1 : Nat → Nat → Foo\n | bar2 : Nat → Nat → Nat → Foo\n------\ndef silly (x : Foo) : Nat := by\n cases x\n case bar1 a b => exact b\n case bar2 c d e => exact e\n```\n:::\n\nThe {leanRef}`case` tactic is clever, in that it will match the constructor to the appropriate goal. For example, we can fill the goals above in the opposite order:\n\n```lean\ninductive Foo where\n | bar1 : Nat → Nat → Foo\n | bar2 : Nat → Nat → Nat → Foo\n------\ndef silly (x : Foo) : Nat := by\n cases x\n case bar2 c d e => exact e\n case bar1 a b => exact b\n```\n\nYou can also use {leanRef}`cases` with an arbitrary expression. Assuming that\nexpression occurs in the goal, the cases tactic will generalize over\nthe expression, introduce the resulting universally quantified\nvariable, and case on that.\n\n```lean\nopen Nat\n\nexample (p : Nat → Prop) (hz : p 0) (hs : ∀ n, p (succ n)) (m k : Nat)\n : p (m + 3 * k) := by\n cases m + 3 * k\n exact hz -- goal is p 0\n apply hs -- goal is a : Nat ⊢ p (succ a)\n```\n\nThink of this as saying “split on cases as to whether {leanRef}`m + 3 * k` is\nzero or the successor of some number.” The result is functionally\nequivalent to the following:\n\n```lean (showProofStates := \"Z S\")\nopen Nat\n\nexample (p : Nat → Prop) (hz : p 0) (hs : ∀ n, p (succ n)) (m k : Nat)\n : p (m + 3 * k) := by\n generalize m + 3 * k = n\n cases n\n -- ^ PROOF_STATE: Z\n exact hz\n -- ^ PROOF_STATE: S\n apply hs\n```\n\nNotice that the expression {leanRef}`m + 3 * k` is erased by {leanRef}`generalize`; all\nthat matters is whether it is of the form {leanRef}`0` or {leanRef}`n✝ + 1`. This\nform of {leanRef}`cases` will _not_ revert any hypotheses that also mention\nthe expression in the equation (in this case, {leanRef}`m + 3 * k`). If such a\nterm appears in a hypothesis and you want to generalize over that as\nwell, you need to {tactic}`revert` it explicitly.\n\nIf the expression you case on does not appear in the goal, the\n{tactic}`cases` tactic uses {tactic}`have` to put the type of the expression into\nthe context. Here is an example:\n\n```lean\nexample (p : Prop) (m n : Nat)\n (h₁ : m < n → p) (h₂ : m ≥ n → p) : p := by\n cases Nat.lt_or_ge m n\n case inl hlt => exact h₁ hlt\n -- ^ PROOF_STATE: one\n case inr hge => exact h₂ hge\n -- ^ PROOF_STATE: two\n```\n\nThe theorem {leanRef}`Nat.lt_or_ge m n` says {leanRef}`m < n`{lit}` ∨ `{leanRef}`m ≥ n`, and it is\nnatural to think of the proof above as splitting on these two\ncases. In the first branch, we have the hypothesis {leanRef}`hlt : m < n`, and\nin the second we have the hypothesis {leanRef}`hge : m ≥ n`. The proof above\nis functionally equivalent to the following:\n\n```lean\nexample (p : Prop) (m n : Nat)\n (h₁ : m < n → p) (h₂ : m ≥ n → p) : p := by\n have h : m < n ∨ m ≥ n := Nat.lt_or_ge m n\n cases h\n case inl hlt => exact h₁ hlt\n case inr hge => exact h₂ hge\n```\n\nAfter the first two lines, we have {leanRef}`h : m < n ∨ m ≥ n` as a\nhypothesis, and we simply do cases on that.\n\n:::leanFirst\nHere is another example, where we use the decidability of equality on\nthe natural numbers to split on the cases {leanRef}`m = n` and {leanRef}`m ≠ n`.\n\n```lean\n#check Nat.sub_self\n\nexample (m n : Nat) : m - n = 0 ∨ m ≠ n := by\n cases Decidable.em (m = n) with\n | inl heq => rw [heq]; apply Or.inl; exact Nat.sub_self n\n | inr hne => apply Or.inr; exact hne\n```\n:::\n\nRemember that if you {kw}`open `{lit}`Classical`, you can use the law of the\nexcluded middle for any proposition at all. But using type class\ninference (see {ref \"type-classes\"}[Type Classes]), Lean can actually\nfind the relevant decision procedure, which means that you can use the\ncase split in a computable function.\n\n:::leanFirst\nJust as the {leanRef}`cases` tactic can be used to carry out proof by cases,\nthe {leanRef}`induction` tactic can be used to carry out proofs by\ninduction. The syntax is similar to that of {leanRef}`cases`, except that the\nargument can only be a term in the local context. Here is an example:\n\n```lean\nnamespace Hidden\n------\ntheorem zero_add (n : Nat) : 0 + n = n := by\n induction n with\n | zero => rfl\n | succ n ih => rw [Nat.add_succ, ih]\n-------\nend Hidden\n```\n:::\n\n:::leanFirst\nAs with {leanRef}`cases`, we can use the {leanRef}`case` tactic instead of {leanRef}`with`.\n\n```lean\nnamespace Hidden\n------\ntheorem zero_add (n : Nat) : 0 + n = n := by\n induction n\n case zero => rfl\n case succ n ih => rw [Nat.add_succ, ih]\n-------\nend Hidden\n```\n:::\n\nHere are some additional examples:\n:::TODO\nFIXME\n:::\n```lean\nnamespace Hidden\ninductive Nat where\n | zero\n | succ : Nat → Nat\n\ndef Nat.toNat : Nat → _root_.Nat\n | .zero => .zero\n | .succ n => .succ n.toNat\n\ndef Nat.ofNat : _root_.Nat → Nat\n | .zero => .zero\n | .succ n => .succ (.ofNat n)\n\ndef add (m n : Nat) : Nat :=\n match n with\n | Nat.zero => m\n | Nat.succ n => Nat.succ (add m n)\n\ninstance : Add Nat where\n add := add\n\ninstance : OfNat Nat n where\n ofNat := .ofNat n\n\n@[simp]\ntheorem zero_zero : (.zero : Nat) = 0 := rfl\ntheorem add_zero (n : Nat) : n + 0 = n := rfl\ntheorem add_succ (n k : Nat) : n + k.succ = (n + k).succ := rfl\n------\nopen Nat\n\ntheorem zero_add (n : Nat) : 0 + n = n := by\n induction n <;> simp [*, add_zero, add_succ]\n\ntheorem succ_add (m n : Nat) : succ m + n = succ (m + n) := by\n induction n <;> simp [*, add_zero, add_succ]\n\ntheorem add_comm (m n : Nat) : m + n = n + m := by\n induction n <;> simp [*, add_zero, add_succ, succ_add, zero_add]\n\ntheorem add_assoc (m n k : Nat) : m + n + k = m + (n + k) := by\n induction k <;> simp [*, add_zero, add_succ]\n-------\nend Hidden\n```\n\nThe {leanRef}`induction` tactic also supports user-defined induction principles with\nmultiple targets (aka major premises). This example uses {name}`Nat.mod.inductionOn`, which has the following signature:\n```signature\nNat.mod.inductionOn\n {motive : Nat → Nat → Sort u}\n (x y : Nat)\n (ind : ∀ x y, 0 < y ∧ y ≤ x → motive (x - y) y → motive x y)\n (base : ∀ x y, ¬(0 < y ∧ y ≤ x) → motive x y) :\n motive x y\n```\n\n\n```lean\nexample (x : Nat) {y : Nat} (h : y > 0) : x % y < y := by\n induction x, y using Nat.mod.inductionOn with\n | ind x y h₁ ih =>\n rw [Nat.mod_eq_sub_mod h₁.2]\n exact ih h\n | base x y h₁ =>\n have : ¬ 0 < y ∨ ¬ y ≤ x := Iff.mp (Decidable.not_and_iff_or_not ..) h₁\n match this with\n | Or.inl h₁ => exact absurd h h₁\n | Or.inr h₁ =>\n have hgt : y > x := Nat.gt_of_not_le h₁\n rw [← Nat.mod_eq_of_lt hgt] at hgt\n assumption\n```\n\nYou can use the {kw}`match` notation in tactics too:\n\n```lean\nexample : p ∨ q → q ∨ p := by\n intro h\n match h with\n | Or.inl _ => apply Or.inr; assumption\n | Or.inr h2 => apply Or.inl; exact h2\n```\n\n:::leanFirst\nAs a convenience, pattern-matching has been integrated into tactics such as {leanRef}`intro` and {leanRef}`funext`.\n\n```lean\nexample : s ∧ q ∧ r → p ∧ r → q ∧ p := by\n intro ⟨_, ⟨hq, _⟩⟩ ⟨hp, _⟩\n exact ⟨hq, hp⟩\n\nexample :\n (fun (x : Nat × Nat) (y : Nat × Nat) => x.1 + y.2)\n =\n (fun (x : Nat × Nat) (z : Nat × Nat) => z.2 + x.1) := by\n funext (a, b) (c, d)\n show a + d = d + a\n rw [Nat.add_comm]\n```\n:::\n\n:::leanFirst\nWe close this section with one last tactic that is designed to\nfacilitate working with inductive types, namely, the {leanRef}`injection`\ntactic. By design, the elements of an inductive type are freely\ngenerated, which is to say, the constructors are injective and have\ndisjoint ranges. The {leanRef}`injection` tactic is designed to make use of\nthis fact:\n\n```lean\nopen Nat\n\nexample (m n k : Nat) (h : succ (succ m) = succ (succ n))\n : n + k = m + k := by\n injection h with h'\n injection h' with h''\n rw [h'']\n```\n:::\n\nThe first instance of the tactic adds {leanRef}`h' : m.succ = n.succ` to the\ncontext, and the second adds {leanRef}`h'' : m = n`.\n\nThe {leanRef}`injection` tactic also detects contradictions that arise when different constructors\nare set equal to one another, and uses them to close the goal.\n\n```lean\nopen Nat\n\nexample (m n : Nat) (h : succ m = 0) : n = n + 7 := by\n injection h\n\nexample (m n : Nat) (h : succ m = 0) : n = n + 7 := by\n contradiction\n\nexample (h : 7 = 4) : False := by\n contradiction\n```\n\nAs the second example shows, the {leanRef}`contradiction` tactic also detects contradictions of this form.\n\n# Inductive Families\n%%%\ntag := \"inductive-families\"\n%%%\n\nWe are almost done describing the full range of inductive definitions\naccepted by Lean. So far, you have seen that Lean allows you to\nintroduce inductive types with any number of recursive\nconstructors. In fact, a single inductive definition can introduce an\nindexed _family_ of inductive types, in a manner we now describe.\n\nAn inductive family is an indexed family of types defined by a\nsimultaneous induction of the following form:\n\n```\ninductive foo : ... → Sort u where\n | constructor₁ : ... → foo ...\n | constructor₂ : ... → foo ...\n ...\n | constructorₙ : ... → foo ...\n```\n::::setup\n```\nuniverse u\n```\n\n:::leanFirst\nIn contrast to an ordinary inductive definition, which constructs an\nelement of some {leanRef}`Sort u`, the more general version constructs a\nfunction {lit}`... → `{lean}`Sort u`, where “{lit}`...`” denotes a sequence of\nargument types, also known as _indices_. Each constructor then\nconstructs an element of some member of the family. One example is the\ndefinition of {leanRef}`Vect α n`, the type of vectors of elements of {leanRef}`α`\nof length {leanRef}`n`:\n\n```lean\ninductive Vect (α : Type u) : Nat → Type u where\n | nil : Vect α 0\n | cons : α → {n : Nat} → Vect α n → Vect α (n + 1)\n```\n:::\n::::\n\nNotice that the {leanRef}`cons` constructor takes an element of\n{leanRef}`Vect α n` and returns an element of {leanRef}`Vect α (n + 1)`, thereby using an\nelement of one member of the family to build an element of another.\n\nA more exotic example is given by the definition of the equality type in Lean:\n\n```lean\nnamespace Hidden\n------\ninductive Eq {α : Sort u} (a : α) : α → Prop where\n | refl : Eq a a\n-------\nend Hidden\n```\n\n:::setup\n```\nvariable (α : Sort u) (a : α) (x : α)\n```\n\nFor each fixed {leanRef}`α : Sort u` and {leanRef}`a : α`, this definition\nconstructs a family of types {lean}`Eq a x`, indexed by {lean}`x : α`.\nNotably, however, there is only one constructor, {leanRef}`refl`, which\nis an element of {leanRef}`Eq a a`.\nIntuitively, the only way to construct a proof of {lean}`Eq a x`\nis to use reflexivity, in the case where {lean}`x` is {lean}`a`.\nNote that {lean}`Eq a a` is the only inhabited type in the family of types\n{lean}`Eq a x`. The elimination principle generated by Lean is as follows:\n:::\n\n```lean\nset_option pp.proofs true\n--------\nuniverse u v\n\n#check (@Eq.rec : {α : Sort u} → {a : α} →\n {motive : (x : α) → a = x → Sort v} →\n motive a rfl →\n {b : α} → (h : a = b) → motive b h)\n```\n\nIt is a remarkable fact that all the basic axioms for equality follow\nfrom the constructor, {leanRef}`refl`, and the eliminator, {leanRef}`Eq.rec`. The\ndefinition of equality is atypical, however; see the discussion in {ref \"axiomatic-details\"}[Axiomatic Details].\n\nThe recursor {leanRef}`Eq.rec` is also used to define substitution:\n\n```lean\nnamespace Hidden\n------\ntheorem subst {α : Type u} {a b : α} {p : α → Prop}\n (h₁ : Eq a b) (h₂ : p a) : p b :=\n Eq.rec (motive := fun x _ => p x) h₂ h₁\n-------\nend Hidden\n```\n\nYou can also define {leanRef}`subst` using {kw}`match`.\n\n```lean\nnamespace Hidden\n------\ntheorem subst {α : Type u} {a b : α} {p : α → Prop}\n (h₁ : Eq a b) (h₂ : p a) : p b :=\n match h₁ with\n | rfl => h₂\n-------\nend Hidden\n```\n\nActually, Lean compiles the {kw}`match` expressions using a definition based on generated helpers\nsuch as {name}`Eq.casesOn` and {name}`Eq.ndrec`, which are themselves defined using {leanRef}`Eq.rec`.\n\n```lean\nnamespace Hidden\n------\ntheorem subst {α : Type u} {a b : α} {p : α → Prop}\n (h₁ : a = b) (h₂ : p a) : p b :=\n match h₁ with\n | rfl => h₂\n\nset_option pp.all true\n#print subst\n\n#print subst.match_1_1\n\n#print Eq.casesOn\n\n#print Eq.ndrec\n-------\nend Hidden\n```\n\nUsing the recursor or {kw}`match` with {leanRef}`h₁ : a = b`, we may assume {leanRef}`a` and {leanRef}`b` are the same,\nin which case, {leanRef}`p b` and {leanRef}`p a` are the same.\n\n:::leanFirst\nIt is not hard to prove that {leanRef}`Eq` is symmetric and transitive.\nIn the following example, we prove {leanRef}`symm` and leave as exercises the theorems {leanRef}`trans` and {leanRef}`congr` (congruence).\n\n```lean\nnamespace Hidden\n------\nvariable {α β : Type u} {a b c : α}\n\ntheorem symm (h : Eq a b) : Eq b a :=\n match h with\n | rfl => rfl\n\ntheorem trans (h₁ : Eq a b) (h₂ : Eq b c) : Eq a c :=\n sorry\n\ntheorem congr (f : α → β) (h : Eq a b) : Eq (f a) (f b) :=\n sorry\n-------\nend Hidden\n```\n:::\n\nIn the type theory literature, there are further generalizations of\ninductive definitions, for example, the principles of\n_induction-recursion_ and _induction-induction_. These are not\nsupported by Lean.\n\n# Axiomatic Details\n%%%\ntag := \"axiomatic-details\"\n%%%\n\nWe have described inductive types and their syntax through\nexamples. This section provides additional information for those\ninterested in the axiomatic foundations.\n\nWe have seen that the constructor to an inductive type takes\n_parameters_—intuitively, the arguments that remain fixed\nthroughout the inductive construction—and _indices_, the arguments\nparameterizing the family of types that is simultaneously under\nconstruction. Each constructor should have a type, where the\nargument types are built up from previously defined types, the\nparameter and index types, and the inductive family currently being\ndefined. The requirement is that if the latter is present at all, it\noccurs only _strictly positively_. This means simply that any argument\nto the constructor in which it occurs is a dependent arrow type in which the\ninductive type under definition occurs only as the resulting type,\nwhere the indices are given in terms of constants and previous\narguments.\n\nSince an inductive type lives in {leanRef}`Sort u` for some {leanRef}`u`, it is\nreasonable to ask _which_ universe levels {leanRef}`u` can be instantiated\nto. Each constructor {lit}`c` in the definition of a family {lit}`C` of\ninductive types is of the form\n\n```\n c : (a : α) → (b : β[a]) → C a p[a,b]\n```\n\nwhere {lit}`a` is a sequence of data type parameters, {lit}`b` is the\nsequence of arguments to the constructors, and {lit}`p[a, b]` are the\nindices, which determine which element of the inductive family the\nconstruction inhabits. (Note that this description is somewhat\nmisleading, in that the arguments to the constructor can appear in any\norder as long as the dependencies make sense.) The constraints on the\nuniverse level of {lit}`C` fall into two cases, depending on whether or\nnot the inductive type is specified to land in {lean}`Prop` (that is,\n{lean}`Sort 0`).\n\nLet us first consider the case where the inductive type is _not_\nspecified to land in {lean}`Prop`. Then the universe level {leanRef}`u` is\nconstrained to satisfy the following:\n\n> For each constructor {lit}`c` as above, and each {lit}`βk[a]` in the sequence {lit}`β[a]`, if {lit}`βk[a] : Sort v`, we have {leanRef}`u` ≥ {leanRef}`v`.\n\nIn other words, the universe level {leanRef}`u` is required to be at least as\nlarge as the universe level of each type that represents an argument\nto a constructor.\n\nWhen the inductive type is specified to land in {lean}`Prop`, there are no\nconstraints on the universe levels of the constructor arguments. But\nthese universe levels do have a bearing on the elimination\nrule. Generally speaking, for an inductive type in {lean}`Prop`, the\nmotive of the elimination rule is required to be in {lean}`Prop`.\n\nThere is an exception to this last rule: we are allowed to eliminate\nfrom an inductively defined {lean}`Prop` to an arbitrary {leanRef}`Sort` when\nthere is only one constructor and each constructor argument is either\nin {lean}`Prop` or an index. The intuition is that in this case the\nelimination does not make use of any information that is not already\ngiven by the mere fact that the type of argument is inhabited. This\nspecial case is known as _singleton elimination_.\n\nWe have already seen singleton elimination at play in applications of\n{name}`Eq.rec`, the eliminator for the inductively defined equality\ntype. We can use an element {leanRef}`h : Eq a b` to cast an element\n{leanRef}`h₂ : p a` to {leanRef}`p b` even when {leanRef}`p a` and {leanRef}`p b` are arbitrary types,\nbecause the cast does not produce new data; it only reinterprets the\ndata we already have. Singleton elimination is also used with\nheterogeneous equality and well-founded recursion, which will be\ndiscussed in a the chapter on {ref \"well-founded-recursion-and-induction\"}[induction and recursion].\n\n# Mutual and Nested Inductive Types\n%%%\ntag := \"mutual-and-nested-inductive-types\"\n%%%\n\nWe now consider two generalizations of inductive types that are often\nuseful, which Lean supports by “compiling” them down to the more\nprimitive kinds of inductive types described above. In other words,\nLean parses the more general definitions, defines auxiliary inductive\ntypes based on them, and then uses the auxiliary types to define the\nones we really want. Lean's equation compiler, described in the next\nchapter, is needed to make use of these types\neffectively. Nonetheless, it makes sense to describe the declarations\nhere, because they are straightforward variations on ordinary\ninductive definitions.\n\nFirst, Lean supports _mutually defined_ inductive types. The idea is\nthat we can define two (or more) inductive types at the same time,\nwhere each one refers to the other(s).\n\n```lean\nmutual\n inductive Even : Nat → Prop where\n | even_zero : Even 0\n | even_succ : (n : Nat) → Odd n → Even (n + 1)\n\n inductive Odd : Nat → Prop where\n | odd_succ : (n : Nat) → Even n → Odd (n + 1)\nend\n```\n\nIn this example, two types are defined simultaneously: a natural\nnumber {leanRef}`n` is {leanRef}`Even` if it is {lean}`0` or one more than an {leanRef}`Odd`\nnumber, and {leanRef}`Odd` if it is one more than an {leanRef}`Even` number.\nIn the exercises below, you are asked to spell out the details.\n\n:::leanFirst\nA mutual inductive definition can also be used to define the notation\nof a finite tree with nodes labelled by elements of {leanRef (in:=\"Tree (α\")}`α`:\n\n```lean\nmutual\n inductive Tree (α : Type u) where\n | node : α → TreeList α → Tree α\n\n inductive TreeList (α : Type u) where\n | nil : TreeList α\n | cons : Tree α → TreeList α → TreeList α\nend\n```\n:::\n\nWith this definition, one can construct an element of {leanRef}`Tree α` by\ngiving an element of {leanRef}`α` together with a list of subtrees, possibly\nempty. The list of subtrees is represented by the type {leanRef}`TreeList α`,\nwhich is defined to be either the empty list, {leanRef}`nil`, or the\n{leanRef}`cons` of a tree and an element of {leanRef}`TreeList α`.\n\n:::leanFirst\nThis definition is inconvenient to work with, however. It would be\nmuch nicer if the list of subtrees were given by the type\n{leanRef}`List (Tree α)`, especially since Lean's library contains a number of functions\nand theorems for working with lists. One can show that the type\n{leanRef}`TreeList α` is _isomorphic_ to {leanRef}`List (Tree α)`, but translating\nresults back and forth along this isomorphism is tedious.\n\nIn fact, Lean allows us to define the inductive type we really want:\n\n```lean\ninductive Tree (α : Type u) where\n | mk : α → List (Tree α) → Tree α\n```\n:::\n\nThis is known as a _nested_ inductive type. It falls outside the\nstrict specification of an inductive type given in the last section\nbecause {leanRef}`Tree` does not occur strictly positively among the\narguments to {leanRef}`mk`, but, rather, nested inside the {leanRef}`List` type\nconstructor. Lean then automatically builds the\nisomorphism between {leanRef}`TreeList α` and {leanRef}`List (Tree α)` in its kernel,\nand defines the constructors for {leanRef}`Tree` in terms of the isomorphism.\n\n# Exercises\n%%%\ntag := none\n%%%\n\n```setup\nopen Nat\nvariable {n m : Nat}\ndef length : List α → Nat\n | [] => 0\n | _ :: xs => length xs + 1\ndef reverse : List α → List α := go []\nwhere\n go (acc : List α) : List α → List α\n | [] => acc\n | x :: xs => go (x :: acc) xs\nvariable {xs ys : List α}\n\ninductive Term where\n | const (n : Nat)\n | var (n : Nat)\n | plus (s t : Term)\n | times (s t : Term)\nopen Term\nvariable {s t : Term}\n\n```\n\n1. Try defining other operations on the natural numbers, such as\n multiplication, the predecessor function (with {lean}`pred 0 = 0`),\n truncated subtraction (with {lean}`n - m = 0` when {lean}`m` is greater\n than or equal to {lean}`n`), and exponentiation. Then try proving some\n of their basic properties, building on the theorems we have already\n proved.\n\n Since many of these are already defined in Lean's core library, you\n should work within a namespace named {lit}`Hidden`, or something like\n that, in order to avoid name clashes.\n\n2. Define some operations on lists, like a {lean}`length` function or the\n {lean}`reverse` function. Prove some properties, such as the following:\n\n a. {lean}`length (xs ++ ys) = length xs + length ys`\n\n b. {lean}`length (reverse xs) = length xs`\n\n c. {lean}`reverse (reverse xs) = xs`\n\n3. Define an inductive data type consisting of terms built up from the following constructors:\n\n - {lean}`const n`, a constant denoting the natural number {lean}`n`\n - {lean}`var n`, a variable, numbered {lean}`n`\n - {lean}`plus s t`, denoting the sum of {leanRef}`s` and {leanRef}`t`\n - {lean}`times s t`, denoting the product of {leanRef}`s` and {leanRef}`t`\n\n Recursively define a function that evaluates any such term with respect to an assignment of values to the variables.\n\n4. Similarly, define the type of propositional formulas, as well as\n functions on the type of such formulas: an evaluation function,\n functions that measure the complexity of a formula, and a function\n that substitutes another formula for a given variable.\n"
},
{
"path": "book/TPiL/InteractingWithLean.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre Manual\nopen TPiL\n\n#doc (Manual) \"Interacting with Lean\" =>\n\nYou are now familiar with the fundamentals of dependent type theory,\nboth as a language for defining mathematical objects and a language\nfor constructing proofs. The one thing you are missing is a mechanism\nfor defining new data types. We will fill this gap in the next\nchapter, which introduces the notion of an _inductive data type_. But\nfirst, in this chapter, we take a break from the mechanics of type\ntheory to explore some pragmatic aspects of interacting with Lean.\n\nNot all of the information found here will be useful to you right\naway. We recommend skimming this section to get a sense of Lean's\nfeatures, and then returning to it as necessary.\n\n# Messages\n%%%\ntag := \"messages\"\n%%%\n\nLean produces three kinds of messages:\n\n: Errors\n\n Errors are produced when an inconsistency in the code means that it can't\n be processed. Examples include syntax errors (e.g. a missing {lit}`)`) and type\n errors such as attempting to add a natural number to a function.\n\n: Warnings\n\n Warnings describe potential problems with the code, such as the presence of {lean}`sorry`.\n Unlike with errors, the code is not meaningless; however, warnings deserve careful attention.\n\n: Information\n\n Information doesn't indicate any problem with the code, and includes output from commands such as {kw}`#check` and {kw}`#eval`.\n\nLean can check that a command produces the expected messages. If the messages match,\nthen any errors are disregarded; this can be used to ensure that the right errors occur.\nIf they don't, an error is produced. You can use the {kw}`#guard_msgs` command to indicate\nwhich messages are expected.\n\nHere is an example:\n```lean\n/--\nerror: Type mismatch\n \"Not a number\"\nhas type\n String\nbut is expected to have type\n Nat\n-/\n#guard_msgs in\ndef x : Nat := \"Not a number\"\n```\n\n:::leanFirst\nIncluding a message category in parentheses after {leanRef}`#guard_msgs` causes it to check only\nthe specified category, letting others through. In this example, {leanRef}`#eval` issues an error\ndue to the presence of {lean}`sorry`, but the warning that is always issued for {lean}`sorry` is displayed\nas usual:\n```lean\n/--\nerror: aborting evaluation since the expression depends on the\n'sorry' axiom, which can lead to runtime instability and crashes.\n\nTo attempt to evaluate anyway despite the risks, use the '#eval!'\ncommand.\n-/\n#guard_msgs(error) in\n#eval (sorry : Nat)\n```\n:::\n\nWithout the configuration, both messages are captured:\n```lean\n/--\nerror: aborting evaluation since the expression depends on the\n'sorry' axiom, which can lead to runtime instability and crashes.\n\nTo attempt to evaluate anyway despite the risks, use the '#eval!'\ncommand.\n---\nwarning: declaration uses 'sorry'\n-/\n#guard_msgs in\n#eval (sorry : Nat)\n```\n\nSome examples in this book use {leanRef}`#guard_msgs` to indicate expected errors.\n\n# Importing Files\n%%%\ntag := \"importing-files\"\n%%%\n\nThe goal of Lean's front end is to interpret user input, construct\nformal expressions, and check that they are well-formed and type-correct.\nLean also supports the use of various editors, which provide\ncontinuous checking and feedback. More information can be found on the\nLean [documentation pages](https://lean-lang.org/documentation/).\n\nThe definitions and theorems in Lean's standard library are spread\nacross multiple files. Users may also wish to make use of additional\nlibraries, or develop their own projects across multiple files. When\nLean starts, it automatically imports the contents of the library\n{lit}`Init` folder, which includes a number of fundamental definitions\nand constructions. As a result, most of the examples we present here\nwork “out of the box.”\n\nIf you want to use additional files, however, they need to be imported\nmanually, via an {kw}`import` statement at the beginning of a file. The\ncommand\n\n> {kw}`import`{lit}` Bar.Baz.Blah`\n\n\nimports the file {lit}`Bar/Baz/Blah.olean`, where the descriptions are\ninterpreted relative to the Lean _search path_. Information as to how\nthe search path is determined can be found on the\n[documentation pages](https://lean-lang.org/documentation/).\nBy default, it includes the standard library directory, and (in some contexts)\nthe root of the user's local project.\n\nImporting is transitive. In other words, if you import {lit}`Foo` and {lit}`Foo` imports {lit}`Bar`,\nthen you also have access to the contents of {lit}`Bar`, and do not need to import it explicitly.\n\n# More on Sections\n%%%\ntag := \"more-on-sections\"\n%%%\n\nLean provides various sectioning mechanisms to help structure a\ntheory. You saw in {ref \"variables-and-sections\"}[Variables and Sections] that the\n{kw}`section` command makes it possible not only to group together\nelements of a theory that go together, but also to declare variables\nthat are inserted as arguments to theorems and definitions, as\nnecessary. Remember that the point of the {kw}`variable` command is to\ndeclare variables for use in theorems, as in the following example:\n\n```lean\nsection\nvariable (x y : Nat)\n\ndef double := x + x\n\n#check double y\n\n#check double (2 * x)\n\nattribute [local simp] Nat.add_assoc Nat.add_comm Nat.add_left_comm\n\ntheorem t1 : double (x + y) = double x + double y := by\n simp [double]\n\n#check t1 y\n\n#check t1 (2 * x)\n\ntheorem t2 : double (x * y) = double x * y := by\n simp [double, Nat.add_mul]\n\nend\n```\n\nThe definition of {leanRef}`double` does not have to declare {leanRef}`x` as an\nargument; Lean detects the dependence and inserts it\nautomatically. Similarly, Lean detects the occurrence of {leanRef}`x` in\n{leanRef}`t1` and {leanRef}`t2`, and inserts it automatically there, too.\nNote that {leanRef}`double` does _not_ have {leanRef}`y` as argument. Variables are only\nincluded in declarations where they are actually used.\n\n# More on Namespaces\n%%%\ntag := \"more-on-namespaces\"\n%%%\n\nIn Lean, identifiers are given by hierarchical _names_ like\n{lit}`Foo.Bar.baz`. We saw in {ref \"namespaces\"}[Namespaces] that Lean provides\nmechanisms for working with hierarchical names. The command\n{kw}`namespace`{lit}` Foo` causes {lit}`Foo` to be prepended to the name of each\ndefinition and theorem until {kw}`end`{lit}` Foo` is encountered. The command\n{kw}`open`{lit}` Foo` then creates temporary _aliases_ to definitions and\ntheorems that begin with prefix {lit}`Foo`.\n\n```lean\nnamespace Foo\ndef bar : Nat := 1\nend Foo\n\nopen Foo\n\n#check bar\n\n#check Foo.bar\n```\n\nThe following definition\n\n```lean\ndef Foo.bar : Nat := 1\n```\n\nis treated as a macro, and expands to\n\n```lean\nnamespace Foo\ndef bar : Nat := 1\nend Foo\n```\n\nAlthough the names of theorems and definitions have to be unique, the\naliases that identify them do not. When we open a namespace, an\nidentifier may be ambiguous. Lean tries to use type information to\ndisambiguate the meaning in context, but you can always disambiguate\nby giving the full name. To that end, the string {lit}`_root_` is an\nexplicit description of the empty prefix.\n\n```lean\ndef String.add (a b : String) : String :=\n a ++ b\n\ndef Bool.add (a b : Bool) : Bool :=\n a != b\n\ndef add (α β : Type) : Type := Sum α β\n\nopen Bool\nopen String\n\n-- This reference is ambiguous:\n-- #check add\n\n#check String.add -- String.add (a b : String) : String\n\n#check Bool.add -- Bool.add (a b : Bool) : Bool\n\n#check _root_.add -- _root_.add (α β : Type) : Type\n\n#check add \"hello\" \"world\" -- \"hello\".add \"world\" : String\n\n#check add true false -- true.add false : Bool\n\n#check add Nat Nat -- _root_.add Nat Nat : Type\n```\n\nWe can prevent the shorter alias from being created by using the {kw}`protected` keyword:\n\n```lean\nprotected def Foo.bar : Nat := 1\n\nopen Foo\n\n/-- error: Unknown identifier `bar` -/\n#guard_msgs in\n#check bar -- error\n\n#check Foo.bar\n```\n\nThis is often used for names like {name}`Nat.rec` and {name}`Nat.recOn`, to prevent\noverloading of common names.\n\nThe {leanRef}`open` command admits variations. The command\n\n```lean\nopen Nat (succ zero gcd)\n\n#check zero -- Nat.zero : Nat\n\n#eval gcd 15 6 -- 3\n```\n\ncreates aliases for only the identifiers listed. The command\n\n```lean\nopen Nat hiding succ gcd\n\n#check zero -- Nat.zero : Nat\n\n/-- error: Unknown identifier `gcd` -/\n#guard_msgs in\n#eval gcd 15 6 -- error\n\n#eval Nat.gcd 15 6 -- 3\n```\n\ncreates aliases for everything in the {lit}`Nat` namespace _except_ the identifiers listed.\n\n```lean\nopen Nat renaming mul → times, add → plus\n\n#eval plus (times 2 2) 3 -- 7\n```\n\ncreates aliases renaming {lean}`Nat.mul` to {leanRef}`times` and {lean}`Nat.add` to {leanRef}`plus`.\n\nIt is sometimes useful to {kw}`export` aliases from one namespace to another, or to the top level. The command\n\n```lean\nexport Nat (succ add sub)\n```\n\ncreates aliases for {leanRef}`succ`, {leanRef}`add`, and {leanRef}`sub` in the current\nnamespace, so that whenever the namespace is open, these aliases are\navailable. If this command is used outside a namespace, the aliases\nare exported to the top level.\n\n# Attributes\n%%%\ntag := \"attributes\"\n%%%\n\nThe main function of Lean is to translate user input to formal\nexpressions that are checked by the kernel for correctness and then\nstored in the environment for later use. But some commands have other\neffects on the environment, either assigning attributes to objects in\nthe environment, defining notation, or declaring instances of type\nclasses, as described in the chapter on {ref \"type-classes\"}[type classes]. Most of\nthese commands have global effects, which is to say, they remain\nin effect not only in the current file, but also in any file that\nimports it. However, such commands often support the {kw}`local` modifier,\nwhich indicates that they only have effect until\nthe current {kw}`section` or {leanRef}`namespace` is closed, or until the end\nof the current file.\n\nIn {ref \"using-the-simplifier\"}[Using the Simplifier],\nwe saw that theorems can be annotated with the {attr}`[simp]` attribute,\nwhich makes them available for use by the simplifier.\nThe following example defines the prefix relation on lists,\nproves that this relation is reflexive, and assigns the {attr}`[simp]` attribute to that theorem.\n\n```lean\ndef isPrefix (l₁ : List α) (l₂ : List α) : Prop :=\n ∃ t, l₁ ++ t = l₂\n\n@[simp] theorem List.isPrefix_self (as : List α) : isPrefix as as :=\n ⟨[], by simp⟩\n\nexample : isPrefix [1, 2, 3] [1, 2, 3] := by\n simp\n```\n\nThe simplifier then proves {leanRef}`isPrefix [1, 2, 3] [1, 2, 3]` by rewriting it to {lean}`True`.\n\nOne can also assign the attribute any time after the definition takes place:\n\n```lean\ndef isPrefix (l₁ : List α) (l₂ : List α) : Prop :=\n ∃ t, l₁ ++ t = l₂\n------\ntheorem List.isPrefix_self (as : List α) : isPrefix as as :=\n ⟨[], by simp⟩\n\nattribute [simp] List.isPrefix_self\n```\n\nIn all these cases, the attribute remains in effect in any file that\nimports the one in which the declaration occurs. Adding the {kw}`local`\nmodifier restricts the scope:\n\n```lean\ndef isPrefix (l₁ : List α) (l₂ : List α) : Prop :=\n ∃ t, l₁ ++ t = l₂\n------\nsection\n\ntheorem List.isPrefix_self (as : List α) : isPrefix as as :=\n ⟨[], by simp⟩\n\nattribute [local simp] List.isPrefix_self\n\nexample : isPrefix [1, 2, 3] [1, 2, 3] := by\n simp\n\nend\n\n/-- error: `simp` made no progress -/\n#guard_msgs in\nexample : isPrefix [1, 2, 3] [1, 2, 3] := by\n simp\n```\n\n:::leanFirst\nFor another example, we can use the {kw}`instance` command to assign the\nnotation {lit}`≤` to the {leanRef}`isPrefix` relation. That command, which will\nbe explained in the chapter on {ref \"type-classes\"}[type classes], works by\nassigning an {attr}`[instance]` attribute to the associated definition.\n\n```lean\ndef isPrefix (l₁ : List α) (l₂ : List α) : Prop :=\n ∃ t, l₁ ++ t = l₂\n\ninstance : LE (List α) where\n le := isPrefix\n\ntheorem List.isPrefix_self (as : List α) : as ≤ as :=\n ⟨[], by simp⟩\n```\n\n:::\n\nThat assignment can also be made local:\n\n```lean\ndef isPrefix (l₁ : List α) (l₂ : List α) : Prop :=\n ∃ t, l₁ ++ t = l₂\n------\ndef instLe : LE (List α) :=\n { le := isPrefix }\n\nsection\nattribute [local instance] instLe\n\nexample (as : List α) : as ≤ as :=\n ⟨[], by simp⟩\n\nend\n\n/--\nerror: failed to synthesize\n LE (List α)\n\nHint: Additional diagnostic information may be available using the\n`set_option diagnostics true` command.\n-/\n#guard_msgs in\nexample (as : List α) : as ≤ as :=\n ⟨[], by simp⟩\n```\n\nIn {ref \"notation\"}[Notation] below, we will discuss Lean's\nmechanisms for defining notation, and see that they also support the\n{kw}`local` modifier. However, in {ref \"setting-options\"}[Setting Options], we will\ndiscuss Lean's mechanisms for setting options, which does _not_ follow\nthis pattern: options can _only_ be set locally, which is to say,\ntheir scope is always restricted to the current section or current\nfile.\n\n# More on Implicit Arguments\n%%%\ntag := \"more-on-implicit-arguments\"\n%%%\n\n:::setup\n\n```\nvariable (α : Type u) (β : α → Type v) (t : {x : α} → β x)\n```\n\n\nIn {ref \"implicit-arguments\"}[Implicit Arguments],\nwe saw that if Lean displays the type\nof a term {lean}`t` as {lean}`{x : α} → β x`, then the curly brackets\nindicate that {leanRef}`x` has been marked as an _implicit argument_ to\n{lean}`t`. This means that whenever you write {lean}`t`, a placeholder, or\n“hole,” is inserted, so that {lean}`t` is replaced by {lean}`@t _`. If you\ndon't want that to happen, you have to write {lean}`@t` instead.\n:::\n\n\n:::setup\n```\ndef f (x : Nat) {y : Nat} (z : Nat) : Nat := x + y + z\n-- Equivalent:\nexample := f 7\nexample := @f 7 _\n```\n\nNotice that implicit arguments are inserted eagerly. Suppose we define\na function {lean}`f : (x : Nat) → {y : Nat} → (z : Nat) → Nat`.\nThen, when we write the expression {lean}`f 7` without further\narguments, it is parsed as {lean}`@f 7 _`.\n:::\n\n:::setup\n```\ndef f (x : Nat) {{y : Nat}} (z : Nat) : Nat := x + y + z\n-- Just f 7\nexample := f 7\n-- These are equivalent:\nexample := @f 7 _ 3\nexample := f 7 3\n-- Alternative syntax:\ndef f' (x : Nat) ⦃y : Nat⦄ (z : Nat) : Nat := x + y + z\n```\n\nLean offers a weaker annotation which specifies that a placeholder should only be added\n_before_ a subsequent explicit argument. It can be written with double braces, so the type of {lean}`f` would be\n{lean}`f : (x : Nat) → {{y : Nat}} → (z : Nat) → Nat`.\nWith this annotation, the expression {lean}`f 7` would be parsed as is, whereas {lean}`f 7 3` would be\nparsed as {lean}`@f 7 _ 3`, just as it would be with the strong annotation.\nThis annotation can also be written as {lit}`⦃y : Nat⦄`, where the Unicode brackets are entered\nas {kbd}`\\{{` and {kbd}`\\}}`, respectively.\n:::\n\n\nTo illustrate the difference, consider the following example, which\nshows that a reflexive euclidean relation is both symmetric and\ntransitive.\n\n```lean\ndef reflexive {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ (a : α), r a a\n\ndef symmetric {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {a b : α}, r a b → r b a\n\ndef transitive {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {a b c : α}, r a b → r b c → r a c\n\ndef Euclidean {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {a b c : α}, r a b → r a c → r b c\n\ntheorem th1 {α : Type u} {r : α → α → Prop}\n (reflr : reflexive r) (euclr : Euclidean r)\n : symmetric r :=\n fun {a b : α} =>\n fun (h : r a b) =>\n show r b a from euclr h (reflr _)\n\ntheorem th2 {α : Type u} {r : α → α → Prop}\n (symmr : symmetric r) (euclr : Euclidean r)\n : transitive r :=\n fun {a b c : α} =>\n fun (rab : r a b) (rbc : r b c) =>\n euclr (symmr rab) rbc\n\ntheorem th3 {α : Type u} {r : α → α → Prop}\n (reflr : reflexive r) (euclr : Euclidean r)\n : transitive r :=\n th2 (th1 reflr @euclr) @euclr\n\nvariable (r : α → α → Prop)\nvariable (euclr : Euclidean r)\n\n#check euclr\n```\n\nThe results are broken down into small steps: {leanRef}`th1` shows that a\nrelation that is reflexive and euclidean is symmetric, and {leanRef}`th2`\nshows that a relation that is symmetric and euclidean is\ntransitive. Then {leanRef}`th3` combines the two results. But notice that we\nhave to manually disable the implicit arguments in {leanRef}`euclr`, because\notherwise too many implicit arguments are inserted. The problem goes\naway if we use weak implicit arguments:\n\n```lean\ndef reflexive {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ (a : α), r a a\n\ndef symmetric {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {{a b : α}}, r a b → r b a\n\ndef transitive {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {{a b c : α}}, r a b → r b c → r a c\n\ndef Euclidean {α : Type u} (r : α → α → Prop) : Prop :=\n ∀ {{a b c : α}}, r a b → r a c → r b c\n\ntheorem th1 {α : Type u} {r : α → α → Prop}\n (reflr : reflexive r) (euclr : Euclidean r)\n : symmetric r :=\n fun {a b : α} =>\n fun (h : r a b) =>\n show r b a from euclr h (reflr _)\n\ntheorem th2 {α : Type u} {r : α → α → Prop}\n (symmr : symmetric r) (euclr : Euclidean r)\n : transitive r :=\n fun {a b c : α} =>\n fun (rab : r a b) (rbc : r b c) =>\n euclr (symmr rab) rbc\n\ntheorem th3 {α : Type u} {r : α → α → Prop}\n (reflr : reflexive r) (euclr : Euclidean r)\n : transitive r :=\n th2 (th1 reflr euclr) euclr\n\nvariable (r : α → α → Prop)\nvariable (euclr : Euclidean r)\n\n#check euclr -- euclr : Euclidean r\n```\n\nThere is a third kind of implicit argument that is denoted with square\nbrackets, {lit}`[` and {lit}`]`. These are used for type classes, as\nexplained in the chapter on {ref \"type-classes\"}[type classes].\n\n# Notation\n%%%\ntag := \"notation\"\n%%%\n\nIdentifiers in Lean can include any alphanumeric characters, including\nGreek characters (other than ∀ , Σ , and λ , which, as we have seen,\nhave a special meaning in the dependent type theory). They can also\ninclude subscripts, which can be entered by typing {kbd}`\\_` followed by\nthe desired subscripted character.\n\nLean's parser is extensible, which is to say, we can define new notation.\n\nLean's syntax can be extended and customized by users at every level,\nranging from basic “mixfix” notations to custom elaborators. In fact,\nall builtin syntax is parsed and processed using the same mechanisms\nand APIs open to users. In this section, we will describe and explain\nthe various extension points.\n\nWhile introducing new notations is a relatively rare feature in\nprogramming languages and sometimes even frowned upon because of its\npotential to obscure code, it is an invaluable tool in formalization\nfor expressing established conventions and notations of the respective\nfield succinctly in code. Going beyond basic notations, Lean's\nability to factor out common boilerplate code into (well-behaved)\nmacros and to embed entire custom domain specific languages (DSLs) to\ntextually encode subproblems efficiently and readably can be of great\nbenefit to both programmers and proof engineers alike.\n\n## Notations and Precedence\n%%%\ntag := \"notations-and-precedence\"\n%%%\n\nThe most basic syntax extension commands allow introducing new (or\noverloading existing) prefix, infix, and postfix operators.\n\n```lean\ninfixl:65 \" + \" => HAdd.hAdd -- left-associative\ninfix:50 \" = \" => Eq -- non-associative\ninfixr:80 \" ^ \" => HPow.hPow -- right-associative\nprefix:100 \"-\" => Neg.neg\npostfix:max \"⁻¹\" => Inv.inv\n```\n\nAfter the initial command name describing the operator kind (its\n“{deftech}[fixity]”), we give the _parsing precedence_ of the operator preceded\nby a colon {lit}`:`, then a new or existing token surrounded by double\nquotes (the whitespace is used for pretty printing), then the function\nthis operator should be translated to after the arrow {lit}`=>`.\n\nThe precedence is a natural number describing how “tightly” an\noperator binds to its arguments, encoding the order of operations. We\ncan make this more precise by looking at the commands the above unfold to:\n\n```lean\nnotation:65 lhs:65 \" + \" rhs:66 => HAdd.hAdd lhs rhs\nnotation:50 lhs:51 \" = \" rhs:51 => Eq lhs rhs\nnotation:80 lhs:81 \" ^ \" rhs:80 => HPow.hPow lhs rhs\nnotation:100 \"-\" arg:100 => Neg.neg arg\n -- `max` is a shorthand for precedence 1024:\nnotation:1024 arg:1024 \"⁻¹\" => Inv.inv arg\n```\n\n:::setup\n```\nvariable {p : Nat} {a b c : α} [Add α] [Pow α α]\n```\nIt turns out that all commands from the first code block are in fact\ncommand _macros_ translating to the more general {leanRef}`notation` command.\nWe will learn about writing such macros below. Instead of a single\ntoken, the {leanRef}`notation` command accepts a mixed sequence of tokens and\nnamed term placeholders with precedences, which can be referenced on\nthe right-hand side of {lit}`=>` and will be replaced by the respective\nterm parsed at that position. A placeholder with precedence {lean}`p`\naccepts only notations with precedence at least {lean}`p` in that place.\nThus the string {lean}`a + b + c` cannot be parsed as the equivalent of\n{lean}`a + (b + c)` because the right-hand side operand of an {leanRef}`infixl` notation\nhas precedence one greater than the notation itself. In contrast,\n{leanRef}`infixr` reuses the notation's precedence for the right-hand side\noperand, so {lean}`a ^ b ^ c` _can_ be parsed as {lean}`a ^ (b ^ c)`. Note that\nif we used {leanRef}`notation` directly to introduce an infix notation like\n:::\n\n```lean\ndef wobble : α → β → γ := sorry\n------\nnotation:65 lhs:65 \" ~ \" rhs:65 => wobble lhs rhs\n```\n\n:::setup\n```\nvariable (a : α) (b : β) (c : γ)\ndef wobble : α → β → γ := sorry\nnotation:65 lhs:65 \" ~ \" rhs:65 => wobble lhs rhs\n\n```\n\nwhere the precedences do not sufficiently determine associativity,\nLean's parser will default to right associativity. More precisely,\nLean's parser follows a local _longest parse_ rule in the presence of\nambiguous grammars: when parsing the right-hand side of {lit}`a ~` in\n{lean}`a ~ b ~ c`, it will continue parsing as long as possible (as the current\nprecedence allows), not stopping after {leanRef}`b` but parsing {leanRef}`~ c` as well.\nThus the term is equivalent to {lean}`a ~ (b ~ c)`.\n:::\n\nAs mentioned above, the {leanRef}`notation` command allows us to define\narbitrary _mixfix_ syntax freely mixing tokens and placeholders.\n\n```lean\nset_option quotPrecheck false\n------\nnotation:max \"(\" e \")\" => e\nnotation:10 Γ \" ⊢ \" e \" : \" τ => Typing Γ e τ\n```\n\nPlaceholders without precedence default to {lit}`0`, i.e. they accept notations of any precedence in their place.\nIf two notations overlap, we again apply the longest parse rule:\n\n```lean\nnotation:65 a \" + \" b:66 \" + \" c:66 => a + b - c\n#eval 1 + 2 + 3 -- 0\n```\n\nThe new notation is preferred to the binary notation since the latter,\nbefore chaining, would stop parsing after {leanRef}`1 + 2`. If there are\nmultiple notations accepting the same longest parse, the choice will\nbe delayed until elaboration, which will fail unless exactly one\noverload is type-correct.\n\n# Coercions\n%%%\ntag := \"coercions\"\n%%%\n\nIn Lean, the type of natural numbers, {lean}`Nat`, is different from the\ntype of integers, {lean}`Int`. But there is a function {lean}`Int.ofNat` that\nembeds the natural numbers in the integers, meaning that we can view\nany natural number as an integer, when needed. Lean has mechanisms to\ndetect and insert _coercions_ of this sort. Coercions can be explicitly\nrequested using the overloaded {lit}`↑` operator.\n\n```lean\nvariable (m n : Nat)\nvariable (i j : Int)\n\n#check i + m -- i + ↑m : Int\n\n#check i + m + j -- i + ↑m + j : Int\n\n#check i + m + n -- i + ↑m + ↑n : Int\n```\n\n# Displaying Information\n%%%\ntag := \"displaying-information\"\n%%%\n\nThere are a number of ways in which you can query Lean for information\nabout its current state and the objects and theorems that are\navailable in the current context. You have already seen two of the\nmost common ones, {kw}`#check` and {kw}`#eval`. Remember that {kw}`#check`\nis often used in conjunction with the {lit}`@` operator, which makes all\nof the arguments to a theorem or definition explicit. In addition, you\ncan use the {kw}`#print` command to get information about any\nidentifier. If the identifier denotes a definition or theorem, Lean\nprints the type of the symbol, and its definition. If it is a constant\nor an axiom, Lean indicates that fact, and shows the type.\n\n```lean\n-- examples with equality\n#check Eq\n\n#check @Eq\n\n#check Eq.symm\n\n#check @Eq.symm\n\n#print Eq.symm\n\n-- examples with And\n#check And\n\n#check And.intro\n\n#check @And.intro\n\n-- a user-defined function\ndef foo {α : Type u} (x : α) : α := x\n\n#check foo\n\n#check @foo\n\n#print foo\n```\n\n# Setting Options\n%%%\ntag := \"setting-options\"\n%%%\n\nLean maintains a number of internal variables that can be set by users\nto control its behavior. The syntax for doing so is as follows:\n\n\n{kw}`set_option`{lit}` `\n\n\nOne very useful family of options controls the way Lean's _pretty printer_ displays terms. The following options take an input of true or false:\n\n```\npp.explicit : display implicit arguments\npp.universes : display hidden universe parameters\npp.notation : display output using defined notations\n```\n\nAs an example, the following settings yield much longer output:\n\n```lean\nset_option pp.explicit true\nset_option pp.universes true\nset_option pp.notation false\n\n#check 2 + 2 = 4\n\n#reduce (fun x => x + 2) = (fun x => x + 3)\n\n#check (fun x => x + 1) 1\n```\n\nThe command {leanCommand}`set_option pp.all true` carries out these settings all\nat once, whereas {leanCommand}`set_option pp.all false` reverts to the previous\nvalues. Pretty printing additional information is often very useful\nwhen you are debugging a proof, or trying to understand a cryptic\nerror message. Too much information can be overwhelming, though, and\nLean's defaults are generally sufficient for ordinary interactions.\n\n:::comment\n```\n\n```\n:::\n\n# Using the Library\n%%%\ntag := \"using-the-library\"\n%%%\n\nTo use Lean effectively you will inevitably need to make use of\ndefinitions and theorems in the library. Recall that the {kw}`import`\ncommand at the beginning of a file imports previously compiled results\nfrom other files, and that importing is transitive; if you import\n{lit}`Foo` and {lit}`Foo` imports {lit}`Bar`, then the definitions and theorems\nfrom {lit}`Bar` are available to you as well. But the act of opening a\nnamespace, which provides shorter names, does not carry over. In each\nfile, you need to open the namespaces you wish to use.\n\nIn general, it is important for you to be familiar with the library\nand its contents, so you know what theorems, definitions, notations,\nand resources are available to you. Below we will see that Lean's\neditor modes can also help you find things you need, but studying the\ncontents of the library directly is often unavoidable. Lean's standard\nlibrary can be found online, on GitHub:\n\n- [https://github.com/leanprover/lean4/tree/master/src/Init](https://github.com/leanprover/lean4/tree/master/src/Init)\n\n- [https://github.com/leanprover/lean4/tree/master/src/Std](https://github.com/leanprover/lean4/tree/master/src/Std)\n\n\nYou can see the contents of these directories and files using GitHub's\nbrowser interface. If you have installed Lean on your own computer,\nyou can find the library in the {lit}`lean` folder, and explore it with\nyour file manager. Comment headers at the top of each file provide\nadditional information.\n\nLean's library developers follow general naming guidelines to make it\neasier to guess the name of a theorem you need, or to find it using\ntab completion in editors with a Lean mode that supports this, which\nis discussed in the next section. Identifiers are generally\n{lit}`camelCase`, and types are {lit}`CamelCase`. For theorem names,\nwe rely on descriptive names where the different components are separated\nby {lit}`_`s. Often the name of theorem simply describes the conclusion:\n\n```lean\n#check Nat.succ_ne_zero\n\n#check Nat.zero_add\n\n#check Nat.mul_one\n\n#check Nat.le_of_succ_le_succ\n```\n\n:::setup\n```\nopen Nat\n```\n\nRemember that identifiers in Lean can be organized into hierarchical\nnamespaces. For example, the theorem named {lean}`le_of_succ_le_succ` in the\nnamespace {lit}`Nat` has full name {lean}`Nat.le_of_succ_le_succ`, but the shorter\nname is made available by the command {kw}`open`{lit}` Nat` (for names not marked as\n{kw}`protected`). We will see in the chapters on {ref \"inductive-types\"}[inductive types]\nand {ref \"structures-and-records\"}[structures and records]\nthat defining structures and inductive data types in Lean generates\nassociated operations, and these are stored in\na namespace with the same name as the type under definition. For\nexample, the product type comes with the following operations:\n:::\n\n```lean\n#check @Prod.mk\n\n#check @Prod.fst\n\n#check @Prod.snd\n\n#check @Prod.rec\n```\n\nThe first is used to construct a pair, whereas the next two,\n{leanRef}`Prod.fst` and {leanRef}`Prod.snd`, project the two elements. The last,\n{leanRef}`Prod.rec`, provides another mechanism for defining functions on a\nproduct in terms of a function on the two components. Names like\n{leanRef}`Prod.rec` are _protected_, which means that one has to use the full\nname even when the {lit}`Prod` namespace is open.\n\nWith the propositions as types correspondence, logical connectives are\nalso instances of inductive types, and so we tend to use dot notation\nfor them as well:\n\n```lean\n#check @And.intro\n\n#check @And.casesOn\n\n#check @And.left\n\n#check @And.right\n\n#check @Or.inl\n\n#check @Or.inr\n\n#check @Or.elim\n\n#check @Exists.intro\n\n#check @Exists.elim\n\n#check @Eq.refl\n\n#check @Eq.subst\n```\n\n# Auto Bound Implicit Arguments\n%%%\ntag := \"auto-bound-implicit-arguments\"\n%%%\n\n:::leanFirst\nIn the previous section, we have shown how implicit arguments make functions more convenient to use.\nHowever, functions such as {leanRef}`compose` are still quite verbose to define. Note that the universe\npolymorphic {leanRef}`compose` is even more verbose than the one previously defined.\n\n```lean\nuniverse u v w\n\ndef compose {α : Type u} {β : Type v} {γ : Type w}\n (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n```\n:::\n\n:::leanFirst\nYou can avoid the {kw}`universe` command by providing the universe parameters when defining {leanRef}`compose`.\n\n```lean\ndef compose.{u, v, w}\n {α : Type u} {β : Type v} {γ : Type w}\n (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n```\n:::\n\n::::leanFirst\nLean 4 supports a new feature called _auto bound implicit arguments_. It makes functions such as\n{leanRef}`compose` much more convenient to write. When Lean processes the header of a declaration,\nany unbound identifier is automatically added as an implicit argument. With this feature we can write {leanRef}`compose` as\n\n:::TODO\n\nUpdate and check details\n\n:::\n\n```lean\ndef compose (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n\n#check @compose -- @compose : {β : Sort u_1} → {γ : Sort u_2} → {α : Sort u_3} → (β → γ) → (α → β) → α → γ\n```\n\nNote that Lean inferred a more general type using {lean}`Sort` instead of {leanRef}`Type`.\n::::\n\nAlthough we love this feature and use it extensively when implementing Lean,\nwe realize some users may feel uncomfortable with it. Thus, you can disable it using\nthe command {leanCommand}`set_option autoImplicit false`.\n\n```lean\nset_option autoImplicit false\n\n/--\nerror: Unknown identifier `β`\n---\nerror: Unknown identifier `γ`\n---\nerror: Unknown identifier `α`\n---\nerror: Unknown identifier `β`\n---\nerror: Unknown identifier `α`\n---\nerror: Unknown identifier `γ`\n-/\n#guard_msgs in\ndef compose (g : β → γ) (f : α → β) (x : α) : γ :=\n g (f x)\n```\n\n# Implicit Lambdas\n%%%\ntag := \"implicit-lambdas\"\n%%%\n\n:::TODO\nUpdate this text after archaeology\n:::\n\n:::leanFirst\nWhen the expected type of an expression is a function that is awaiting implicit\narguments, the elaborator automatically introduces the corresponding lambdas.\nFor example, {leanRef}`pure`'s type states that the first argument is an implicit type\n{leanRef}`α`, but {leanRef}`ReaderT.pure`'s first argument is the reader monad's context type {leanRef}`ρ`.\nIt is automatically surrounded with a {kw}`fun`{lit}` {α} => ...`, which allows the elaborator to\ncorrectly fill in the implicit arguments in the body.\n\n```lean\nvariable (ρ : Type) (m : Type → Type) [Monad m]\n------\ninstance : Monad (ReaderT ρ m) where\n pure := ReaderT.pure\n bind := ReaderT.bind\n```\n:::\n\nUsers can disable the implicit lambda feature by using {lit}`@` or writing\na lambda expression with {lit}`{}` or {lit}`[]` binder annotations. Here are\nfew examples\n\n```lean\nset_option linter.unusedVariables false\nnamespace Ex2\n------\ndef id1 : {α : Type} → α → α :=\n fun x => x\n\ndef listId : List ({α : Type} → α → α) :=\n (fun x => x) :: []\n\n-- In this example, implicit lambda introduction has been disabled because\n-- we use `@` before {kw}`fun`\ndef id2 : {α : Type} → α → α :=\n @fun α (x : α) => id1 x\n\ndef id3 : {α : Type} → α → α :=\n @fun α x => id1 x\n\ndef id4 : {α : Type} → α → α :=\n fun x => id1 x\n\n-- In this example, implicit lambda introduction has been disabled\n-- because we used the binder annotation `{...}`\ndef id5 : {α : Type} → α → α :=\n fun {α} x => id1 x\n------\nend Ex2\n```\n\n# Sugar for Simple Functions\n%%%\ntag := \"sugar-for-simple-functions\"\n%%%\n\nLean includes a notation for describing simple functions using anonymous\nplaceholders rather than {kw}`fun`. When {lit}`·` occurs as part of a term,\nthe nearest enclosing parentheses become a function with the {lit}`·` as its argument.\nIf the parentheses include multiple placeholders without other intervening parentheses,\nthen they are made into arguments from left to right. Here are a few examples:\n\n```lean\nnamespace Ex3\n------\n#check (· + 1) -- fun x => x + 1 : Nat → Nat\n\n#check (2 - ·) -- fun x => 2 - x : Nat → Nat\n\n#eval [1, 2, 3, 4, 5].foldl (· * ·) 1 -- 120\n\ndef f (x y z : Nat) :=\n x + y + z\n\n#check (f · 1 ·) -- fun x1 x2 => f x1 1 x2 : Nat → Nat → Nat\n\n#eval [(1, 2), (3, 4), (5, 6)].map (·.1) -- [1, 3, 5]\n------\nend Ex3\n```\n\nNested parentheses introduce new functions. In the following example, two different lambda expressions are created:\n\n```lean\n#check (Prod.mk · (· + 1)) -- fun x => (x, fun x => x + 1) : ?m.2 → ?m.2 × (Nat → Nat)\n```\n\n# Named Arguments\n%%%\ntag := \"named-arguments\"\n%%%\n\nNamed arguments enable you to specify an argument for a parameter by\nmatching the argument with its name rather than with its position in\nthe parameter list. If you don't remember the order of the parameters\nbut know their names, you can send the arguments in any order. You may\nalso provide the value for an implicit parameter when Lean failed to\ninfer it. Named arguments also improve the readability of your code by\nidentifying what each argument represents.\n\n```lean\ndef sum (xs : List Nat) :=\n xs.foldl (init := 0) (·+·)\n\n#eval sum [1, 2, 3, 4]\n-- 10\n\nexample {a b : Nat} {p : Nat → Nat → Nat → Prop}\n (h₁ : p a b b) (h₂ : b = a) :\n p a a b :=\n Eq.subst (motive := fun x => p a x b) h₂ h₁\n```\n\nIn the following examples, we illustrate the interaction between named\nand default arguments.\n\n```lean\ndef f (x : Nat) (y : Nat := 1) (w : Nat := 2) (z : Nat) :=\n x + y + w - z\n\nexample (x z : Nat) : f (z := z) x = x + 1 + 2 - z := rfl\n\nexample (x z : Nat) : f x (z := z) = x + 1 + 2 - z := rfl\n\nexample (x y : Nat) : f x y = fun z => x + y + 2 - z := rfl\n\nexample : f = (fun x z => x + 1 + 2 - z) := rfl\n\nexample (x : Nat) : f x = fun z => x + 1 + 2 - z := rfl\n\nexample (y : Nat) : f (y := 5) = fun x z => x + 5 + 2 - z := rfl\n\ndef g {α} [Add α] (a : α) (b? : Option α := none) (c : α) : α :=\n match b? with\n | none => a + c\n | some b => a + b + c\n\nvariable {α} [Add α]\n\nexample : g = fun (a c : α) => a + c := rfl\n\nexample (x : α) : g (c := x) = fun (a : α) => a + x := rfl\n\nexample (x : α) : g (b? := some x) = fun (a c : α) => a + x + c := rfl\n\nexample (x : α) : g x = fun (c : α) => x + c := rfl\n\nexample (x y : α) : g x y = fun (c : α) => x + y + c := rfl\n```\n\nYou can use {lit}`..` to provide missing explicit arguments as {lit}`_`.\nThis feature combined with named arguments is useful for writing patterns. Here is an example:\n\n```lean\ninductive Term where\n | var (name : String)\n | num (val : Nat)\n | app (fn : Term) (arg : Term)\n | lambda (name : String) (type : Term) (body : Term)\n\ndef getBinderName : Term → Option String\n | Term.lambda (name := n) .. => some n\n | _ => none\n\ndef getBinderType : Term → Option Term\n | Term.lambda (type := t) .. => some t\n | _ => none\n```\n\nEllipses are also useful when explicit arguments can be automatically\ninferred by Lean, and we want to avoid a sequence of {lit}`_`s.\n\n```lean\nexample (f : Nat → Nat) (a b c : Nat) : f (a + b + c) = f (a + (b + c)) :=\n congrArg f (Nat.add_assoc ..)\n```\n"
},
{
"path": "book/TPiL/Intro.lean",
"content": "import VersoManual\n\nimport TPiL.Examples\n\nopen TPiL\n\nopen Verso.Genre Manual\nopen Verso Code External\n\n#doc (Manual) \"Introduction\" =>\n%%%\ntag := \"Intro\"\nhtmlSplit := .never\n%%%\n\n# Computers and Theorem Proving\n%%%\ntag := \"computers-and-theorem-proving\"\n%%%\n\n_Formal verification_ involves the use of logical and computational methods to establish claims that are expressed in\nprecise mathematical terms. These can include ordinary mathematical theorems, as well as claims that pieces of hardware\nor software, network protocols, and mechanical and hybrid systems meet their specifications. In practice, there is not a\nsharp distinction between verifying a piece of mathematics and verifying the correctness of a system: formal\nverification requires describing hardware and software systems in mathematical terms, at which point establishing claims\nas to their correctness becomes a form of theorem proving. Conversely, the proof of a mathematical theorem may require a\nlengthy computation, in which case verifying the truth of the theorem requires verifying that the computation does what\nit is supposed to do.\n\nThe gold standard for supporting a mathematical claim is to provide a proof, and twentieth-century developments in logic\nshow most if not all conventional proof methods can be reduced to a small set of axioms and rules in any of a number of\nfoundational systems. With this reduction, there are two ways that a computer can help establish a claim: it can help\nfind a proof in the first place, and it can help verify that a purported proof is correct.\n\n_Automated theorem proving_ focuses on the “finding” aspect. Resolution theorem provers, tableau theorem provers, fast\nsatisfiability solvers, and so on provide means of establishing the validity of formulas in propositional and\nfirst-order logic. Other systems provide search procedures and decision procedures for specific languages and domains,\nsuch as linear or nonlinear expressions over the integers or the real numbers. Architectures like SMT (\"satisfiability\nmodulo theories”) combine domain-general search methods with domain-specific procedures. Computer algebra systems and\nspecialized mathematical software packages provide means of carrying out mathematical computations, establishing\nmathematical bounds, or finding mathematical objects. A calculation can be viewed as a proof as well, and these systems,\ntoo, help establish mathematical claims.\n\nAutomated reasoning systems strive for power and efficiency, often at the expense of guaranteed soundness. Such systems\ncan have bugs, and it can be difficult to ensure that the results they deliver are correct. In contrast, _interactive\ntheorem proving_ focuses on the “verification” aspect of theorem proving, requiring that every claim is supported by a\nproof in a suitable axiomatic foundation. This sets a very high standard: every rule of inference and every step of a\ncalculation has to be justified by appealing to prior definitions and theorems, all the way down to basic axioms and\nrules. In fact, most such systems provide fully elaborated “proof objects” that can be communicated to other systems and\nchecked independently. Constructing such proofs typically requires much more input and interaction from users, but it\nallows you to obtain deeper and more complex proofs.\n\nThe _Lean Theorem Prover_ aims to bridge the gap between interactive and automated theorem proving, by situating\nautomated tools and methods in a framework that supports user interaction and the construction of fully specified\naxiomatic proofs. The goal is to support both mathematical reasoning and reasoning about complex systems, and to verify\nclaims in both domains.\n\nLean's underlying logic has a computational interpretation, and Lean can be viewed equally well as a programming\nlanguage. More to the point, it can be viewed as a system for writing programs with a precise semantics, as well as\nreasoning about the functions that the programs compute. Lean also has mechanisms to serve as its own _metaprogramming\nlanguage_, which means that you can implement automation and extend the functionality of Lean using Lean itself. These\naspects of Lean are described in the free online book, [Functional Programming in Lean](https://lean-lang.org/functional_programming_in_lean/), though computational\naspects of the system will make an appearance here.\n\n# About Lean\n%%%\ntag := \"about-lean\"\n%%%\n\nThe _Lean_ project was launched by Leonardo de Moura at Microsoft Research Redmond in 2013. It is an ongoing, long-term\neffort, and much of the potential for automation will be realized only gradually over time. Lean is released under the\n[Apache 2.0 license](https://github.com/leanprover/lean4/blob/master/LICENSE), a permissive open source license that permits others to use and extend the code and\nmathematical libraries freely.\n\nTo install Lean in your computer consider using the [Quickstart](https://lean-lang.org/install/) instructions. The Lean source code, and instructions for building Lean, are available at\n[https://github.com/leanprover/lean4/](https://github.com/leanprover/lean4/).\n\nThis tutorial describes the current version of Lean, known as Lean 4.\n\n# About this Book\n%%%\ntag := \"about-this-book\"\n%%%\n\nThis book is designed to teach you to develop and verify proofs in Lean. Much of the background information you will\nneed in order to do this is not specific to Lean at all. To start with, you will learn the logical system that Lean is\nbased on, a version of _dependent type theory_ that is powerful enough to prove almost any conventional mathematical\ntheorem, and expressive enough to do it in a natural way. More specifically, Lean is based on a version of a system\nknown as the Calculus of Constructions with inductive types. Lean can not only define mathematical objects and express\nmathematical assertions in dependent type theory, but it also can be used as a language for writing proofs.\n\nBecause fully detailed axiomatic proofs are so complicated, the challenge of theorem proving is to have the computer\nfill in as many of the details as possible. You will learn various methods to support this in {ref \"dependent-type-theory\"}[dependent type\ntheory]. For example, term rewriting, and Lean's automated methods for simplifying terms and\nexpressions automatically. Similarly, methods of _elaboration_ and _type inference_, which can be used to support\nflexible forms of algebraic reasoning.\n\nFinally, you will learn about features that are specific to Lean, including the language you use to communicate\nwith the system, and the mechanisms Lean offers for managing complex theories and data.\n\nThroughout the text you will find examples of Lean code like the one below:\n\n```lean\ntheorem and_commutative (p q : Prop) : p ∧ q → q ∧ p :=\n fun hpq : p ∧ q =>\n have hp : p := And.left hpq\n have hq : q := And.right hpq\n show q ∧ p from And.intro hq hp\n```\n\nNext to every code example in this book, you will see a button that reads “Copy to clipboard”.\nPressing the button copies the example with enough surrounding context to make the code compile correctly.\nYou can paste the example code into [VS Code](https://code.visualstudio.com/) and modify the examples, and Lean will check the results and provide feedback continuously as you type.\nWe recommend running the examples and experimenting with the code on your own as you work through the chapters that follow.\nYou can open this book in VS Code by using the command “Lean 4: Docs: Show Documentation Resources” and selecting “Theorem Proving in Lean 4” in the tab that opens.\n\n# Acknowledgments\n%%%\ntag := \"acknowledgments\"\n%%%\n\nThis tutorial is an open access project maintained on Github. Many people have contributed to the effort, providing\ncorrections, suggestions, examples, and text. We are grateful to Ulrik Buchholz, Kevin Buzzard, Mario Carneiro, Nathan\nCarter, Eduardo Cavazos, Amine Chaieb, Joe Corneli, William DeMeo, Marcus Klaas de Vries, Ben Dyer, Gabriel Ebner,\nAnthony Hart, Simon Hudon, Sean Leather, Assia Mahboubi, Gihan Marasingha, Patrick Massot, Christopher John Mazey,\nSebastian Ullrich, Floris van Doorn, Daniel Velleman, Théo Zimmerman, Paul Chisholm, Chris Lovett, and Siddhartha Gadgil for their contributions. Please see [lean prover](https://github.com/leanprover/) and [lean community](https://github.com/leanprover-community/) for an up to date list\nof our amazing contributors.\n"
},
{
"path": "book/TPiL/PropositionsAndProofs.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre Manual\nopen TPiL\n\n\n\nset_option pp.rawOnError true\n\n#doc (Manual) \"Propositions and Proofs\" =>\n%%%\ntag := \"propositions-and-proofs\"\nhtmlSplit := .never\n%%%\n\nBy now, you have seen some ways of defining objects and functions in\nLean. In this chapter, we will begin to explain how to write\nmathematical assertions and proofs in the language of dependent type\ntheory as well.\n\n# Propositions as Types\n%%%\ntag := \"propositions-as-types\"\n%%%\n\nOne strategy for proving assertions about objects defined in the\nlanguage of dependent type theory is to layer an assertion language\nand a proof language on top of the definition language. But there is\nno reason to multiply languages in this way: dependent type theory is\nflexible and expressive, and there is no reason we cannot represent\nassertions and proofs in the same general framework.\n\nFor example, we could introduce a new type, {lean}`Prop`, to represent\npropositions, and introduce constructors to build new propositions\nfrom others.\n\n```lean\ndef Implies (p q : Prop) : Prop := p → q\n------\n#check And -- And (a b : Prop) : Prop\n\n#check Or -- Or (a b : Prop) : Prop\n\n#check Not -- Not (a : Prop) : Prop\n\n#check Implies -- Implies (p q : Prop) : Prop\n\nvariable (p q r : Prop)\n\n#check And p q -- p ∧ q : Prop\n\n#check Or (And p q) r -- p ∧ q ∨ r : Prop\n\n#check Implies (And p q) (And q p) -- Implies (p ∧ q) (q ∧ p) : Prop\n```\n\n\n```setup\nvariable (p : Prop)\nstructure Proof (p : Prop) : Type where\n proof : p\nvariable (t : p) (q r : Prop)\ndef Implies (p q : Prop) : Prop := p → q\nuniverse u\nvariable (t1 t2 : p) {α : Type u} {β : Type v}\n```\n\nWe could then introduce, for each element {lean}`p : Prop`, another type\n{lean}`Proof p`, for the type of proofs of {lean}`p`. An “axiom” would be a\nconstant of such a type.\n\n\n```lean\ndef Implies (p q : Prop) : Prop := p → q\nstructure Proof (p : Prop) : Type where\n proof : p\n------\n#check Proof -- Proof (p : Prop) : Type\n\naxiom and_commut (p q : Prop) : Proof (Implies (And p q) (And q p))\n\nvariable (p q : Prop)\n\n#check and_commut p q -- and_commut p q : Proof (Implies (p ∧ q) (q ∧ p))\n```\n\n\n\nIn addition to axioms, however, we would also need rules to build new\nproofs from old ones. For example, in many proof systems for\npropositional logic, we have the rule of _modus ponens_:\n\n> From a proof of {lean}`Implies p q` and a proof of {lean}`p`, we obtain a proof of {lean}`q`.\n\nWe could represent this as follows:\n\n```lean\ndef Implies (p q : Prop) : Prop := p → q\nstructure Proof (p : Prop) : Type where\n proof : p\n------\naxiom modus_ponens (p q : Prop) :\n Proof (Implies p q) → Proof p →\n Proof q\n```\n\nSystems of natural deduction for propositional logic also typically rely on the following rule:\n\n> Suppose that, assuming {lean}`p` as a hypothesis, we have a proof of {lean}`q`. Then we can “cancel” the hypothesis and obtain a proof of {lean}`Implies p q`.\n\nWe could render this as follows:\n\n```lean\ndef Implies (p q : Prop) : Prop := p → q\nstructure Proof (p : Prop) : Type where\n proof : p\n------\naxiom implies_intro (p q : Prop) :\n (Proof p → Proof q) → Proof (Implies p q)\n```\n\nThis approach would provide us with a reasonable way of building assertions and proofs.\nDetermining that an expression {lean}`t` is a correct proof of assertion {lean}`p` would then\nsimply be a matter of checking that {lean}`t` has type {lean}`Proof p`.\n\nSome simplifications are possible, however. To start with, we can\navoid writing the term {lean}`Proof` repeatedly by conflating {lean}`Proof p`\nwith {lean}`p` itself. In other words, whenever we have {lean}`p : Prop`, we\ncan interpret {lean}`p` as a type, namely, the type of its proofs. We can\nthen read {lean}`t : p` as the assertion that {lean}`t` is a proof of {lean}`p`.\n\nMoreover, once we make this identification, the rules for implication\nshow that we can pass back and forth between {lean}`Implies p q` and\n{lean}`p → q`. In other words, implication between propositions {lean}`p` and {lean}`q`\ncorresponds to having a function that takes any element of {lean}`p` to an\nelement of {lean}`q`. As a result, the introduction of the connective\n{lean}`Implies` is entirely redundant: we can use the usual function space\nconstructor {lean}`p → q` from dependent type theory as our notion of\nimplication.\n\nThis is the approach followed in the Calculus of Constructions, and\nhence in Lean as well. The fact that the rules for implication in a\nproof system for natural deduction correspond exactly to the rules\ngoverning abstraction and application for functions is an instance of\nthe {deftech}_Curry-Howard isomorphism_, sometimes known as the\n{deftech}_propositions-as-types_ paradigm. In fact, the type {lean}`Prop` is\nsyntactic sugar for {lean}`Sort 0`, the very bottom of the type hierarchy\ndescribed in the last chapter. Moreover, {lean}`Type u` is also just\nsyntactic sugar for {lean}`Sort (u+1)`. {lean}`Prop` has some special\nfeatures, but like the other type universes, it is closed under the\narrow constructor: if we have {lean}`p q : Prop`, then {lean}`p → q : Prop`.\n\nThere are at least two ways of thinking about propositions as\ntypes. To some who take a constructive view of logic and mathematics,\nthis is a faithful rendering of what it means to be a proposition: a\nproposition {lean}`p` represents a sort of data type, namely, a\nspecification of the type of data that constitutes a proof. A proof of\n{lean}`p` is then simply an object {lean}`t : p` of the right type.\n\nThose not inclined to this ideology can view it, rather, as a simple\ncoding trick. To each proposition {lean}`p` we associate a type that is\nempty if {lean}`p` is false and has a single element, say {lit}`*`, if {lean}`p`\nis true. In the latter case, let us say that (the type associated\nwith) {lean}`p` is _inhabited_. It just so happens that the rules for\nfunction application and abstraction can conveniently help us keep\ntrack of which elements of {lean}`Prop` are inhabited. So constructing an\nelement {lean}`t : p` tells us that {lean}`p` is indeed true. You can think of\nthe inhabitant of {lean}`p` as being the “fact that {lean}`p` is true.” A\nproof of {lean}`p → q` uses “the fact that {lean}`p` is true” to obtain “the\nfact that {lean}`q` is true.”\n\nIndeed, if {lean}`p : Prop` is any proposition, Lean's kernel treats any\ntwo elements {lean}`t1 t2 : p` as being definitionally equal, much the\nsame way as it treats {lit}`(fun x => t) s` and {lit}`t[s/x]` as\ndefinitionally equal. This is known as {deftech}_proof irrelevance_, and is\nconsistent with the interpretation in the last paragraph. It means\nthat even though we can treat proofs {lean}`t : p` as ordinary objects in\nthe language of dependent type theory, they carry no information\nbeyond the fact that {lean}`p` is true.\n\nThe two ways we have suggested thinking about the\n{tech}[propositions-as-types] paradigm differ in a fundamental way. From the\nconstructive point of view, proofs are abstract mathematical objects\nthat are _denoted_ by suitable expressions in dependent type\ntheory. In contrast, if we think in terms of the coding trick\ndescribed above, then the expressions themselves do not denote\nanything interesting. Rather, it is the fact that we can write them\ndown and check that they are well-typed that ensures that the\nproposition in question is true. In other words, the expressions\n_themselves_ are the proofs.\n\nIn the exposition below, we will slip back and forth between these two\nways of talking, at times saying that an expression “constructs” or\n“produces” or “returns” a proof of a proposition, and at other times\nsimply saying that it “is” such a proof. This is similar to the way\nthat computer scientists occasionally blur the distinction between\nsyntax and semantics by saying, at times, that a program “computes” a\ncertain function, and at other times speaking as though the program\n“is” the function in question.\n\nIn any case, all that really matters is the bottom line. To formally\nexpress a mathematical assertion in the language of dependent type\ntheory, we need to exhibit a term {lean}`p : Prop`. To _prove_ that\nassertion, we need to exhibit a term {lean}`t : p`. Lean's task, as a\nproof assistant, is to help us to construct such a term, {lean}`t`, and to\nverify that it is well-formed and has the correct type.\n\n# Working with Propositions as Types\n%%%\ntag := \"working-with-propositions-as-types\"\n%%%\n\nIn the {tech}[propositions-as-types] paradigm, theorems involving only {lit}`→`\ncan be proved using lambda abstraction and application. In Lean, the\n{kw}`theorem` command introduces a new theorem:\n\n```lean\nset_option linter.unusedVariables false\n---\nvariable {p : Prop}\nvariable {q : Prop}\n\ntheorem t1 : p → q → p := fun hp : p => fun hq : q => hp\n```\n\nCompare this proof to the expression {lean}`fun x : α => fun y : β => x`\nof type {lean}`α → β → α`, where {lean}`α` and {lean}`β` are data types.\nThis describes the function that takes arguments {leanRef}`x` and {leanRef}`y`\nof type {lean}`α` and {lean}`β`, respectively, and returns {leanRef}`x`.\nThe proof of {lean}`t1` has the same form, the only difference being that\n{lean}`p` and {lean}`q` are elements of {lean}`Prop` rather than {lean}`Type`.\nIntuitively, our proof of\n{lean}`p → q → p` assumes {lean}`p` and {lean}`q` are true, and uses the first\nhypothesis (trivially) to establish that the conclusion, {lean}`p`, is\ntrue.\n\nNote that the {kw}`theorem` command is really a version of the\n{kw}`def` command: under the propositions and types\ncorrespondence, proving the theorem {lean}`p → q → p` is really the same\nas defining an element of the associated type. To the kernel type\nchecker, there is no difference between the two.\n\nThere are a few pragmatic differences between definitions and\ntheorems, however. In normal circumstances, it is never necessary to\nunfold the “definition” of a theorem; by {tech}[proof irrelevance], any two\nproofs of that theorem are definitionally equal. Once the proof of a\ntheorem is complete, typically we only need to know that the proof\nexists; it doesn't matter what the proof is. In light of that fact,\nLean tags proofs as _irreducible_, which serves as a hint to the\nparser (more precisely, the _elaborator_) that there is generally no\nneed to unfold them when processing a file. In fact, Lean is generally\nable to process and check proofs in parallel, since assessing the\ncorrectness of one proof does not require knowing the details of\nanother. Additionally, {ref \"variables-and-sections\"}[section variables]\nthat are referred to in the body of a definition are automatically added as\nparameters, but only the variables referred to in a theorem's type are added.\nThis is because the way in which a statement is proved should not influence\nthe statement that is being proved.\n\nAs with definitions, the {kw}`#print` command will show you the proof of\na theorem:\n\n```lean\nset_option linter.unusedVariables false\nvariable {p : Prop}\nvariable {q : Prop}\n------\ntheorem t1 : p → q → p := fun hp : p => fun hq : q => hp\n\n#print t1 -- theorem t1 : ∀ {p q : Prop}, p → q → p := fun {p q} hp hq => hp\n```\n\nNotice that the lambda abstractions {leanRef}`hp : p` and {leanRef}`hq : q` can be\nviewed as temporary assumptions in the proof of {lean}`t1`. Lean also\nallows us to specify the type of the final term {leanRef}`hp`, explicitly,\nwith a {kw}`show` statement:\n\n```lean\nset_option linter.unusedVariables false\nvariable {p : Prop}\nvariable {q : Prop}\n------\ntheorem t1 : p → q → p :=\n fun hp : p =>\n fun hq : q =>\n show p from hp\n```\n\nAdding such extra information can improve the clarity of a proof and\nhelp detect errors when writing a proof. The {kw}`show` command does\nnothing more than annotate the type, and, internally, all the\npresentations of {leanRef}`t1` that we have seen produce the same term.\n\nAs with ordinary definitions, we can move the lambda-abstracted\nvariables to the left of the colon:\n\n```lean\nset_option linter.unusedVariables false\nvariable {p : Prop}\nvariable {q : Prop}\n------\ntheorem t1 (hp : p) (hq : q) : p := hp\n\n#print t1 -- theorem t1 : ∀ {p q : Prop}, p → q → p := fun {p q} hp hq => hp\n```\n\nWe can use the theorem {leanRef}`t1` just as a function application:\n\n```lean\nset_option linter.unusedVariables false\nvariable {p : Prop}\nvariable {q : Prop}\n------\ntheorem t1 (hp : p) (hq : q) : p := hp\n\naxiom hp : p\n\ntheorem t2 : q → p := t1 hp\n```\n\nThe {kw}`axiom` declaration postulates the existence of an\nelement of the given type and may compromise logical consistency. For\nexample, we can use it to postulate that the empty type {lean}`False` has an\nelement:\n\n```lean\naxiom unsound : False\n-- Everything follows from false\ntheorem ex : 1 = 0 :=\n False.elim unsound\n```\n\n:::setup\n```\nvariable {p q : Prop} (hp : p) {t1 : p → q → p}\n```\nDeclaring an “axiom” {lean}`hp : p` is tantamount to declaring that {lean}`p`\nis true, as witnessed by {lean}`hp`. Applying the theorem\n{lean}`t1 : p → q → p` to the fact {lean}`hp : p` that {lean}`p` is true yields the theorem\n{lean}`t1 hp : q → p`.\n\n:::\n\nRecall that we can also write theorem {leanRef}`t1` as follows:\n\n```lean\nset_option linter.unusedVariables false\n------\ntheorem t1 {p q : Prop} (hp : p) (hq : q) : p := hp\n\n#print t1\n```\n\nThe type of {leanRef}`t1` is now {lean}`∀ {p q : Prop}, p → q → p`. We can read\nthis as the assertion “for every pair of propositions {lean}`p`{lit}` `{lean}`q`, we have\n{lean}`p → q → p`.” For example, we can move all parameters to the right\nof the colon:\n\n```lean\nset_option linter.unusedVariables false\n------\ntheorem t1 : ∀ {p q : Prop}, p → q → p :=\n fun {p q : Prop} (hp : p) (hq : q) => hp\n```\n\nIf {lean}`p` and {lean}`q` have been declared as {ref \"variables-and-sections\"}[variables], Lean will\ngeneralize them for us automatically:\n\n```lean\nvariable {p q : Prop}\n\ntheorem t1 : p → q → p := fun (hp : p) (hq : q) => hp\n```\n\nWhen we generalize {leanRef}`t1` in such a way, we can then apply it to\ndifferent pairs of propositions, to obtain different instances of the\ngeneral theorem.\n\n```lean\nset_option linter.unusedVariables false\n------\ntheorem t1 (p q : Prop) (hp : p) (hq : q) : p := hp\n\nvariable (p q r s : Prop)\n\n#check t1 p q -- t1 p q : p → q → p\n#check t1 r s -- t1 r s : r → s → r\n#check t1 (r → s) (s → r) -- t1 (r → s) (s → r) : (r → s) → (s → r) → r → s\n\nvariable (h : r → s)\n\n#check t1 (r → s) (s → r) h -- t1 (r → s) (s → r) h : (s → r) → r → s\n```\n\nOnce again, using the {tech}[propositions-as-types] correspondence, the\nvariable {leanRef}`h` of type {leanRef}`r → s` can be viewed as the hypothesis, or\npremise, that {leanRef}`r → s` holds.\n\nAs another example, let us consider the composition function discussed\nin the last chapter, now with propositions instead of types.\n\n```lean\nvariable (p q r s : Prop)\n\ntheorem t2 (h₁ : q → r) (h₂ : p → q) : p → r :=\n fun h₃ : p =>\n show r from h₁ (h₂ h₃)\n```\n\nAs a theorem of propositional logic, what does {leanRef}`t2` say?\n\nNote that it is often useful to use numeric Unicode subscripts,\nentered as {kbd}`\\0`, {kbd}`\\1`, {kbd}`\\2`, ..., for hypotheses, as we did in\nthis example.\n\n# Propositional Logic\n%%%\ntag := \"propositional-logic\"\n%%%\n\nLean defines all the standard logical connectives and notation. The propositional connectives come with the following notation:\n\n:::table +header\n*\n * ASCII\n * Unicode\n * Editor shortcut\n * Definition\n\n*\n * {lean}`True`\n * {empty}[]\n * {empty}[]\n * {lean}`True`\n\n*\n * {lean}`False`\n * {empty}[]\n * {empty}[]\n * {lean}`False`\n\n*\n * {lean}`Not`\n * {lit}`¬`\n * {kbd}`\\not`, {kbd}`\\neg`\n * {lean}`Not`\n\n*\n * {lit}`/\\`\n * {lit}`∧`\n * {kbd}`\\and`\n * {lean}`And`\n\n*\n * {lit}`\\/`\n * {lit}`∨`\n * {kbd}`\\or`\n * {lean}`Or`\n\n*\n * {lit}`->`\n * {lit}`→`\n * {kbd}`\\to`, {kbd}`\\r`, {kbd}`\\imp`\n * {empty}[]\n\n*\n * {lit}`<->`\n * {lit}`↔`\n * {kbd}`\\iff`, {kbd}`\\lr`\n * {lean}`Iff`\n\n:::\n\nThey all take values in {lean}`Prop`.\n\n```lean\nvariable (p q : Prop)\n\n#check p → q → p ∧ q\n\n#check ¬p → p ↔ False\n\n#check p ∨ q → q ∨ p\n```\n\n:::setup\n```\nvariable (p q r a b c d e : Prop)\n```\n\nThe order of operations is as follows: unary negation {lit}`¬` binds most\nstrongly, then {lit}`∧`, then {lit}`∨`, then {lit}`→`, and finally {lit}`↔`. For\nexample, {lean}`a ∧ b → c ∨ d ∧ e` means {lean}`(a ∧ b) → (c ∨ (d ∧ e))`.\nRemember that {lit}`→` associates to the right (nothing changes\nnow that the arguments are elements of {lean}`Prop`, instead of some other\n{lean}`Type`), as do the other binary connectives. So if we have\n{lean}`p q r : Prop`, the expression {lean}`p → q → r` reads “if {lean}`p`, then if {lean}`q`,\nthen {lean}`r`.” This is just the “curried” form of {lean}`p ∧ q → r`.\n\n:::\n\nIn the last chapter we observed that lambda abstraction can be viewed\nas an “introduction rule” for {lit}`→`. In the current setting, it shows\nhow to “introduce” or establish an implication. Application can be\nviewed as an “elimination rule,” showing how to “eliminate” or use an\nimplication in a proof. The other propositional connectives are\ndefined in Lean's library, and are automatically imported. Each connective\ncomes with its canonical introduction and elimination rules.\n\n## Conjunction\n%%%\ntag := \"conjunction\"\n%%%\n\n:::setup\n```\nvariable (p q : Prop) (h1 : p) (h2 : q)\n```\n\nThe expression {lean}`And.intro h1 h2` builds a proof of {lean}`p ∧ q` using\nproofs {lean}`h1 : p` and {lean}`h2 : q`. It is common to describe\n{lean}`And.intro` as the _and-introduction_ rule. In the next example we\nuse {lean}`And.intro` to create a proof of {lean}`p → q → p ∧ q`.\n\n:::\n\n```lean\nvariable (p q : Prop)\n\nexample (hp : p) (hq : q) : p ∧ q := And.intro hp hq\n\n#check fun (hp : p) (hq : q) => And.intro hp hq\n```\n\nThe {kw}`example` command states a theorem without naming it or storing\nit in the permanent context. Essentially, it just checks that the\ngiven term has the indicated type. It is convenient for illustration,\nand we will use it often.\n\n:::setup\n```\nvariable (p q : Prop) (h : p ∧ q)\n```\n\nThe expression {lean}`And.left h` creates a proof of {lean}`p` from a proof\n{lean}`h : p ∧ q`. Similarly, {lean}`And.right h` is a proof of {lean}`q`. They\nare commonly known as the left and right _and-elimination_ rules.\n\n:::\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : p := And.left h\nexample (h : p ∧ q) : q := And.right h\n```\n\nWe can now prove {lean}`p ∧ q → q ∧ p` with the following proof term.\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : q ∧ p :=\n And.intro (And.right h) (And.left h)\n```\n\n:::setup\n```\nvariable (p q : Prop) (hp : p) (hq : q) (α β : Type) (a : α) (b : β)\n\n```\nNotice that and-introduction and and-elimination are similar to the\npairing and projection operations for the Cartesian product. The\ndifference is that given {lean}`hp : p` and {lean}`hq : q`, {lean}`And.intro hp hq` has type\n{lean}`p ∧ q : Prop`, while given {lean}`a : α` and {lean}`b : β`, {lean}`Prod.mk a b` has type\n{lean}`α × β : Type`. {lean}`Prod` cannot be used with {lean}`Prop`s, and {lean}`And` cannot be used with {lean}`Type`s.\nThe similarity between {lit}`∧` and {lit}`×` is another instance\nof the {tech}[Curry-Howard isomorphism], but in contrast to implication and\nthe function space constructor, {lit}`∧` and {lit}`×` are treated separately\nin Lean. With the analogy, however, the proof we have just constructed\nis similar to a function that swaps the elements of a pair.\n\nWe will see in {ref \"structures-and-records\"}[Structures and Records] that certain\ntypes in Lean are _structures_, which is to say, the type is defined\nwith a single canonical _constructor_ which builds an element of the\ntype from a sequence of suitable arguments. For every {lean}`p q : Prop`,\n{lean}`p ∧ q` is an example: the canonical way to construct an element is\nto apply {lean}`And.intro` to suitable arguments {lean}`hp : p` and\n{lean}`hq : q`. Lean allows us to use _anonymous constructor_ notation\n{lit}`⟨arg1, arg2, ...⟩` in situations like these, when the relevant type is an\ninductive type and can be inferred from the context. In particular, we\ncan often write {lean (type := \"p ∧ q\")}`⟨hp, hq⟩` instead of {lean}`And.intro hp hq`:\n\n:::\n\n```lean\nvariable (p q : Prop)\nvariable (hp : p) (hq : q)\n\n#check (⟨hp, hq⟩ : p ∧ q)\n```\n\nThese angle brackets are obtained by typing {kbd}`\\<` and {kbd}`\\>`, respectively.\n\n:::setup\n```\ninductive Foo where | mk\ninductive Bar where | mk : Foo → Bar\nvariable (e : Foo)\ndef Foo.bar (x : Foo) : Bar := .mk x\n```\n\nLean provides another useful syntactic gadget. Given an expression\n{lean}`e` of an inductive type {lean}`Foo` (possibly applied to some\narguments), the notation {lean}`e.bar` is shorthand for {lean}`Foo.bar e`.\nThis provides a convenient way of accessing functions without opening\na namespace. For example, the following two expressions mean the same\nthing:\n\n:::\n\n```lean\nvariable (xs : List Nat)\n\n#check List.length xs\n\n#check xs.length\n```\n\n:::setup\n```\nvariable (p q : Prop) (h : p ∧ q)\n```\n\n\nAs a result, given {lean}`h : p ∧ q`, we can write {lean}`h.left` for\n{lean}`And.left h` and {lean}`h.right` for {lean}`And.right h`. We can therefore\nrewrite the sample proof above conveniently as follows:\n\n:::\n\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : q ∧ p :=\n ⟨h.right, h.left⟩\n```\n\nThere is a fine line between brevity and obfuscation, and omitting\ninformation in this way can sometimes make a proof harder to read. But\nfor straightforward constructions like the one above, when the type of\n{leanRef}`h` and the goal of the construction are salient, the notation is\nclean and effective.\n\nIt is common to iterate constructions like “And.” Lean also allows you\nto flatten nested constructors that associate to the right, so that\nthese two proofs are equivalent:\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : q ∧ p ∧ q :=\n ⟨h.right, ⟨h.left, h.right⟩⟩\n\nexample (h : p ∧ q) : q ∧ p ∧ q :=\n ⟨h.right, h.left, h.right⟩\n```\n\nThis is often useful as well.\n\n## Disjunction\n%%%\ntag := \"disjunction\"\n%%%\n\n:::setup\n```\nvariable (p q : Prop) (hp : p) (hq : q)\n```\n\n\nThe expression {lean}`Or.intro_left q hp` creates a proof of {lean}`p ∨ q`\nfrom a proof {lean}`hp : p`. Similarly, {lean}`Or.intro_right p hq` creates a\nproof for {lean}`p ∨ q` using a proof {lean}`hq : q`. These are the left and\nright _or-introduction_ rules.\n:::\n\n```lean\nvariable (p q : Prop)\nexample (hp : p) : p ∨ q := Or.intro_left q hp\nexample (hq : q) : p ∨ q := Or.intro_right p hq\n```\n\n:::setup\n```\nvariable (p q r : Prop) (hpq : p ∨ q) (hpr : p → r) (hqr : q → r)\n```\n\nThe _or-elimination_ rule is slightly more complicated. The idea is\nthat we can prove {lean}`r` from {lean}`p ∨ q`, by showing that {lean}`r` follows\nfrom {lean}`p` and that {lean}`r` follows from {lean}`q`. In other words, it is a\nproof by cases. In the expression {lean}`Or.elim hpq hpr hqr`, {lean}`Or.elim`\ntakes three arguments, {lean}`hpq : p ∨ q`, {lean}`hpr : p → r` and\n{lean}`hqr : q → r`, and produces a proof of {lean}`r`. In the following example, we use\n{lean}`Or.elim` to prove {lean}`p ∨ q → q ∨ p`.\n:::\n\n```lean\nvariable (p q r : Prop)\n\nexample (h : p ∨ q) : q ∨ p :=\n Or.elim h\n (fun hp : p =>\n show q ∨ p from Or.intro_right q hp)\n (fun hq : q =>\n show q ∨ p from Or.intro_left p hq)\n```\n\nIn most cases, the first argument of {lean}`Or.intro_right` and\n{lean}`Or.intro_left` can be inferred automatically by Lean. Lean\ntherefore provides {lean}`Or.inr` and {lean}`Or.inl` which can be viewed as\nshorthand for {lean}`Or.intro_right _` and {lean}`Or.intro_left _`. Thus the\nproof term above could be written more concisely:\n\n```lean\nvariable (p q r : Prop)\n\nexample (h : p ∨ q) : q ∨ p :=\n Or.elim h (fun hp => Or.inr hp) (fun hq => Or.inl hq)\n```\n\nNotice that there is enough information in the full expression for\nLean to infer the types of {leanRef}`hp` and {leanRef}`hq` as well. But using the\ntype annotations in the longer version makes the proof more readable,\nand can help catch and debug errors.\n\n:::setup\n```\nvariable (h : p ∨ q)\n```\n\nBecause {lean}`Or` has two constructors, we cannot use anonymous\nconstructor notation. But we can still write {lean}`h.elim` instead of\n{lean}`Or.elim h`:\n:::\n\n```lean\nvariable (p q r : Prop)\n\nexample (h : p ∨ q) : q ∨ p :=\n h.elim (fun hp => Or.inr hp) (fun hq => Or.inl hq)\n```\n\nOnce again, you should exercise judgment as to whether such\nabbreviations enhance or diminish readability.\n\n## Negation and Falsity\n%%%\ntag := \"negation-and-falsity\"\n%%%\n\n:::setup\n```\nvariable (p q : Prop) (hnp : ¬ p) (hp : p)\n```\n\nNegation, {lean}`¬p`, is actually defined to be {lean}`p → False`, so we\nobtain {lean}`¬p` by deriving a contradiction from {lean}`p`. Similarly, the\nexpression {lean}`hnp hp` produces a proof of {lean}`False` from {lean}`hp : p`\nand {lean}`hnp : ¬p`. The next example uses both these rules to produce a\nproof of {lean}`(p → q) → ¬q → ¬p`. (The symbol {lit}`¬` is produced by\ntyping {kbd}`\\not` or {kbd}`\\neg`.)\n\n:::\n\n```lean\nvariable (p q : Prop)\n\nexample (hpq : p → q) (hnq : ¬q) : ¬p :=\n fun hp : p =>\n show False from hnq (hpq hp)\n```\n\nThe connective {lean}`False` has a single elimination rule,\n{lean}`False.elim`, which expresses the fact that anything follows from a\ncontradiction. This rule is sometimes called _ex falso_ (short for _ex\nfalso sequitur quodlibet_), or the _principle of explosion_.\n\n```lean\nvariable (p q : Prop)\n\nexample (hp : p) (hnp : ¬p) : q := False.elim (hnp hp)\n```\n\nThe arbitrary fact, {lean}`q`, that follows from falsity is an implicit\nargument in {lean}`False.elim` and is inferred automatically. This\npattern, deriving an arbitrary fact from contradictory hypotheses, is\nquite common, and is represented by {lean}`absurd`.\n\n```lean\nvariable (p q : Prop)\n\nexample (hp : p) (hnp : ¬p) : q := absurd hp hnp\n```\n\nHere, for example, is a proof of {lean}`¬p → q → (q → p) → r`:\n\n```lean\nvariable (p q r : Prop)\n\nexample (hnp : ¬p) (hq : q) (hqp : q → p) : r :=\n absurd (hqp hq) hnp\n```\n\nIncidentally, just as {lean}`False` has only an elimination rule, {lean}`True`\nhas only an introduction rule, {lean}`True.intro : True`. In other words,\n{lean}`True` is simply true, and has a canonical proof, {lean}`True.intro`.\n\n## Logical Equivalence\n%%%\ntag := \"logical-equivalence\"\n%%%\n\n:::setup\n\n```\nvariable (p q : Prop) (h1 : p → q) (h2 : q → p) (h : p ↔ q)\n```\n\nThe expression {lean}`Iff.intro h1 h2` produces a proof of {lean}`p ↔ q` from\n{lean}`h1 : p → q` and {lean}`h2 : q → p`. The expression {lean}`Iff.mp h`\nproduces a proof of {lean}`p → q` from {lean}`h : p ↔ q`. Similarly,\n{lean}`Iff.mpr h` produces a proof of {lean}`q → p` from {lean}`h : p ↔ q`. Here is a proof\nof {lean}`p ∧ q ↔ q ∧ p`:\n\n:::\n```lean\nvariable (p q : Prop)\n\ntheorem and_swap : p ∧ q ↔ q ∧ p :=\n Iff.intro\n (fun h : p ∧ q =>\n show q ∧ p from And.intro (And.right h) (And.left h))\n (fun h : q ∧ p =>\n show p ∧ q from And.intro (And.right h) (And.left h))\n\n#check and_swap p q -- and_swap p q : p ∧ q ↔ q ∧ p\n\nvariable (h : p ∧ q)\nexample : q ∧ p := Iff.mp (and_swap p q) h\n```\n\nWe can use the anonymous constructor notation to construct a proof of\n{lean}`p ↔ q` from proofs of the forward and backward directions, and we\ncan also use {lit}`.` notation with {lit}`mp` and {lit}`mpr`. The previous\nexamples can therefore be written concisely as follows:\n\n```lean\nvariable (p q : Prop)\n\ntheorem and_swap : p ∧ q ↔ q ∧ p :=\n ⟨ fun h => ⟨h.right, h.left⟩, fun h => ⟨h.right, h.left⟩ ⟩\n\nexample (h : p ∧ q) : q ∧ p := (and_swap p q).mp h\n```\n\n# Introducing Auxiliary Subgoals\n%%%\ntag := \"introducing-auxiliary-subgoals\"\n%%%\n\nThis is a good place to introduce another device Lean offers to help\nstructure long proofs, namely, the {kw}`have` construct, which\nintroduces an auxiliary subgoal in a proof. Here is a small example,\nadapted from the last section:\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : q ∧ p :=\n have hp : p := h.left\n have hq : q := h.right\n show q ∧ p from And.intro hq hp\n```\n\n:::setup\n```\nvariable (p q : Prop) (s : p) (t : q)\n```\n\nInternally, the expression {lean}`have h : p := s; t` produces the term\n{lean}`(fun (h : p) => t) s`. In other words, {lean}`s` is a proof of {lean}`p`,\n{lean}`t` is a proof of the desired conclusion assuming {leanRef}`h : p`, and the\ntwo are combined by a lambda abstraction and application. This simple\ndevice is extremely useful when it comes to structuring long proofs,\nsince we can use intermediate {kw}`have`'s as stepping stones leading to\nthe final goal.\n:::\n\nLean also supports a structured way of reasoning backwards from a\ngoal, which models the “suffices to show” construction in ordinary\nmathematics. The next example simply permutes the last two lines in\nthe previous proof.\n\n```lean\nvariable (p q : Prop)\n\nexample (h : p ∧ q) : q ∧ p :=\n have hp : p := h.left\n suffices hq : q from And.intro hq hp\n show q from And.right h\n```\n\nWriting {leanRef}`suffices hq : q` leaves us with two goals. First, we have\nto show that it indeed suffices to show {lean}`q`, by proving the original\ngoal of {leanRef}`q ∧ p` with the additional hypothesis {leanRef}`hq : q`. Finally,\nwe have to show {leanRef}`q`.\n\n# Classical Logic\n%%%\ntag := \"classical-logic\"\n%%%\n\nThe introduction and elimination rules we have seen so far are all\nconstructive, which is to say, they reflect a computational\nunderstanding of the logical connectives based on the\n{tech}[propositions-as-types] correspondence. Ordinary classical logic adds to\nthis the law of the excluded middle, {lean}`p ∨ ¬p`. To use this\nprinciple, you have to open the classical namespace.\n\n```lean\nopen Classical\n\nvariable (p : Prop)\n\n#check em p\n```\n\n:::setup\n```\nvariable (p q RH : Prop)\n```\n\nIntuitively, the constructive “Or” is very strong: asserting {lean}`p ∨ q`\namounts to knowing which is the case. If {lean}`RH` represents the Riemann\nhypothesis, a classical mathematician is willing to assert\n{lean}`RH ∨ ¬RH`, even though we cannot yet assert either disjunct.\n\n:::\n\nOne consequence of the law of the excluded middle is the principle of\ndouble-negation elimination:\n\n```lean\nopen Classical\n\ntheorem dne {p : Prop} (h : ¬¬p) : p :=\n Or.elim (em p)\n (fun hp : p => hp)\n (fun hnp : ¬p => absurd hnp h)\n```\n\n:::setup\n```\nopen Classical\nvariable (p : Prop)\ntheorem dne {p : Prop} (h : ¬¬p) : p :=\n Or.elim (em p)\n (fun hp : p => hp)\n (fun hnp : ¬p => absurd hnp h)\n```\n\n\nDouble-negation elimination allows one to prove any proposition,\n{lean}`p`, by assuming {lean}`¬p` and deriving {lean}`False`, because that amounts\nto proving {lean}`¬¬p`. In other words, double-negation elimination allows\none to carry out a proof by contradiction, something which is not\ngenerally possible in constructive logic. As an exercise, you might\ntry proving the converse, that is, showing that {lean}`em` can be proved\nfrom {lean}`dne`.\n\n\n\nThe classical axioms also give you access to additional patterns of\nproof that can be justified by appeal to {lean}`em`. For example, one can\ncarry out a proof by cases:\n:::\n\n```lean\nopen Classical\nvariable (p : Prop)\n\nexample (h : ¬¬p) : p :=\n byCases\n (fun h1 : p => h1)\n (fun h1 : ¬p => absurd h1 h)\n```\n\nOr you can carry out a proof by contradiction:\n\n```lean\nopen Classical\nvariable (p : Prop)\n\nexample (h : ¬¬p) : p :=\n byContradiction\n (fun h1 : ¬p =>\n show False from h h1)\n```\n\nIf you are not used to thinking constructively, it may take some time\nfor you to get a sense of where classical reasoning is used. It is\nneeded in the following example because, from a constructive\nstandpoint, knowing that {lean}`p` and {lean}`q` are not both true does not\nnecessarily tell you which one is false:\n\n```lean\nopen Classical\nvariable (p q : Prop)\n------\nexample (h : ¬(p ∧ q)) : ¬p ∨ ¬q :=\n Or.elim (em p)\n (fun hp : p =>\n Or.inr\n (show ¬q from\n fun hq : q =>\n h ⟨hp, hq⟩))\n (fun hp : ¬p =>\n Or.inl hp)\n```\n\nWe will see later that there _are_ situations in constructive logic\nwhere principles like excluded middle and double-negation elimination\nare permissible, and Lean supports the use of classical reasoning in\nsuch contexts without relying on excluded middle.\n\nThe full list of axioms that are used in Lean to support classical\nreasoning are discussed in {ref \"axioms-and-computation\"}[Axioms and Computation].\n\n# Examples of Propositional Validities\n%%%\ntag := \"examples-of-propositional-validities\"\n%%%\n\n:::setup\n```\nvariable (p q r s : Prop)\n```\n\n\nLean's standard library contains proofs of many valid statements of\npropositional logic, all of which you are free to use in proofs of\nyour own. The following list includes a number of common identities.\n\nCommutativity:\n\n1. {lean}`p ∧ q ↔ q ∧ p`\n2. {lean}`p ∨ q ↔ q ∨ p`\n\nAssociativity:\n\n3. {lean}`(p ∧ q) ∧ r ↔ p ∧ (q ∧ r)`\n4. {lean}`(p ∨ q) ∨ r ↔ p ∨ (q ∨ r)`\n\nDistributivity:\n\n5. {lean}`p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r)`\n6. {lean}`p ∨ (q ∧ r) ↔ (p ∨ q) ∧ (p ∨ r)`\n\nOther properties:\n\n7. {lean}`(p → (q → r)) ↔ (p ∧ q → r)`\n8. {lean}`((p ∨ q) → r) ↔ (p → r) ∧ (q → r)`\n9. {lean}`¬(p ∨ q) ↔ ¬p ∧ ¬q`\n10. {lean}`¬p ∨ ¬q → ¬(p ∧ q)`\n11. {lean}`¬(p ∧ ¬p)`\n12. {lean}`p ∧ ¬q → ¬(p → q)`\n13. {lean}`¬p → (p → q)`\n14. {lean}`(¬p ∨ q) → (p → q)`\n15. {lean}`p ∨ False ↔ p`\n16. {lean}`p ∧ False ↔ False`\n17. {lean}`¬(p ↔ ¬p)`\n18. {lean}`(p → q) → (¬q → ¬p)`\n\nThese require classical reasoning:\n\n19. {lean}`(p → r ∨ s) → ((p → r) ∨ (p → s))`\n20. {lean}`¬(p ∧ q) → ¬p ∨ ¬q`\n21. {lean}`¬(p → q) → p ∧ ¬q`\n22. {lean}`(p → q) → (¬p ∨ q)`\n23. {lean}`(¬q → ¬p) → (p → q)`\n24. {lean}`p ∨ ¬p`\n25. {lean}`(((p → q) → p) → p)`\n\nThe {lean}`sorry` identifier magically produces a proof of anything, or\nprovides an object of any data type at all. Of course, it is unsound\nas a proof method—for example, you can use it to prove {lean}`False`—and\nLean produces severe warnings when files use or import theorems\nwhich depend on it. But it is very useful for building long proofs\nincrementally. Start writing the proof from the top down, using\n{lean}`sorry` to fill in subproofs. Make sure Lean accepts the term with\nall the {lean}`sorry`'s; if not, there are errors that you need to\ncorrect. Then go back and replace each {lean}`sorry` with an actual proof,\nuntil no more remain.\n\nHere is another useful trick. Instead of using {lean}`sorry`, you can use\nan underscore {lit}`_` as a placeholder. Recall this tells Lean that\nthe argument is implicit, and should be filled in automatically. If\nLean tries to do so and fails, it returns with an error message “don't\nknow how to synthesize placeholder,” followed by the type of\nthe term it is expecting, and all the objects and hypotheses available\nin the context. In other words, for each unresolved placeholder, Lean\nreports the subgoal that needs to be filled at that point. You can\nthen construct a proof by incrementally filling in these placeholders.\n\n:::\n\nFor reference, here are two sample proofs of validities taken from the\nlist above.\n\n```lean\nopen Classical\n\n-- distributivity\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) :=\n Iff.intro\n (fun h : p ∧ (q ∨ r) =>\n have hp : p := h.left\n Or.elim (h.right)\n (fun hq : q =>\n show (p ∧ q) ∨ (p ∧ r) from Or.inl ⟨hp, hq⟩)\n (fun hr : r =>\n show (p ∧ q) ∨ (p ∧ r) from Or.inr ⟨hp, hr⟩))\n (fun h : (p ∧ q) ∨ (p ∧ r) =>\n Or.elim h\n (fun hpq : p ∧ q =>\n have hp : p := hpq.left\n have hq : q := hpq.right\n show p ∧ (q ∨ r) from ⟨hp, Or.inl hq⟩)\n (fun hpr : p ∧ r =>\n have hp : p := hpr.left\n have hr : r := hpr.right\n show p ∧ (q ∨ r) from ⟨hp, Or.inr hr⟩))\n\n-- an example that requires classical reasoning\nexample (p q : Prop) : ¬(p ∧ ¬q) → (p → q) :=\n fun h : ¬(p ∧ ¬q) =>\n fun hp : p =>\n show q from\n Or.elim (em q)\n (fun hq : q => hq)\n (fun hnq : ¬q => absurd (And.intro hp hnq) h)\n```\n\n# Exercises\n%%%\ntag := none\n%%%\n\nProve the following identities, replacing the {lean}`sorry` placeholders with actual proofs.\n\n```lean\nvariable (p q r : Prop)\n\n-- commutativity of ∧ and ∨\nexample : p ∧ q ↔ q ∧ p := sorry\nexample : p ∨ q ↔ q ∨ p := sorry\n\n-- associativity of ∧ and ∨\nexample : (p ∧ q) ∧ r ↔ p ∧ (q ∧ r) := sorry\nexample : (p ∨ q) ∨ r ↔ p ∨ (q ∨ r) := sorry\n\n-- distributivity\nexample : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := sorry\nexample : p ∨ (q ∧ r) ↔ (p ∨ q) ∧ (p ∨ r) := sorry\n\n-- other properties\nexample : (p → (q → r)) ↔ (p ∧ q → r) := sorry\nexample : ((p ∨ q) → r) ↔ (p → r) ∧ (q → r) := sorry\nexample : ¬(p ∨ q) ↔ ¬p ∧ ¬q := sorry\nexample : ¬p ∨ ¬q → ¬(p ∧ q) := sorry\nexample : ¬(p ∧ ¬p) := sorry\nexample : p ∧ ¬q → ¬(p → q) := sorry\nexample : ¬p → (p → q) := sorry\nexample : (¬p ∨ q) → (p → q) := sorry\nexample : p ∨ False ↔ p := sorry\nexample : p ∧ False ↔ False := sorry\nexample : (p → q) → (¬q → ¬p) := sorry\n```\n\nProve the following identities, replacing the {lean}`sorry` placeholders\nwith actual proofs. These require classical reasoning.\n\n```lean\nopen Classical\n\nvariable (p q r : Prop)\n\nexample : (p → q ∨ r) → ((p → q) ∨ (p → r)) := sorry\nexample : ¬(p ∧ q) → ¬p ∨ ¬q := sorry\nexample : ¬(p → q) → p ∧ ¬q := sorry\nexample : (p → q) → (¬p ∨ q) := sorry\nexample : (¬q → ¬p) → (p → q) := sorry\nexample : p ∨ ¬p := sorry\nexample : (((p → q) → p) → p) := sorry\n```\n\nProve {lean}`¬(p ↔ ¬p)` without using classical logic.\n"
},
{
"path": "book/TPiL/QuantifiersEquality.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre\nopen Verso.Genre.Manual hiding tactic\nopen TPiL\n\n#doc (Manual) \"Quantifiers and Equality\" =>\n%%%\ntag := \"quantifiers-and-equality\"\n%%%\n\n```setup\nvariable {α : Type u} (p : α → Prop) (x y t : α) (r : α → α → Prop) {β : α → Type v}\n```\n\nThe last chapter introduced you to methods that construct proofs of\nstatements involving the propositional connectives. In this chapter,\nwe extend the repertoire of logical constructions to include the\nuniversal and existential quantifiers, and the equality relation.\n\n# The Universal Quantifier\n%%%\ntag := \"the-universal-quantifier\"\n%%%\n\nNotice that if {lean}`α` is any type, we can represent a unary predicate\n{lean}`p` on {lean}`α` as an object of type {lean}`α → Prop`. In that case, given\n{lean}`x : α`, {lean}`p x` denotes the assertion that {lean}`p` holds of\n{lean}`x`. Similarly, an object {lean}`r : α → α → Prop` denotes a binary\nrelation on {lean}`α`: given {lean}`x y : α`, {lean}`r x y` denotes the assertion\nthat {lean}`x` is related to {lean}`y`.\n\nThe universal quantifier, {lean}`∀ x : α, p x` is supposed to denote the\nassertion that “for every {lean}`x : α`, {lean}`p x`” holds. As with the\npropositional connectives, in systems of natural deduction, “forall”\nis governed by an introduction and elimination rule. Informally, the\nintroduction rule states:\n\n> Given a proof of {lean}`p x`, in a context where {lean}`x : α` is arbitrary, we obtain a proof {lean}`∀ x : α, p x`.\n\nThe elimination rule states:\n\n> Given a proof {lean}`∀ x : α, p x` and any term {lean}`t : α`, we obtain a proof of {lean}`p t`.\n\nAs was the case for implication, the propositions-as-types\ninterpretation now comes into play. Remember the introduction and\nelimination rules for dependent arrow types:\n\n```setup\nvariable {α : Type u} (p : α → Prop) (x y : α) (r : α → α → Prop) {β : α → Type v} {t : {x : α} → β x}\n```\n> Given a term {lean}`t` of type {lean}`β x`, in a context where {lean}`x : α` is arbitrary, we have {lean}`(fun x : α => t) : (x : α) → β x`.\n\n```setup\nvariable {α : Type u} (p : α → Prop) (x y : α) (r : α → α → Prop) {β : α → Type v} {t : α} {s : (x : α) → β x}\n```\n\nThe elimination rule states:\n\n> Given a term {lean}`s : (x : α) → β x` and any term {lean}`t : α`, we have {lean}`s t : β t`.\n\nIn the case where {lean}`p x` has type {lean}`Prop`, if we replace\n{lean}`(x : α) → β x` with {lean}`∀ x : α, p x`, we can read these as the correct rules\nfor building proofs involving the universal quantifier.\n\n:::setup\n```\nvariable {α : Type u} {β : Type v} {p : {x : α} → Prop} (q : Prop)\n```\nThe Calculus of Constructions therefore identifies dependent arrow\ntypes with forall-expressions in this way. If {lean}`p` is any expression,\n{lean}`∀ x : α, p` is nothing more than alternative notation for\n{lean}`(x : α) → p`, with the idea that the former is more natural than the latter\nin cases where {lean}`p` is a proposition. Typically, the expression {lean}`p`\nwill depend on {leanRef}`x : α`. Recall that, in the case of ordinary\nfunction spaces, we could interpret {lean}`α → β` as the special case of\n{lean}`(x : α) → β` in which {lean}`β` does not depend on {leanRef}`x`. Similarly, we\ncan think of an implication {lean}`p → q` between propositions as the\nspecial case of {lean}`∀ x : p, q` in which the expression {lean}`q` does not\ndepend on {leanRef}`x`.\n:::\n\nHere is an example of how the {tech}[propositions-as-types] correspondence gets put into practice.\n\n```lean\nexample (α : Type) (p q : α → Prop) :\n (∀ x : α, p x ∧ q x) → ∀ y : α, p y :=\n fun h : ∀ x : α, p x ∧ q x =>\n fun y : α =>\n show p y from (h y).left\n```\n\nAs a notational convention, we give the universal quantifier the\nwidest scope possible, so parentheses are needed to limit the\nquantifier over {leanRef}`x` to the hypothesis in the example above. The\ncanonical way to prove {lean}`∀ y : α, p y` is to take an arbitrary {leanRef}`y`,\nand prove {leanRef}`p y`. This is the introduction rule. Now, given that\n{leanRef}`h` has type {leanRef}`∀ x : α, p x ∧ q x`, the expression {leanRef}`h y` has type\n{leanRef}`p`{lit}` `{leanRef}`y`{lit}` ∧ `{leanRef}`q`{lit}` `{leanRef}`y`. This is the elimination rule. Taking the left conjunct\ngives the desired conclusion, {leanRef}`p y`.\n\n:::setup\n```\nvariable {x z : α}\n```\n\nRemember that expressions which differ up to renaming of bound\nvariables are considered to be equivalent. So, for example, we could\nhave used the same variable, {lean}`x`, in both the hypothesis and\nconclusion, and instantiated it by a different variable, {lean}`z`, in the\nproof:\n:::\n\n```lean\nexample (α : Type) (p q : α → Prop) :\n (∀ x : α, p x ∧ q x) → ∀ x : α, p x :=\n fun h : ∀ x : α, p x ∧ q x =>\n fun z : α =>\n show p z from And.left (h z)\n```\n\nAs another example, here is how we can express the fact that a relation, {lean}`r`, is transitive:\n\n```lean\nvariable (α : Type) (r : α → α → Prop)\nvariable (trans_r : ∀ x y z, r x y → r y z → r x z)\n\nvariable (a b c : α)\nvariable (hab : r a b) (hbc : r b c)\n\n#check trans_r -- trans_r : ∀ (x y z : α), r x y → r y z → r x z\n\n#check trans_r a b c -- trans_r a b c : r a b → r b c → r a c\n\n#check trans_r a b c hab -- trans_r a b c hab : r b c → r a c\n\n#check trans_r a b c hab hbc -- trans_r a b c hab hbc : r a c\n```\n\nThink about what is going on here. When we instantiate {leanRef}`trans_r` at\nthe values {leanRef}`a b c`, we end up with a proof of {leanRef}`r`{lit}` `{leanRef}`a b`{lit}` → `{leanRef}`r`{lit}` `{leanRef}`b c`{lit}` → `{leanRef}`r`{lit}` `{leanRef}`a`{lit}` `{leanRef}`c`.\nApplying this to the “hypothesis” {leanRef}`hab : r a b`, we get a proof\nof the implication {leanRef}`r`{lit}` `{leanRef}`b c`{lit}` → `{leanRef}`r`{lit}` `{leanRef}`a`{lit}` `{leanRef}`c`. Finally, applying it to the\nhypothesis {leanRef}`hbc` yields a proof of the conclusion {leanRef}`r`{lit}` `{leanRef}`a`{lit}` `{leanRef}`c`.\n\nIn situations like this, it can be tedious to supply the arguments\n{leanRef}`a b c`, when they can be inferred from {leanRef}`hab hbc`. For that reason, it\nis common to make these arguments implicit:\n\n```lean\nvariable (α : Type) (r : α → α → Prop)\nvariable (trans_r : ∀ {x y z}, r x y → r y z → r x z)\n\nvariable (a b c : α)\nvariable (hab : r a b) (hbc : r b c)\n\n#check trans_r\n\n#check trans_r hab\n\n#check trans_r hab hbc\n```\n\nThe advantage is that we can simply write {leanRef}`trans_r hab hbc` as a\nproof of {leanRef}`r`{lit}` `{leanRef}`a`{lit}` `{leanRef}`c`. A disadvantage is that Lean does not have enough\ninformation to infer the types of the arguments in the expressions\n{leanRef}`trans_r` and {leanRef}`trans_r hab`. The output of the first {kw}`#check`\ncommand is {lit}`r ?m.1 ?m.2 → r ?m.2 ?m.3 → r ?m.1 ?m.3`, indicating\nthat the implicit arguments are unspecified in this case.\n\nHere is an example of how we can carry out elementary reasoning with an equivalence relation:\n\n```lean\nvariable (α : Type) (r : α → α → Prop)\n\nvariable (refl_r : ∀ x, r x x)\nvariable (symm_r : ∀ {x y}, r x y → r y x)\nvariable (trans_r : ∀ {x y z}, r x y → r y z → r x z)\n\nexample (a b c d : α) (hab : r a b) (hcb : r c b) (hcd : r c d) : r a d :=\n trans_r (trans_r hab (symm_r hcb)) hcd\n```\n\nTo get used to using universal quantifiers, you should try some of the\nexercises at the end of this section.\n\n:::setup\n```\nuniverse i j\nvariable (α : Sort i) (β : {x : α} → Sort j) {x : α}\n```\n\nIt is the typing rule for dependent arrow types, and the universal\nquantifier in particular, that distinguishes {lean}`Prop` from other\ntypes. Suppose we have {lean}`α : Sort i` and {lean}`β : Sort j`, where the\nexpression {lean}`β` may depend on a variable {lean}`x : α`. Then\n{lean}`(x : α) → β` is an element of {lean}`Sort (imax i j)`, where {lit}`imax i j` is the\nmaximum of {lit}`i` and {lit}`j` if {lit}`j` is not {lit}`0`, and {lit}`0` otherwise.\n\nThe idea is as follows. If {lit}`j` is not {lit}`0`, then {lean}`(x : α) → β` is\nan element of {lean}`Sort (max i j)`. In other words, the type of\ndependent functions from {lean}`α` to {lean}`β` “lives” in the universe whose\nindex is the maximum of {lit}`i` and {lit}`j`. Suppose, however, that {lean}`β`\nis of {lean}`Sort 0`, that is, an element of {lean}`Prop`. In that case,\n{lean}`(x : α) → β` is an element of {lean}`Sort 0` as well, no matter which\ntype universe {lean}`α` lives in. In other words, if {lean}`β` is a\nproposition depending on {lean}`α`, then {lean}`∀ x : α, β` is again a\nproposition. This reflects the interpretation of {lean}`Prop` as the type\nof propositions rather than data, and it is what makes {lean}`Prop`\n{deftech}_impredicative_.\n\nThe term “{deftech}[predicative]” stems from foundational developments around the\nturn of the twentieth century, when logicians such as Poincaré and\nRussell blamed set-theoretic paradoxes on the “vicious circles” that\narise when we define a property by quantifying over a collection that\nincludes the very property being defined. Notice that if {lean}`α` is any\ntype, we can form the type {lean}`α → Prop` of all predicates on {lean}`α`\n(the “power type of {lean}`α`”). The impredicativity of {lean}`Prop` means that we\ncan form propositions that quantify over {lean}`α → Prop`. In particular,\nwe can define predicates on {lean}`α` by quantifying over all predicates\non {lean}`α`, which is exactly the type of circularity that was once\nconsidered problematic.\n:::\n\n# Equality\n%%%\ntag := \"equality\"\n%%%\n\nLet us now turn to one of the most fundamental relations defined in\nLean's library, namely, the equality relation. In the chapter on {ref \"inductive-types\"}[inductive types],\nwe will explain _how_ equality is defined from the primitives of Lean's logical framework.\nIn the meanwhile, here we explain how to use it.\n\nOf course, a fundamental property of equality is that it is an equivalence relation:\n\n```lean\n#check Eq.refl -- Eq.refl.{u_1} {α : Sort u_1} (a : α) : a = a\n\n#check Eq.symm -- Eq.symm.{u} {α : Sort u} {a b : α} (h : a = b) : b = a\n\n#check Eq.trans -- Eq.trans.{u} {α : Sort u} {a b c : α} (h₁ : a = b) (h₂ : b = c) : a = c\n```\n\nWe can make the output easier to read by telling Lean not to insert\nthe implicit arguments (which are displayed here as metavariables).\n\n```lean\nuniverse u\n\n#check @Eq.refl.{u} -- @Eq.refl : ∀ {α : Sort u} (a : α), a = a\n\n#check @Eq.symm.{u} -- @Eq.symm : ∀ {α : Sort u} {a b : α}, a = b → b = a\n\n#check @Eq.trans.{u} -- @Eq.trans : ∀ {α : Sort u} {a b c : α}, a = b → b = c → a = c\n```\n\nThe inscription {lit}`.{u}` tells Lean to instantiate the constants at the universe {lit}`u`.\n\nThus, for example, we can specialize the example from the previous section to the equality relation:\n\n```lean\nvariable (α : Type) (a b c d : α)\nvariable (hab : a = b) (hcb : c = b) (hcd : c = d)\n\nexample : a = d :=\n Eq.trans (Eq.trans hab (Eq.symm hcb)) hcd\n```\n\nWe can also use the projection notation:\n\n```lean\nvariable (α : Type) (a b c d : α)\nvariable (hab : a = b) (hcb : c = b) (hcd : c = d)\n------\nexample : a = d := (hab.trans hcb.symm).trans hcd\n```\n\nReflexivity is more powerful than it looks. Recall that terms in the\nCalculus of Constructions have a computational interpretation, and\nthat the logical framework treats terms with a common reduct as the\nsame. As a result, some nontrivial identities can be proved by\nreflexivity:\n\n```lean\nvariable (α β : Type)\n\nexample (f : α → β) (a : α) : (fun x => f x) a = f a := Eq.refl _\nexample (a : α) (b : β) : (a, b).1 = a := Eq.refl _\nexample : 2 + 3 = 5 := Eq.refl _\n```\n\nThis feature of the framework is so important that the library defines a notation {lean}`rfl` for {lean}`Eq.refl _`:\n\n```lean\nvariable (α β : Type)\n------\nexample (f : α → β) (a : α) : (fun x => f x) a = f a := rfl\nexample (a : α) (b : β) : (a, b).1 = a := rfl\nexample : 2 + 3 = 5 := rfl\n```\n\n:::setup\n```\nvariable {a b : α} {p : α → Prop} {h1 : a = b} {h2 : p a}\n```\n\nEquality is much more than an equivalence relation, however. It has\nthe important property that every assertion respects the equivalence,\nin the sense that we can substitute equal expressions without changing\nthe truth value. That is, given {lean}`h1 : a = b` and {lean}`h2 : p a`, we\ncan construct a proof for {lean}`p b` using substitution:\n{lean}`Eq.subst h1 h2`.\n:::\n\n```lean\nexample (α : Type) (a b : α) (p : α → Prop)\n (h1 : a = b) (h2 : p a) : p b :=\n Eq.subst h1 h2\n\nexample (α : Type) (a b : α) (p : α → Prop)\n (h1 : a = b) (h2 : p a) : p b :=\n h1 ▸ h2\n```\n\nThe triangle in the second presentation is a macro built on top of\n{lean}`Eq.subst` and {lean}`Eq.symm`, and you can enter it by typing {kbd}`\\t`.\n\nThe rule {lean}`Eq.subst` is used to define the following auxiliary rules,\nwhich carry out more explicit substitutions. They are designed to deal\nwith applicative terms, that is, terms of form {lean}`s t`. Specifically,\n{lean}`congrArg` can be used to replace the argument, {lean}`congrFun` can be\nused to replace the term that is being applied, and {lean}`congr` can be\nused to replace both at once.\n\n```lean\nvariable (α : Type)\nvariable (a b : α)\nvariable (f g : α → Nat)\nvariable (h₁ : a = b)\nvariable (h₂ : f = g)\n\nexample : f a = f b := congrArg f h₁\nexample : f a = g a := congrFun h₂ a\nexample : f a = g b := congr h₂ h₁\n```\n\nLean's library contains a large number of common identities, such as these:\n\n```lean\nvariable (a b c : Nat)\n\nexample : a + 0 = a := Nat.add_zero a\nexample : 0 + a = a := Nat.zero_add a\nexample : a * 1 = a := Nat.mul_one a\nexample : 1 * a = a := Nat.one_mul a\nexample : a + b = b + a := Nat.add_comm a b\nexample : a + b + c = a + (b + c) := Nat.add_assoc a b c\nexample : a * b = b * a := Nat.mul_comm a b\nexample : a * b * c = a * (b * c) := Nat.mul_assoc a b c\nexample : a * (b + c) = a * b + a * c := Nat.mul_add a b c\nexample : a * (b + c) = a * b + a * c := Nat.left_distrib a b c\nexample : (a + b) * c = a * c + b * c := Nat.add_mul a b c\nexample : (a + b) * c = a * c + b * c := Nat.right_distrib a b c\n```\n\nNote that {lean}`Nat.mul_add` and {lean}`Nat.add_mul` are alternative names\nfor {lean}`Nat.left_distrib` and {lean}`Nat.right_distrib`, respectively. The\nproperties above are stated for the natural numbers (type {lean}`Nat`).\n\nHere is an example of a calculation in the natural numbers that uses\nsubstitution combined with associativity and distributivity.\n\n```lean\nexample (x y : Nat) :\n (x + y) * (x + y) =\n x * x + y * x + x * y + y * y :=\n have h1 : (x + y) * (x + y) = (x + y) * x + (x + y) * y :=\n Nat.mul_add (x + y) x y\n have h2 : (x + y) * (x + y) = x * x + y * x + (x * y + y * y) :=\n (Nat.add_mul x y x) ▸ (Nat.add_mul x y y) ▸ h1\n h2.trans (Nat.add_assoc (x * x + y * x) (x * y) (y * y)).symm\n```\n\n:::setup\n```\nvariable {α : Type u}\n```\n\n```lean (show := false)\nexample {α : Type u} {x y : α} {h : x = y} {p : α → Prop} {e : p x} : p y := h ▸ e\n```\n\n\nNotice that the second implicit parameter to {lean}`Eq.subst`, which\nprovides the context in which the substitution is to occur, has type\n{lean}`α → Prop`. Inferring this predicate therefore requires an instance\nof _higher-order unification_. In full generality, the problem of\ndetermining whether a higher-order unifier exists is undecidable, and\nLean can at best provide imperfect and approximate solutions to the\nproblem. As a result, {lean}`Eq.subst` doesn't always do what you want it\nto. The macro {leanRef}`h ▸ e` uses more effective heuristics for computing\nthis implicit parameter, and often succeeds in situations where\napplying {lean}`Eq.subst` fails.\n\n:::\n\nBecause equational reasoning is so common and important, Lean provides\na number of mechanisms to carry it out more effectively. The next\nsection offers syntax that allow you to write calculational proofs in\na more natural and perspicuous way. But, more importantly, equational\nreasoning is supported by a term rewriter, a simplifier, and other\nkinds of automation. The term rewriter and simplifier are described\nbriefly in the next section, and then in greater detail in the next\nchapter.\n\n# Calculational Proofs\n%%%\ntag := \"calculational-proofs\"\n%%%\n\nA calculational proof is just a chain of intermediate results that are\nmeant to be composed by basic principles such as the transitivity of\nequality. In Lean, a calculational proof starts with the keyword\n{kw}`calc`, and has the following syntax:\n\n```\ncalc\n _0 'op_1' _1 ':=' _1\n '_' 'op_2' _2 ':=' _2\n ...\n '_' 'op_n' _n ':=' _n\n```\n\nNote that the {kw}`calc` relations all have the same indentation. Each\n{lit}`_i` is a proof for {lit}`_{i-1} op_i _i`.\n\nWe can also use {lit}`_` in the first relation (right after {lit}`_0`)\nwhich is useful to align the sequence of relation/proof pairs:\n\n```\ncalc _0\n '_' 'op_1' _1 ':=' _1\n '_' 'op_2' _2 ':=' _2\n ...\n '_' 'op_n' _n ':=' _n\n```\n\nHere is an example:\n\n```lean\nvariable (a b c d e : Nat)\n\ntheorem T\n (h1 : a = b)\n (h2 : b = c + 1)\n (h3 : c = d)\n (h4 : e = 1 + d) :\n a = e :=\n calc\n a = b := h1\n _ = c + 1 := h2\n _ = d + 1 := congrArg Nat.succ h3\n _ = 1 + d := Nat.add_comm d 1\n _ = e := Eq.symm h4\n```\n\nThis style of writing proofs is most effective when it is used in\nconjunction with the {tactic}`simp` and {tactic}`rw` tactics, which are\ndiscussed in greater detail in the next chapter. For example, using\n{tactic}`rw` for rewrite, the proof above could be written\nas follows:\n\n```lean\nvariable (a b c d e : Nat)\n------\ntheorem T\n (h1 : a = b)\n (h2 : b = c + 1)\n (h3 : c = d)\n (h4 : e = 1 + d) :\n a = e :=\n calc\n a = b := by rw [h1]\n _ = c + 1 := by rw [h2]\n _ = d + 1 := by rw [h3]\n _ = 1 + d := by rw [Nat.add_comm]\n _ = e := by rw [h4]\n```\n\nEssentially, the {kw}`rw` tactic uses a given equality (which can be a\nhypothesis, a theorem name, or a complex term) to “rewrite” the\ngoal. If doing so reduces the goal to an identity {lean}`t = t`, the\ntactic applies reflexivity to prove it.\n\nRewrites can be applied sequentially, so that the proof above can be\nshortened to this:\n\n```lean\nvariable (a b c d e : Nat)\n------\ntheorem T\n (h1 : a = b)\n (h2 : b = c + 1)\n (h3 : c = d)\n (h4 : e = 1 + d) :\n a = e :=\n calc\n a = d + 1 := by rw [h1, h2, h3]\n _ = 1 + d := by rw [Nat.add_comm]\n _ = e := by rw [h4]\n```\n\nOr even this:\n\n```lean\nvariable (a b c d e : Nat)\n------\ntheorem T\n (h1 : a = b)\n (h2 : b = c + 1)\n (h3 : c = d)\n (h4 : e = 1 + d) :\n a = e :=\n by rw [h1, h2, h3, Nat.add_comm, h4]\n```\n\n\nThe {kw}`simp` tactic, instead, rewrites the goal by applying the given\nidentities repeatedly, in any order, anywhere they are applicable in a\nterm. It also uses other rules that have been previously declared to\nthe system, and applies commutativity wisely to avoid looping. As a\nresult, we can also prove the theorem as follows:\n\n```lean\nvariable (a b c d e : Nat)\n------\ntheorem T\n (h1 : a = b)\n (h2 : b = c + 1)\n (h3 : c = d)\n (h4 : e = 1 + d) :\n a = e :=\n by simp [h1, h2, h3, Nat.add_comm, h4]\n```\n\nWe will discuss variations of {kw}`rw` and {kw}`simp` in the next chapter.\n\nThe {kw}`calc` command can be configured for any relation that supports\nsome form of transitivity. It can even combine different relations.\n\n```lean\nvariable (a b c d : Nat)\nexample (h1 : a = b) (h2 : b ≤ c) (h3 : c + 1 < d) : a < d :=\n calc\n a = b := h1\n _ < b + 1 := Nat.lt_succ_self b\n _ ≤ c + 1 := Nat.succ_le_succ h2\n _ < d := h3\n```\n\nYou can “teach” {kw}`calc` new transitivity theorems by adding new instances\nof the {lean}`Trans` type class. Type classes are introduced later, but the following\nsmall example demonstrates how to extend the {kw}`calc` notation using new {lean}`Trans` instances.\n\n```lean\ndef divides (x y : Nat) : Prop :=\n ∃ k, k*x = y\n\ndef divides_trans (h₁ : divides x y) (h₂ : divides y z) : divides x z :=\n let ⟨k₁, d₁⟩ := h₁\n let ⟨k₂, d₂⟩ := h₂\n ⟨k₁ * k₂, by rw [Nat.mul_comm k₁ k₂, Nat.mul_assoc, d₁, d₂]⟩\n\ndef divides_mul (x : Nat) (k : Nat) : divides x (k*x) :=\n ⟨k, rfl⟩\n\ninstance : Trans divides divides divides where\n trans := divides_trans\n\nexample (h₁ : divides x y) (h₂ : y = z) : divides x (2*z) :=\n calc\n divides x y := h₁\n _ = z := h₂\n divides _ (2*z) := divides_mul ..\n\ninfix:50 \" | \" => divides\n\nexample (h₁ : divides x y) (h₂ : y = z) : divides x (2*z) :=\n calc\n x | y := h₁\n _ = z := h₂\n _ | 2*z := divides_mul ..\n```\n\nThe example above also makes it clear that you can use {kw}`calc` even if you do not have an infix\nnotation for your relation. Lean already includes the standard Unicode notation for divisibility\n(using {lit}`∣`, which can be entered as {kbd}`\\dvd` or {kbd}`\\mid`), so the example above uses the ordinary\nvertical bar to avoid a conflict. In practice, this is not a good idea, as it risks confusion with\nthe ASCII {lit}`|` used in the {kw}`match`{lit}` ... `{kw}`with` expression.\n\nWith {kw}`calc`, we can write the proof in the last section in a more\nnatural and perspicuous way.\n\n```lean\nvariable (x y : Nat)\n\nexample : (x + y) * (x + y) = x * x + y * x + x * y + y * y :=\n calc\n (x + y) * (x + y) = (x + y) * x + (x + y) * y :=\n by rw [Nat.mul_add]\n _ = x * x + y * x + (x + y) * y :=\n by rw [Nat.add_mul]\n _ = x * x + y * x + (x * y + y * y) :=\n by rw [Nat.add_mul]\n _ = x * x + y * x + x * y + y * y :=\n by rw [←Nat.add_assoc]\n```\n\nThe alternative {kw}`calc` notation is worth considering here. When the\nfirst expression is taking this much space, using {lit}`_` in the first\nrelation naturally aligns all relations:\n\n```lean\nvariable (x y : Nat)\n\nexample : (x + y) * (x + y) = x * x + y * x + x * y + y * y :=\n calc (x + y) * (x + y)\n _ = (x + y) * x + (x + y) * y :=\n by rw [Nat.mul_add]\n _ = x * x + y * x + (x + y) * y :=\n by rw [Nat.add_mul]\n _ = x * x + y * x + (x * y + y * y) :=\n by rw [Nat.add_mul]\n _ = x * x + y * x + x * y + y * y :=\n by rw [←Nat.add_assoc]\n```\n\nHere the left arrow before {lean}`Nat.add_assoc` tells rewrite to use the\nidentity in the opposite direction. (You can enter it with {kbd}`\\l` or\nuse the ASCII equivalent, {lit}`<-`.) If brevity is what we are after,\nboth {tactic}`rw` and {tactic}`simp` can do the job on their own:\n\n```lean\nvariable (x y : Nat)\nexample : (x + y) * (x + y) = x * x + y * x + x * y + y * y := by\n rw [Nat.mul_add, Nat.add_mul, Nat.add_mul, ←Nat.add_assoc]\n\nexample : (x + y) * (x + y) = x * x + y * x + x * y + y * y := by\n simp [Nat.mul_add, Nat.add_mul, Nat.add_assoc]\n```\n\n# The Existential Quantifier\n%%%\ntag := \"the-existential-quantifier\"\n%%%\n\nFinally, consider the existential quantifier, which can be written as\neither {lean}`exists x : α, p x` or {lean}`∃ x : α, p x`. Both versions are\nactually notationally convenient abbreviations for a more long-winded\nexpression, {lean}`Exists (fun x : α => p x)`, defined in Lean's library.\n\nAs you should by now expect, the library includes both an introduction\nrule and an elimination rule. The introduction rule is\nstraightforward: to prove {lean}`∃ x : α, p x`, it suffices to provide a\nsuitable term {lean}`t` and a proof of {lean}`p t`. Here are some examples:\n\n```lean\nexample : ∃ x : Nat, x > 0 :=\n have h : 1 > 0 := Nat.zero_lt_succ 0\n Exists.intro 1 h\n\nexample (x : Nat) (h : x > 0) : ∃ y, y < x :=\n Exists.intro 0 h\n\nexample (x y z : Nat) (hxy : x < y) (hyz : y < z) : ∃ w, x < w ∧ w < z :=\n Exists.intro y (And.intro hxy hyz)\n\n#check @Exists.intro -- @Exists.intro : ∀ {α : Sort u_1} {p : α → Prop} (w : α), p w → Exists p\n```\n\n:::setup\n```\nvariable {t : α} {p : α → Prop} (h : p t)\n```\nWe can use the anonymous constructor notation {lean (type := \"Exists (fun x : α => p x)\")}`⟨t, h⟩` for\n{lean}`Exists.intro t h`, when the type is clear from the context.\n:::\n\n```lean\nexample : ∃ x : Nat, x > 0 :=\n have h : 1 > 0 := Nat.zero_lt_succ 0\n ⟨1, h⟩\n\nexample (x : Nat) (h : x > 0) : ∃ y, y < x :=\n ⟨0, h⟩\n\nexample (x y z : Nat) (hxy : x < y) (hyz : y < z) : ∃ w, x < w ∧ w < z :=\n ⟨y, hxy, hyz⟩\n```\n\n:::setup\n```\nvariable (p : α → Prop) (g : Nat → Nat → Nat) (hg : g 0 0 = 0)\n```\n\nNote that {lean}`Exists.intro` has implicit arguments: Lean has to infer\nthe predicate {lean}`p : α → Prop` in the conclusion {lean}`∃ x, p x`. This\nis not a trivial affair. For example, if we have\n{lean}`hg : g 0 0 = 0` and write {lean}`Exists.intro 0 hg`, there are many possible values\nfor the predicate {lean}`p`, corresponding to the theorems {lean}`∃ x, g x x = x`,\n{lean}`∃ x, g x x = 0`, {lean}`∃ x, g x 0 = x`, etc. Lean uses the\ncontext to infer which one is appropriate. This is illustrated in the\nfollowing example, in which we set the option {option}`pp.explicit` to true\nto ask Lean's pretty-printer to show the implicit arguments.\n:::\n\n```lean\nvariable (g : Nat → Nat → Nat)\n\ntheorem gex1 (hg : g 0 0 = 0) : ∃ x, g x x = x := ⟨0, hg⟩\ntheorem gex2 (hg : g 0 0 = 0) : ∃ x, g x 0 = x := ⟨0, hg⟩\ntheorem gex3 (hg : g 0 0 = 0) : ∃ x, g 0 0 = x := ⟨0, hg⟩\ntheorem gex4 (hg : g 0 0 = 0) : ∃ x, g x x = 0 := ⟨0, hg⟩\n\nset_option pp.explicit true -- display implicit arguments\n\n#print gex1\n\n#print gex2\n\n#print gex3\n\n#print gex4\n```\n\n:::setup\n```\nvariable (q : Prop) (α : Type u) (p : α → Prop) (w : α) (x : α)\n```\n\nWe can view {lean}`Exists.intro` as an information-hiding operation, since\nit hides the witness to the body of the assertion. The existential\nelimination rule, {lean}`Exists.elim`, performs the opposite operation. It\nallows us to prove a proposition {lean}`q` from {lean}`∃ x : α, p x`, by\nshowing that {lean}`q` follows from {lean}`p w` for an arbitrary value\n{lean}`w`. Roughly speaking, since we know there is an {lean}`x` satisfying\n{lean}`p x`, we can give it a name, say, {lean}`w`. If {lean}`q` does not mention\n{lean}`w`, then showing that {lean}`q` follows from {lean}`p w` is tantamount to\nshowing that {lean}`q` follows from the existence of any such {lean}`x`. Here\nis an example:\n:::\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n\nexample (h : ∃ x, p x ∧ q x) : ∃ x, q x ∧ p x :=\n Exists.elim h\n (fun w =>\n fun hw : p w ∧ q w =>\n show ∃ x, q x ∧ p x from ⟨w, hw.right, hw.left⟩)\n```\n\n:::setup\n```\nvariable {α : Type u} (p : α → Prop) {β : α → Type} (a : α) (h : p a) (h' : β a)\n```\n\nIt may be helpful to compare the exists-elimination rule to the\nor-elimination rule: the assertion {lean}`∃ x : α, p x` can be thought of\nas a big disjunction of the propositions {lean}`p a`, as {lean}`a` ranges over\nall the elements of {lean}`α`. Note that the anonymous constructor\nnotation {leanRef}`⟨w, hw.right, hw.left⟩` abbreviates a nested constructor\napplication; we could equally well have written {lit}`⟨`{leanRef}`w`{lit}`, ⟨`{leanRef}`hw.right`{lit}`, `{leanRef}`hw.left`{lit}`⟩⟩`.\n\nNotice that an existential proposition is very similar to a sigma\ntype, as described in dependent types section. The difference is that\nexistential propositions are _propositions_, while sigma types are _types_.\nOtherwise, they are very similar. Given a predicate {lean}`p : α → Prop` and a family of types {lean}`β : α → Type`,\nfor a term {lean}`a : α` with {lean}`h : p a` and {lean}`h' : β a`, the term {lean}`Exists.intro a h` has\ntype {lean}`(∃ x : α, p x) : Prop`, while {lean}`Sigma.mk a h'` has type\n{lean}`(Σ x : α, β x)`. The similarity between {lit}`∃` and {lit}`Σ` is another\ninstance of the {tech}[Curry-Howard isomorphism].\n:::\n\nLean provides a more convenient way to eliminate from an existential\nquantifier with the {kw}`match` expression:\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n\nexample (h : ∃ x, p x ∧ q x) : ∃ x, q x ∧ p x :=\n match h with\n | ⟨w, hw⟩ => ⟨w, hw.right, hw.left⟩\n```\n\nThe {kw}`match` expression is part of Lean's function definition system,\nwhich provides convenient and expressive ways of defining complex\nfunctions. Once again, it is the {tech}[Curry-Howard isomorphism] that allows\nus to co-opt this mechanism for writing proofs as well. The {kw}`match`\nstatement “destructs” the existential assertion into the components\n{leanRef}`w` and {leanRef}`hw`, which can then be used in the body of the statement\nto prove the proposition. We can annotate the types used in the match\nfor greater clarity:\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n------\nexample (h : ∃ x, p x ∧ q x) : ∃ x, q x ∧ p x :=\n match h with\n | ⟨(w : α), (hw : p w ∧ q w)⟩ => ⟨w, hw.right, hw.left⟩\n```\n\nWe can even use the match statement to decompose the conjunction at the same time:\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n------\nexample (h : ∃ x, p x ∧ q x) : ∃ x, q x ∧ p x :=\n match h with\n | ⟨w, hpw, hqw⟩ => ⟨w, hqw, hpw⟩\n```\n\nLean also provides a pattern-matching {kw}`let` expression:\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n------\nexample (h : ∃ x, p x ∧ q x) : ∃ x, q x ∧ p x :=\n let ⟨w, hpw, hqw⟩ := h\n ⟨w, hqw, hpw⟩\n```\n\nThis is essentially just alternative notation for the {kw}`match`\nconstruct above. Lean will even allow us to use an implicit {kw}`match`\nin the {kw}`fun` expression:\n\n```lean\nvariable (α : Type) (p q : α → Prop)\n------\nexample : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x :=\n fun ⟨w, hpw, hqw⟩ => ⟨w, hqw, hpw⟩\n```\n\nWe will see in {ref \"induction-and-recursion\"}[Induction and Recursion] that all these variations are\ninstances of a more general pattern-matching construct.\n\n:::setup\n```\ndef IsEven (a : Nat) := ∃ b, a = 2 * b\nvariable (a : Nat)\n```\n\nIn the following example, we define {lean}`IsEven a` as {lean}`∃ b, a = 2 * b`,\nand then we show that the sum of two even numbers is an even number.\n:::\n\n```lean\ndef IsEven (a : Nat) := ∃ b, a = 2 * b\n\ntheorem even_plus_even (h1 : IsEven a) (h2 : IsEven b) :\n IsEven (a + b) :=\n Exists.elim h1 (fun w1 (hw1 : a = 2 * w1) =>\n Exists.elim h2 (fun w2 (hw2 : b = 2 * w2) =>\n Exists.intro (w1 + w2)\n (calc a + b\n _ = 2 * w1 + 2 * w2 := by rw [hw1, hw2]\n _ = 2 * (w1 + w2) := by rw [Nat.mul_add])))\n```\n\nUsing the various gadgets described in this chapter—the match\nstatement, anonymous constructors, and the {tactic}`rewrite` tactic, we can\nwrite this proof concisely as follows:\n\n```lean\ndef IsEven (a : Nat) := ∃ b, a = 2 * b\n------\ntheorem even_plus_even (h1 : IsEven a) (h2 : IsEven b) :\n IsEven (a + b) :=\n match h1, h2 with\n | ⟨w1, hw1⟩, ⟨w2, hw2⟩ =>\n ⟨w1 + w2, by rw [hw1, hw2, Nat.mul_add]⟩\n```\n\n:::leanFirst\nJust as the constructive “or” is stronger than the classical “or,” so,\ntoo, is the constructive “exists” stronger than the classical\n“exists”. For example, the following implication requires classical\nreasoning because, from a constructive standpoint, knowing that it is\nnot the case that every {leanRef}`x` satisfies {leanRef}`¬ p` is not the same as\nhaving a particular {leanRef}`x` that satisfies {leanRef}`p`.\n\n```lean\nopen Classical\nvariable (p : α → Prop)\n\nexample (h : ¬ ∀ x, ¬ p x) : ∃ x, p x :=\n byContradiction\n (fun h1 : ¬ ∃ x, p x =>\n have h2 : ∀ x, ¬ p x :=\n fun x =>\n fun h3 : p x =>\n have h4 : ∃ x, p x := ⟨x, h3⟩\n show False from h1 h4\n show False from h h2)\n```\n:::\n\nWhat follows are some common identities involving the existential\nquantifier. In the exercises below, we encourage you to prove as many\nas you can. We also leave it to you to determine which are\nnonconstructive, and hence require some form of classical reasoning.\n\n```lean\nopen Classical\n\nvariable (α : Type) (p q : α → Prop)\nvariable (r : Prop)\n\nexample : (∃ x : α, r) → r := sorry\nexample (a : α) : r → (∃ x : α, r) := sorry\nexample : (∃ x, p x ∧ r) ↔ (∃ x, p x) ∧ r := sorry\nexample : (∃ x, p x ∨ q x) ↔ (∃ x, p x) ∨ (∃ x, q x) := sorry\n\nexample : (∀ x, p x) ↔ ¬ (∃ x, ¬ p x) := sorry\nexample : (∃ x, p x) ↔ ¬ (∀ x, ¬ p x) := sorry\nexample : (¬ ∃ x, p x) ↔ (∀ x, ¬ p x) := sorry\nexample : (¬ ∀ x, p x) ↔ (∃ x, ¬ p x) := sorry\n\nexample : (∀ x, p x → r) ↔ (∃ x, p x) → r := sorry\nexample (a : α) : (∃ x, p x → r) ↔ (∀ x, p x) → r := sorry\nexample (a : α) : (∃ x, r → p x) ↔ (r → ∃ x, p x) := sorry\n```\n\nNotice that the second example and the last two examples require the\nassumption that there is at least one element {leanRef}`a` of type {leanRef}`α`.\n\nHere are solutions to two of the more difficult ones:\n\n```lean\nopen Classical\n\nvariable (α : Type) (p q : α → Prop)\nvariable (a : α)\nvariable (r : Prop)\n\nexample : (∃ x, p x ∨ q x) ↔ (∃ x, p x) ∨ (∃ x, q x) :=\n Iff.intro\n (fun ⟨a, (h1 : p a ∨ q a)⟩ =>\n Or.elim h1\n (fun hpa : p a => Or.inl ⟨a, hpa⟩)\n (fun hqa : q a => Or.inr ⟨a, hqa⟩))\n (fun h : (∃ x, p x) ∨ (∃ x, q x) =>\n Or.elim h\n (fun ⟨a, hpa⟩ => ⟨a, (Or.inl hpa)⟩)\n (fun ⟨a, hqa⟩ => ⟨a, (Or.inr hqa)⟩))\n\nexample : (∃ x, p x → r) ↔ (∀ x, p x) → r :=\n Iff.intro\n (fun ⟨b, (hb : p b → r)⟩ =>\n fun h2 : ∀ x, p x =>\n show r from hb (h2 b))\n (fun h1 : (∀ x, p x) → r =>\n show ∃ x, p x → r from\n byCases\n (fun hap : ∀ x, p x => ⟨a, λ h' => h1 hap⟩)\n (fun hnap : ¬ ∀ x, p x =>\n byContradiction\n (fun hnex : ¬ ∃ x, p x → r =>\n have hap : ∀ x, p x :=\n fun x =>\n byContradiction\n (fun hnp : ¬ p x =>\n have hex : ∃ x, p x → r := ⟨x, (fun hp => absurd hp hnp)⟩\n show False from hnex hex)\n show False from hnap hap)))\n```\n\n# More on the Proof Language\n%%%\ntag := \"more-on-the-proof-language\"\n%%%\n\nWe have seen that keywords like {kw}`fun`, {kw}`have`, and {kw}`show` make\nit possible to write formal proof terms that mirror the structure of\ninformal mathematical proofs. In this section, we discuss some\nadditional features of the proof language that are often convenient.\n\nTo start with, we can use anonymous {kw}`have` expressions to introduce an\nauxiliary goal without having to label it. We can refer to the last\nexpression introduced in this way using the keyword {lit}`this`:\n\n```lean\nvariable (f : Nat → Nat)\nvariable (h : ∀ x : Nat, f x ≤ f (x + 1))\n\nexample : f 0 ≤ f 3 :=\n have : f 0 ≤ f 1 := h 0\n have : f 0 ≤ f 2 := Nat.le_trans this (h 1)\n show f 0 ≤ f 3 from Nat.le_trans this (h 2)\n```\n\nOften proofs move from one fact to the next, so this can be effective\nin eliminating the clutter of lots of labels.\n\nWhen the goal can be inferred, we can also ask Lean instead to fill in\nthe proof by writing {kw}`by assumption`:\n\n```lean\nvariable (f : Nat → Nat)\nvariable (h : ∀ x : Nat, f x ≤ f (x + 1))\n------\nexample : f 0 ≤ f 3 :=\n have : f 0 ≤ f 1 := h 0\n have : f 0 ≤ f 2 := Nat.le_trans (by assumption) (h 1)\n show f 0 ≤ f 3 from Nat.le_trans (by assumption) (h 2)\n```\n\nThis tells Lean to use the {leanRef}`assumption` tactic, which, in turn,\nproves the goal by finding a suitable hypothesis in the local\ncontext. We will learn more about the {leanRef}`assumption` tactic in the\nnext chapter.\n\n:::setup\n```\nvariable {p : Prop} (prf : p)\n```\nWe can also ask Lean to fill in the proof by writing {lean}`‹p›`, where\n{lean}`p` is the proposition whose proof we want Lean to find in the\ncontext. You can type these corner quotes using {kbd}`\\f<` and {kbd}`\\f>`,\nrespectively. The letter “f” is for “French,” since the Unicode\nsymbols can also be used as French quotation marks. In fact, the\nnotation is defined in Lean as follows:\n:::\n\n```lean\nnotation \"‹\" p \"›\" => show p by assumption\n```\n\nThis approach is more robust than using {leanRef}`by assumption`, because the\ntype of the assumption that needs to be inferred is given\nexplicitly. It also makes proofs more readable. Here is a more\nelaborate example:\n\n```lean\nvariable (f : Nat → Nat)\nvariable (h : ∀ x : Nat, f x ≤ f (x + 1))\n\nexample : f 0 ≥ f 1 → f 1 ≥ f 2 → f 0 = f 2 :=\n fun _ : f 0 ≥ f 1 =>\n fun _ : f 1 ≥ f 2 =>\n have : f 0 ≥ f 2 := Nat.le_trans ‹f 1 ≥ f 2› ‹f 0 ≥ f 1›\n have : f 0 ≤ f 2 := Nat.le_trans (h 0) (h 1)\n show f 0 = f 2 from Nat.le_antisymm this ‹f 0 ≥ f 2›\n```\n\nKeep in mind that you can use the French quotation marks in this way\nto refer to _anything_ in the context, not just things that were\nintroduced anonymously. Its use is also not limited to propositions,\nthough using it for data is somewhat odd:\n\n```lean\nexample (n : Nat) : Nat := ‹Nat›\n```\n\nLater, we show how you can extend the proof language using the Lean macro system.\n\n# Exercises\n%%%\ntag := none\n%%%\n\n1. Prove these equivalences:\n\n ```lean\n variable (α : Type) (p q : α → Prop)\n\n example : (∀ x, p x ∧ q x) ↔ (∀ x, p x) ∧ (∀ x, q x) := sorry\n example : (∀ x, p x → q x) → (∀ x, p x) → (∀ x, q x) := sorry\n example : (∀ x, p x) ∨ (∀ x, q x) → ∀ x, p x ∨ q x := sorry\n ```\n\n You should also try to understand why the reverse implication is not derivable in the last example.\n\n2. It is often possible to bring a component of a formula outside a\n universal quantifier, when it does not depend on the quantified\n variable. Try proving these (one direction of the second of these\n requires classical logic):\n\n ```lean\n variable (α : Type) (p q : α → Prop)\n variable (r : Prop)\n\n example : α → ((∀ x : α, r) ↔ r) := sorry\n example : (∀ x, p x ∨ r) ↔ (∀ x, p x) ∨ r := sorry\n example : (∀ x, r → p x) ↔ (r → ∀ x, p x) := sorry\n ```\n\n3. Consider the “barber paradox,” that is, the claim that in a certain\n town there is a (male) barber that shaves all and only the men who\n do not shave themselves. Prove that this is a contradiction:\n\n ```lean\n variable (men : Type) (barber : men)\n variable (shaves : men → men → Prop)\n\n example (h : ∀ x : men, shaves barber x ↔ ¬ shaves x x) : False :=\n sorry\n ```\n\n4. ::::setup\n ```\n variable {n : Nat}\n ```\n :::leanFirst\n Remember that, without any parameters, an expression of type\n {lean}`Prop` is just an assertion. Fill in the definitions of {leanRef}`prime`\n and {leanRef}`Fermat_prime` below, and construct each of the given\n assertions. For example, you can say that there are infinitely many\n primes by asserting that for every natural number {lean}`n`, there is a\n prime number greater than {lean}`n`. Goldbach's weak conjecture states\n that every odd number greater than 5 is the sum of three\n primes. Look up the definition of a Fermat prime or any of the\n other statements, if necessary.\n\n ```lean\n def even (n : Nat) : Prop := sorry\n\n def prime (n : Nat) : Prop := sorry\n\n def infinitely_many_primes : Prop := sorry\n\n def Fermat_prime (n : Nat) : Prop := sorry\n\n def infinitely_many_Fermat_primes : Prop := sorry\n\n def goldbach_conjecture : Prop := sorry\n\n def Goldbach's_weak_conjecture : Prop := sorry\n\n def Fermat's_last_theorem : Prop := sorry\n ```\n :::\n ::::\n\n5. Prove as many of the identities listed in the Existential\n Quantifier section as you can.\n"
},
{
"path": "book/TPiL/StructuresAndRecords.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre Manual\nopen TPiL\n\n#doc (Manual) \"Structures and Records\" =>\n%%%\ntag := \"structures-and-records\"\n%%%\n\nWe have seen that Lean's foundational system includes inductive\ntypes. We have, moreover, noted that it is a remarkable fact that it\nis possible to construct a substantial edifice of mathematics based on\nnothing more than the type universes, dependent arrow types, and inductive types;\neverything else follows from those. The Lean standard library contains\nmany instances of inductive types (e.g., {lean}`Nat`, {lean}`Prod`, {lean}`List`),\nand even the logical connectives are defined using inductive types.\n\nRecall that a non-recursive inductive type that contains only one\nconstructor is called a _structure_ or _record_. The product type is a\nstructure, as is the dependent product (Sigma) type.\nIn general, whenever we define a structure {lit}`S`, we usually\ndefine _projection_ functions that allow us to “destruct” each\ninstance of {lit}`S` and retrieve the values that are stored in its\nfields. The functions {lean}`Prod.fst` and {lean}`Prod.snd`, which return the\nfirst and second elements of a pair, are examples of such projections.\n\nWhen writing programs or formalizing mathematics, it is not uncommon\nto define structures containing many fields. The {kw}`structure`\ncommand, available in Lean, provides infrastructure to support this\nprocess. When we define a structure using this command, Lean\nautomatically generates all the projection functions. The\n{kw}`structure` command also allows us to define new structures based on\npreviously defined ones. Moreover, Lean provides convenient notation\nfor defining instances of a given structure.\n\n# Declaring Structures\n%%%\ntag := \"declaring-structures\"\n%%%\n\nThe structure command is essentially a “front end” for defining\ninductive data types. Every {kw}`structure` declaration introduces a\nnamespace with the same name. The general form is as follows:\n\n```\n structure where\n :: \n```\n\nMost parts are optional. Here is an example:\n\n```lean\nstructure Point (α : Type u) where\n mk ::\n x : α\n y : α\n```\n\n:::setup\n```\nstructure Point (α : Type u) where\n mk ::\n x : α\n y : α\nvariable (p : Point α) (a b : α)\n```\nValues of type {leanRef}`Point` are created using {lean}`Point.mk a b`, and the\nfields of a point {lean}`p` are accessed using {lean}`Point.x p` and\n{lean}`Point.y p` (but {lean}`p.x` and {lean}`p.y` also work, see below).\nThe structure command also generates useful recursors and\ntheorems. Here are some of the constructions generated for the\ndeclaration above.\n:::\n\n```lean\nstructure Point (α : Type u) where\n mk ::\n x : α\n y : α\n------\n-- a Type\n#check Point\n\n-- the eliminator\n#check @Point.rec\n\n-- the constructor\n#check @Point.mk -- @Point.mk : {α : Type u_1} → α → α → Point α\n\n-- a projection\n#check @Point.x -- @Point.x : {α : Type u_1} → Point α → α\n\n-- a projection\n#check @Point.y -- @Point.y : {α : Type u_1} → Point α → α\n```\n\nIf the constructor name is not provided, then a constructor is named\n{lit}`mk` by default.\n\n:::leanFirst\nHere are some simple theorems and expressions that use the generated\nconstructions. As usual, you can avoid the prefix {leanRef}`Point` by using\nthe command {leanRef}`open Point`.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n------\n#eval Point.x (Point.mk 10 20) -- 10\n\n#eval Point.y (Point.mk 10 20) -- 20\n\nopen Point\n\nexample (a b : α) : x (mk a b) = a :=\n rfl\n\nexample (a b : α) : y (mk a b) = b :=\n rfl\n```\n:::\n\n\n:::setup\n```\nstructure Point (α : Type u) where\n x : α\n y : α\nvariable (p : Point Nat)\n```\n\n\nGiven {lean}`p : Point Nat`, the dot notation {lean}`p.x` is shorthand for\n{lean}`Point.x p`. This provides a convenient way of accessing the fields\nof a structure.\n:::\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n------\ndef p := Point.mk 10 20\n\n#check p.x -- p.x : Nat\n#eval p.x -- 10\n#eval p.y -- 20\n```\n\n:::leanFirst\nThe dot notation is convenient not just for accessing the projections\nof a record, but also for applying functions defined in a namespace\nwith the same name. Recall from the {ref \"conjunction\"}[Conjunction section] if {leanRef}`p`\nhas type {leanRef}`Point`, the expression {lit}`p.foo` is interpreted as\n{lit}`Point.foo p`, assuming that the first non-implicit argument to\n{lit}`foo` has type {leanRef}`Point`. The expression {leanRef}`p.add q` is therefore\nshorthand for {lit}`Point.add p q` in the example below.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\nderiving Repr\n\ndef Point.add (p q : Point Nat) :=\n mk (p.x + q.x) (p.y + q.y)\n\ndef p : Point Nat := Point.mk 1 2\ndef q : Point Nat := Point.mk 3 4\n\n#eval p.add q -- { x := 4, y := 6 }\n```\n:::\n\n:::setup\n```\nstructure Point (α : Type u) where\n x : α\n y : α\nderiving Repr\n\nvariable {α : Type u}\n```\n\nIn the next chapter, you will learn how to define a function like\n{leanRef}`add` so that it works generically for elements of {lean}`Point α`\nrather than just {lean}`Point Nat`, assuming {lean}`α` has an associated\naddition operation.\n:::\n\n:::leanFirst\nMore generally, given an expression {lit}`p.foo x y z` where {lit}`p : Point`,\nLean will insert {lit}`p` at the first argument to {lit}`Point.foo` of type\n{lit}`Point`. For example, with the definition of scalar multiplication\nbelow, {leanRef}`p.smul 3` is interpreted as {leanRef}`Point.smul 3 p`.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n deriving Repr\n------\ndef Point.smul (n : Nat) (p : Point Nat) :=\n Point.mk (n * p.x) (n * p.y)\n\ndef p : Point Nat := Point.mk 1 2\n\n#eval p.smul 3 -- { x := 3, y := 6 }\n\nexample {p : Point Nat} : p.smul 3 = Point.smul 3 p := rfl\n```\n:::\n\nIt is common to use a similar trick with the {name}`List.map` function,\nwhich takes a list as its second non-implicit argument:\n\n```lean\n#check @List.map\n\ndef xs : List Nat := [1, 2, 3]\ndef f : Nat → Nat := fun x => x * x\n\n#eval xs.map f -- [1, 4, 9]\n\nexample {xs : List α} {f : α → β} :\n xs.map f = List.map f xs :=\n rfl\n```\n\nHere {leanRef}`xs.map f` is interpreted as {leanRef}`List.map f xs`.\n\n# Objects\n%%%\ntag := \"objects\"\n%%%\n\nWe have been using constructors to create elements of a structure\ntype. For structures containing many fields, this is often\ninconvenient, because we have to remember the order in which the\nfields were defined. Lean therefore provides the following alternative\nnotations for defining elements of a structure type.\n\n```\n { ( := )* : structure-type }\n or\n { ( := )* }\n```\n\nThe suffix {lit}`: structure-type` can be omitted whenever the name of\nthe structure can be inferred from the expected type. For example, we\nuse this notation to define “points.” The order that the fields are\nspecified does not matter, so all the expressions below define the\nsame point.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n\n#check { x := 10, y := 20 : Point Nat } -- { x := 10, y := 20 } : Point Nat\n\n#check { y := 20, x := 10 : Point _ } -- { x := 10, y := 20 } : Point Nat\n\n#check ({ x := 10, y := 20 } : Point Nat) -- { x := 10, y := 20 } : Point Nat\n\nexample : Point Nat :=\n { y := 20, x := 10 }\n```\n\nFields can be marked as implicit using curly braces.\nImplicit fields become implicit parameters to the constructor.\n\nIf the value of a field is not specified, Lean tries to infer it. If\nthe unspecified fields cannot be inferred, Lean flags an error\nindicating the corresponding placeholder could not be synthesized.\n\n```lean\nstructure MyStruct where\n {α : Type u}\n {β : Type v}\n a : α\n b : β\n\n#check { a := 10, b := true : MyStruct }\n```\n\n_Record update_ is another common operation which amounts to creating\na new record object by modifying the value of one or more fields in an\nold one. Lean allows you to specify that unassigned fields in the\nspecification of a record should be taken from a previously defined\nstructure object {lit}`s` by adding the annotation {lit}`s `{kw}`with` before the field\nassignments. If more than one record object is provided, then they are\nvisited in order until Lean finds one that contains the unspecified\nfield. Lean raises an error if any of the field names remain\nunspecified after all the objects are visited.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\nderiving Repr\n\ndef p : Point Nat :=\n { x := 1, y := 2 }\n\n#eval { p with y := 3 } -- { x := 1, y := 3 }\n\n#eval { p with x := 4 } -- { x := 4, y := 2 }\n\nstructure Point3 (α : Type u) where\n x : α\n y : α\n z : α\n\ndef q : Point3 Nat :=\n { x := 5, y := 5, z := 5 }\n\ndef r : Point3 Nat :=\n { p, q with x := 6 }\n\nexample : r.x = 6 := rfl\nexample : r.y = 2 := rfl\nexample : r.z = 5 := rfl\n```\n\n# Inheritance\n%%%\ntag := \"inheritance\"\n%%%\n\nWe can _extend_ existing structures by adding new fields. This feature\nallows us to simulate a form of _inheritance_.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n\ninductive Color where\n | red | green | blue\n\nstructure ColorPoint (α : Type u) extends Point α where\n c : Color\n```\n\nIn the next example, we define a structure using multiple inheritance,\nand then define an object using objects of the parent structures.\n\n```lean\nstructure Point (α : Type u) where\n x : α\n y : α\n z : α\n\nstructure RGBValue where\n red : Nat\n green : Nat\n blue : Nat\n\nstructure RedGreenPoint (α : Type u) extends Point α, RGBValue where\n no_blue : blue = 0\n\ndef p : Point Nat :=\n { x := 10, y := 10, z := 20 }\n\ndef rgp : RedGreenPoint Nat :=\n { p with red := 200, green := 40, blue := 0, no_blue := rfl }\n\nexample : rgp.x = 10 := rfl\nexample : rgp.red = 200 := rfl\n```\n"
},
{
"path": "book/TPiL/Tactics.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre\nopen Manual hiding tactic\nopen TPiL\n\n#doc (Manual) \"Tactics\" =>\n\nIn this chapter, we describe an alternative approach to constructing\nproofs, using _tactics_. A proof term is a representation of a\nmathematical proof; tactics are commands, or instructions, that\ndescribe how to build such a proof. Informally, you might begin a\nmathematical proof by saying “to prove the forward direction, unfold\nthe definition, apply the previous lemma, and simplify.” Just as these\nare instructions that tell the reader how to find the relevant proof,\ntactics are instructions that tell Lean how to construct a proof\nterm. They naturally support an incremental style of writing proofs,\nin which you decompose a proof and work on goals one step at a time.\n\nWe will describe proofs that consist of sequences of tactics as\n“tactic-style” proofs, to contrast with the ways of writing proof\nterms we have seen so far, which we will call “term-style”\nproofs. Each style has its own advantages and disadvantages. For\nexample, tactic-style proofs can be harder to read, because they\nrequire the reader to predict or guess the results of each\ninstruction. But they can also be shorter and easier to\nwrite. Moreover, tactics offer a gateway to using Lean's automation,\nsince automated procedures are themselves tactics.\n\n# Entering Tactic Mode\n%%%\ntag := \"entering-tactic-mode\"\n%%%\n\n\n:::leanFirst\nConceptually, stating a theorem or introducing a {kw}`have` statement\ncreates a goal, namely, the goal of constructing a term with the\nexpected type. For example, the following creates the goal of\nconstructing a term of type {leanRef}`p ∧ q ∧ p`, in a context with constants\n{leanRef}`p q : Prop`, {leanRef}`hp : p` and {leanRef}`hq : q`:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n -- PROOF_STATE: X ^\n sorry\n```\n:::\n\nYou can write this goal as follows:\n\n```proofState X\np : Prop\nq : Prop\nhp : p\nhq : q\n⊢ p ∧ q ∧ p\n```\n\n\nIndeed, if you replace the “sorry” by an underscore in the example\nabove, Lean will report that it is exactly this goal that has been\nleft unsolved.\n\nOrdinarily, you meet such a goal by writing an explicit term. But\nwherever a term is expected, Lean allows us to insert instead a\n{lit}`by ` block, where {lit}`` is a sequence of commands,\nseparated by semicolons or line breaks. You can prove the theorem above\nin that way:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p :=\n by apply And.intro\n exact hp\n apply And.intro\n exact hq\n exact hp\n```\n\nWe often put the {leanRef}`by` keyword on the preceding line, and write the\nexample above as:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro\n-- ^ PROOF_STATE: intro\n exact hp\n apply And.intro\n exact hq\n exact hp\n```\n\nThe {leanRef}`apply` tactic applies an expression, viewed as denoting a\nfunction with zero or more arguments. It unifies the conclusion with\nthe expression in the current goal, and creates new goals for the\nremaining arguments, provided that no later arguments depend on\nthem. In the example above, the command {leanRef}`apply And.intro` yields two\nsubgoals:\n\n```proofState intro\ncase left\np : Prop\nq : Prop\nhp : p\nhq : q\n⊢ p\n\ncase right\np : Prop\nq : Prop\nhp : p\nhq : q\n⊢ q ∧ p\n```\n\nThe first goal is met with the command {leanRef}`exact hp`. The {leanRef}`exact`\ncommand is just a variant of {leanRef}`apply` which signals that the\nexpression given should fill the goal exactly. It is good form to use\nit in a tactic proof, since its failure signals that something has\ngone wrong. It is also more robust than {leanRef}`apply`, since the\nelaborator takes the expected type, given by the target of the goal,\ninto account when processing the expression that is being applied. In\nthis case, however, {leanRef}`apply` would work just as well.\n\nYou can see the resulting proof term with the {kw}`#print` command:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro\n exact hp\n apply And.intro\n exact hq\n exact hp\n------\n#print test\n```\n\n::: TODO\nCheck these. Vim?\n:::\nYou can write a tactic script incrementally. In VS Code, you can open\na window to display messages by pressing {kbd}[`Ctrl` `Shift` `Enter`], and\nthat window will then show you the current goal whenever the cursor is\nin a tactic block. If the proof is incomplete, the token {kw}`by` is\ndecorated with a red squiggly line, and the error message contains the\nremaining goals.\n\nTactic commands can take compound expressions, not just single\nidentifiers. The following is a shorter version of the preceding\nproof:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro hp\n exact And.intro hq hp\n```\n\nUnsurprisingly, it produces exactly the same proof term:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro hp\n exact And.intro hq hp\n------\n#print test\n```\n\nMultiple tactic applications can be written in a single line by concatenating with a semicolon.\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro hp; exact And.intro hq hp\n```\n\nTactics that may produce multiple subgoals often tag them. For\nexample, the tactic {leanRef}`apply And.intro` tagged the first subgoal as\n{goal intro}`left`, and the second as {goal intro}`right`. In the case of the {leanRef}`apply`\ntactic, the tags are inferred from the parameters' names used in the\n{leanRef}`And.intro` declaration. You can structure your tactics using the\nnotation {kw}`case`{lit}` => `. The following is a structured\nversion of our first tactic proof in this chapter.\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro\n case left => exact hp\n case right =>\n apply And.intro\n case left => exact hq\n case right => exact hp\n```\n\n:::leanFirst\n\nYou can solve the subgoal {goal intro2}`right` before {goal intro2}`left` using the {leanRef}`case`\nnotation:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro\n -- ^ PROOF_STATE: intro2\n case right =>\n apply And.intro\n case left => exact hq\n -- ^ PROOF_STATE: leftBranch\n case right => exact hp\n case left => exact hp\n```\n:::\n\nNote that Lean hides the other goals inside the {leanRef}`case` block. After {leanRef}`case left =>`,\nthe proof state is:\n\n```proofState leftBranch\np : Prop\nq : Prop\nhp : p\nhq : q\n⊢ q\n```\n\nWe say that {leanRef}`case` is “focusing” on the selected goal. Moreover, Lean flags an error\nif the selected goal is not fully solved at the end of the {leanRef}`case`\nblock.\n\nFor simple subgoals, it may not be worth selecting a subgoal using its\ntag, but you may still want to structure the proof. Lean also provides\nthe “bullet” notation {lit}`. ` (or {lit}`· `) for\nstructuring proofs:\n\n```lean\ntheorem test (p q : Prop) (hp : p) (hq : q) : p ∧ q ∧ p := by\n apply And.intro\n . exact hp\n . apply And.intro\n . exact hq\n . exact hp\n```\n\n# Basic Tactics\n%%%\ntag := \"basic-tactics\"\n%%%\n\n:::leanFirst\nIn addition to {leanRef}`apply` and {leanRef}`exact`, another useful tactic is\n{leanRef}`intro`, which introduces a hypothesis. What follows is an example\nof an identity from propositional logic that we proved in a previous\nchapter, now proved using tactics.\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro h\n apply Or.elim (And.right h)\n . intro hq\n apply Or.inl\n apply And.intro\n . exact And.left h\n . exact hq\n . intro hr\n apply Or.inr\n apply And.intro\n . exact And.left h\n . exact hr\n . intro h\n apply Or.elim h\n . intro hpq\n apply And.intro\n . exact And.left hpq\n . apply Or.inl\n exact And.right hpq\n . intro hpr\n apply And.intro\n . exact And.left hpr\n . apply Or.inr\n exact And.right hpr\n```\n:::\n\nThe {leanRef}`intro` command can more generally be used to introduce a variable of any type:\n\n```lean\nexample (α : Type) : α → α := by\n intro a\n exact a\n\nexample (α : Type) : ∀ x : α, x = x := by\n intro x\n exact Eq.refl x\n```\n\nYou can use it to introduce several variables:\n\n```lean\nexample : ∀ a b c : Nat, a = b → a = c → c = b := by\n intro a b c h₁ h₂\n exact Eq.trans (Eq.symm h₂) h₁\n```\n\n:::setup\n```\nvariable {α : Sort u} {p : Prop} {e : p}\n```\n\nAs the {leanRef}`apply` tactic is a command for constructing function\napplications interactively, the {leanRef}`intro` tactic is a command for\nconstructing function abstractions interactively (i.e., terms of the\nform {lean (type := \"∀ (x : α), p\")}`fun x => e`). As with lambda abstraction notation, the\n{leanRef}`intro` tactic allows us to use an implicit {kw}`match`.\n:::\n\n```lean\nexample (p q : α → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by\n intro ⟨w, hpw, hqw⟩\n exact ⟨w, hqw, hpw⟩\n```\n\nYou can also provide multiple alternatives like in the {kw}`match` expression.\n\n```lean\nexample (p q : α → Prop) : (∃ x, p x ∨ q x) → ∃ x, q x ∨ p x := by\n intro\n | ⟨w, Or.inl h⟩ => exact ⟨w, Or.inr h⟩\n | ⟨w, Or.inr h⟩ => exact ⟨w, Or.inl h⟩\n```\n\n::::leanFirst\nThe {leanRef}`intros` tactic can be used without any arguments, in which\ncase, it chooses names and introduces as many variables as it can. You\nwill see an example of this in a moment.\n\n:::leanFirst\nThe {leanRef}`assumption` tactic looks through the assumptions in context of\nthe current goal, and if there is one matching the conclusion, it\napplies it.\n\n```lean\nvariable (x y z w : Nat)\n\nexample (h₁ : x = y) (h₂ : y = z) (h₃ : z = w) : x = w := by\n apply Eq.trans h₁\n apply Eq.trans h₂\n assumption -- applied h₃\n```\n:::\n\nIt will unify metavariables in the conclusion if necessary:\n\n```lean\nvariable (x y z w : Nat)\n\nexample (h₁ : x = y) (h₂ : y = z) (h₃ : z = w) : x = w := by\n apply Eq.trans\n assumption -- solves x = ?b with h₁\n apply Eq.trans\n assumption -- solves y = ?h₂.b with h₂\n assumption -- solves z = w with h₃\n```\n\nThe following example uses the {leanRef}`intros` command to introduce the three variables and two hypotheses automatically:\n\n```lean\nexample : ∀ a b c : Nat, a = b → a = c → c = b := by\n intros\n apply Eq.trans\n apply Eq.symm\n assumption\n assumption\n```\n::::\n\n:::leanFirst\nNote that names automatically generated by Lean are inaccessible by default. The motivation is to\nensure your tactic proofs do not rely on automatically generated names, and are consequently more robust.\nHowever, you can use the combinator {leanRef}`unhygienic` to disable this restriction.\n\n```lean\nexample : ∀ a b c : Nat, a = b → a = c → c = b := by unhygienic\n intros\n apply Eq.trans\n apply Eq.symm\n exact a_2\n exact a_1\n```\n:::\n\n:::leanFirst\nYou can also use the {leanRef}`rename_i` tactic to rename the most recent inaccessible names in your context.\nIn the following example, the tactic {leanRef}`rename_i h1 _ h2` renames two of the last three hypotheses in\nyour context.\n\n```lean\nexample : ∀ a b c d : Nat, a = b → a = d → a = c → c = b := by\n intros\n rename_i h1 _ h2\n apply Eq.trans\n apply Eq.symm\n exact h2\n exact h1\n```\n:::\n\n:::leanFirst\nThe {leanRef}`rfl` tactic solves goals that are reflexive relations applied to definitionally equal arguments.\nEquality is reflexive:\n\n```lean\nexample (y : Nat) : (fun x : Nat => 0) y = 0 := by\n rfl\n```\n:::\n\n:::leanFirst\nThe {leanRef}`repeat` combinator can be used to apply a tactic several times:\n\n```lean\nexample : ∀ a b c : Nat, a = b → a = c → c = b := by\n intros\n apply Eq.trans\n apply Eq.symm\n repeat assumption\n```\n:::\n\n:::leanFirst\nAnother tactic that is sometimes useful is the {leanRef}`revert` tactic,\nwhich is, in a sense, an inverse to {leanRef}`intro`:\n\n```lean\nexample (x : Nat) : x = x := by\n revert x\n -- ^ PROOF_STATE: afterRevert\n intro y\n -- ^ PROOF_STATE: afterRevertIntro\n rfl\n```\n\nAfter {leanRef}`revert x`, the proof state is:\n\n```proofState afterRevert\n⊢ ∀ (x : Nat), x = x\n```\n\nAfter {leanRef}`intro y`, it is:\n\n```proofState afterRevertIntro\ny : Nat\n⊢ y = y\n```\n\n:::\n\nMoving a hypothesis into the goal yields an implication:\n\n```lean\nexample (x y : Nat) (h : x = y) : y = x := by\n revert h\n -- ^ PROOF_STATE: afterRevertH\n intro h₁\n -- ^ PROOF_STATE: afterRevertHIntro\n -- goal is x y : Nat, h₁ : x = y ⊢ y = x\n apply Eq.symm\n assumption\n```\n\nAfter {leanRef}`revert h`, the proof state is:\n\n```proofState afterRevertH\nx : Nat\ny : Nat\n⊢ x = y → y = x\n```\n\nAfter {leanRef}`intro h₁`, it is:\n\n```proofState afterRevertHIntro\nx : Nat\ny : Nat\nh₁ : x = y\n⊢ y = x\n```\n\n:::leanFirst\nBut {leanRef}`revert` is even more clever, in that it will revert not only an\nelement of the context but also all the subsequent elements of the\ncontext that depend on it. For example, reverting {leanRef (in := \"revert x\")}`x` in the example\nabove brings {leanRef}`h` along with it:\n\n```lean\nexample (x y : Nat) (h : x = y) : y = x := by\n revert x\n -- ^ PROOF_STATE: afterRevertXH\n intros\n apply Eq.symm\n assumption\n```\n\nAfter {leanRef}`revert x`, the goal is:\n\n```proofState afterRevertXH\ny : Nat\n⊢ ∀ (x : Nat), x = y → y = x\n```\n\n:::\n\nYou can also revert multiple elements of the context at once:\n\n```lean\nexample (x y : Nat) (h : x = y) : y = x := by\n revert x y\n -- ^ PROOF_STATE: revertXY\n intros\n apply Eq.symm\n assumption\n```\n\nAfter {leanRef}`revert x y`, the goal is:\n\n```proofState revertXY\n⊢ ∀ (x y : Nat), x = y → y = x\n```\n\n:::leanFirst\nYou can only {leanRef}`revert` an element of the local context, that is, a\nlocal variable or hypothesis. But you can replace an arbitrary\nexpression in the goal by a fresh variable using the {leanRef}`generalize`\ntactic:\n\n```lean (showProofStates := \"afterGen afterRevert afterIntro\")\nexample : 3 = 3 := by\n generalize 3 = x\n -- ^ PROOF_STATE: afterGen\n revert x\n -- ^ PROOF_STATE: afterRevert\n intro y\n -- ^ PROOF_STATE: afterIntro\n rfl\n```\n\nIn particular, after {leanRef}`generalize`, the goal is\n\n```proofState afterGen\nx : Nat\n⊢ x = x\n```\n\n:::\n\nThe mnemonic in the notation above is that you are generalizing the\ngoal by setting {leanRef}`3` to an arbitrary variable {leanRef (in := \"revert x\")}`x`. Be careful: not\nevery generalization preserves the validity of the goal. Here,\n{leanRef}`generalize` replaces a goal that could be proved using\n{tactic}`rfl` with one that is not provable:\n\n```lean (showProofStates := \"afterGen\")\nexample : 2 + 3 = 5 := by\n generalize 3 = x\n -- ^ PROOF_STATE: afterGen\n sorry\n```\n\nIn this example, the {leanRef}`sorry` tactic is the analogue of the {lean}`sorry`\nproof term. It closes the current goal, producing the usual warning\nthat {lean}`sorry` has been used. To preserve the validity of the previous\ngoal, the {leanRef}`generalize` tactic allows us to record the fact that\n{leanRef}`3` has been replaced by {leanRef}`x`. All you need to do is to provide a\nlabel, and {leanRef}`generalize` uses it to store the assignment in the local\ncontext:\n\n```lean\nexample : 2 + 3 = 5 := by\n generalize h : 3 = x\n -- ^ PROOF_STATE: afterGen\n rw [← h]\n```\n\nFollowing {leanRef}`generalize h : 3 = x`, {leanRef}`h` is a proof that {leanRef}`3 = x`:\n\n```proofState afterGen\nx : Nat\nh : 3 = x\n⊢ 2 + x = 5\n```\n\nHere the rewriting tactic {leanRef}`rw` uses {leanRef}`h` to replace\n{leanRef}`x` by {leanRef}`3` again. The {leanRef}`rw` tactic will be discussed below.\n\n# More Tactics\n%%%\ntag := \"more-tactics\"\n%%%\n\n:::leanFirst\nSome additional tactics are useful for constructing and destructing\npropositions and data. For example, when applied to a goal of the form\n{leanRef}`p ∨ q`, you use tactics such as {leanRef}`apply Or.inl` and\n{leanRef}`apply Or.inr`. Conversely, the {leanRef}`cases` tactic can be used to decompose a\ndisjunction:\n\n```lean\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h with\n | inl hp => apply Or.inr; exact hp\n | inr hq => apply Or.inl; exact hq\n```\n:::\n\nNote that the syntax is similar to the one used in {kw}`match` expressions.\nThe new subgoals can be solved in any order:\n\n```lean\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h with\n | inr hq => apply Or.inl; exact hq\n | inl hp => apply Or.inr; exact hp\n```\n\nYou can also use a (unstructured) {leanRef}`cases` without the {leanRef}`with` and a tactic\nfor each alternative:\n\n```lean\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h\n apply Or.inr\n assumption\n apply Or.inl\n assumption\n```\n\nThe (unstructured) {leanRef}`cases` is particularly useful when you can close several\nsubgoals using the same tactic:\n\n```lean\nexample (p : Prop) : p ∨ p → p := by\n intro h\n cases h\n repeat assumption\n```\n\nYou can also use the combinator {lit}`tac1 `{tactic}`<;>`{lit}` tac2` to apply {lit}`tac2` to each\nsubgoal produced by tactic {lit}`tac1`:\n\n```lean\nexample (p : Prop) : p ∨ p → p := by\n intro h\n cases h <;> assumption\n```\n\n:::leanFirst\nYou can combine the unstructured {leanRef}`cases` tactic with the {leanRef}`case` and {leanRef}`.` notation:\n\n```lean\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h\n . apply Or.inr\n assumption\n . apply Or.inl\n assumption\n\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h\n case inr h =>\n apply Or.inl\n assumption\n case inl h =>\n apply Or.inr\n assumption\n\nexample (p q : Prop) : p ∨ q → q ∨ p := by\n intro h\n cases h\n case inr h =>\n apply Or.inl\n assumption\n . apply Or.inr\n assumption\n```\n:::\n\n\nThe {leanRef}`cases` tactic can also be used to\ndecompose a conjunction:\n\n```lean\nexample (p q : Prop) : p ∧ q → q ∧ p := by\n intro h\n cases h with\n | intro hp hq => constructor; exact hq; exact hp\n -- ^ PROOF_STATE: afterIntroCase\n```\n\n\nIn this example, there is only one goal after the {leanRef}`cases` tactic is\napplied, with {leanRef}`h`{lit}` : `{leanRef}`p ∧ q` replaced by a pair of assumptions,\n{leanRef}`hp`{lit}` : `{leanRef}`p` and {leanRef}`hq`{lit}` : `{leanRef}`q`:\n\n```proofState afterIntroCase\ncase intro\np : Prop\nq : Prop\nhp : p\nhq : q\n⊢ q ∧ p\n```\n\nThe {leanRef}`constructor` tactic applies the unique\nconstructor for conjunction, {lean}`And.intro`.\n\nWith these tactics, an\nexample from the previous section can be rewritten as follows:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro h\n cases h with\n | intro hp hqr =>\n cases hqr\n . apply Or.inl; constructor <;> assumption\n . apply Or.inr; constructor <;> assumption\n . intro h\n cases h with\n | inl hpq =>\n cases hpq with\n | intro hp hq =>\n constructor; exact hp; apply Or.inl; exact hq\n | inr hpr =>\n cases hpr with\n | intro hp hr =>\n constructor; exact hp; apply Or.inr; exact hr\n```\n\nYou will see in {ref \"inductive-types\"}[Inductive Types] that\nthese tactics are quite general. The {leanRef}`cases` tactic can be used to\ndecompose any element of an inductively defined type; {leanRef}`constructor`\nalways applies the first applicable constructor of an inductively defined type.\nFor example, you can use {leanRef}`cases` and {leanRef}`constructor` with an existential quantifier:\n\n```lean\nexample (p q : Nat → Prop) : (∃ x, p x) → ∃ x, p x ∨ q x := by\n intro h\n cases h with\n | intro x px => constructor; apply Or.inl; exact px\n```\n\nHere, the {leanRef}`constructor` tactic leaves the first component of the\nexistential assertion, the value of {leanRef}`x`, implicit. It is represented\nby a metavariable, which should be instantiated later on. In the\nprevious example, the proper value of the metavariable is determined\nby the tactic {leanRef}`exact px`, since {leanRef}`px` has type {leanRef}`p x`. If you want\nto specify a witness to the existential quantifier explicitly, you can\nuse the {tactic}`exists` tactic instead:\n\n```lean\nexample (p q : Nat → Prop) : (∃ x, p x) → ∃ x, p x ∨ q x := by\n intro h\n cases h with\n | intro x px => exists x; apply Or.inl; exact px\n```\n\nHere is another example:\n\n```lean\nexample (p q : Nat → Prop) : (∃ x, p x ∧ q x) → ∃ x, q x ∧ p x := by\n intro h\n cases h with\n | intro x hpq =>\n cases hpq with\n | intro hp hq =>\n exists x\n```\n\nThese tactics can be used on data just as well as propositions. In the\nnext example, they are used to define functions which swap the\ncomponents of the product and sum types:\n\n```lean\ndef swap_pair : α × β → β × α := by\n intro p\n cases p\n constructor <;> assumption\n\ndef swap_sum : Sum α β → Sum β α := by\n intro p\n cases p\n . apply Sum.inr; assumption\n . apply Sum.inl; assumption\n```\n\nNote that up to the names we have chosen for the variables, the\ndefinitions are identical to the proofs of the analogous propositions\nfor conjunction and disjunction. The {leanRef}`cases` tactic will also do a\ncase distinction on a natural number:\n\n```lean\nopen Nat\nexample (P : Nat → Prop)\n (h₀ : P 0) (h₁ : ∀ n, P (succ n))\n (m : Nat) : P m := by\n cases m with\n | zero => exact h₀\n | succ m' => exact h₁ m'\n```\n\nThe {leanRef}`cases` tactic, and its companion, the {tactic}`induction` tactic, are discussed in greater detail in\nthe {ref \"tactics-for-inductive-types\"}[Tactics for Inductive Types] section.\n\n:::leanFirst\nThe {leanRef}`contradiction` tactic searches for a contradiction among the hypotheses of the current goal:\n\n```lean\nexample (p q : Prop) : p ∧ ¬ p → q := by\n intro h\n cases h\n contradiction\n```\n:::\n\n:::leanFirst\nYou can also use {tactic}`match` in tactic blocks.\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro h\n match h with\n | ⟨_, Or.inl _⟩ =>\n apply Or.inl; constructor <;> assumption\n | ⟨_, Or.inr _⟩ =>\n apply Or.inr; constructor <;> assumption\n . intro h\n match h with\n | Or.inl ⟨hp, hq⟩ =>\n constructor; exact hp; apply Or.inl; exact hq\n | Or.inr ⟨hp, hr⟩ =>\n constructor; exact hp; apply Or.inr; exact hr\n```\n:::\n\n:::leanFirst\nYou can “combine” {leanRef}`intro` with {tactic}`match` and write the previous examples as follows:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro\n | ⟨hp, Or.inl hq⟩ =>\n apply Or.inl; constructor <;> assumption\n | ⟨hp, Or.inr hr⟩ =>\n apply Or.inr; constructor <;> assumption\n . intro\n | Or.inl ⟨hp, hq⟩ =>\n constructor; assumption; apply Or.inl; assumption\n | Or.inr ⟨hp, hr⟩ =>\n constructor; assumption; apply Or.inr; assumption\n```\n:::\n\n# Structuring Tactic Proofs\n%%%\ntag := \"structuring-tactic-proofs\"\n%%%\n\nTactics often provide an efficient way of building a proof, but long\nsequences of instructions can obscure the structure of the\nargument. In this section, we describe some means that help provide\nstructure to a tactic-style proof, making such proofs more readable\nand robust.\n\n:::leanFirst\nOne thing that is nice about Lean's proof-writing syntax is that it is\npossible to mix term-style and tactic-style proofs, and pass between\nthe two freely. For example, the tactics {leanRef}`apply` and {leanRef}`exact`\nexpect arbitrary terms, which you can write using {kw}`have`, {kw}`show`,\nand so on. Conversely, when writing an arbitrary Lean term, you can\nalways invoke the tactic mode by inserting a {kw}`by`\nblock. The following is a somewhat toy example:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by\n intro h\n exact\n have hp : p := h.left\n have hqr : q ∨ r := h.right\n show (p ∧ q) ∨ (p ∧ r) by\n cases hqr with\n | inl hq => exact Or.inl ⟨hp, hq⟩\n | inr hr => exact Or.inr ⟨hp, hr⟩\n```\n:::\n\nThe following is a more natural example:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro h\n cases h.right with\n | inl hq => exact Or.inl ⟨h.left, hq⟩\n | inr hr => exact Or.inr ⟨h.left, hr⟩\n . intro h\n cases h with\n | inl hpq => exact ⟨hpq.left, Or.inl hpq.right⟩\n | inr hpr => exact ⟨hpr.left, Or.inr hpr.right⟩\n```\n\n:::leanFirst\nIn fact, there is a {tactic}`show` tactic, which is similar to the\n{kw}`show` expression in a proof term. It simply declares the type of the\ngoal that is about to be solved, while remaining in tactic\nmode.\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n . intro h\n cases h.right with\n | inl hq =>\n show (p ∧ q) ∨ (p ∧ r)\n exact Or.inl ⟨h.left, hq⟩\n | inr hr =>\n show (p ∧ q) ∨ (p ∧ r)\n exact Or.inr ⟨h.left, hr⟩\n . intro h\n cases h with\n | inl hpq =>\n show p ∧ (q ∨ r)\n exact ⟨hpq.left, Or.inl hpq.right⟩\n | inr hpr =>\n show p ∧ (q ∨ r)\n exact ⟨hpr.left, Or.inr hpr.right⟩\n```\n:::\n\nThe {tactic}`show` tactic can actually be used to rewrite a goal to something definitionally equivalent:\n\n```lean\nexample (n : Nat) : n + 1 = Nat.succ n := by\n show Nat.succ n = Nat.succ n\n rfl\n```\n\nThere is also a {tactic}`have` tactic, which introduces a new subgoal, just as when writing proof terms:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by\n intro ⟨hp, hqr⟩\n show (p ∧ q) ∨ (p ∧ r)\n cases hqr with\n | inl hq =>\n have hpq : p ∧ q := And.intro hp hq\n apply Or.inl\n exact hpq\n | inr hr =>\n have hpr : p ∧ r := And.intro hp hr\n apply Or.inr\n exact hpr\n```\n\n:::leanFirst\nAs with proof terms, you can omit the label in the {tactic}`have` tactic, in\nwhich case, the default label {leanRef}`this` is used:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by\n intro ⟨hp, hqr⟩\n show (p ∧ q) ∨ (p ∧ r)\n cases hqr with\n | inl hq =>\n have : p ∧ q := And.intro hp hq\n apply Or.inl\n exact this\n | inr hr =>\n have : p ∧ r := And.intro hp hr\n apply Or.inr\n exact this\n```\n:::\n\n:::leanFirst\nThe types in a {tactic}`have` tactic can be omitted, so you can write\n{lit}`have hp := h.left` and {lit}`have hqr := h.right`. In fact, with this\nnotation, you can even omit both the type and the label, in which case\nthe new fact is introduced with the label {leanRef}`this`:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) → (p ∧ q) ∨ (p ∧ r) := by\n intro ⟨hp, hqr⟩\n cases hqr with\n | inl hq =>\n have := And.intro hp hq\n apply Or.inl; exact this\n | inr hr =>\n have := And.intro hp hr\n apply Or.inr; exact this\n```\n:::\n\nLean also has a {tactic}`let` tactic, which is similar to the {tactic}`have`\ntactic, but is used to introduce local definitions instead of\nauxiliary facts. It is the tactic analogue of a {kw}`let` in a proof\nterm:\n\n```lean\nexample : ∃ x, x + 2 = 8 := by\n let a : Nat := 3 * 2\n exists a\n```\n\nAs with {tactic}`have`, you can leave the type implicit by writing\n{lit}`let a := 3 * 2`. The difference between {tactic}`let` and {tactic}`have` is that\n{tactic}`let` introduces a local definition in the context, so that the\ndefinition of the local declaration can be unfolded in the proof.\n\nWe have used {leanRef}`.` to create nested tactic blocks. In a nested block,\nLean focuses on the first goal, and generates an error if it has not\nbeen fully solved at the end of the block. This can be helpful in\nindicating the separate proofs of multiple subgoals introduced by a\ntactic. The notation {leanRef}`.` is whitespace sensitive and relies on the indentation\nto detect whether the tactic block ends. Alternatively, you can\ndefine tactic blocks using curly braces and semicolons:\n\n```lean\nexample (p q r : Prop) : p ∧ (q ∨ r) ↔ (p ∧ q) ∨ (p ∧ r) := by\n apply Iff.intro\n { intro h;\n cases h.right;\n { show (p ∧ q) ∨ (p ∧ r);\n exact Or.inl ⟨h.left, ‹q›⟩ }\n { show (p ∧ q) ∨ (p ∧ r);\n exact Or.inr ⟨h.left, ‹r›⟩ } }\n { intro h;\n cases h;\n { show p ∧ (q ∨ r);\n rename_i hpq;\n exact ⟨hpq.left, Or.inl hpq.right⟩ }\n { show p ∧ (q ∨ r);\n rename_i hpr;\n exact ⟨hpr.left, Or.inr hpr.right⟩ } }\n```\n\nIt is useful to use indentation to structure proof: every time a tactic\nleaves more than one subgoal, we separate the remaining subgoals by\nenclosing them in blocks and indenting. Thus if the application of\ntheorem {lit}`foo` to a single goal produces four subgoals, one would\nexpect the proof to look like this:\n\n```\n apply foo\n . \n . \n . \n . \n```\n\nor\n\n```\n apply foo\n case => \n case => \n case => \n case => \n```\n\nor\n\n```\n apply foo\n { }\n { }\n { }\n { }\n```\n\n# Tactic Combinators\n%%%\ntag := \"tactic-combinators\"\n%%%\n\n_Tactic combinators_ are operations that form new tactics from old\nones. A sequencing combinator is already implicit in the {kw}`by` block:\n\n```lean\nexample (p q : Prop) (hp : p) : p ∨ q :=\n by apply Or.inl; assumption\n```\n\nHere, {leanRef}`apply Or.inl; assumption` is functionally equivalent to a\nsingle tactic which first applies {leanRef}`apply Or.inl` and then applies\n{leanRef}`assumption`.\n\nIn {lit}`t₁ `{tactic}`<;>`{lit}` t₂`, the {leanRef}`<;>` operator provides a _parallel_ version of the sequencing operation:\n{lit}`t₁` is applied to the current goal, and then {lit}`t₂` is applied to _all_ the resulting subgoals:\n\n```lean\nexample (p q : Prop) (hp : p) (hq : q) : p ∧ q :=\n by constructor <;> assumption\n```\n\nThis is especially useful when the resulting goals can be finished off\nin a uniform way, or, at least, when it is possible to make progress\non all of them uniformly.\n\nThe {tactic}`first`{lit}` | t₁ | t₂ | ... | tₙ` applies each {lit}`tᵢ` until one succeeds, or else fails:\n\n```lean\nexample (p q : Prop) (hp : p) : p ∨ q := by\n first | apply Or.inl; assumption | apply Or.inr; assumption\n\nexample (p q : Prop) (hq : q) : p ∨ q := by\n first | apply Or.inl; assumption | apply Or.inr; assumption\n```\n\nIn the first example, the left branch succeeds, whereas in the second one, it is the right one that succeeds.\nIn the next three examples, the same compound tactic succeeds in each case:\n\n```lean\nexample (p q r : Prop) (hp : p) : p ∨ q ∨ r := by\n repeat (first | apply Or.inl; assumption | apply Or.inr | assumption)\n\nexample (p q r : Prop) (hq : q) : p ∨ q ∨ r := by\n repeat (first | apply Or.inl; assumption | apply Or.inr | assumption)\n\nexample (p q r : Prop) (hr : r) : p ∨ q ∨ r := by\n repeat (first | apply Or.inl; assumption | apply Or.inr | assumption)\n```\n\nThe tactic tries to solve the left disjunct immediately by assumption;\nif that fails, it tries to focus on the right disjunct; and if that\ndoesn't work, it invokes the assumption tactic.\n\n:::leanFirst\nYou will have no doubt noticed by now that tactics can fail. Indeed,\nit is the “failure” state that causes the _first_ combinator to\nbacktrack and try the next tactic. The {leanRef}`try` combinator builds a\ntactic that always succeeds, though possibly in a trivial way:\n{tactic}`try`{lit}` t` executes {lit}`t` and reports success, even if {lit}`t` fails. It is\nequivalent to {tactic}`first`{lit}` | t | `{tactic}`skip`, where {tactic}`skip` is a tactic that does\nnothing (and succeeds in doing so). In the next example, the second\n{leanRef}`constructor` succeeds on the right conjunct {leanRef}`q ∧ r` (remember that\ndisjunction and conjunction associate to the right) but fails on the\nfirst. The {leanRef}`try` tactic ensures that the sequential composition\nsucceeds:\n\n```lean\nexample (p q r : Prop) (hp : p) (hq : q) (hr : r) : p ∧ q ∧ r := by\n constructor <;> (try constructor) <;> assumption\n```\n:::\n\nBe careful: {tactic}`repeat`{lit}` (`{tactic}`try`{lit}` t)` will loop forever, because the inner tactic never fails.\n\nIn a proof, there are often multiple goals outstanding. Parallel\nsequencing is one way to arrange it so that a single tactic is applied\nto multiple goals, but there are other ways to do this. For example,\n{tactic}`all_goals`{lit}` t` applies {lit}`t` to all open goals:\n\n```lean\nexample (p q r : Prop) (hp : p) (hq : q) (hr : r) : p ∧ q ∧ r := by\n constructor\n all_goals (try constructor)\n all_goals assumption\n```\n\nIn this case, the {tactic}`any_goals` tactic provides a more robust solution.\nIt is similar to {tactic}`all_goals`, except it succeeds if its argument\nsucceeds on at least one goal:\n\n```lean\nexample (p q r : Prop) (hp : p) (hq : q) (hr : r) : p ∧ q ∧ r := by\n constructor\n any_goals constructor\n any_goals assumption\n```\n\nThe first tactic in the {kw}`by` block below repeatedly splits\nconjunctions:\n\n```lean\nexample (p q r : Prop) (hp : p) (hq : q) (hr : r) :\n p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by\n repeat (any_goals constructor)\n all_goals assumption\n```\n\nIn fact, we can compress the full tactic down to one line:\n\n```lean\nexample (p q r : Prop) (hp : p) (hq : q) (hr : r) :\n p ∧ ((p ∧ q) ∧ r) ∧ (q ∧ r ∧ p) := by\n repeat (any_goals (first | constructor | assumption))\n```\n\nThe combinator {tactic}`focus`{lit}` t` ensures that {lit}`t` only effects the current\ngoal, temporarily hiding the others from the scope. So, if {lit}`t`\nordinarily only effects the current goal, {tactic}`focus`{lit}` (`{tactic}`all_goals`{lit}` t)` has\nthe same effect as {lit}`t`.\n\n# Rewriting\n%%%\ntag := \"rewriting\"\n%%%\n\nThe {tactic}`rw` tactic and the {tactic}`simp` tactic\nwere introduced briefly in {ref \"calculational-proofs\"}[Calculational Proofs]. In this\nsection and the next, we discuss them in greater detail.\n\n:::setup\n```\nvariable (x y : α) (h : x = y)\ntheorem add_comm : ∀ (x y : Nat), x + y = y + x := by omega\n```\n\nThe {tactic}`rw` tactic provides a basic mechanism for applying\nsubstitutions to goals and hypotheses, providing a convenient and\nefficient way of working with equality. The most basic form of the\ntactic is {tactic}`rw`{lit}` [t]`, where {lit}`t` is a term whose type asserts an\nequality. For example, {lit}`t` can be a hypothesis {lean}`h : x = y` in the\ncontext; it can be a general lemma, like\n{lean}`add_comm : ∀ x y, x + y = y + x`, in which the rewrite tactic tries to find suitable\ninstantiations of {lean}`x` and {lean}`y`; or it can be any compound term\nasserting a concrete or general equation. In the following example, we\nuse this basic form to rewrite the goal using a hypothesis.\n\n:::\n\n```lean\nvariable (k : Nat) (f : Nat → Nat)\n\nexample (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by\n rw [h₂] -- replace k with 0\n rw [h₁] -- replace f 0 with 0\n```\n\n:::setup\n```\nvariable (t : α)\n```\n\nIn the example above, the first use of {leanRef}`rw` replaces {leanRef}`k` with\n{leanRef}`0` in the goal {leanRef}`f k = 0`. Then, the second one replaces {leanRef}`f 0`\nwith {leanRef}`0`. The tactic automatically closes any goal of the form\n{lean}`t = t`. Here is an example of rewriting using a compound expression:\n:::\n\n```lean\nexample (x y : Nat) (p : Nat → Prop) (q : Prop) (h : q → x = y)\n (h' : p y) (hq : q) : p x := by\n rw [h hq]; assumption\n```\n\nHere, {leanRef}`h hq` establishes the equation {leanRef}`x = y`.\n\nMultiple rewrites can be combined using the notation {tactic}`rw`{lit}` [t_1, ..., t_n]`,\nwhich is just shorthand for {tactic}`rw`{lit}` [t_1]; ...; `{tactic}`rw`{lit}` [t_n]`. The previous example can be written as follows:\n\n```lean\nvariable (k : Nat) (f : Nat → Nat)\n\nexample (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by\n rw [h₂, h₁]\n```\n\nBy default, {leanRef}`rw` uses an equation in the forward direction, matching\nthe left-hand side with an expression, and replacing it with the\nright-hand side. The notation {lit}`←t` can be used to instruct the\ntactic to use the equality {lit}`t` in the reverse direction.\n\n```lean\nvariable (a b : Nat) (f : Nat → Nat)\n\nexample (h₁ : a = b) (h₂ : f a = 0) : f b = 0 := by\n rw [←h₁, h₂]\n```\n\nIn this example, the term {leanRef}`←h₁` instructs the rewriter to replace\n{leanRef}`b` with {leanRef}`a`. In the editors, you can type the backwards arrow as\n{kbd}`\\l`. You can also use the ASCII equivalent, {lit}`<-`.\n\nSometimes the left-hand side of an identity can match more than one\nsubterm in the pattern, in which case the {tactic}`rw` tactic chooses the\nfirst match it finds when traversing the term. If that is not the one\nyou want, you can use additional arguments to specify the appropriate\nsubterm.\n\n```lean\nexample (a b c : Nat) : a + b + c = a + c + b := by\n rw [Nat.add_assoc, Nat.add_comm b, ← Nat.add_assoc]\n\nexample (a b c : Nat) : a + b + c = a + c + b := by\n rw [Nat.add_assoc, Nat.add_assoc, Nat.add_comm b]\n\nexample (a b c : Nat) : a + b + c = a + c + b := by\n rw [Nat.add_assoc, Nat.add_assoc, Nat.add_comm _ b]\n```\n\n:::TODO\nGet the intermediate proof states from `rw` into the reference ring to help these examples be better\n:::\n\nIn the first example above, the first step rewrites {leanRef}`a + b + c` to\n{leanRef}`a`{lit}` + (`{leanRef}`b + c`{lit}`)`. The next step applies commutativity to the term\n{leanRef}`b + c`; without specifying the argument, the tactic would instead rewrite\n{leanRef}`a`{lit}` + (`{leanRef}`b + c`{lit}`)` to {lit}`(`{leanRef}`b + c`{lit}`) + `{leanRef}`a`. Finally, the last step applies\nassociativity in the reverse direction, rewriting {leanRef}`a`{lit}` + (`{leanRef}`c`{lit}` + `{leanRef}`b`{lit}`)` to\n{leanRef}`a + c + b`. The next two examples instead apply associativity to\nmove the parenthesis to the right on both sides, and then switch {leanRef}`b`\nand {leanRef}`c`. Notice that the last example specifies that the rewrite\nshould take place on the right-hand side by specifying the second\nargument to {leanRef}`Nat.add_comm`.\n\nBy default, the {leanRef}`rw` tactic affects only the goal. The notation\n{tactic}`rw`{lit}` [t] `{kw}`at`{lit}` h` applies the rewrite\n\n```lean\nexample (f : Nat → Nat) (a : Nat) (h : a + 0 = 0) : f a = f 0 := by\n rw [Nat.add_zero] at h\n rw [h]\n```\n\nThe first step, {leanRef}`rw [Nat.add_zero] at h`, rewrites the hypothesis {leanRef}`a + 0 = 0` to {leanRef}`a = 0`.\nThen the new hypothesis {leanRef}`a = 0` is used to rewrite the goal to {leanRef}`f 0`{lit}` = `{leanRef}`f 0`.\n\n:::leanFirst\nThe {leanRef}`rw` tactic is not restricted to propositions.\nIn the following example, we use {tactic}`rw`{lit}` [h] `{kw}`at`{lit}` t` to rewrite the hypothesis {leanRef}`t : Tuple α n` to {leanRef}`t : Tuple α`{lit}` 0`.\n\n```lean\ndef Tuple (α : Type) (n : Nat) :=\n { as : List α // as.length = n }\n\nexample (n : Nat) (h : n = 0) (t : Tuple α n) : Tuple α 0 := by\n rw [h] at t\n exact t\n```\n:::\n\n# Using the Simplifier\n%%%\ntag := \"using-the-simplifier\"\n%%%\n\nWhereas {tactic}`rw` is designed as a surgical tool for manipulating a\ngoal, the simplifier offers a more powerful form of automation. A\nnumber of identities in Lean's library have been tagged with the\n{attr}`[simp]` attribute, and the {tactic}`simp` tactic uses them to iteratively\nrewrite subterms in an expression.\n\n```lean\nexample (x y z : Nat) : (x + 0) * (0 + y * 1 + z * 0) = x * y := by\n simp\n\nexample (x y z : Nat) (p : Nat → Prop) (h : p (x * y))\n : p ((x + 0) * (0 + y * 1 + z * 0)) := by\n simp; assumption\n```\n\nIn the first example, the left-hand side of the equality in the goal\nis simplified using the usual identities involving 0 and 1, reducing\nthe goal to {leanRef}`x * y`{lit}` = `{leanRef}`x * y`. At that point, {leanRef}`simp` applies\nreflexivity to finish it off. In the second example, {leanRef}`simp` reduces\nthe goal to {leanRef}`p (x * y)`, at which point the assumption {leanRef}`h`\nfinishes it off. Here are some more examples\nwith lists:\n\n```lean\nopen List\n\nexample (xs : List Nat)\n : reverse (xs ++ [1, 2, 3]) = [3, 2, 1] ++ reverse xs := by\n simp\n\nexample (xs ys : List α)\n : length (reverse (xs ++ ys)) = length xs + length ys := by\n simp [Nat.add_comm]\n```\n\nAs with {leanRef}`rw`, you can use the keyword {leanRef}`at` to simplify a hypothesis:\n\n```lean\nexample (x y z : Nat) (p : Nat → Prop)\n (h : p ((x + 0) * (0 + y * 1 + z * 0))) : p (x * y) := by\n simp at h; assumption\n```\n\nMoreover, you can use a “wildcard” asterisk to simplify all the hypotheses and the goal:\n\n```lean\nattribute [local simp] Nat.mul_comm Nat.mul_assoc Nat.mul_left_comm\nattribute [local simp] Nat.add_assoc Nat.add_comm Nat.add_left_comm\n\nexample (w x y z : Nat) (p : Nat → Prop)\n (h : p (x * y + z * w * x)) : p (x * w * z + y * x) := by\n simp at *; assumption\n\nexample (x y z : Nat) (p : Nat → Prop)\n (h₁ : p (1 * x + y)) (h₂ : p (x * z * 1))\n : p (y + 0 + x) ∧ p (z * x) := by\n simp at * <;> constructor <;> assumption\n```\n\n:::setup\n```\nvariable (x y z : Nat)\n```\n\nFor operations that are commutative and associative, like\nmultiplication on the natural numbers, the simplifier uses these two\nfacts to rewrite an expression, as well as _left commutativity_. In\nthe case of multiplication the latter is expressed as follows:\n{lean}`x * (y * z) = y * (x * z)`. The {leanRef}`local` modifier tells the simplifier\nto use these rules in the current file (or section or namespace, as\nthe case may be). It may seem that commutativity and\nleft-commutativity are problematic, in that repeated application of\neither causes looping. But the simplifier detects identities that\npermute their arguments, and uses a technique known as _ordered\nrewriting_. This means that the system maintains an internal ordering\nof terms, and only applies the identity if doing so decreases the\norder. With the three identities mentioned above, this has the effect\nthat all the parentheses in an expression are associated to the right,\nand the expressions are ordered in a canonical (though somewhat\narbitrary) way. Two expressions that are equivalent up to\nassociativity and commutativity are then rewritten to the same\ncanonical form.\n:::\n\n```lean\nattribute [local simp] Nat.mul_comm Nat.mul_assoc Nat.mul_left_comm\nattribute [local simp] Nat.add_assoc Nat.add_comm Nat.add_left_comm\n------\nexample (w x y z : Nat) (p : Nat → Prop)\n : x * y + z * w * x = x * w * z + y * x := by\n simp\n\nexample (w x y z : Nat) (p : Nat → Prop)\n (h : p (x * y + z * w * x)) : p (x * w * z + y * x) := by\n simp; simp at h; assumption\n```\n\nAs with {tactic}`rw`, you can send {tactic}`simp` a list of facts to use,\nincluding general lemmas, local hypotheses, definitions to unfold, and\ncompound expressions. The {tactic}`simp` tactic also recognizes the {lit}`←t`\nsyntax that {tactic}`rewrite` does. In any case, the additional rules are\nadded to the collection of identities that are used to simplify a\nterm.\n\n```lean\ndef f (m n : Nat) : Nat :=\n m + n + m\n\nexample {m n : Nat} (h : n = 1) (h' : 0 = m) : (f m n) = n := by\n simp [h, ←h', f]\n```\n\nA common idiom is to simplify a goal using local hypotheses:\n\n```lean\nvariable (k : Nat) (f : Nat → Nat)\n\nexample (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by\n simp [h₁, h₂]\n```\n\n:::leanFirst\nTo use all the hypotheses present in the local context when\nsimplifying, we can use the wildcard symbol, {leanRef}`*`:\n\n```lean\nvariable (k : Nat) (f : Nat → Nat)\n\nexample (h₁ : f 0 = 0) (h₂ : k = 0) : f k = 0 := by\n simp [*]\n```\n:::\n\nHere is another example:\n\n```lean\nexample (u w x y z : Nat) (h₁ : x = y + z) (h₂ : w = u + x)\n : w = z + y + u := by\n simp [*, Nat.add_comm]\n```\n\n:::leanFirst\nThe simplifier will also do propositional rewriting. For example,\nusing the hypothesis {leanRef (in := \"p ∧ q\")}`p`, it rewrites {leanRef}`p ∧ q` to {leanRef (in := \"p ∨ q\")}`q` and {leanRef}`p ∨ q` to {lean}`True`,\nwhich it then proves trivially. Iterating such\nrewrites produces nontrivial propositional reasoning.\n\n```lean\nexample (p q : Prop) (hp : p) : p ∧ q ↔ q := by\n simp [*]\n\nexample (p q : Prop) (hp : p) : p ∨ q := by\n simp [*]\n\nexample (p q r : Prop) (hp : p) (hq : q) : p ∧ (q ∨ r) := by\n simp [*]\n```\n:::\n\nThe next example simplifies all the hypotheses, and then uses them to prove the goal.\n\n```lean\nset_option linter.unusedVariables false\n------\nexample (u w x x' y y' z : Nat) (p : Nat → Prop)\n (h₁ : x + 0 = x') (h₂ : y + 0 = y')\n : x + y + 0 = x' + y' := by\n simp at *\n simp [*]\n```\n\nOne thing that makes the simplifier especially useful is that its\ncapabilities can grow as a library develops. For example, suppose we\ndefine a list operation that symmetrizes its input by appending its\nreversal:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n```\n\n:::leanFirst\nThen for any list {leanRef (in := \"mk_symm xs\")}`xs`, {leanRef}`(mk_symm xs).reverse` is equal to {leanRef}`mk_symm xs`,\nwhich can easily be proved by unfolding the definition:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n------\ntheorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n```\n:::\n\nWe can now use this theorem to prove new results:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\ntheorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n------\nexample (xs ys : List Nat)\n : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by\n simp [reverse_mk_symm]\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp [reverse_mk_symm] at h; assumption\n```\n\nBut using {leanRef}`reverse_mk_symm` is generally the right thing to do, and\nit would be nice if users did not have to invoke it explicitly. You can\nachieve that by marking it as a simplification rule when the theorem\nis defined:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n------\n@[simp] theorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n\nexample (xs ys : List Nat)\n : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by\n simp\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp at h; assumption\n```\n\nThe notation {leanRef}`@[simp]` declares {leanRef}`reverse_mk_symm` to have the\n{attr}`[simp]` attribute, and can be spelled out more explicitly:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n------\ntheorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n\nattribute [simp] reverse_mk_symm\n\nexample (xs ys : List Nat)\n : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by\n simp\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp at h; assumption\n```\n\nThe attribute can also be applied any time after the theorem is declared:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n------\ntheorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n\nexample (xs ys : List Nat)\n : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by\n simp [reverse_mk_symm]\n\nattribute [simp] reverse_mk_symm\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp at h; assumption\n```\n\n:::leanFirst\nOnce the attribute is applied, however, there is no way to permanently\nremove it; it persists in any file that imports the one where the\nattribute is assigned. As we will discuss further in\n{ref \"attributes\"}[Attributes], one can limit the scope of an attribute to the\ncurrent file or section using the {leanRef}`local` modifier:\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n------\ntheorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n\nsection\nattribute [local simp] reverse_mk_symm\n\nexample (xs ys : List Nat)\n : (xs ++ mk_symm ys).reverse = mk_symm ys ++ xs.reverse := by\n simp\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp at h; assumption\nend\n```\n:::\n\nOutside the section, the simplifier will no longer use\n{leanRef}`reverse_mk_symm` by default.\n\nNote that the various {leanRef}`simp` options we have discussed—giving an\nexplicit list of rules, and using {leanRef}`at` to specify the location—can be combined,\nbut the order they are listed is rigid. You can see the correct order\nin an editor by placing the cursor on the {leanRef}`simp` identifier to see\nthe documentation string that is associated with it.\n\n:::leanFirst\nThere are two additional modifiers that are useful. By default,\n{leanRef}`simp` includes all theorems that have been marked with the\nattribute {attr}`[simp]`. Writing {leanRef}`simp only` excludes these defaults,\nallowing you to use a more explicitly crafted list of\nrules. In the examples below, the minus sign and\n{leanRef}`only` are used to block the application of {leanRef}`reverse_mk_symm`.\n\n```lean\ndef mk_symm (xs : List α) :=\n xs ++ xs.reverse\n@[simp] theorem reverse_mk_symm (xs : List α)\n : (mk_symm xs).reverse = mk_symm xs := by\n simp [mk_symm]\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p (mk_symm ys ++ xs.reverse) := by\n simp at h; assumption\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p ((mk_symm ys).reverse ++ xs.reverse) := by\n simp [-reverse_mk_symm] at h; assumption\n\nexample (xs ys : List Nat) (p : List Nat → Prop)\n (h : p (xs ++ mk_symm ys).reverse)\n : p ((mk_symm ys).reverse ++ xs.reverse) := by\n simp only [List.reverse_append] at h; assumption\n```\n:::\n\nThe {leanRef}`simp` tactic has many configuration options. For example, we can enable contextual simplifications as follows:\n\n```lean\nexample : if x = 0 then y + x = y else x ≠ 0 := by\n simp +contextual\n```\n\nWith {leanRef}`+contextual`, the {leanRef}`simp` tactic uses the fact that {leanRef}`x = 0` when simplifying {leanRef}`y + x = y`, and\n{leanRef}`x ≠ 0` when simplifying the other branch. Here is another example:\n\n```lean\nexample : ∀ (x : Nat) (h : x = 0), y + x = y := by\n simp +contextual\n```\n\n:::leanFirst\nAnother useful configuration option is {leanRef}`+arith` which enables arithmetical simplifications.\n\n```lean\nexample : 0 < 1 + x ∧ x + y + 2 ≥ y + 1 := by\n simp +arith\n```\n:::\n\n# Split Tactic\n%%%\ntag := \"split-tactic\"\n%%%\n\n::::leanFirst\n\n\nThe {leanRef}`split` tactic is useful for breaking nested {kw}`if`-{kw}`then`-{kw}`else` and {kw}`match` expressions in cases.\nFor a {kw}`match` expression with $`n` cases, the {leanRef}`split` tactic generates at most $`n` subgoals. Here is an example:\n\n\n```lean\ndef f (x y z : Nat) : Nat :=\n match x, y, z with\n | 5, _, _ => y\n | _, 5, _ => y\n | _, _, 5 => y\n | _, _, _ => 1\n\nexample (x y z : Nat) : x ≠ 5 → y ≠ 5 → z ≠ 5 → z = w → f x y w = 1 := by\n intros\n simp [f]\n split\n . contradiction\n . contradiction\n . contradiction\n . rfl\n```\n::::\n\nWe can compress the tactic proof above as follows.\n\n```lean\ndef f (x y z : Nat) : Nat :=\n match x, y, z with\n | 5, _, _ => y\n | _, 5, _ => y\n | _, _, 5 => y\n | _, _, _ => 1\n------\nexample (x y z : Nat) :\n x ≠ 5 → y ≠ 5 → z ≠ 5 → z = w →\n f x y w = 1 := by\n intros; simp [f]; split <;> first | contradiction | rfl\n```\n\nThe tactic {leanRef}`split <;> first | contradiction | rfl` first applies the {leanRef}`split` tactic,\nand then for each generated goal it tries {leanRef}`contradiction`, and then {leanRef}`rfl` if {leanRef}`contradiction` fails.\nLike {leanRef}`simp`, we can apply {leanRef}`split` to a particular hypothesis:\n\n```lean\ndef g (xs ys : List Nat) : Nat :=\n match xs, ys with\n | [a, b], _ => a+b+1\n | _, [b, _] => b+1\n | _, _ => 1\n\nexample (xs ys : List Nat) (h : g xs ys = 0) : False := by\n simp [g] at h; split at h <;> simp +arith at h\n```\n\n# Extensible Tactics\n%%%\ntag := \"extensible-tactics\"\n%%%\n\n:::leanFirst\nIn the following example, we define the notation {leanRef}`triv` using the command {leanRef}`syntax`.\nThen, we use the command {leanRef}`macro_rules` to specify what should\nbe done when {leanRef}`triv` is used. You can provide different expansions, and the tactic\ninterpreter will try all of them until one succeeds:\n\n```lean\n-- Define a new tactic notation\nsyntax \"triv\" : tactic\n\nmacro_rules\n | `(tactic| triv) => `(tactic| assumption)\n\nexample (h : p) : p := by\n triv\n\n-- You cannot prove the following theorem using `triv`\n-- example (x : α) : x = x := by\n-- triv\n\n-- Let's extend `triv`. The tactic interpreter\n-- tries all possible macro extensions for `triv` until one succeeds\nmacro_rules\n | `(tactic| triv) => `(tactic| rfl)\n\nexample (x : α) : x = x := by\n triv\n\nexample (x : α) (h : p) : x = x ∧ p := by\n apply And.intro <;> triv\n\n-- We now add a (recursive) extension\nmacro_rules | `(tactic| triv) => `(tactic| apply And.intro <;> triv)\n\nexample (x : α) (h : p) : x = x ∧ p := by\n triv\n```\n:::\n\n# Exercises\n%%%\ntag := none\n%%%\n\n1. Go back to the exercises in {ref \"propositions-and-proofs\"}[Propositions and Proofs] and\n{ref \"quantifiers-and-equality\"}[Quantifiers and Equality] and\nredo as many as you can now with tactic proofs, using also {tactic}`rw`\nand {tactic}`simp` as appropriate.\n\n2. Use tactic combinators to obtain a one-line proof of the following:\n\n```lean\nexample (p q r : Prop) (hp : p)\n : (p ∨ q ∨ r) ∧ (q ∨ p ∨ r) ∧ (q ∨ r ∨ p) := by\n sorry\n```\n"
},
{
"path": "book/TPiL/TypeClasses.lean",
"content": "import VersoManual\nimport TPiL.Examples\n\nopen Verso.Genre\nopen Verso.Genre.Manual hiding tactic\nopen TPiL\n\n#doc (Manual) \"Type Classes\" =>\n%%%\ntag := \"type-classes\"\n%%%\n\nType classes were introduced as a principled way of enabling\nad-hoc polymorphism in functional programming languages. We first observe that it\nwould be easy to implement an ad-hoc polymorphic function (such as addition) if the\nfunction simply took the type-specific implementation of addition as an argument\nand then called that implementation on the remaining arguments. For example,\nsuppose we declare a structure in Lean to hold implementations of addition.\n\n```lean\nnamespace Ex\n------\nstructure Add (α : Type) where\n add : α → α → α\n\n#check @Add.add -- @Add.add : {α : Type} → Add α → α → α → α\n------\nend Ex\n```\n\n\n::::setup\n```\nnamespace Ex\nstructure Add (α : Type) where\n add : α → α → α\ndef double (s : Add α) (x : α) : α :=\n s.add x x\nvariable {n : Nat}\n```\n:::leanFirst\nIn the above Lean code, the field {leanRef}`add` has type\n{lean}`Add.add : {α : Type} → Add α → α → α → α`\nwhere the curly braces around the type {leanRef}`α` mean that it is an implicit argument.\nWe could implement {leanRef}`double` by:\n\n\n```lean\nnamespace Ex\nstructure Add (α : Type) where\n add : α → α → α\n------\ndef double (s : Add α) (x : α) : α :=\n s.add x x\n\n#eval double { add := Nat.add } 10 -- 20\n\n#eval double { add := Nat.mul } 10 -- 100\n\n#eval double { add := Int.add } 10 -- 20\n------\nend Ex\n```\n:::\n\nNote that you can double a natural number {lean}`n` by {lean}`double { add := Nat.add } n`.\nOf course, it would be highly cumbersome for users to manually pass the\nimplementations around in this way.\nIndeed, it would defeat most of the potential benefits of ad-hoc\npolymorphism.\n::::\n\n:::leanFirst\nThe main idea behind type classes is to make arguments such as {leanRef}`Add α` implicit,\nand to use a database of user-defined instances to synthesize the desired instances\nautomatically through a process known as typeclass resolution. In Lean, by changing\n{kw}`structure` to {kw}`class` in the example above, the type of {leanRef}`Add.add` becomes:\n\n```lean\nnamespace Ex\n------\nclass Add (α : Type) where\n add : α → α → α\n\n#check @Add.add -- @Add.add : {α : Type} → [self : Add α] → α → α → α\n------\nend Ex\n```\n:::\n\nwhere the square brackets indicate that the argument of type {leanRef}`Add α` is _instance implicit_,\ni.e. that it should be synthesized using typeclass resolution. This version of\n{leanRef}`add` is the Lean analogue of the Haskell term {lit}`add :: Add a => a -> a -> a`.\nSimilarly, we can register instances by:\n\n```lean\nnamespace Ex\nclass Add (α : Type) where\n add : α → α → α\n------\ninstance : Add Nat where\n add := Nat.add\n\ninstance : Add Int where\n add := Int.add\n\ninstance : Add Float where\n add := Float.add\n------\nend Ex\n```\n\n::::leanFirst\n:::setup\n```\nnamespace Ex\nclass Add (α : Type) where\n add : α → α → α\n------\ninstance : Add Nat where\n add := Nat.add\n\ninstance : Add Int where\n add := Int.add\n\ninstance : Add Float where\n add := Float.add\n\nvariable (n m : Nat)\n```\nThen for {lean}`n : Nat` and {lean}`m : Nat`, the term {lean}`Add.add n m` triggers typeclass resolution with\nthe goal of {lean}`Add Nat`, and typeclass resolution will synthesize the instance for {lean}`Nat` above.\nWe can now reimplement {leanRef}`double` using an instance implicit by:\n:::\n\n```lean\nnamespace Ex\nclass Add (α : Type) where\n add : α → α → α\ninstance : Add Nat where\n add := Nat.add\ninstance : Add Int where\n add := Int.add\ninstance : Add Float where\n add := Float.add\n------\ndef double [Add α] (x : α) : α :=\n Add.add x x\n\n#check @double -- @double : {α : Type} → [Add α] → α → α\n\n#eval double 10 -- 20\n\n#eval double (10 : Int) -- 20\n\n#eval double (7 : Float) -- 14.000000\n\n#eval double (239.0 + 2) -- 482.000000\n\n------\nend Ex\n```\n::::\n\n:::leanFirst\nIn general, instances may depend on other instances in complicated ways. For example,\nyou can declare an instance stating that if {leanRef}`α` has addition, then {leanRef}`Array α`\nhas addition:\n\n```lean\ninstance [Add α] : Add (Array α) where\n add x y := Array.zipWith (· + ·) x y\n\n#eval Add.add #[1, 2] #[3, 4] -- #[4, 6]\n\n#eval #[1, 2] + #[3, 4] -- #[4, 6]\n```\n:::\n\nNote that {leanRef}`(· + ·)` is notation for {lean}`fun x y => x + y` in Lean.\n\n\n:::setup\n```\ndef head [Inhabited α] (xs : List α) : α := default\nvariable {α : Type u} {x : α} {xs : List α} [Inhabited α]\n```\n\nThe example above demonstrates how type classes are used to overload notation.\nNow, we explore another application. We often need an arbitrary element of a given type.\nRecall that types may not have any elements in Lean.\nIt often happens that we would like a definition to return an arbitrary element in a “corner case.”\nFor example, we may like the expression {lean}`head xs` to be of type {lean}`α` when {lean}`xs` is of type {lean}`List α`.\nSimilarly, many theorems hold under the additional assumption that a type is not empty.\nFor example, if {lean}`α` is a type, {lean}`∃ x : α, x = x` is true only if {lean}`α` is not empty.\nThe standard library defines a type class {lean}`Inhabited` to enable type class inference to infer a\n“default” element of an inhabited type.\nLet us start with the first step of the program above, declaring an appropriate class:\n\n\n\n```lean\nnamespace Ex\n------\nclass Inhabited (α : Type u) where\n default : α\n\n#check @Inhabited.default -- @Inhabited.default : {α : Type u_1} → [self : Inhabited α] → α\n------\nend Ex\n```\n\nNote {leanRef}`Inhabited.default` doesn't have any explicit arguments.\n\nAn element of the class {lean}`Inhabited α` is simply an expression of the form {lean}`Inhabited.mk x`, for some element {lean}`x : α`.\nThe projection {lean}`Inhabited.default` will allow us to “extract” such an element of {lean}`α` from an element of {lean}`Inhabited α`.\nNow we populate the class with some instances:\n:::\n\n```lean\nnamespace Ex\nclass Inhabited (a : Type _) where\n default : a\n------\ninstance : Inhabited Bool where\n default := true\n\ninstance : Inhabited Nat where\n default := 0\n\ninstance : Inhabited Unit where\n default := ()\n\ninstance : Inhabited Prop where\n default := True\n\n#eval (Inhabited.default : Nat) -- 0\n\n#eval (Inhabited.default : Bool) -- true\n--------\nend Ex\n```\n\nYou can use the command {kw}`export` to create the alias {lean}`default` for {lean}`Inhabited.default`.\n\n```lean\nnamespace Ex\nclass Inhabited (a : Type _) where\n default : a\ninstance : Inhabited Bool where\n default := true\ninstance : Inhabited Nat where\n default := 0\ninstance : Inhabited Unit where\n default := ()\ninstance : Inhabited Prop where\n default := True\n------\nexport Inhabited (default)\n\n#eval (default : Nat) -- 0\n\n#eval (default : Bool) -- true\n------\nend Ex\n```\n\n# Chaining Instances\n%%%\ntag := \"chaining-instances\"\n%%%\n\nIf that were the extent of type class inference, it would not be all that impressive;\nit would be simply a mechanism of storing a list of instances for the elaborator to find in a lookup table.\nWhat makes type class inference powerful is that one can _chain_ instances. That is,\nan instance declaration can in turn depend on an implicit instance of a type class.\nThis causes class inference to chain through instances recursively, backtracking when necessary, in a Prolog-like search.\n\n:::leanFirst\nFor example, the following definition shows that if two types {leanRef}`α` and {leanRef}`β` are inhabited, then so is their product:\n\n```lean\ninstance [Inhabited α] [Inhabited β] : Inhabited (α × β) where\n default := (default, default)\n```\n:::\n\nWith this added to the earlier instance declarations, type class instance can infer, for example, a default element of {lean}`Nat × Bool`:\n\n```lean\nnamespace Ex\nclass Inhabited (α : Type u) where\n default : α\ninstance : Inhabited Bool where\n default := true\ninstance : Inhabited Nat where\n default := 0\nopaque default [Inhabited α] : α :=\n Inhabited.default\n------\ninstance [Inhabited α] [Inhabited β] : Inhabited (α × β) where\n default := (default, default)\n\n#eval (default : Nat × Bool) -- (0, true)\n------\nend Ex\n```\n\nSimilarly, we can inhabit type function with suitable constant functions:\n\n```lean\ninstance [Inhabited β] : Inhabited (α → β) where\n default := fun _ => default\n```\n\nAs an exercise, try defining default instances for other types, such as {lean}`List` and {lean}`Sum` types.\n\n:::setup\n```\nuniverse u\nset_option checkBinderAnnotations false\n```\nThe Lean standard library contains the definition {name}`inferInstance`. It has type {lean}`{α : Sort u} → [i : α] → α`,\nand is useful for triggering the type class resolution procedure when the expected type is an instance.\n:::\n\n```lean\n#check (inferInstance : Inhabited Nat) -- inferInstance : Inhabited Nat\n\ndef foo : Inhabited (Nat × Nat) :=\n inferInstance\n\ntheorem ex : foo.default = (default, default) :=\n rfl\n```\n\n:::leanFirst\nYou can use the command {leanRef}`#print` to inspect how simple {leanRef}`inferInstance` is.\n\n```lean\n#print inferInstance\n```\n:::\n\n# ToString\n%%%\ntag := \"ToString\"\n%%%\n```setup\nuniverse u\n```\n\n:::leanFirst\nThe polymorphic method {leanRef}`toString` has type {lean}`{α : Type u} → [ToString α] → α → String`. You implement the instance\nfor your own types and use chaining to convert complex values into strings. Lean comes with {lean}`ToString` instances\nfor most builtin types.\n\n```lean\nstructure Person where\n name : String\n age : Nat\n\ninstance : ToString Person where\n toString p := p.name ++ \"@\" ++ toString p.age\n\n#eval toString { name := \"Leo\", age := 542 : Person } -- \"Leo@542\"\n\n#eval toString ({ name := \"Daniel\", age := 18 : Person }, \"hello\") -- \"(Daniel@18, hello)\"\n```\n:::\n\n# Numerals\n%%%\ntag := \"numerals\"\n%%%\n\nNumerals are polymorphic in Lean. You can use a numeral (e.g., {lit}`2`) to denote an element of any type that implements\nthe type class {name}`OfNat`.\n\n```lean\nstructure Rational where\n num : Int\n den : Nat\n inv : den ≠ 0\n\ninstance : OfNat Rational n where\n ofNat := { num := n, den := 1, inv := by decide }\n\ninstance : ToString Rational where\n toString r := s!\"{r.num}/{r.den}\"\n\n#eval (2 : Rational) -- 2/1\n\n#check (2 : Rational) -- 2 : Rational\n\n#check (2 : Nat) -- 2 : Nat\n```\n\n:::setup\n```\nstructure Rational where\n num : Int\n den : Nat\n inv : den ≠ 0\n\ninstance : OfNat Rational n where\n ofNat := { num := n, den := 1, inv := by decide }\n\ninstance : ToString Rational where\n toString r := s!\"{r.num}/{r.den}\"\n```\nLean elaborates the terms {lean}`(2 : Nat)` and {lean}`(2 : Rational)` as\n{lean (type := \"Nat\")}`@OfNat.ofNat Nat 2 (@instOfNatNat 2)` and\n{lean}`@OfNat.ofNat Rational 2 (@instOfNatRational 2)` respectively.\nWe say the numerals {lit}`2` occurring in the elaborated terms are _raw_ natural numbers.\nYou can input the raw natural number {lit}`2` using the macro {lean}`nat_lit 2`.\n:::\n\n```lean\n#check nat_lit 2 -- 2 : Nat\n```\n\nRaw natural numbers are _not_ polymorphic.\n\nThe {lean}`OfNat` instance is parametric on the numeral. So, you can define instances for particular numerals.\nThe second argument is often a variable as in the example above, or a _raw_ natural number.\n\n```lean\nclass Monoid (α : Type u) where\n unit : α\n op : α → α → α\n\ninstance [s : Monoid α] : OfNat α (nat_lit 1) where\n ofNat := s.unit\n\ndef getUnit [Monoid α] : α :=\n 1\n```\n\n# Output Parameters\n%%%\ntag := \"output-parameters\"\n%%%\n\n:::setup\n```\nuniverse u\nvariable (T : Type u)\n```\n\nBy default, Lean only tries to synthesize an instance {lean}`Inhabited T` when the term {lean}`T` is known and does not\ncontain missing parts. The following command produces the error\n{lit}`typeclass instance problem is stuck, it is often due to metavariables` because the type has a missing part (i.e., the {lit}`_`).\n:::\n\n```lean\n/--\nerror: typeclass instance problem is stuck, it is often due to metavariables\n Inhabited (Nat × ?m.2)\n-/\n#guard_msgs (error) in\n#eval (inferInstance : Inhabited (Nat × _))\n```\n\nYou can view the parameter of the type class {lean}`Inhabited` as an _input_ value for the type class synthesizer.\nWhen a type class has multiple parameters, you can mark some of them as {deftech}_output parameters_.\nLean will start type class synthesizer even when these parameters have missing parts.\nIn the following example, we use output parameters to define a _heterogeneous_ polymorphic\nmultiplication.\n\n```lean\nnamespace Ex\n------\nclass HMul (α : Type u) (β : Type v) (γ : outParam (Type w)) where\n hMul : α → β → γ\n\nexport HMul (hMul)\n\ninstance : HMul Nat Nat Nat where\n hMul := Nat.mul\n\ninstance : HMul Nat (Array Nat) (Array Nat) where\n hMul a bs := bs.map (fun b => hMul a b)\n\n#eval hMul 4 3 -- 12\n\n#eval hMul 4 #[2, 3, 4] -- #[8, 12, 16]\n------\nend Ex\n```\n\nThe parameters {leanRef}`α` and {leanRef}`β` are considered input parameters and {leanRef}`γ` an output one.\nGiven an application {leanRef}`hMul a b`, after the types of {leanRef}`a` and {leanRef}`b` are known, the type class\nsynthesizer is invoked, and the resulting type is obtained from the output parameter {leanRef}`γ`.\nIn the example above, we defined two instances. The first one is the homogeneous\nmultiplication for natural numbers. The second is the scalar multiplication for arrays.\nNote that you chain instances and generalize the second instance.\n\n```lean\nnamespace Ex\n------\nclass HMul (α : Type u) (β : Type v) (γ : outParam (Type w)) where\n hMul : α → β → γ\n\nexport HMul (hMul)\n\ninstance : HMul Nat Nat Nat where\n hMul := Nat.mul\n\ninstance : HMul Int Int Int where\n hMul := Int.mul\n\ninstance [HMul α β γ] : HMul α (Array β) (Array γ) where\n hMul a bs := bs.map (fun b => hMul a b)\n\n#eval hMul 4 3 -- 12\n\n#eval hMul 4 #[2, 3, 4] -- #[8, 12, 16]\n\n#eval hMul (-2) #[3, -1, 4] -- #[-6, 2, -8]\n\n#eval hMul 2 #[#[2, 3], #[0, 4]] -- #[#[4, 6], #[0, 8]]\n------\nend Ex\n```\n\nYou can use our new scalar array multiplication instance on arrays of type {leanRef}`Array β`\nwith a scalar of type {leanRef}`α` whenever you have an instance {leanRef}`HMul α β γ`.\nIn the last {kw}`#eval`, note that the instance was used twice on an array of arrays.\n\nOutput parameters are ignored during instance synthesis. Even when instance synthesis occurs in a\ncontext in which the values of output parameters are already determined, their values are ignored.\nOnce an instance is found using its input parameters, Lean ensures that the already-known values of\nthe output parameters match those which were found.\n\nLean also features {deftech}_semi-output parameters_, which have some features of input parameters\nand some features of output parameters. Like input parameters, semi-output parameters are considered\nwhen selecting instances. Like output parameters, they can be used to instantiate unknown values.\nHowever, they do not do so uniquely. Instance synthesis with semi-output parameters can be more difficult\nto predict, because the order in which instances are considered can determine which is selected, but it is\nalso more flexible.\n\n# Default Instances\n%%%\ntag := \"default-instances\"\n%%%\n\nIn the class {leanRef}`HMul`, the parameters {leanRef}`α` and {leanRef}`β` are treated as input values.\nThus, type class synthesis only starts after these two types are known. This may often\nbe too restrictive.\n\n```lean\nnamespace Ex\n------\nclass HMul (α : Type u) (β : Type v) (γ : outParam (Type w)) where\n hMul : α → β → γ\n\nexport HMul (hMul)\n\ninstance : HMul Int Int Int where\n hMul := Int.mul\n\ndef xs : List Int := [1, 2, 3]\n\n/--\nerror: typeclass instance problem is stuck\n HMul Int ?m.2 (?m.11 y)\n\nNote: Lean will not try to resolve this typeclass instance problem because the second type argument to `HMul` is a metavariable. This argument must be fully determined before Lean will try to resolve the typeclass.\n\nHint: Adding type annotations and supplying implicit arguments to functions can give Lean more information for typeclass resolution. For example, if you have a variable `x` that you intend to be a `Nat`, but Lean reports it as having an unresolved type like `?m`, replacing `x` with `(x : Nat)` can get typeclass resolution un-stuck.\n-/\n#guard_msgs (error) in\n#eval fun y => xs.map (fun x => hMul x y)\n------\nend Ex\n```\n\nThe instance {leanRef}`HMul` is not synthesized by Lean because the type of {leanRef}`y` has not been provided.\nHowever, it is natural to assume that the type of {leanRef}`y` and {leanRef}`x` should be the same in\nthis kind of situation. We can achieve exactly that using _default instances_.\n\n```lean\nnamespace Ex\n------\nclass HMul (α : Type u) (β : Type v) (γ : outParam (Type w)) where\n hMul : α → β → γ\n\nexport HMul (hMul)\n\n@[default_instance]\ninstance : HMul Int Int Int where\n hMul := Int.mul\n\ndef xs : List Int := [1, 2, 3]\n\n#check fun y => xs.map (fun x => hMul x y) -- fun y => List.map (fun x => hMul x y) xs : Int → List Int\n------\nend Ex\n```\n\n:::setup\n```\nvariable {α : Type u} {β : Type v} {γ : Type w} {a : α} {b : β} {n : Nat}\nvariable [HAdd α β γ] [HSub α β γ] [HMul α β γ] [HDiv α β γ] [HMod α β γ]\n```\nBy tagging the instance above with the attribute {attr}`[default_instance]`, we are instructing Lean\nto use this instance on pending type class synthesis problems.\nThe actual Lean implementation defines homogeneous and heterogeneous classes for arithmetical operators.\nMoreover, {lean}`a + b`, {lean}`a * b`, {lean}`a - b`, {lean}`a / b`, and {lean}`a % b` are notations for the heterogeneous versions.\nThe instance {lean}`OfNat Nat n` is the default instance (with priority 100) for the {lean}`OfNat` class. This is why the numeral\n{lean}`2` has type {lean}`Nat` when the expected type is not known. You can define default instances with higher\npriority to override the builtin ones.\n:::\n```lean\nstructure Rational where\n num : Int\n den : Nat\n inv : den ≠ 0\n\n@[default_instance 200]\ninstance : OfNat Rational n where\n ofNat := { num := n, den := 1, inv := by decide }\n\ninstance : ToString Rational where\n toString r := s!\"{r.num}/{r.den}\"\n\n#check 2 -- 2 : Rational\n```\n\n:::setup\n```\nvariable {α : Type u} {xs : List α} [Mul α] [OfNat α 2]\n```\n\nPriorities are also useful to control the interaction between different default instances.\nFor example, suppose {lean}`xs` has type {lean}`List α`. When elaborating {lean}`xs.map (fun x => 2 * x)`, we want the homogeneous instance for multiplication\nto have higher priority than the default instance for {lean}`OfNat α 2`. This is particularly important when we have implemented only the instance\n{lean}`HMul α α α`, and did not implement {lean}`HMul Nat α α`.\nNow, we reveal how the notation {lit}`a * b` is defined in Lean.\n:::\n```lean\nnamespace Ex\n------\nclass OfNat (α : Type u) (n : Nat) where\n ofNat : α\n\n@[default_instance]\ninstance (n : Nat) : OfNat Nat n where\n ofNat := n\n\nclass HMul (α : Type u) (β : Type v) (γ : outParam (Type w)) where\n hMul : α → β → γ\n\nclass Mul (α : Type u) where\n mul : α → α → α\n\n@[default_instance 10]\ninstance [Mul α] : HMul α α α where\n hMul a b := Mul.mul a b\n\ninfixl:70 \" * \" => HMul.hMul\n------\nend Ex\n```\n\nThe {leanRef}`Mul` class is convenient for types that only implement the homogeneous multiplication.\n\n# Local Instances\n%%%\ntag := \"local-instances\"\n%%%\n\nType classes are implemented using attributes in Lean. Thus, you can\nuse the {kw}`local` modifier to indicate that they only have effect until\nthe current {kw}`section` or {kw}`namespace` is closed, or until the end\nof the current file.\n\n```lean\nstructure Point where\n x : Nat\n y : Nat\n\nsection\n\nlocal instance : Add Point where\n add a b := { x := a.x + b.x, y := a.y + b.y }\n\ndef double (p : Point) :=\n p + p\n\nend -- instance `Add Point` is not active anymore\n\n/--\nerror: failed to synthesize\n HAdd Point Point ?m.5\n\nHint: Additional diagnostic information may be available using\nthe `set_option diagnostics true` command.\n-/\n#guard_msgs in\ndef triple (p : Point) :=\n p + p + p\n```\n\nYou can also temporarily disable an instance using the {kw}`attribute` command\nuntil the current {kw}`section` or {kw}`namespace` is closed, or until the end\nof the current file.\n\n```lean\nstructure Point where\n x : Nat\n y : Nat\n\ninstance addPoint : Add Point where\n add a b := { x := a.x + b.x, y := a.y + b.y }\n\ndef double (p : Point) :=\n p + p\n\nattribute [-instance] addPoint\n\n/--\nerror: failed to synthesize\n HAdd Point Point ?m.5\n\nHint: Additional diagnostic information may be available using\nthe `set_option diagnostics true` command.\n-/\n#guard_msgs in\ndef triple (p : Point) :=\n p + p + p -- Error: failed to synthesize instance\n```\n\nWe recommend you only use this command to diagnose problems.\n\n# Scoped Instances\n%%%\ntag := \"scoped-instances\"\n%%%\n\nYou can also declare scoped instances in namespaces. This kind of instance is\nonly active when you are inside of the namespace or open the namespace.\n\n```lean\nstructure Point where\n x : Nat\n y : Nat\n\nnamespace Point\n\nscoped instance : Add Point where\n add a b := { x := a.x + b.x, y := a.y + b.y }\n\ndef double (p : Point) :=\n p + p\n\nend Point\n-- instance `Add Point` is not active anymore\n\n/--\nerror: failed to synthesize\n HAdd Point Point ?m.3\n\nHint: Additional diagnostic information may be available using\nthe `set_option diagnostics true` command.\n-/\n#guard_msgs (error) in\n#check fun (p : Point) => p + p + p\n\nnamespace Point\n-- instance `Add Point` is active again\n#check fun (p : Point) => p + p + p\n\nend Point\n\nopen Point -- activates instance `Add Point`\n#check fun (p : Point) => p + p + p\n```\n\nYou can use the command {kw}`open scoped`{lit}` ` to activate scoped attributes but will\nnot “open” the names from the namespace.\n\n```lean\nstructure Point where\n x : Nat\n y : Nat\n\nnamespace Point\n\nscoped instance : Add Point where\n add a b := { x := a.x + b.x, y := a.y + b.y }\n\ndef double (p : Point) :=\n p + p\n\nend Point\n\nopen scoped Point -- activates instance `Add Point`\n#check fun (p : Point) => p + p + p\n\n/--\nerror: Unknown identifier `double`\n-/\n#guard_msgs (error) in\n#check fun (p : Point) => double p\n```\n\n# Decidable Propositions\n%%%\ntag := \"decidable-propositions\"\n%%%\n\nLet us consider another example of a type class defined in the\nstandard library, namely the type class of {lean}`Decidable`\npropositions. Roughly speaking, an element of {lean}`Prop` is said to be\ndecidable if we can decide whether it is true or false. The\ndistinction is only useful in constructive mathematics; classically,\nevery proposition is decidable. But if we use the classical principle,\nsay, to define a function by cases, that function will not be\ncomputable. Algorithmically speaking, the {lean}`Decidable` type class can\nbe used to infer a procedure that effectively determines whether or\nnot the proposition is true. As a result, the type class supports such\ncomputational definitions when they are possible while at the same\ntime allowing a smooth transition to the use of classical definitions\nand classical reasoning.\n\nIn the standard library, {lean}`Decidable` is defined formally as follows:\n\n```lean\nnamespace Hidden\n------\nclass inductive Decidable (p : Prop) where\n | isFalse (h : ¬p) : Decidable p\n | isTrue (h : p) : Decidable p\n------\nend Hidden\n```\n\n:::setup\n```\nvariable {p : Prop} (t : Decidable p) (t' : p ∨ ¬p) (a b : α)\n```\n\nLogically speaking, having an element {lean}`t : Decidable p` is stronger\nthan having an element {lean}`t' : p ∨ ¬p`; it enables us to define values\nof an arbitrary type depending on the truth value of {lean}`p`. For\nexample, for the expression {lean}`if p then a else b` to make sense, we\nneed to know that {lean}`p` is decidable. That expression is syntactic\nsugar for {lean}`ite p a b`, where {lean}`ite` is defined as follows:\n:::\n```lean\nnamespace Hidden\n------\ndef ite {α : Sort u}\n (c : Prop) [h : Decidable c]\n (t e : α) : α :=\n h.casesOn (motive := fun _ => α) (fun _ => e) (fun _ => t)\n------\nend Hidden\n```\n\n:::leanFirst\nThe standard library also contains a variant of {leanRef}`ite` called\n{leanRef}`dite`, the dependent if-then-else expression. It is defined as\nfollows:\n\n```lean\nnamespace Hidden\n------\ndef dite {α : Sort u}\n (c : Prop) [h : Decidable c]\n (t : c → α) (e : Not c → α) : α :=\n Decidable.casesOn (motive := fun _ => α) h e t\n------\nend Hidden\n```\n:::\n\n:::setup\n```\nvariable {c : Prop} [Decidable c] (t : c → α) (e : ¬c → α) (hc : c) (hnc : ¬c)\n```\n```lean (show := false)\nexample [Decidable c] (t e : α) : α := if h : c then t else e\n```\n\nThat is, in {lean}`dite c t e`, we can assume {lean}`hc : c` in the “then”\nbranch, and {lean}`hnc : ¬c` in the “else” branch. To make {lean}`dite` more\nconvenient to use, Lean allows us to write {leanRef}`if h : c then t else e`\ninstead of {lean}`dite c (fun h : c => t h) (fun h : ¬c => e h)`.\n:::\n\nWithout classical logic, we cannot prove that every proposition is\ndecidable. But we can prove that _certain_ propositions are\ndecidable. For example, we can prove the decidability of basic\noperations like equality and comparisons on the natural numbers and\nthe integers. Moreover, decidability is preserved under propositional\nconnectives:\n\n```lean\n#check @instDecidableAnd -- @instDecidableAnd : {p q : Prop} → [dp : Decidable p] → [dq : Decidable q] → Decidable (p ∧ q)\n\n#check @instDecidableOr\n#check @instDecidableNot\n```\n\nThus we can carry out definitions by cases on decidable predicates on\nthe natural numbers:\n\n```lean\ndef step (a b x : Nat) : Nat :=\n if x < a ∨ x > b then 0 else 1\n\nset_option pp.explicit true\n#print step\n```\n\nTurning on implicit arguments shows that the elaborator has inferred\nthe decidability of the proposition {leanRef}`x < a ∨ x > b`, simply by\napplying appropriate instances.\n\nWith the classical axioms, we can prove that every proposition is\ndecidable. You can import the classical axioms and make the generic\ninstance of decidability available by opening the {lit}`Classical` namespace.\n\n```lean\nopen Classical\n```\n\n:::setup\n```\nopen Classical\nvariable {p : Prop}\n```\nThereafter {lean}`Decidable p` has an instance for every {leanRef}`p`.\nThus all theorems in the library\nthat rely on decidability assumptions are freely available when you\nwant to reason classically. In {ref \"axioms-and-computation\"}[Axioms and Computation],\nwe will see that using the law of the\nexcluded middle to define functions can prevent them from being used\ncomputationally. Thus, the standard library assigns a low priority to\nthe {lean}`propDecidable` instance.\n:::\n\n```lean\nnamespace Hidden\n------\nopen Classical\nnoncomputable scoped\ninstance (priority := low) propDecidable (a : Prop) : Decidable a :=\n choice <| match em a with\n | Or.inl h => ⟨isTrue h⟩\n | Or.inr h => ⟨isFalse h⟩\n------\nend Hidden\n```\n\nThis guarantees that Lean will favor other instances and fall back on\n{leanRef}`propDecidable` only after other attempts to infer decidability have\nfailed.\n\nThe {lean}`Decidable` type class also provides a bit of small-scale\nautomation for proving theorems. The standard library introduces the\ntactic {tactic}`decide` that uses the {lean}`Decidable` instance to solve simple goals,\nas well as a function {name}`decide` that uses a {lean}`Decidable` instance to compute the\ncorresponding {lean}`Bool`.\n\n```lean\nexample : 10 < 5 ∨ 1 > 0 := by\n decide\n\nexample : ¬(True ∧ False) := by\n decide\n\nexample : 10 * 20 = 200 := by\n decide\n\ntheorem ex : True ∧ 2 = 1 + 1 := by\n decide\n\n#print ex\n\n#check @of_decide_eq_true -- @of_decide_eq_true : ∀ {p : Prop} [inst : Decidable p], decide p = true → p\n\n#check @decide -- decide : (p : Prop) → [h : Decidable p] → Bool\n```\n\n:::setup\n```\nvariable {p : Prop} [Decidable p]\n```\n\nThey work as follows. The expression {lean}`decide p` tries to infer a\ndecision procedure for {leanRef}`p`, and, if it is successful, evaluates to\neither {lean}`true` or {lean}`false`. In particular, if {leanRef}`p` is a true closed\nexpression, {leanRef}`decide p` will reduce definitionally to the Boolean {lean}`true`.\nOn the assumption that {lean}`decide p = true` holds, {lean}`of_decide_eq_true`\nproduces a proof of {lean}`p`. The tactic {tactic}`decide` puts it all together to\nprove a target {lean}`p`. By the previous observations,\n{tactic}`decide` will succeed any time the inferred decision procedure\n for {lean}`p` has enough information to evaluate, definitionally, to the {lean}`isTrue` case.\n:::\n\n# Managing Type Class Inference\n%%%\ntag := \"managing-type-class-inference\"\n%%%\n\nIf you are ever in a situation where you need to supply an expression\nthat Lean can infer by type class inference, you can ask Lean to carry\nout the inference using {name}`inferInstance`:\n\n```lean\ndef foo : Add Nat := inferInstance\ndef bar : Inhabited (Nat → Nat) := inferInstance\n\n#check @inferInstance -- @inferInstance : {α : Sort u_1} → [i : α] → α\n```\n\n:::setup\n```\nvariable (t : T)\n```\n\nIn fact, you can use Lean's {lean}`(t : T)` notation to specify the class whose instance you are looking for,\nin a concise manner:\n:::\n\n```lean\n#check (inferInstance : Add Nat)\n```\n\nYou can also use the auxiliary definition {lean}`inferInstanceAs`:\n\n```lean\n#check inferInstanceAs (Add Nat)\n\n#check @inferInstanceAs -- inferInstanceAs : (α : Sort u_1) → [i : α] → α\n```\n\n:::leanFirst\nSometimes Lean can't find an instance because the class is buried\nunder a definition. For example, Lean cannot\nfind an instance of {leanRef}`Inhabited (Set α)`. We can declare one\nexplicitly:\n\n```lean\ndef Set (α : Type u) := α → Prop\n\n/--\nerror: failed to synthesize\n Inhabited (Set α)\n\nHint: Additional diagnostic information may be available using\nthe `set_option diagnostics true` command.\n-/\n#guard_msgs in\nexample : Inhabited (Set α) :=\n inferInstance\n\ninstance : Inhabited (Set α) :=\n inferInstanceAs (Inhabited (α → Prop))\n```\n:::\n\nAt times, you may find that the type class inference fails to find an\nexpected instance, or, worse, falls into an infinite loop and times\nout. To help debug in these situations, Lean enables you to request a\ntrace of the search:\n\n```lean\nset_option trace.Meta.synthInstance true\n```\n\nIf you are using VS Code, you can read the results by hovering over\nthe relevant theorem or definition, or opening the messages window\nwith {kbd}[`Ctrl` `Shift` `Enter`].\n\nYou can also limit the search using the following options:\n\n```lean\nset_option synthInstance.maxHeartbeats 10000\nset_option synthInstance.maxSize 400\n```\n\nOption {option}`synthInstance.maxHeartbeats` specifies the maximum amount of\nheartbeats per typeclass resolution problem. A heartbeat is the number of\n(small) memory allocations (in thousands), 0 means there is no limit.\nOption {option}`synthInstance.maxSize` is the maximum number of instances used\nto construct a solution in the type class instance synthesis procedure.\n\nRemember also that in both the VS Code and Emacs editor modes, tab\ncompletion works in {kw}`set_option`, to help you find suitable options.\n\nAs noted above, the type class instances in a given context represent\na Prolog-like program, which gives rise to a backtracking search. Both\nthe efficiency of the program and the solutions that are found can\ndepend on the order in which the system tries the instance. Instances\nwhich are declared last are tried first. Moreover, if instances are\ndeclared in other modules, the order in which they are tried depends\non the order in which namespaces are opened. Instances declared in\nnamespaces which are opened later are tried earlier.\n\nYou can change the order that type class instances are tried by\nassigning them a _priority_. When an instance is declared, it is\nassigned a default priority value. You can assign other priorities\nwhen defining an instance. The following example illustrates how this\nis done:\n\n```lean\nclass Foo where\n a : Nat\n b : Nat\n\ninstance (priority := default + 1) i1 : Foo where\n a := 1\n b := 1\n\ninstance i2 : Foo where\n a := 2\n b := 2\n\nexample : Foo.a = 1 :=\n rfl\n\ninstance (priority := default + 2) i3 : Foo where\n a := 3\n b := 3\n\nexample : Foo.a = 3 :=\n rfl\n```\n\n# Coercions using Type Classes\n%%%\ntag := \"coercions-using-type-classes\"\n%%%\n\n:::setup\n```\nvariable {n : Nat} {α : Type u} {as : List α}\ndef Set (α : Type u) := α → Prop\n\n```\n\nThe most basic type of coercion maps elements of one type to another. For example, a coercion from {lean}`Nat` to {lean}`Int` allows us to view any element {lean}`n : Nat` as an element of {lean}`Int`. But some coercions depend on parameters; for example, for any type {lean}`α`, we can view any element {lean}`as : List α` as an element of {lean}`Set α`, namely, the set of elements occurring in the list. The corresponding coercion is defined on the “family” of types {lean}`List α`, parameterized by {lean}`α`.\n:::\n\nLean allows us to declare three kinds of coercions:\n\n- from a family of types to another family of types\n- from a family of types to the class of sorts\n- from a family of types to the class of function types\n\nThe first kind of coercion allows us to view any element of a member of the source family as an element of a corresponding member of the target family. The second kind of coercion allows us to view any element of a member of the source family as a type. The third kind of coercion allows us to view any element of the source family as a function. Let us consider each of these in turn.\n\n:::setup\n```\nvariable {α : Type u} {β : Type v} [Coe α β]\n```\n\nIn Lean, coercions are implemented on top of the type class resolution framework. We define a coercion from {lean}`α` to {lean}`β` by declaring an instance of {lean}`Coe α β`. For example, we can define a coercion from {lean}`Bool` to {lean}`Prop` as follows:\n\n```lean\ninstance : Coe Bool Prop where\n coe b := b = true\n```\n:::\n\nThis enables us to use boolean terms in {kw}`if`-{kw}`then`-{kw}`else` expressions:\n\n```lean\n#eval if true then 5 else 3\n\n#eval if false then 5 else 3\n```\n\n:::leanFirst\nWe can define a coercion from {leanRef}`List α` to {leanRef}`Set α` as follows:\n\n```lean\ndef Set (α : Type u) := α → Prop\ndef Set.empty {α : Type u} : Set α := fun _ => False\ndef Set.mem (a : α) (s : Set α) : Prop := s a\ndef Set.singleton (a : α) : Set α := fun x => x = a\ndef Set.union (a b : Set α) : Set α := fun x => a x ∨ b x\nnotation \"{ \" a \" }\" => Set.singleton a\ninfix:55 \" ∪ \" => Set.union\n------\ndef List.toSet : List α → Set α\n | [] => Set.empty\n | a::as => {a} ∪ as.toSet\n\ninstance : Coe (List α) (Set α) where\n coe a := a.toSet\n\ndef s : Set Nat := {1}\n\n#check s ∪ [2, 3] -- s ∪ [2, 3].toSet : Set Nat\n```\n:::\n\nWe can use the notation {lit}`↑` to force a coercion to be introduced in a particular place. It is also helpful to make our intent clear, and work around limitations of the coercion resolution system.\n\n```lean\ndef Set (α : Type u) := α → Prop\ndef Set.empty {α : Type u} : Set α := fun _ => False\ndef Set.mem (a : α) (s : Set α) : Prop := s a\ndef Set.singleton (a : α) : Set α := fun x => x = a\ndef Set.union (a b : Set α) : Set α := fun x => a x ∨ b x\nnotation \"{ \" a \" }\" => Set.singleton a\ninfix:55 \" ∪ \" => Set.union\ndef List.toSet : List α → Set α\n | [] => Set.empty\n | a::as => {a} ∪ as.toSet\ninstance : Coe (List α) (Set α) where\n coe a := a.toSet\n------\ndef s : Set Nat := {1}\n\n#check let x := ↑[2, 3]; s ∪ x -- let x := [2, 3].toSet; s ∪ x : Set Nat\n\n#check let x := [2, 3]; s ∪ x -- let x := [2, 3]; s ∪ x.toSet : Set Nat\n```\n\n\nLean also supports dependent coercions using the type class {lean}`CoeDep`. For example, we cannot coerce arbitrary propositions to {lean}`Bool`, only the ones that implement the {lean}`Decidable` typeclass.\n\n```lean\ninstance (p : Prop) [Decidable p] : CoeDep Prop p Bool where\n coe := decide p\n```\n\nLean will also chain (non-dependent) coercions as necessary. Actually, the type class {lean}`CoeT` is the transitive closure of {lean}`Coe`.\n\nLet us now consider the second kind of coercion. By the _class of sorts_, we mean the collection of universes {lean}`Type u`. A coercion of the second kind is of the form:\n\n```\n c : (x1 : A1) → ... → (xn : An) → F x1 ... xn → Type u\n```\n\nwhere {lit}`F` is a family of types as above. This allows us to write {lit}`s : t` whenever {lit}`t` is of type {lit}`F a₁ ... aₙ`. In other words, the coercion allows us to view the elements of {lit}`F a₁ ... aₙ` as types. This is very useful when defining algebraic structures in which one component, the carrier of the structure, is a {lean}`Type`. For example, we can define a semigroup as follows:\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\n\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\n```\n\n:::setup\n\n```\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\n\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\n\nvariable {S : Semigroup} (a b : S.carrier)\n\ninstance : CoeSort Semigroup (Type u) where\n coe s := s.carrier\nuniverse u\n```\nIn other words, a semigroup consists of a type, {leanRef}`carrier`, and a multiplication, {leanRef}`mul`, with the property that the multiplication is associative. The {kw}`instance` command allows us to write {lean}`a * b` instead of {lean}`Semigroup.mul S a b` whenever we have {lean}`a b : S.carrier`; notice that Lean can infer the argument {leanRef}`S` from the types of {leanRef}`a` and {leanRef}`b`. The function {lean}`Semigroup.carrier` maps the class {leanRef}`Semigroup` to the sort {leanRef}`Type u`:\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\n------\n#check Semigroup.carrier -- Semigroup.carrier.{u} (self : Semigroup) : Type u\n```\n\nIf we declare this function to be a coercion, then whenever we have a semigroup {lean}`S : Semigroup`, we can write {lean}`a : S` instead of {lean}`a : S.carrier`:\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\n------\ninstance : CoeSort Semigroup (Type u) where\n coe s := s.carrier\n\nexample (S : Semigroup) (a b c : S) : (a * b) * c = a * (b * c) :=\n Semigroup.mul_assoc _ a b c\n```\n\nIt is the coercion that makes it possible to write {leanRef}`(a b c : S)`. Note that, we define an instance of {leanRef}`CoeSort Semigroup (Type u)` instead of {lean}`Coe Semigroup (Type u)`.\n\n:::\n\n::::setup\n```\nvariable (B : Type u) (C : Type v)\n\n```\n\nBy the _class of function types_, we mean the collection of Pi types {lean}`(z : B) → C`. The third kind of coercion has the form:\n\n```\n c : (x₁ : A₁) → ... → (xₙ : Aₙ) → (y : F x₁ ... xₙ) → (z : B) → C\n```\n\n:::leanFirst\nwhere {lit}`F` is again a family of types and {lit}`B` and {lit}`C` can depend on {lit}`x₁, ..., xₙ, y`. This makes it possible to write {lit}`t s` whenever {lit}`t` is an element of {lit}`F a₁ ... aₙ`. In other words, the coercion enables us to view elements of {lit}`F a₁ ... aₙ` as functions. Continuing the example above, we can define the notion of a morphism between semigroups {leanRef}`S1` and {leanRef}`S2`. That is, a function from the carrier of {leanRef}`S1` to the carrier of {leanRef}`S2` (note the implicit coercion) that respects the multiplication. The projection {leanRef}`Morphism.mor` takes a morphism to the underlying function:\n\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\ninstance : CoeSort Semigroup (Type u) where\n coe s := s.carrier\n------\nstructure Morphism (S1 S2 : Semigroup) where\n mor : S1 → S2\n resp_mul : ∀ a b : S1, mor (a * b) = (mor a) * (mor b)\n\n#check @Morphism.mor\n```\n:::\n\nAs a result, it is a prime candidate for the third type of coercion.\n::::\n\n```lean\nstructure Semigroup where\n carrier : Type u\n mul : carrier → carrier → carrier\n mul_assoc (a b c : carrier) : mul (mul a b) c = mul a (mul b c)\ninstance (S : Semigroup) : Mul S.carrier where\n mul a b := S.mul a b\ninstance : CoeSort Semigroup (Type u) where\n coe s := s.carrier\nstructure Morphism (S1 S2 : Semigroup) where\n mor : S1 → S2\n resp_mul : ∀ a b : S1, mor (a * b) = (mor a) * (mor b)\n------\ninstance (S1 S2 : Semigroup) :\n CoeFun (Morphism S1 S2) (fun _ => S1 → S2) where\n coe m := m.mor\n\ntheorem resp_mul {S1 S2 : Semigroup} (f : Morphism S1 S2) (a b : S1)\n : f (a * b) = f a * f b :=\n f.resp_mul a b\n\nexample (S1 S2 : Semigroup) (f : Morphism S1 S2) (a : S1) :\n f (a * a * a) = f a * f a * f a :=\n calc f (a * a * a)\n _ = f (a * a) * f a := by rw [resp_mul f]\n _ = f a * f a * f a := by rw [resp_mul f]\n```\n\nWith the coercion in place, we can write {leanRef}`f (a * a * a)` instead of {leanRef}`f.mor (a * a * a)`. When the {leanRef}`Morphism`, {leanRef}`f`, is used where a function is expected, Lean inserts the coercion. Similar to {lean}`CoeSort`, we have yet another class {lean}`CoeFun` for this class of coercions. The parameter {lit}`γ` is used to specify the function type we are coercing to. This type may depend on the type we are coercing from.\n"
},
{
"path": "book/TPiL.lean",
"content": "import VersoManual\nimport TPiL.Intro\nimport TPiL.DependentTypeTheory\nimport TPiL.PropositionsAndProofs\nimport TPiL.QuantifiersEquality\nimport TPiL.Tactics\nimport TPiL.InteractingWithLean\nimport TPiL.InductiveTypes\nimport TPiL.InductionAndRecursion\nimport TPiL.StructuresAndRecords\nimport TPiL.TypeClasses\nimport TPiL.Conv\nimport TPiL.AxiomsComputation\n\nopen Verso.Genre Manual\nopen Verso Code External\n\nopen Verso Doc Elab in\nopen Lean (quote) in\n@[role_expander versionString]\ndef versionString : RoleExpander\n | #[], #[] => do\n let version ← IO.FS.readFile \"../examples/lean-toolchain\"\n let version := version.dropPrefix \"leanprover/lean4:\" |>.dropPrefix \"v\" |>.trimAscii |>.copy\n pure #[← ``(Verso.Doc.Inline.code $(quote version))]\n | _, _ => throwError \"Unexpected arguments\"\n\n\n#doc (Manual) \"Theorem Proving in Lean 4\" =>\n\n%%%\nauthors := [\"Jeremy Avigad\", \"Leonardo de Moura\", \"Soonho Kong\", \"Sebastian Ullrich\"]\nauthorshipNote := some \"with contributions from the Lean Community\"\n%%%\n\n\nThis version of the text assumes you’re using Lean 4 (specifically {versionString}[]). See the\n[Quickstart section](https://lean-lang.org/documentation/setup/) of\nthe Lean documentation to install Lean. The first version of this book was\nwritten for Lean 2, and the Lean 3 version is available\n[here](https://leanprover.github.io/theorem_proving_in_lean/).\n\n{include 1 TPiL.Intro}\n\n{include 1 TPiL.DependentTypeTheory}\n\n{include 1 TPiL.PropositionsAndProofs}\n\n{include 1 TPiL.QuantifiersEquality}\n\n{include 1 TPiL.Tactics}\n\n{include 1 TPiL.InteractingWithLean}\n\n{include 1 TPiL.InductiveTypes}\n\n{include 1 TPiL.InductionAndRecursion}\n\n{include 1 TPiL.StructuresAndRecords}\n\n{include 1 TPiL.TypeClasses}\n\n{include 1 TPiL.Conv}\n\n{include 1 TPiL.AxiomsComputation}\n"
},
{
"path": "book/lake-manifest.json",
"content": "{\"version\": \"1.1.0\",\n \"packagesDir\": \".lake/packages\",\n \"packages\":\n [{\"url\": \"https://github.com/leanprover/verso.git\",\n \"type\": \"git\",\n \"subDir\": null,\n \"scope\": \"\",\n \"rev\": \"ea44a4d919a4570055bf53171ea4d8a8919cde84\",\n \"name\": \"verso\",\n \"manifestFile\": \"lake-manifest.json\",\n \"inputRev\": \"main\",\n \"inherited\": false,\n \"configFile\": \"lakefile.lean\"},\n {\"url\": \"https://github.com/leanprover-community/plausible\",\n \"type\": \"git\",\n \"subDir\": null,\n \"scope\": \"\",\n \"rev\": \"160af9e8e7d4ae448f3c92edcc5b6a8522453f11\",\n \"name\": \"plausible\",\n \"manifestFile\": \"lake-manifest.json\",\n \"inputRev\": \"main\",\n \"inherited\": true,\n \"configFile\": \"lakefile.toml\"},\n {\"url\": \"https://github.com/acmepjz/md4lean\",\n \"type\": \"git\",\n \"subDir\": null,\n \"scope\": \"\",\n \"rev\": \"38ac5945d744903ffcc473ce1030223991b11cf6\",\n \"name\": \"MD4Lean\",\n \"manifestFile\": \"lake-manifest.json\",\n \"inputRev\": \"main\",\n \"inherited\": true,\n \"configFile\": \"lakefile.lean\"},\n {\"url\": \"https://github.com/leanprover/subverso\",\n \"type\": \"git\",\n \"subDir\": null,\n \"scope\": \"\",\n \"rev\": \"eb77622e97e942ba2cfe02f60637705fc2d9481b\",\n \"name\": \"subverso\",\n \"manifestFile\": \"lake-manifest.json\",\n \"inputRev\": \"main\",\n \"inherited\": true,\n \"configFile\": \"lakefile.lean\"}],\n \"name\": \"tpil\",\n \"lakeDir\": \".lake\"}\n"
},
{
"path": "book/lakefile.toml",
"content": "name = \"tpil\"\nversion = \"0.1.0\"\ndefaultTargets = [\"tpil\"]\n\n[[require]]\nname = \"verso\"\ngit = \"https://github.com/leanprover/verso.git\"\nrev = \"main\"\n\n\n[leanOptions]\n#weak.verso.examples.suggest = true\nweak.linter.typography.quotes = true\nweak.linter.typography.dashes = true\nweak.linter.verso.manual.headerTags = true\n\n[[lean_lib]]\nname = \"TPiL\"\n\n[[lean_exe]]\nname = \"tpil\"\nroot = \"Main\"\n"
},
{
"path": "book/lean-toolchain",
"content": "leanprover/lean4:v4.27.0-rc1\n"
},
{
"path": "book/static/fonts/noto-sans-mono/OFL.txt",
"content": "Copyright 2022 The Noto Project Authors (https://github.com/notofonts/latin-greek-cyrillic)\r\n\r\nThis Font Software is licensed under the SIL Open Font License, Version 1.1.\r\nThis license is copied below, and is also available with a FAQ at:\r\nhttps://openfontlicense.org\r\n\r\n\r\n-----------------------------------------------------------\r\nSIL OPEN FONT LICENSE Version 1.1 - 26 February 2007\r\n-----------------------------------------------------------\r\n\r\nPREAMBLE\r\nThe goals of the Open Font License (OFL) are to stimulate worldwide\r\ndevelopment of collaborative font projects, to support the font creation\r\nefforts of academic and linguistic communities, and to provide a free and\r\nopen framework in which fonts may be shared and improved in partnership\r\nwith others.\r\n\r\nThe OFL allows the licensed fonts to be used, studied, modified and\r\nredistributed freely as long as they are not sold by themselves. The\r\nfonts, including any derivative works, can be bundled, embedded, \r\nredistributed and/or sold with any software provided that any reserved\r\nnames are not used by derivative works. The fonts and derivatives,\r\nhowever, cannot be released under any other type of license. The\r\nrequirement for fonts to remain under this license does not apply\r\nto any document created using the fonts or their derivatives.\r\n\r\nDEFINITIONS\r\n\"Font Software\" refers to the set of files released by the Copyright\r\nHolder(s) under this license and clearly marked as such. This may\r\ninclude source files, build scripts and documentation.\r\n\r\n\"Reserved Font Name\" refers to any names specified as such after the\r\ncopyright statement(s).\r\n\r\n\"Original Version\" refers to the collection of Font Software components as\r\ndistributed by the Copyright Holder(s).\r\n\r\n\"Modified Version\" refers to any derivative made by adding to, deleting,\r\nor substituting -- in part or in whole -- any of the components of the\r\nOriginal Version, by changing formats or by porting the Font Software to a\r\nnew environment.\r\n\r\n\"Author\" refers to any designer, engineer, programmer, technical\r\nwriter or other person who contributed to the Font Software.\r\n\r\nPERMISSION & CONDITIONS\r\nPermission is hereby granted, free of charge, to any person obtaining\r\na copy of the Font Software, to use, study, copy, merge, embed, modify,\r\nredistribute, and sell modified and unmodified copies of the Font\r\nSoftware, subject to the following conditions:\r\n\r\n1) Neither the Font Software nor any of its individual components,\r\nin Original or Modified Versions, may be sold by itself.\r\n\r\n2) Original or Modified Versions of the Font Software may be bundled,\r\nredistributed and/or sold with any software, provided that each copy\r\ncontains the above copyright notice and this license. These can be\r\nincluded either as stand-alone text files, human-readable headers or\r\nin the appropriate machine-readable metadata fields within text or\r\nbinary files as long as those fields can be easily viewed by the user.\r\n\r\n3) No Modified Version of the Font Software may use the Reserved Font\r\nName(s) unless explicit written permission is granted by the corresponding\r\nCopyright Holder. This restriction only applies to the primary font name as\r\npresented to the users.\r\n\r\n4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font\r\nSoftware shall not be used to promote, endorse or advertise any\r\nModified Version, except to acknowledge the contribution(s) of the\r\nCopyright Holder(s) and the Author(s) or with their explicit written\r\npermission.\r\n\r\n5) The Font Software, modified or unmodified, in part or in whole,\r\nmust be distributed entirely under this license, and must not be\r\ndistributed under any other license. The requirement for fonts to\r\nremain under this license does not apply to any document created\r\nusing the Font Software.\r\n\r\nTERMINATION\r\nThis license becomes null and void if any of the above conditions are\r\nnot met.\r\n\r\nDISCLAIMER\r\nTHE FONT SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,\r\nEXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF\r\nMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT\r\nOF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE\r\nCOPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,\r\nINCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL\r\nDAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\r\nFROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM\r\nOTHER DEALINGS IN THE FONT SOFTWARE.\r\n"
},
{
"path": "book/static/fonts/noto-sans-mono/noto-sans-mono.css",
"content": "@font-face {\n font-family: 'Noto Sans Mono';\n font-style: normal;\n font-display: swap;\n font-weight: 100 900;\n src: url('./NotoSansMono-VariableFont_wdth,wght.ttf') format('truetype');\n unicode-range: U+207a-207F, U+208a-208f, U+2090-209c;\n}\n\n@font-face {\n font-family: 'Noto Sans Mono';\n font-style: italic;\n font-display: swap;\n font-weight: 100 900;\n src: url('./NotoSansMono-VariableFont_wdth,wght.ttf') format('truetype');\n unicode-range: U+207a-207F, U+208a-208f, U+2090-209c;\n}"
},
{
"path": "book/static/fonts/source-code-pro/LICENSE.md",
"content": "© 2023 Adobe (http://www.adobe.com/), with Reserved Font Name 'Source'. All Rights Reserved. Source is a trademark of Adobe in the United States and/or other countries.\r\n\r\nThis Font Software is licensed under the SIL Open Font License, Version 1.1.\r\n\r\nThis license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL\r\n\r\n\r\n-----------------------------------------------------------\r\nSIL OPEN FONT LICENSE Version 1.1 - 26 February 2007\r\n-----------------------------------------------------------\r\n\r\nPREAMBLE\r\nThe goals of the Open Font License (OFL) are to stimulate worldwide\r\ndevelopment of collaborative font projects, to support the font creation\r\nefforts of academic and linguistic communities, and to provide a free and\r\nopen framework in which fonts may be shared and improved in partnership\r\nwith others.\r\n\r\nThe OFL allows the licensed fonts to be used, studied, modified and\r\nredistributed freely as long as they are not sold by themselves. The\r\nfonts, including any derivative works, can be bundled, embedded,\r\nredistributed and/or sold with any software provided that any reserved\r\nnames are not used by derivative works. The fonts and derivatives,\r\nhowever, cannot be released under any other type of license. The\r\nrequirement for fonts to remain under this license does not apply\r\nto any document created using the fonts or their derivatives.\r\n\r\nDEFINITIONS\r\n\"Font Software\" refers to the set of files released by the Copyright\r\nHolder(s) under this license and clearly marked as such. This may\r\ninclude source files, build scripts and documentation.\r\n\r\n\"Reserved Font Name\" refers to any names specified as such after the\r\ncopyright statement(s).\r\n\r\n\"Original Version\" refers to the collection of Font Software components as\r\ndistributed by the Copyright Holder(s).\r\n\r\n\"Modified Version\" refers to any derivative made by adding to, deleting,\r\nor substituting -- in part or in whole -- any of the components of the\r\nOriginal Version, by changing formats or by porting the Font Software to a\r\nnew environment.\r\n\r\n\"Author\" refers to any designer, engineer, programmer, technical\r\nwriter or other person who contributed to the Font Software.\r\n\r\nPERMISSION & CONDITIONS\r\nPermission is hereby granted, free of charge, to any person obtaining\r\na copy of the Font Software, to use, study, copy, merge, embed, modify,\r\nredistribute, and sell modified and unmodified copies of the Font\r\nSoftware, subject to the following conditions:\r\n\r\n1) Neither the Font Software nor any of its individual components,\r\nin Original or Modified Versions, may be sold by itself.\r\n\r\n2) Original or Modified Versions of the Font Software may be bundled,\r\nredistributed and/or sold with any software, provided that each copy\r\ncontains the above copyright notice and this license. These can be\r\nincluded either as stand-alone text files, human-readable headers or\r\nin the appropriate machine-readable metadata fields within text or\r\nbinary files as long as those fields can be easily viewed by the user.\r\n\r\n3) No Modified Version of the Font Software may use the Reserved Font\r\nName(s) unless explicit written permission is granted by the corresponding\r\nCopyright Holder. This restriction only applies to the primary font name as\r\npresented to the users.\r\n\r\n4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font\r\nSoftware shall not be used to promote, endorse or advertise any\r\nModified Version, except to acknowledge the contribution(s) of the\r\nCopyright Holder(s) and the Author(s) or with their explicit written\r\npermission.\r\n\r\n5) The Font Software, modified or unmodified, in part or in whole,\r\nmust be distributed entirely under this license, and must not be\r\ndistributed under any other license. The requirement for fonts to\r\nremain under this license does not apply to any document created\r\nusing the Font Software.\r\n\r\nTERMINATION\r\nThis license becomes null and void if any of the above conditions are\r\nnot met.\r\n\r\nDISCLAIMER\r\nTHE FONT SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,\r\nEXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF\r\nMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT\r\nOF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE\r\nCOPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,\r\nINCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL\r\nDAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\r\nFROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM\r\nOTHER DEALINGS IN THE FONT SOFTWARE.\r\n"
},
{
"path": "book/static/fonts/source-code-pro/source-code-pro.css",
"content": "@font-face{\n font-family: 'Source Code Pro';\n font-weight: 200;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-ExtraLight.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-ExtraLight.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-ExtraLight.otf') format('opentype'),\n url('./TTF/SourceCodePro-ExtraLight.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 200;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-ExtraLightIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-ExtraLightIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-ExtraLightIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-ExtraLightIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 300;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Light.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Light.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Light.otf') format('opentype'),\n url('./TTF/SourceCodePro-Light.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 300;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-LightIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-LightIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-LightIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-LightIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 400;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Regular.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Regular.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Regular.otf') format('opentype'),\n url('./TTF/SourceCodePro-Regular.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 400;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-It.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-It.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-It.otf') format('opentype'),\n url('./TTF/SourceCodePro-It.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 500;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Medium.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Medium.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Medium.otf') format('opentype'),\n url('./TTF/SourceCodePro-Medium.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 500;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-MediumIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-MediumIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-MediumIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-MediumIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 600;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Semibold.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Semibold.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Semibold.otf') format('opentype'),\n url('./TTF/SourceCodePro-Semibold.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 600;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-SemiboldIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-SemiboldIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-SemiboldIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-SemiboldIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 700;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Bold.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Bold.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Bold.otf') format('opentype'),\n url('./TTF/SourceCodePro-Bold.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 700;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-BoldIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-BoldIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-BoldIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-BoldIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 900;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-Black.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-Black.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-Black.otf') format('opentype'),\n url('./TTF/SourceCodePro-Black.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Code Pro';\n font-weight: 900;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceCodePro-BlackIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceCodePro-BlackIt.otf.woff') format('woff'),\n url('./OTF/SourceCodePro-BlackIt.otf') format('opentype'),\n url('./TTF/SourceCodePro-BlackIt.ttf') format('truetype');\n}\n"
},
{
"path": "book/static/fonts/source-sans/LICENSE.md",
"content": "Copyright 2010-2024 Adobe (http://www.adobe.com/), with Reserved Font Name 'Source'. All Rights Reserved. Source is a trademark of Adobe in the United States and/or other countries.\n\nThis Font Software is licensed under the SIL Open Font License, Version 1.1.\n\nThis license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL\n\n\n-----------------------------------------------------------\nSIL OPEN FONT LICENSE Version 1.1 - 26 February 2007\n-----------------------------------------------------------\n\nPREAMBLE\nThe goals of the Open Font License (OFL) are to stimulate worldwide\ndevelopment of collaborative font projects, to support the font creation\nefforts of academic and linguistic communities, and to provide a free and\nopen framework in which fonts may be shared and improved in partnership\nwith others.\n\nThe OFL allows the licensed fonts to be used, studied, modified and\nredistributed freely as long as they are not sold by themselves. The\nfonts, including any derivative works, can be bundled, embedded, \nredistributed and/or sold with any software provided that any reserved\nnames are not used by derivative works. The fonts and derivatives,\nhowever, cannot be released under any other type of license. The\nrequirement for fonts to remain under this license does not apply\nto any document created using the fonts or their derivatives.\n\nDEFINITIONS\n\"Font Software\" refers to the set of files released by the Copyright\nHolder(s) under this license and clearly marked as such. This may\ninclude source files, build scripts and documentation.\n\n\"Reserved Font Name\" refers to any names specified as such after the\ncopyright statement(s).\n\n\"Original Version\" refers to the collection of Font Software components as\ndistributed by the Copyright Holder(s).\n\n\"Modified Version\" refers to any derivative made by adding to, deleting,\nor substituting -- in part or in whole -- any of the components of the\nOriginal Version, by changing formats or by porting the Font Software to a\nnew environment.\n\n\"Author\" refers to any designer, engineer, programmer, technical\nwriter or other person who contributed to the Font Software.\n\nPERMISSION & CONDITIONS\nPermission is hereby granted, free of charge, to any person obtaining\na copy of the Font Software, to use, study, copy, merge, embed, modify,\nredistribute, and sell modified and unmodified copies of the Font\nSoftware, subject to the following conditions:\n\n1) Neither the Font Software nor any of its individual components,\nin Original or Modified Versions, may be sold by itself.\n\n2) Original or Modified Versions of the Font Software may be bundled,\nredistributed and/or sold with any software, provided that each copy\ncontains the above copyright notice and this license. These can be\nincluded either as stand-alone text files, human-readable headers or\nin the appropriate machine-readable metadata fields within text or\nbinary files as long as those fields can be easily viewed by the user.\n\n3) No Modified Version of the Font Software may use the Reserved Font\nName(s) unless explicit written permission is granted by the corresponding\nCopyright Holder. This restriction only applies to the primary font name as\npresented to the users.\n\n4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font\nSoftware shall not be used to promote, endorse or advertise any\nModified Version, except to acknowledge the contribution(s) of the\nCopyright Holder(s) and the Author(s) or with their explicit written\npermission.\n\n5) The Font Software, modified or unmodified, in part or in whole,\nmust be distributed entirely under this license, and must not be\ndistributed under any other license. The requirement for fonts to\nremain under this license does not apply to any document created\nusing the Font Software.\n\nTERMINATION\nThis license becomes null and void if any of the above conditions are\nnot met.\n\nDISCLAIMER\nTHE FONT SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,\nEXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF\nMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT\nOF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE\nCOPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,\nINCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL\nDAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\nFROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM\nOTHER DEALINGS IN THE FONT SOFTWARE.\n"
},
{
"path": "book/static/fonts/source-sans/source-sans-3.css",
"content": "@font-face{\n font-family: 'Source Sans 3';\n font-weight: 200;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-ExtraLight.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-ExtraLight.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 200;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-ExtraLightIt.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-ExtraLightIt.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 300;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-Light.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-Light.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 300;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-LightIt.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-LightIt.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 400;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-Regular.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-Regular.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 400;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-It.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-It.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 600;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-Semibold.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-Semibold.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 600;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-SemiboldIt.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-SemiboldIt.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 700;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-Bold.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-Bold.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 700;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-BoldIt.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-BoldIt.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 900;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-Black.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-Black.otf.woff') format('woff');\n}\n\n@font-face{\n font-family: 'Source Sans 3';\n font-weight: 900;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/TTF/SourceSans3-BlackIt.ttf.woff2') format('woff2'),\n url('WOFF/OTF/SourceSans3-BlackIt.otf.woff') format('woff');\n}\n"
},
{
"path": "book/static/fonts/source-sans/source-sans-3VF.css",
"content": "@font-face{\n font-family: 'Source Sans 3 VF';\n font-weight: 200 900;\n font-style: normal;\n font-stretch: normal;\n src: url('WOFF2/VF/SourceSans3VF-Upright.ttf.woff2') format('woff2-variations'),\n url('WOFF/VF/SourceSans3VF-Upright.ttf.woff') format('woff-variations'),\n url('VF/SourceSans3VF-Upright.ttf') format('truetype-variations');\n}\n\n@font-face{\n font-family: 'Source Sans 3 VF';\n font-weight: 200 900;\n font-style: italic;\n font-stretch: normal;\n src: url('WOFF2/VF/SourceSans3VF-Italic.ttf.woff2') format('woff2-variations'),\n url('WOFF/VF/SourceSans3VF-Italic.ttf.woff') format('woff-variations'),\n url('VF/SourceSans3VF-Italic.ttf') format('truetype-variations');\n}\n"
},
{
"path": "book/static/fonts/source-serif/LICENSE.md",
"content": "Copyright 2014 - 2023 Adobe (http://www.adobe.com/), with Reserved Font Name ‘Source’. All Rights Reserved. Source is a trademark of Adobe in the United States and/or other countries.\n\nThis Font Software is licensed under the SIL Open Font License, Version 1.1.\n\nThis license is copied below, and is also available with a FAQ at: http://scripts.sil.org/OFL\n\n\n-----------------------------------------------------------\nSIL OPEN FONT LICENSE Version 1.1 - 26 February 2007\n-----------------------------------------------------------\n\nPREAMBLE\nThe goals of the Open Font License (OFL) are to stimulate worldwide\ndevelopment of collaborative font projects, to support the font creation\nefforts of academic and linguistic communities, and to provide a free and\nopen framework in which fonts may be shared and improved in partnership\nwith others.\n\nThe OFL allows the licensed fonts to be used, studied, modified and\nredistributed freely as long as they are not sold by themselves. The\nfonts, including any derivative works, can be bundled, embedded,\nredistributed and/or sold with any software provided that any reserved\nnames are not used by derivative works. The fonts and derivatives,\nhowever, cannot be released under any other type of license. The\nrequirement for fonts to remain under this license does not apply\nto any document created using the fonts or their derivatives.\n\nDEFINITIONS\n\"Font Software\" refers to the set of files released by the Copyright\nHolder(s) under this license and clearly marked as such. This may\ninclude source files, build scripts and documentation.\n\n\"Reserved Font Name\" refers to any names specified as such after the\ncopyright statement(s).\n\n\"Original Version\" refers to the collection of Font Software components as\ndistributed by the Copyright Holder(s).\n\n\"Modified Version\" refers to any derivative made by adding to, deleting,\nor substituting -- in part or in whole -- any of the components of the\nOriginal Version, by changing formats or by porting the Font Software to a\nnew environment.\n\n\"Author\" refers to any designer, engineer, programmer, technical\nwriter or other person who contributed to the Font Software.\n\nPERMISSION & CONDITIONS\nPermission is hereby granted, free of charge, to any person obtaining\na copy of the Font Software, to use, study, copy, merge, embed, modify,\nredistribute, and sell modified and unmodified copies of the Font\nSoftware, subject to the following conditions:\n\n1) Neither the Font Software nor any of its individual components,\nin Original or Modified Versions, may be sold by itself.\n\n2) Original or Modified Versions of the Font Software may be bundled,\nredistributed and/or sold with any software, provided that each copy\ncontains the above copyright notice and this license. These can be\nincluded either as stand-alone text files, human-readable headers or\nin the appropriate machine-readable metadata fields within text or\nbinary files as long as those fields can be easily viewed by the user.\n\n3) No Modified Version of the Font Software may use the Reserved Font\nName(s) unless explicit written permission is granted by the corresponding\nCopyright Holder. This restriction only applies to the primary font name as\npresented to the users.\n\n4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font\nSoftware shall not be used to promote, endorse or advertise any\nModified Version, except to acknowledge the contribution(s) of the\nCopyright Holder(s) and the Author(s) or with their explicit written\npermission.\n\n5) The Font Software, modified or unmodified, in part or in whole,\nmust be distributed entirely under this license, and must not be\ndistributed under any other license. The requirement for fonts to\nremain under this license does not apply to any document created\nusing the Font Software.\n\nTERMINATION\nThis license becomes null and void if any of the above conditions are\nnot met.\n\nDISCLAIMER\nTHE FONT SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND,\nEXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF\nMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT\nOF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE\nCOPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,\nINCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL\nDAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING\nFROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM\nOTHER DEALINGS IN THE FONT SOFTWARE.\n"
},
{
"path": "book/static/fonts/source-serif/source-serif-text.css",
"content": "@font-face{\n font-family: 'Source Serif';\n font-weight: 200;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-ExtraLight.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-ExtraLight.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-ExtraLight.otf') format('opentype'),\n url('./TTF/SourceSerif4-ExtraLight.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 200;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-ExtraLightIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-ExtraLightIt.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-ExtraLightIt.otf') format('opentype'),\n url('./TTF/SourceSerif4-ExtraLightIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 300;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-Light.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-Light.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-Light.otf') format('opentype'),\n url('./TTF/SourceSerif4-Light.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 300;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-LightIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-LightIt.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-LightIt.otf') format('opentype'),\n url('./TTF/SourceSerif4-LightIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 400;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-Regular.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-Regular.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-Regular.otf') format('opentype'),\n url('./TTF/SourceSerif4-Regular.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 400;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-It.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-It.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-It.otf') format('opentype'),\n url('./TTF/SourceSerif4-It.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 600;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-Semibold.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-Semibold.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-Semibold.otf') format('opentype'),\n url('./TTF/SourceSerif4-Semibold.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 600;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-SemiboldIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-SemiboldIt.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-SemiboldIt.otf') format('opentype'),\n url('./TTF/SourceSerif4-SemiboldIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 700;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-Bold.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-Bold.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-Bold.otf') format('opentype'),\n url('./TTF/SourceSerif4-Bold.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 700;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-BoldIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-BoldIt.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-BoldIt.otf') format('opentype'),\n url('./TTF/SourceSerif4-BoldIt.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 900;\n font-display: swap;\n font-style: normal;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-Black.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-Black.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-Black.otf') format('opentype'),\n url('./TTF/SourceSerif4-Black.ttf') format('truetype');\n}\n\n@font-face{\n font-family: 'Source Serif';\n font-weight: 900;\n font-display: swap;\n font-style: italic;\n font-stretch: normal;\n src: url('./WOFF2/TTF/SourceSerif4-BlackIt.ttf.woff2') format('woff2'),\n url('./WOFF/OTF/SourceSerif4-BlackIt.otf.woff') format('woff'),\n url('./OTF/SourceSerif4-BlackIt.otf') format('opentype'),\n url('./TTF/SourceSerif4-BlackIt.ttf') format('truetype');\n}\n"
},
{
"path": "book/static/theme.css",
"content": ":root {\n --verso-structure-font-family: \"Source Sans 3\",\"Helvetica Neue\",\"Segoe UI\",\"Roboto\",Arial,sans-serif;\n --verso-text-font-family: \"Source Sans 3\",\"Helvetica Neue\",\"Segoe UI\",\"Roboto\",Arial,sans-serif;\n --verso-code-font-family: \"Source Code Pro\",\"Noto Sans Mono\",monospace;\n --verso-selected-color: #def;\n}\n\n.eval-steps > *:not(:last-child):after {\n content: \"⇒\";\n display: block;\n padding-left: 1rem;\n font-size: 150%;\n}\n\n\n.hl.lean .keyword.token {\n font-weight: 600 !important;\n}\n\n\n.error pre, .information pre, .warning pre,\n.error code, .information code, .warning code {\n overflow-x: auto;\n margin: 0px;\n}\n\n.information pre, .error pre, .warning pre,\n.information code, .error code, .warning code {\n margin: 0.5em .85em;\n border-left: 0.2em solid red;\n padding: 0 0.45em;\n}\n\n/* Different color for warning */\n.warning pre, .warning code {\n border-color: var(--verso-warning-color);\n}\n\n/* Different color for information */\n.information pre, .information code {\n border-color: #0000c0;\n}\n\n/* TODO: fix upstream */\n.hl.lean code {\n font-family: var(--verso-code-font-family) !important;\n}\n\n\n#toc .split-toc > ol > li {\n margin-bottom: 0.2rem;\n}\n\n#toc .split-toc > ol .tactic-name {\n font-weight: 600;\n}\n\n.def-technical-term:target {\n background-color: var(--verso-selected-color);\n outline: auto;\n}\n\ntable.tabular {\n border-collapse: collapse;\n}\n\n.tabular thead th {\n background-color: #f8f9fa;\n font-weight: 600;\n text-align: left;\n padding: 12px 16px;\n border-bottom: 2px solid #dee2e6;\n color: #495057;\n}\n\n.tabular td {\n padding: 10px 16px;\n border-bottom: 1px solid #e9ecef;\n vertical-align: top;\n}\n\n\n/* Alternating row colors */\n.tabular tbody tr:nth-child(even) {\n background-color: #f8f9fa;\n}\n\n.tabular tbody tr:nth-child(odd) {\n background-color: #ffffff;\n}\n\n/* Subtle hover effect */\n.tabular tbody tr:hover {\n background-color: #e3f2fd;\n}\n\n\n/********/\n\np {\n font-feature-settings: \"calt\" off;\n}\n"
},
{
"path": "book/verso-sources.json",
"content": "{\n \"version\": 0,\n \"sources\": {\n \"manual\": {\n \"root\": \"https://lean-lang.org/doc/reference/4.26.0/\",\n \"updateFrequency\": \"manual\",\n \"shortName\": \"ref\",\n \"longName\": \"Lean Language Reference\"\n }\n }\n}\n"
},
{
"path": "examples/.gitignore",
"content": "/.lake\nExamples/*.json\nExamples/*.lean\n"
},
{
"path": "examples/Examples/Basic.lean",
"content": "def hello := \"world\"\n"
},
{
"path": "examples/Examples.lean",
"content": "-- This module serves as the root of the `Examples` library.\n-- Import modules here that should be built as part of the library.\nimport Examples.Basic\n\n\nexample (g : Nat → Nat → Nat)\n (h₁ : ∀ x, x ≠ 0 → g x x = 1)\n (h₂ : x ≠ 0)\n : g x x + x = 1 + x := by\n conv =>\n lhs\n -- ⊢ g x x + x\n arg 1\n -- ⊢ g x x\n rw [h₁]\n -- 2 goals: ⊢ 1, ⊢ x ≠ 0\n . skip\n . tactic =>\n exact h₂\n"
},
{
"path": "examples/lake-manifest.json",
"content": "{\"version\": \"1.1.0\",\n \"packagesDir\": \".lake/packages\",\n \"packages\":\n [{\"url\": \"https://github.com/leanprover/subverso.git\",\n \"type\": \"git\",\n \"subDir\": null,\n \"scope\": \"\",\n \"rev\": \"eb77622e97e942ba2cfe02f60637705fc2d9481b\",\n \"name\": \"subverso\",\n \"manifestFile\": \"lake-manifest.json\",\n \"inputRev\": \"main\",\n \"inherited\": false,\n \"configFile\": \"lakefile.lean\"}],\n \"name\": \"«tpil-examples»\",\n \"lakeDir\": \".lake\"}\n"
},
{
"path": "examples/lakefile.toml",
"content": "name = \"tpil-examples\"\nversion = \"0.1.0\"\ndefaultTargets = [\"Examples\"]\n\n[[require]]\nname = \"subverso\"\ngit = \"https://github.com/leanprover/subverso.git\"\nrev = \"main\"\n\n[[lean_lib]]\nname = \"Examples\"\n"
},
{
"path": "examples/lean-toolchain",
"content": "leanprover/lean4:v4.26.0\n"
},
{
"path": "unixode.sty",
"content": "% ------------------------------------------------------------------------------\n% (C) 2012-2013 Olivier Verdier \n% Unixode Package\n% XeTeX Unicode character definitions\n% ------------------------------------------------------------------------------\n\\NeedsTeXFormat{LaTeX2e}\n\\ProvidesPackage{unixode}[2012/05/10]\n\n\\RequirePackage{ifxetex}\n\n\\ifxetex\n%\\RequirePackage{mathspec}\n%\\RequirePackage{fontspec}\n\\defaultfontfeatures{Ligatures=TeX}\n\\usepackage{newunicodechar}\n\\newunicodechar{α}{\\ensuremath{\\mathrm{\\alpha}}}\n\\newunicodechar{β}{\\ensuremath{\\mathrm{\\beta}}}\n\\newunicodechar{γ}{\\ensuremath{\\mathrm{\\gamma}}}\n\\newunicodechar{δ}{\\ensuremath{\\mathrm{\\delta}}}\n\\newunicodechar{ε}{\\ensuremath{\\mathrm{\\varepsilon}}}\n\\newunicodechar{ζ}{\\ensuremath{\\mathrm{\\zeta}}}\n\\newunicodechar{η}{\\ensuremath{\\mathrm{\\eta}}}\n\\newunicodechar{θ}{\\ensuremath{\\mathrm{\\theta}}}\n\\newunicodechar{ι}{\\ensuremath{\\mathrm{\\iota}}}\n\\newunicodechar{κ}{\\ensuremath{\\mathrm{\\kappa}}}\n\\newunicodechar{λ}{\\ensuremath{\\mathrm{\\lambda}}}\n\\newunicodechar{μ}{\\ensuremath{\\mathrm{\\mu}}}\n\\newunicodechar{ν}{\\ensuremath{\\mathrm{\\nu}}}\n\\newunicodechar{ξ}{\\ensuremath{\\mathrm{\\xi}}}\n\\newunicodechar{π}{\\ensuremath{\\mathrm{\\mathnormal{\\pi}}}}\n\\newunicodechar{ρ}{\\ensuremath{\\mathrm{\\rho}}}\n\\newunicodechar{σ}{\\ensuremath{\\mathrm{\\sigma}}}\n\\newunicodechar{τ}{\\ensuremath{\\mathrm{\\tau}}}\n\\newunicodechar{φ}{\\ensuremath{\\mathrm{\\varphi}}}\n\\newunicodechar{χ}{\\ensuremath{\\mathrm{\\chi}}}\n\\newunicodechar{ψ}{\\ensuremath{\\mathrm{\\psi}}}\n\\newunicodechar{ω}{\\ensuremath{\\mathrm{\\omega}}}\n\n\\newunicodechar{Γ}{\\ensuremath{\\mathrm{\\Gamma}}}\n\\newunicodechar{Δ}{\\ensuremath{\\mathrm{\\Delta}}}\n\\newunicodechar{Θ}{\\ensuremath{\\mathrm{\\Theta}}}\n\\newunicodechar{Λ}{\\ensuremath{\\mathrm{\\Lambda}}}\n\\newunicodechar{Σ}{\\ensuremath{\\Sigma}}\n\\newunicodechar{Φ}{\\ensuremath{\\mathrm{\\Phi}}}\n\\newunicodechar{Ξ}{\\ensuremath{\\mathrm{\\Xi}}}\n\\newunicodechar{Ψ}{\\ensuremath{\\mathrm{\\Psi}}}\n\\newunicodechar{Ω}{\\ensuremath{\\mathrm{\\Omega}}}\n\n\\newunicodechar{ℵ}{\\ensuremath{\\aleph}}\n\n\\newunicodechar{≤}{\\ensuremath{\\leq}}\n\\newunicodechar{≥}{\\ensuremath{\\geq}}\n\\newunicodechar{≠}{\\ensuremath{\\neq}}\n\\newunicodechar{≈}{\\ensuremath{\\approx}}\n\\newunicodechar{≡}{\\ensuremath{\\equiv}}\n\\newunicodechar{≃}{\\ensuremath{\\simeq}}\n\\newunicodechar{≺}{\\ensuremath{\\prec}}\n\\newunicodechar{≼}{\\ensuremath{\\preceq}}\n\n\\newunicodechar{≤}{\\ensuremath{\\leq}}\n\\newunicodechar{≥}{\\ensuremath{\\geq}}\n\n\\newunicodechar{∂}{\\ensuremath{\\partial}}\n\\newunicodechar{∆}{\\ensuremath{\\triangle}} % or \\laplace?\n\n\\newunicodechar{∫}{\\ensuremath{\\int}}\n\\newunicodechar{∑}{\\ensuremath{\\mathrm{\\Sigma}}}\n\\newunicodechar{Π}{\\ensuremath{\\Pi}}\n\n\\newunicodechar{⊥}{\\ensuremath{\\perp}}\n\\newunicodechar{∞}{\\ensuremath{\\infty}}\n\\newunicodechar{∂}{\\ensuremath{\\partial}}\n\n\\newunicodechar{∓}{\\ensuremath{\\mp}}\n\\newunicodechar{±}{\\ensuremath{\\pm}}\n\\newunicodechar{×}{\\ensuremath{\\times}}\n\n\\newunicodechar{⊕}{\\ensuremath{\\oplus}}\n\\newunicodechar{⊗}{\\ensuremath{\\otimes}}\n\\newunicodechar{⊞}{\\ensuremath{\\boxplus}}\n\n\\newunicodechar{∇}{\\ensuremath{\\nabla}}\n\\newunicodechar{√}{\\ensuremath{\\sqrt}}\n\n\\newunicodechar{⬝}{\\ensuremath{\\cdot}}\n\\newunicodechar{•}{\\ensuremath{\\cdot}}\n\\newunicodechar{∘}{\\ensuremath{\\circ}}\n\n\\newunicodechar{⁻}{\\ensuremath{^{\\textup{\\kern1pt\\rule{2pt}{0.3pt}\\kern-1pt}}}}\n\\newunicodechar{▸}{\\ensuremath{\\blacktriangleright}}\n\n\\newunicodechar{∧}{\\ensuremath{\\wedge}}\n\\newunicodechar{∨}{\\ensuremath{\\vee}}\n\\newunicodechar{¬}{\\ensuremath{\\neg}}\n\\newunicodechar{⊢}{\\ensuremath{\\vdash}}\n\n%\\newunicodechar{⟨}{\\ensuremath{\\left\\langle}}\n%\\newunicodechar{⟩}{\\ensuremath{\\right\\rangle}}\n\\newunicodechar{⟨}{\\ensuremath{\\langle}}\n\\newunicodechar{⟩}{\\ensuremath{\\rangle}}\n\n\\newunicodechar{∀}{\\ensuremath{\\forall}}\n\\newunicodechar{∃}{\\ensuremath{\\exists}}\n\n\\newunicodechar{↦}{\\ensuremath{\\mapsto}}\n\\newunicodechar{→}{\\ensuremath{\\rightarrow}}\n\\newunicodechar{↔}{\\ensuremath{\\leftrightarrow}}\n\\newunicodechar{⇒}{\\ensuremath{\\Rightarrow}}\n\\newunicodechar{⟹}{\\ensuremath{\\Longrightarrow}}\n\\newunicodechar{⇐}{\\ensuremath{\\Leftarrow}}\n\\newunicodechar{⟸}{\\ensuremath{\\Longleftarrow}}\n\n\\newunicodechar{∩}{\\ensuremath{\\cap}}\n\\newunicodechar{∪}{\\ensuremath{\\cup}}\n\\newunicodechar{⊂}{\\ensuremath{\\subseteq}}\n\\newunicodechar{⊆}{\\ensuremath{\\subseteq}}\n\\newunicodechar{⊄}{\\ensuremath{\\nsubseteq}}\n\\newunicodechar{⊈}{\\ensuremath{\\nsubseteq}}\n\\newunicodechar{⊃}{\\ensuremath{\\supseteq}}\n\\newunicodechar{⊇}{\\ensuremath{\\supseteq}}\n\\newunicodechar{⊅}{\\ensuremath{\\nsupseteq}}\n\\newunicodechar{⊉}{\\ensuremath{\\nsupseteq}}\n\\newunicodechar{∈}{\\ensuremath{\\in}}\n\\newunicodechar{∉}{\\ensuremath{\\notin}}\n\\newunicodechar{∋}{\\ensuremath{\\ni}}\n\\newunicodechar{∌}{\\ensuremath{\\notni}}\n\\newunicodechar{∅}{\\ensuremath{\\emptyset}}\n\n\\newunicodechar{∖}{\\ensuremath{\\setminus}}\n\\newunicodechar{†}{\\ensuremath{\\dag}}\n\n\\newunicodechar{ℕ}{\\ensuremath{\\mathbb{N}}}\n\\newunicodechar{ℤ}{\\ensuremath{\\mathbb{Z}}}\n\\newunicodechar{ℝ}{\\ensuremath{\\mathbb{R}}}\n\\newunicodechar{ℚ}{\\ensuremath{\\mathbb{Q}}}\n\\newunicodechar{ℂ}{\\ensuremath{\\mathbb{C}}}\n\\newunicodechar{⌞}{\\ensuremath{\\llcorner}}\n\\newunicodechar{⌟}{\\ensuremath{\\lrcorner}}\n\\newunicodechar{⦃}{\\ensuremath{\\{\\!|}}\n\\newunicodechar{⦄}{\\ensuremath{|\\!\\}}}\n\\newunicodechar{∣}{\\ensuremath{\\mid}}\n\\newunicodechar{∥}{\\ensuremath{\\parallel}}\n\n\\newunicodechar{₁}{\\ensuremath{_1}}\n\\newunicodechar{₂}{\\ensuremath{_2}}\n\\newunicodechar{₃}{\\ensuremath{_3}}\n\\newunicodechar{₄}{\\ensuremath{_4}}\n\\newunicodechar{₅}{\\ensuremath{_5}}\n\\newunicodechar{₆}{\\ensuremath{_6}}\n\\newunicodechar{₇}{\\ensuremath{_7}}\n\\newunicodechar{₈}{\\ensuremath{_8}}\n\\newunicodechar{₉}{\\ensuremath{_9}}\n\\newunicodechar{₀}{\\ensuremath{_0}}\n\\newunicodechar{ᵢ}{\\ensuremath{_i}}\n\\newunicodechar{ⱼ}{\\ensuremath{_j}}\n\\newunicodechar{ₘ}{\\ensuremath{_m}}\n\\newunicodechar{ₙ}{\\ensuremath{_n}}\n\\newunicodechar{ᵤ}{\\ensuremath{_u}}\n\\newunicodechar{↑}{\\ensuremath{\\uparrow}}\n\\newunicodechar{↓}{\\ensuremath{\\downarrow}}\n\\else\n\\usepackage[utf8x]{inputenc}\n\\SetUnicodeOption{mathletters}\n\\DeclareUnicodeCharacter{952}{\\ensuremath{\\theta}}\n\\fi\n"
}
]