2025 11 23 https://kaierikniermann.github.io/notes/001a/ 001a /notes/001a/ Blog posts 2025 11 23 https://kaierikniermann.github.io/notes/001b/ 001b /notes/001b/ Understanding recursors with Lean4 Blog 2025 11 23 The recursor for natural numbers Before we define recursors, let's first introduce the idea of an inductive type. We'll do this by examining how lean defines natural numbers. inductive Nat where | zero : Nat | succ (n : Nat) : Nat 2025 11 23 The recursor for natural numbers Before we define recursors, let's first introduce the idea of an inductive type. We'll do this by examining how lean defines natural numbers. inductive Nat where | zero : Nat | succ (n : Nat) : Nat The idea here being that we can construct natural numbers by either using the constructor zero to get 0, or by applying the constructor succ to an existing natural number to get its successor. For example, we can construct 3 as follows: def three : Nat := Nat.succ (Nat.succ (Nat.succ Nat.zero)) We can equivalently express this definition using the type formation and term introduction rules: While this explanation for inductive types usually gives most people I think enough intuition to understand the basic notions of how to use them to construct something like natural numbers, I think it kind of misses the deeper idea of what an inductive type and by extension a recursor really is. To attempt to explain this we'll take a look into some categorical semantics behind inductive types. 20251123https://kaierikniermann.github.io/notes/001c/001c/notes/001c/Natural Number Object (NNO)Definition We assume that is a category with a terminal object . This category has a natural number object (NNO) if there exists an object together with two morphisms: such that, given any global element and any morphism , there exists a unique morphism such that the following diagram commutes: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> While at first this definition seems a bit needlessly abstract, it actually captures what the inductive type of natural numbers really is. The basic thing to recognize is that the two morphisms (just think of them as functions for now) in reality don't have anything to do with natural numbers directly. Instead, they act as a kind of blueprint for how we can use the properties or constraints of natural numbers to make anything. Here on a high level we can describe the two functions / constructors as follows: - The represents the abstract idea of having some starting point or base case. Within natural numbers this is represented by 0, but in reality it denotes an abstract concept of having a starting point. - This represents the abstract idea of being able to build upon existing things to create new things. Within natural numbers this is represented by the successor function. Now this might quite fairly still seem a bit confusing and abstract. How can we use properties to make anything?. To describe this more formally lets constrain ourselves to the category of sets, . If you are unfamiliar with category theory it's sufficient to think of this as just a collection of all kinds of sets and functions between them. 20251123https://kaierikniermann.github.io/notes/001e/001e/notes/001e/Natural Number Object (NNO) in SetExample In the category Set, the natural number object (NNO) can be represented by the set of natural numbers . If we take some arbitrary other set with some point (which can be identified with an element of ) and some function , we can define a unique function as follows: So in plain English what this is saying is that given any set where we have some starting point and some way of building upon existing elements of (the function ), we can use the properties of natural numbers to create a unique function that maps natural numbers to elements of in a way that respects our starting point and building function. A natural next question to have might be But what does it mean to respect the starting point and building function? Here I'd fast say intuitively you can just imagine construct which has some notion of a start and some way of building upon existing things. For example let's imagine the following graph: Clearly here with have: Starting point: Our start here is the node . Building function: Our building function i.e. successor mechanism here is just following the arrows to the next node. So our two morphisms then are: where maps to . where maps each node to the next node along the arrow. That is f(a) = b f(b) = c f(c) = d f(d) = e ... Creating a minimal replica of this in Lean we could do something like: inductive Node where | start : Node -- this will play the role of “a” | next : Node → Node def succNode (v : Node) : Node := Node. next v def natToNode : ℕ → Node | 0 => Node.start | n + 1 => succNode (natToNode n) So we can see our function here is represented by natToNode. Where the function maps 0 to a and each successor natural number to the next node along the arrow. Something you might notice here is that if our natToNode function is replaced by just an identity, i.e.: def natToNat : ℕ → ℕ | 0 => 0 | n + 1 => n + 1 Then we get just the natural numbers themselves as defined by their properties. This is precisely what's expressed by the earlier commutative diagram we say. The two arrows: Are just the natural numbers defined by their properties. So in a sense the natural numbers are the most basic instantiation of their own properties. So now a fair thing to wonder is: So what does this have to do with recursers? Well the key insight here is that our functions natToNat and natToNode both are our recursers for the natural numbers. A recursor is just a function that allows us to define functions out of an inductive type by specifying how to handle each constructor of the inductive type. So equivalently we can express our recursor for natural numbers as: def recNat {C : Type} (z : C) (s : C → C) : ℕ → C | 0 => z | n + 1 => s (recNat z s n) If we examine the actual type signature generated by #check Nat.rec we have: «Nat».rec.{u} {motive : ℕ → Sort u} (zero : motive «Nat».zero) (succ : (n : ℕ) → motive n → motive n.succ) (t : ℕ) : motive t In our examples above we can see that the motive is just the type we are mapping to (either or ), the zero is our starting point (either 0 or a) and the succ is our building function (either the successor function or following the arrows). So using the recursor we can rewrite our earlier natToNat and natToNode functions as: def natToNat : ℕ → ℕ := Nat.rec 0 -- | 0 => 0 (fun n => n + 1) -- | n + 1 => n + 1 def natToNode : ℕ → Node := Nat.rec Node.start -- | 0 => Node.start (fun n => succNode n) -- | n + 1 => succNode (natToNode n) This for the most part covers the basic idea of recursors for the sake of brevity I won't go into more instances of recursors for other inductive types though conceptually they work the same way. You specify how to handle each constructor of the inductive type and the recursor gives you a function that maps from the inductive type to whatever type you specified. 2025 11 23 The connection to induction A very important property of recursors emerges when we make the motive dependent. To elaborate on what that means let's first consider the situation of simple stepwise induction. 2025 11 23 https://kaierikniermann.github.io/notes/001f/ 001f /notes/001f/ Stepwise (Mathematical) Induction Definition Stepwise (mathematical/natural/ordinary) induction is a proof technique used to establish the truth of a statement for all natural numbers . The process involves two main steps: Base Case: Prove that the statement is true. Inductive Step: Assume that the statement is true for some arbitrary natural number (this assumption is called the inductive hypothesis). Then, using this assumption, prove that the statement is also true. If both the base case and the inductive step are successfully proven, we can conclude that the statement holds for all natural numbers . The concise formulation of this can be given by the induction principle. Something we can notice here just by superficial observation alone is that this seems to look an awful lot like the recursor for natural numbers we defined earlier. In fact, it is an application of the recursor for natural numbers for the dependent motive . To make this a little more concrete let's define a simple property over natural numbers: def P (n : ℕ) : Prop := n + 0 = n Now its important to note that in an abstract sense this is no different from any other function from natural numbers to some type. The dependency comes into play when we try to use the recursor i.e. the properties of naturals with this motive. def natToProp (n : ℕ) : (P n) := Nat.rec (motive := P) (by simp [P]) -- base case: P 0 (fun n ih => by simp [P]) -- inductive step: P n → P (n+1) n A few things we can observe here: The recursor here represents a dependent function, which is to say that the return type of the function depends on the input value. Contrasting this to the earlier case where the return type was always just or . Base case - Importantly here as opposed to providing a function that returns some value of type for the base case, we instead provide a proof that the property holds. Inductive step - Similarly for the inductive step we provide a function that takes an arbitrary natural number and a proof that holds (the inductive hypothesis) and returns a proof that holds. If we view this through the lens of the Curry-Howard correspondence it quite nicely illustrates how our proof here is just a program which constructs witnesses (valid proofs) for each natural number that the property holds. In the same way that our earlier recursor provided elements on the correct type, this dependent recursor provides proofs on the correct property. As this application of a recursor to a proposition represents said proposition being true for all natural numbers, we can equivalently use this within a theorem. theorem add_zero (n : ℕ) : n + 0 = n := natToProp n 2025 11 23 Case Study: Evaluating arithmetic expressions As a little kind of case study I want to give an example of an inductive type (and its recursor) that most people become familiar with; in a sense; as early as primary school: the operational semantics of binary operators. We'll start by defining some basic syntax for arithmetic expressions: inductive BinOp where | add : BinOp | sub : BinOp | mul : BinOp | div : BinOp inductive Expr where | const : ℕ → Expr | binop : BinOp → Expr → Expr → Expr So here we have defined a simple language of arithmetic expressions consisting of natural number constants and binary operations. This provides us with the means to construct expressions like: #check Expr.binop BinOp.add (Expr.const 10) (Expr.const 20) If we want to actually define the semantics of how to evaluate these expressions we'll need to define a set of rewrite rules that describe how we can take an expression and reduce it to a value i.e. evaluate it. To evaluate an expression we want to traverse the expression tree and whenever we encounter a binary operation with two constant operands we want to apply the operation and replace the entire sub-expression with the resulting constant. We express this as 3 rewrite rules: Left Evaluation: If the left operand of a binary operation can be reduced, then we reduce it. Right Evaluation: If the left operand is a constant and the right operand can be reduced, then we reduce the right operand. Operation Evaluation: If both operands are constants, we apply the binary operation and replace the entire sub-expression with the resulting constant. def eval_op : BinOp → (Nat → Nat → Nat) | .add => Nat.add | .sub => Nat.sub | .mul => Nat.mul | .div => Nat.div inductive Step : Expr -> Expr -> Prop | ST_BinOp1 (op : BinOp) (e₁ e₁' e₂ : Expr) (h : Step e₁ e₁') : Step (Expr.binop op e₁ e₂) (Expr.binop op e₁' e₂) | ST_BinOp2 (op : BinOp) (v₁ : Nat) (e₂ e₂' : Expr) (h : Step e₂ e₂') : Step (Expr.binop op (Expr.const v₁) e₂) (Expr.binop op (Expr.const v₁) e₂') | ST_BinOpConst (op : BinOp) (v₁ v₂ : Nat) : Step (Expr.binop op (Expr.const v₁) (Expr.const v₂)) (Expr.const (eval_op op v₁ v₂)) Since expressions can naturally require multiple evaluations steps it makes sense to define a multistep evaluation relation as the reflexive transitive closure of the single step evaluation relation defined above. This we can define as: abbrev MultiStep := Relation.ReflTransGen Step -- helper notation to express multi-step evaluation notation:50 e " ->ⁿ " e' => MultiStep e e' Let's also define a small helper syntax and macro to make it easier to write arithmetic expressions: 20251123A small arithmetic expression grammar declare_syntax_cat arithTm -- atoms syntax num : arithTm syntax "(" arithTm ")" : arithTm -- multiplicative level (higher precedence) syntax:70 arithTm:70 "*" arithTm:71 : arithTm syntax:70 arithTm:70 "/" arithTm:71 : arithTm -- additive level (lower precedence) syntax:60 arithTm:60 "+" arithTm:61 : arithTm syntax:60 arithTm:60 "-" arithTm:61 : arithTm syntax "ex{" arithTm "}" : term macro_rules -- numerals | `(ex{ $n:num }) => `(Expr.const $n) -- parentheses | `(ex{ ($t:arithTm) }) => `(ex{$t}) -- addition | `(ex{ $e₁:arithTm + $e₂:arithTm }) => `(Expr.binop BinOp.add (ex{$e₁}) (ex{$e₂})) -- subtraction | `(ex{ $e₁:arithTm - $e₂:arithTm }) => `(Expr.binop BinOp.sub (ex{$e₁}) (ex{$e₂})) -- multiplication | `(ex{ $e₁:arithTm * $e₂:arithTm }) => `(Expr.binop BinOp.mul (ex{$e₁}) (ex{$e₂})) -- division | `(ex{ $e₁:arithTm / $e₂:arithTm }) => `(Expr.binop BinOp.div (ex{$e₁}) (ex{$e₂})) 20251123Describing arithmetic evaluation Now say that we wanted to evaluate the expression on a high level what we would do is rewrite the multiplication to and then rewrite that to . Expressing this in lean we have: example : -- ((2 * 3) + 4) ->ⁿ 10 ex{ ((2 * 3) + 4) } ->ⁿ ex{ 10 } := .trans (rw_lhs (rw_const .mul 2 3)) (rw_const .add 6 4) Here we say that the expression after multiple steps evaluates to by first rewriting the left-hand side multiplication to and then rewriting that to . And we chain these operations together using the .trans constructor of the multistep evaluation relation. Now the question becomes, how do we define these rewrite steps? Intuitively we can imagine evaluation as being described by the following sort of graph +(lhs [op] rhs) | +-+(rw_lhs) ->ⁿ lhs' [op] rhs (1) reduce lhs some number of steps | +-+(rw_rhs) ->ⁿ lhs [op] rhs' (2) reduce rhs some number of steps | +- (rw_const) -> value (3) reduce both to a constant value The idea of each rule being that: rw_lhs: If the left-hand side can be reduced some number of steps we can reduce it while keeping the right-hand side the same. This corresponds to the ST_BinOp1 rule defined earlier. rw_rhs: If the left-hand side is a constant we can reduce the right-hand side some number of steps while keeping the left-hand side the same. This corresponds to the ST_BinOp2 rule defined earlier. rw_const: If both sides are constants we can apply the binary operation and reduce the entire expression to a single constant value. This corresponds to the ST_BinOpConst rule defined earlier. As these rules are defined over the structure of multistep evaluation our implementation of them will naturally be in terms of the inductive structure of a multistep relationship: lemma rw_lhs (lhs_rw : lhs ->ⁿ lhs') : (lhs [op] rhs) ->ⁿ (lhs' [op] rhs) := match lhs_rw with | .refl => .refl | .tail S₁ S₂ => (rw_lhs S₁).tail (.ST_BinOp1 S₂) lemma rw_rhs (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := match rhs_rw with | .refl => .refl | .tail S₁ S₂ => (rw_rhs S₁).tail (.ST_BinOp2 S₂) lemma rw_const (op : BinOp) (lhs rhs : Nat) : ((.const lhs) [op] (.const rhs)) ->ⁿ .const (eval_op op lhs rhs) := .single (.ST_BinOpConst op lhs rhs) Alternatively we can specify the left and right rewrite rules using the recursor or or head induction principle for multistep evaluation: lemma rw_rhs' (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := .rec (refl := .refl) (tail := by intro _ _ _ hcb ih exact ih.tail (.ST_BinOp2 hcb) ) rhs_rw lemma rw_rhs'' (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := .head_induction_on (refl := .refl) (head := by intro _ _ hac _ ih exact ih.head (.ST_BinOp2 hac) ) rhs_rw The motive function here is inferred by Lean via the Lemma, which allos us to avoid having to explicitly specify it. Other than this we can see that the recursors again simply correspond to providing methods to describe what to do for each of the constructors. 20251123Recursors describe usage So at this point you might, I think fairly ask yourself: Wait why are you spending so much time on this random example for recursors? The main reason is that to me it provides one of the most grounded direct examples of what it means for a recursor function to eliminate a term of an inductive type. In general in type theory we say that term elimination represents the natural deduction rules for how to use terms of a given type. Applied to our example we can see that these recursors precisely correspond to the rules of how we evaluate i.e. use arithmetic expressions. Each rewrite rule describes how we can take an expression and reduce it step by step until we reach a final value. So in a sense the recursor here eliminates the expression by providing a systematic way to break it down into its constituent parts and evaluate it. This is precisely the essence of what recursors do in type theory; they provide a way to systematically deconstruct and utilize terms of inductive types according to their defined structure and properties. 20251123Proving correct evaluation One of the wonderful things we then naturally get from these recursors is that we can use them to describe how a correct evaluation works. So given our evaluation function: @[simp] def eval : Expr -> Nat | Expr.const n => n | Expr.binop op e₁ e₂ => let v₁ := eval e₁ let v₂ := eval e₂ eval_op op v₁ v₂ We can use the recursors describing the rewrite rules to show that this evaluation function for our expressions both yields a constant and that we have some sequence of reduction steps (application of rewrite rules) to get to said constant. Or expressed formally: (e : Expr) : -- for any expression e (∃ v : Nat), -- there exists a value v (eval e = v) ∧ (e ->ⁿ (.const v)) -- such that eval e = v and e reduces to the constant v The proof of this statement works by induction on the structure of the expression e if our expression represents a constant then the proof is trivial as we can just take the value of the constant itself. If our expression represents a binary operation then same as we showed for the concrete example we just apply our recursors to first rewrite the lhs, then the rhs and finally apply the operation to get the final constant value. In full the proof looks like: theorem eval_correct (e : Expr) : ∃ v : Nat, (eval e = v) ∧ (e ->ⁿ (.const v)) := by induction e with | const n => exists n | binop op lhs rhs eval_lhs eval_rhs => rcases eval_lhs with ⟨lhs_v, ⟨rhs_is_v, lhs_rw⟩⟩ rcases eval_rhs with ⟨rhs_v, ⟨lhs_is_v, rhs_rw⟩⟩ simp [rhs_is_v, lhs_is_v] exact (rw_lhs lhs_rw).trans ( (rw_rhs rhs_rw).trans ( rw_const op lhs_v rhs_v ) ) In other words our proof for describing that our evaluation function is correct amounts to essentially simulating or describing quite literally how the evaluation works step by step using the recursors we defined earlier. To see precisely how rcases works here I'd recommend to paste the code into a Lean environment and examine the types of each of the intermediate values. 2025 11 28 https://kaierikniermann.github.io/notes/002r/ 002r /notes/002r/ Type universes in Lean4 Blog 2025 11 28 A brief overview 2025 11 28 Universe hierarchy In Lean4, types are organized into a hierarchy of universes (also referred to as sorts). Each universe is associated with a level, which is a natural number. The operator constructs a universe from a given level. To avoid things like Girard's paradox, Lean4 employs a stratified type system where each universe can only contain types from lower universes, we have the following hierarchy (1): has two main aliases used in Lean4: and . Here, (which is equivalent to ) is the universe of logical propositions, while (which is equivalent to ) represents a universe of types at level . So we can say: In general we can express the hierarchy for any universe level as follows: 2025 11 28 Predicative universes Except propositions, a type in a universe at level cannot quantify over types from strictly larger universes unless the whole result is lifted to a larger universe. In the case of types we have: To demonstrate some valid instance of this inference rule lets consider the following lean examples: example (α : Type 1) (β : Type 2) : Type 2 := α → β example (α : Type 2) (β : Type 1) : Type 2 := α → β Both of the above examples are valid because the resulting type is lifted to the maximum universe level of the input types. In general, we say that the behavior of the universes is called predicative meaning that objects may not be defined in terms of quantifiers ranging over that same object. 2025 11 28 Impredicative universes We can observe that a function type's universe is determined by the universes of its argument and return types. However, in the case of propositions we have a different behavior: Predicates, which are functions that return propositions, may have argument types in any universe, but the function itself remains in the universe. This behavior is called impredicative meaning that objects may be defined in terms of quantifiers ranging over that same object. The rule means that expressions such , which quantify over all propositions (including themselves), yield a proposition, that is: We can see some more examples of quantifying both over propositions and types as follows: /-- Quantifying over propositions yields a proposition -/ example : Prop := ∀ (P : Prop) (p1 p2 : P), p1 = p2 /-- Proposition quantifying over all type stays in Prop -/ example : Prop := ∀ (α : Type), ∀ (x : α), x = x example : Prop := ∀ (α : Type 5), ∀ (x : α), x = x 2025 11 28 The general rule We can combine these two rules to get a more general rule for function types that return types in any universe: Here the function type's universe is determined by the (impredicative max) imax of the universes of its argument and return types, where is defined as follows: 2025 11 28 The level grammar We can describe the level grammar via the following inductive type: inductive Level | zero : Level | succ : Level → Level | max : Level → Level → Level | imax : Level → Level → Level 2025 11 28 Universe Binding 2025 11 28 Explicit We can define functions and types that are universe polymorphic by introducing universe levels either explicitly or implicitly. An explicit universe level is specified directly in the definition, while an implicit universe level is inferred by Lean4. For example: /-- Explicit universe level -/ def map.{u v} {α : Type u} {β : Type v} (f : α → β) : List α → List β := | [] ⇒ [] | x :: xs => f x :: map f xs Here the map is declared with explicit universe levels and and instantiates the polymorphic . We can also define the same function with implicit universe levels as follows: universe u v def map {α : Type u} {β : Type v} (f : α → β) : List α → List β := ... 2025 11 28 Implicit By default in Lean4 the option is set to true, meaning that our universe levels will be inferred automatically meaning that we can simply write: def map {α : Type u} {β : Type v} (f : α → β) : List α → List β := ... Importantly automatic implicit parameter inference only works if the universe is mentioned in the header preceding the assignment, i.e: /-- Bad: unknown universe u -/ def L := List (Type u) /-- Good: universe u mentioned in header -/ def L.{u} := List (Type u) 2025 11 28 Implicit + fresh We can also go even further with implicit universes by allowing Lean4 to generate fresh universe levels for us. This is done by omitting the universe annotation and replacing it with a * suffix: /-- Fresh implicit universe levels -/ def map {α : Type*} {β : Type*} (f : α → β) : List α → List β := ... 2025 11 28 Universe Lifting Sometimes we may want to explicitly lift a type from one universe to a higher universe. Lean4 provides lifting operators which are wrappers around terms of a type that reside in a higher universe. There are two main lifting operators: : Lifts a proposition from to (i.e. ). : Lifts a type from to any number of levels. 2025 11 28 PLift The operator is used to lift propositions into the first type universe. It is defined as follows: structure PLift (α : Sort u) : Type u where /-- Wraps a proof/value to increase its type's universe lvl -/ up :: /-- Extracts a wrapped proof/value from a lifted prop/type. -/ down : α Some simple examples: #check False -- False : Prop #check PLift False -- PLift False : Type #check Nat -- Nat : Type #check PLift Nat -- PLift Nat : Type 1 example : PLift Prop := PLift.up True example : Prop := (PLift.down (PLift.up False)) example : List (PLift True) := [.up (by trivial), .up (by decide)] 2025 11 28 ULift The operator is used to lift types to higher universes. It is defined as follows: structure ULift.{r, s} (α : Type s) : Type (max s r) where /-- Wraps a value to increase its type's universe level. -/ up :: /-- Extracts a wrapped value from a universe-lifted type. -/ down : α Some simple examples: #check Nat -- Nat : Type #check ULift Nat -- ULift Nat : Type 1 #check ULift (ULift Nat) -- ULift (ULift Nat) : Type 2 example : ULift Nat := ULift.up 42 example : List (ULift Nat) := [.up 1, .up 2, .up 3] 2025 11 28 Example: Preorder Category A preorder relation is a binary relation that is reflexive and transitive. In Lean this is expressed as follows: class Preorder (α : Type*) extends LE α, LT α where le_refl : ∀ a : α, a ≤ a le_trans : ∀ a b c : α, a ≤ b → b ≤ c → a ≤ c lt := fun a b => a ≤ b ∧ ¬b ≤ a lt_iff_le_not_ge : ∀ a b : α, a < b ↔ a ≤ b ∧ ¬b ≤ a := by intros; rfl We can already see here that the preorder relation uses implicit universe polymorphism via the annotation. We can now construct a small category from a preorder relation as follows: open CategoryTheory instance {α : Type u} [Preorder α] : SmallCategory α where Hom a b := ULift <| PLift (a ≤ b) id a := .up <| .up <| le_refl a comp {a b c} f g := .up <| .up <| (le_trans f.down.down g.down.down) Let's break this down part by part starting with the homomorphism: 2025 11 28 Arrows For the case of the category definition, Lean fundamentally uses quivers to represent the homs between objects. Now before showing how lean defines them lets I think try and do it ourselves. So in this instance in an abstract sense we want the relationship to represent our morphism or arrow between two objects, so in a sense the following two are equivalent: So in the most straightforward sense what we can do is define any kind of "container" to represent our source and target objects under some label, we can define this naively as follows: class Graph (Obj : Type) where arrow (source : Obj) (target : Obj) : Type Now let's try to define an instance of such a graph on a preorder relation in which our objects simply live in : instance {α : Type} [Preorder α] : Graph α where arrow a b := a ≤ b -- arrow from a to b is the relation a ≤ b Here we are declaring an instance, this instance takes An implicit type parameter which is the type of our objects at the universe level 0. A type class constraint which ensures that the type has a preorder relation defined on it. In other words it guarantees that the relation is reflexive and transitive for all elements of type . And we provide the necessary implementation for the function by setting it to be the preorder relation . But what you will notice is that we have a problem here, namely that our preorder relation lives in the universe as it's obviously a logical relation, but our graph arrows need to live in (i.e. ). A first thought might be to just set the arrow type to be directly, in our definition of the class though this is rather restrictive as it means that any graph we wish to define can only ever have arrows representing propositions, what if we want to have arrows represent other types such as functions or numbers? One way to approach this is to use the operator to lift our preorder relation from to as follows: instance {α : Type} [Preorder α] : Graph α where arrow a b := PLift (a ≤ b) -- lift relation to Type 0 While this does work, and often is probably a reasonable way to go about things, much of Lean's mathlib employs universe polymorphic types to define various kinds of structures. Thus parameterizing over some universe level we define our polymorphic instance as: instance {α : Type u} [Preorder α] : Graph α where arrow a b := PLift (a ≤ b) But now we naturally run into another issue, namely that the class for our graph is now no longer universe polymorphic which leads to a universe level mismatch. The most straightforward fix here is to simply make the objects in the graph universe polymorphic as well: class Graph (Obj : Type u) where -- now polymorphic over u arrow (source : Obj) (target : Obj) : Type But this leads to another question, what level should the arrows live in? We've already seen that arrows can represent various different kinds of things different from the types of objects themselves, (e.g. is a proposition but clearly 2 and 3 are numbers). Now one approach is to simply leave the arrows in but this already is mildly annoying as it forces us to lift any arrows that don't naturally live in . Furthermore, we've already seen that having the type stuck at Prop is also not nice, so what we can do is make the arrows' universe polymorphic as well, though over a different universe level motivated by the aforementioned situation of different levels of arrows and objects: class Graph (Obj : Type u) where arrow (source : Obj) (target : Obj) : Sort v instance {α : Type u} [Preorder α] : Graph α where arrow a b := a ≤ b -- now lives in Sort 0 (i.e. Prop) But hold up, why are we lifting in the definition of the instance for the SmallCategory? Let's take a look at all the relevant type signatures: -- Quiver -- (V : Type u) where -- CategoryStruct -- (obj : Type u) : Type max u (v + 1) extends Quiver.{v + 1} obj -- Category -- (obj : Type u) : Type max u (v + 1) extends CategoryStruct.{v} obj -- SmallCategory -- (obj : Type u) : Type (u + 1) extends Category.{u} obj Let's break this down step by step starting first with the relationship between CategoryStruct and Quiver, for the sake of simplicity i'll abstract away some exact names and make all universes explicit: variable {α : Type m} [Preorder α] (a b c : α) class Box.{u, v} (obj : Type u) where pair : obj → obj → Sort v class A.{u, v} (obj : Type u) : Type max u (v + 1) extends (Box.{u, v + 1} obj) where I think an interesting question I first had here is with the extension of in why might you want to increase the universe level of the arrows by one? The main reason this is done in general is to essentially constrain the to never be zero. The implication of this being that our extended class can never have any pairs which live in . A good follow up to this might be, why would you not want things to live in ? In the most general sense some reasons are: is proof irrelevant: In Lean, propositions are considered proof irrelevant, meaning that all proofs of a given proposition are treated as equal. This can lead to loss of information when you want to be able to distinguish between different morphisms or in our simplified example pairs. is not computational: Propositions in Lean are not computationally relevant, meaning that they do not have computational content. If you want to perform computations or extract algorithms from your morphisms or pairs, having them in would prevent that. has limited structure: Propositions in Lean do not have the same rich structure as types in higher universes. If you need to work with morphisms or pairs that have additional structure (like being functions, sets, etc.), you would want them to live in a higher universe. As an example we can consider the following: -- @classname disables universe inference for that class variable (a₁ : @A.{m, v} α) #check (a₁.pair a b : Sort (v + 1)) -- Box.pair a b : Type v We can see here that the pair now lives in , meaning that if we had then our pairs would now live in . A natural byproduct of this choice - having arrows live in - is that the type of the structure itself must now live in the largest universe such that it can contain both the objects and the arrows. This is why we have the type signature for . Equivalently we can expand this as: -- since Type u = Sort (u + 1) and Type (v + 1) = Sort (v + 2) Sort (max (u + 1) (v + 2)) If we then create similarly abstract versions for the Category class (B) and SmallCategory class (C) we have: class B.{u, v} (obj : Type u) : Type max u (v + 1) extends A.{u, v} obj where class C.{u} (obj : Type u) : Type (u + 1) extends B.{u, u} obj where -- ^ can also type B.{u} (inferres v = u) We can see here that our SmallCategory (C) now constrains the arrows to live in the same universe as the objects by setting in the extension of . Thus, if we construct our pair, we have: variable (c : @C.{m} α) #check (c.pair a b : Sort (m + 1)) -- Box.pair a b : Type m 2025 11 28 Identity morphism Next up let's look at the identity morphism: id a := .up <| .up <| le_refl a The identity is defined as a function that quantifies over all objects in our category and returns an arrow from to . Naturally we then first want to construct our arrow, the identity arrow from to is simply the reflexivity property of the preorder relation , that is which we can get via . However since our arrows live in , we need to lift our relation twice, first using to lift it from to , and then again using to lift it from to . A note to make for people unfamiliar with the syntax here, the following pieces of code are equivalent: -- .up <| .up <| le_refl a == ULift.up (PLift.up (le_refl a)) 2025 11 28 Composition Finally let's look at the composition of arrows: comp {a b c} f g := .up <| .up <| (le_trans f.down.down g.down.down) The lifting portion here follows the same reasoning as the identity morphism, we need to lift the resulting relation from to . The actual composition is done via the transitivity property of the preorder relation . The thing is here that our input arrows and are both lifted types corresponding to: f : ULift (PLift (a ≤ b)) g : ULift (PLift (b ≤ c)) Thus to extract the actual preorder relations we need to use the method twice, first to go from to , and then again to go from to the actual relation in . Once we have the two relations extracted we can then apply the transitivity property to get the composed relation (which we then lift back up). 2025 11 29 https://kaierikniermann.github.io/notes/002u/ 002u /notes/002u/ A simple Bool category in Lean4 Blog 2025 11 27 https://kaierikniermann.github.io/notes/002m/ 002m /notes/002m/ Category Definition There are a few ways you can define a category. In the most basic intuitive sense a category consists of a collection of things called objects and binary relationships (or transitions) between those objects called morphisms (or arrows). We can combine these relationships by composing them, and for each object there is an identity morphism that acts as a neutral element for composition. (1) In the context of quivers a category can be defined as a quiver with a rule saying for how we can compose two edges that fit together to get a new edge. Furthermore, each vertex (object) has an edge starting and ending at that vertex (the identity morphism). The classical definition is something like this: 2025 11 27 The data A category consists of: A collection (or class (2)) of objects, denoted as or . A collection (or set (2)) of morphisms (or arrows), denoted or for . For every morphism , there are two associated objects: the source (or domain) and the target (or co-domain) . In standard function notation, we write where and . NLab has a nice convention where it denotes the source of a morphism as and the target as . For every pair of morphisms and (s.t. i.e. the morphisms type check), there is a composition morphism . Written out we can denote this as: in diagrammatic order this is often written as we can equivalently use a more graphical notation: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> For every object there is an identity morphism: Note: Some additional notations for morphisms include , or . Additionally, people use the notation to denote the following disjoint union Which just expresses the idea that the collection of all morphisms in a category is made up of the morphisms between each pair of objects. 2025 11 27 The axioms The above are often called data of a category. In addition to this data, a category must satisfy the following axioms or (conditions): Morphisms need to be associative which means that for every triple of morphisms , , and the following holds: For each morphism the identity morphisms act as neutral elements for composition: This is also known as the left and right unit laws or just unity in general. 2025 11 27 Remarks A category such as the one described above is often also called a 1-category to distinguish it from higher categories such as 2-categories, n-categories. 2025 11 29 https://kaierikniermann.github.io/notes/002s/ 002s /notes/002s/ Isomorphism (morphisms) Definition A morphism is called an Isomorphism if there exists a morphism such that the following hold (1): Sometimes an isomorphism is also denoted 2025 11 29 The category Example 2025 11 29 The data We want to start off by defining the data of our category. On a high level we want to define a category with two objects, and . Starting with the object representation we have: /-- A wrapper type to make a custom category on Bool -/ structure BoolCat : Type where val : Bool deriving DecidableEq, Repr /-- The two objects -/ def BoolCat.tt : BoolCat := ⟨true⟩ def BoolCat.ff : BoolCat := ⟨false⟩ Next we want to define the morphisms between these objects. For each pair of objects we express 3 kinds of morphisms: the identity morphism, a morphism from to , from to . We can express this in Lean as follows: /-- Morphisms: we allow identity on each, plus iso between them -/ inductive BCHom : BoolCat → BoolCat → Type | id (b : BoolCat) : BCHom b b | swap : BCHom BoolCat.tt BoolCat.ff | swapInv : BCHom BoolCat.ff BoolCat.tt Formally what this describes is a kind of piecewise function: 2025 11 29 Composition and Category instance Now we have some notion of objects and morphisms between them, we can move on to defining composition of morphisms. def comp : {X Y Z : BoolCat} → BCHom Y Z → BCHom X Y → BCHom X Z | _, _, _, id _, f => f | _, _, _, f, id _ => f | _, _, _, swapInv, swap => id _ | _, _, _, swap, swapInv => id _ This defines composition by pattern matching on the possible morphism combinations. Note that we have to explicitly handle the cases where we compose and to get the identity morphism on the respective objects. To construct our category we have to provide proofs for the category axioms, namely associativity and identity. @[simp] theorem id_comp' {X Y : BoolCat} (f : BCHom X Y) : comp (id Y) f = f := by cases f <;> rfl @[simp] theorem comp_id' {X Y : BoolCat} (f : BCHom X Y) : comp f (id X) = f := by cases f <;> rfl theorem assoc' (f : BCHom W X) (g : BCHom X Y) (h : BCHom Y Z) : comp h (comp g f) = comp (comp h g) f := by cases f <;> cases g <;> cases h <;> rfl With all this in place we can finally define our category instance: instance : Category BoolCat where -- The data Hom := BCHom id := BCHom. id comp := fun f g => BCHom. comp g f -- Category laws id_comp := fun f => BCHom.comp_id' f comp_id := fun f => BCHom.id_comp' f assoc := fun f g h => BCHom.assoc' f g h 2025 11 29 Isomorphisms in the Bool category Since we clearly see that the morphisms and are inverses of each other, we can construct an isomorphism between the two objects and as follows: def ttFfIso : BoolCat.tt ≅ BoolCat.ff where hom := BCHom.swap inv := BCHom.swapInv hom_inv_id := rfl inv_hom_id := rfl We can see that lean uses a similar notation for isomorphism as we do in our notes, namely the symbol between the two objects. We can see that an isomorphism consists of a and an morphism along with proofs that composing them in either order yields the respective identity morphism. In Lean4 its defined as follows: structure Iso {C : Type u} [Category.{v} C] (X Y : C) where /-- The forward direction of an isomorphism. -/ hom : X ⟶ Y /-- The backwards direction of an isomorphism. -/ inv : Y ⟶ X /-- Composition is the identity on the source. -/ hom_inv_id : hom ≫ inv = 𝟙 X := by cat_disch /-- Composition, in reverse, is the identity on the target. -/ inv_hom_id : inv ≫ hom = 𝟙 Y := by cat_disch ... /-- Notation for an isomorphism in a category. -/ infixr:10 " ≅ " => Iso We can check out some properties of our isomorphism like so: -- Verify it's an isomorphism #check ttFfIso -- BoolCat.tt ≅ BoolCat.ff #check ttFfIso.hom -- BoolCat.tt ⟶ BoolCat.ff #check ttFfIso.inv -- BoolCat.ff ⟶ BoolCat.tt Furthermore we can also show the identity isomorphism : -- Every object is isomorphic to itself (trivially) def ttSelfIso : BoolCat.tt ≅ BoolCat.tt := Iso.refl _ #check ttSelfIso -- BoolCat.tt ≅ BoolCat.tt Finally for the sake of completeness we can also demonstrate the isomorphism laws in examples as so: -- The isomorphism laws example : ttFfIso.hom ≫ ttFfIso.inv = 𝟙 BoolCat.tt := ttFfIso.hom_inv_id example : ttFfIso.inv ≫ ttFfIso.hom = 𝟙 BoolCat.ff := ttFfIso.inv_hom_id References nLab authors 2025 11 1 https://kaierikniermann.github.io/notes/nlab-category/ nlab-category /notes/nlab-category/ category Reference https://ncatlab.org/nlab/show/category misc nlab:category Baanen, Anne, Bentkamp, Alexander, Blanchette, Jasmin, Holzl, Johannes, Limperg, Jannis 2024 3 28 https://kaierikniermann.github.io/notes/baanen-bentkamp-blanchette-holzl-limperg-hitchhikers-2024/ baanen-bentkamp-blanchette-holzl-limperg-hitchhikers-2024 /notes/baanen-bentkamp-blanchette-holzl-limperg-hitchhikers-2024/ The Hitchhiker’s Guide to Logical Verification (2024 Desktop Edition) Reference Desktop edition https://raw.githubusercontent.com/lean-forward/logical_verification_2024/main/hitchhikers_guide_2024_desktop.pdf Lean Forward book baanen_bentkamp_blanchette_holzl_limperg_hitchhikers_2024 Johnson, Niles, Yau, Donald 2020 6 17 https://kaierikniermann.github.io/notes/johnson-yau-2d-categories-2020/ johnson-yau-2d-categories-2020 /notes/johnson-yau-2d-categories-2020/ 2-Dimensional Categories Reference https://arxiv.org/abs/2002.06055v3 2002.06055 misc johnson_yau_2d_categories_2020 Context https://kaierikniermann.github.io/notes/index/ index /notes/index/ Kai Erik Niermann Vrije Universiteit Amsterdam Student 2025 11 22 https://kaierikniermann.github.io/notes/0002/ 0002 /notes/0002/ Course Notes Course Notes This is a collection of notes for various courses I have taken. 2025 11 22 https://kaierikniermann.github.io/notes/0003/ 0003 /notes/0003/ All VFS Quiz Solutions VU-VFS-2025 This is an explanation and solution to all quizzes in the VFS lectures. By default, I have the solutions minimized, but you can expand them by clicking on the upper part of the solution box (i.e. just click the solution section). 2025 11 22 https://kaierikniermann.github.io/notes/0004/ 0004 /notes/0004/ Lecture 1 - Propositional Logic VU-VFS-2025 2025 11 22 Syntax 2025 11 22 https://kaierikniermann.github.io/notes/0005/ 0005 /notes/0005/ Syntax Definition Using BNF notation, the syntax of propositional logic can be defined as follows: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> 2025 11 22 https://kaierikniermann.github.io/notes/0006/ 0006 /notes/0006/ Evaluating Syntax Quiz Is an atom? Is a literal? Is a formula? What about ? What about ? 20251122Solution Yes, is an atom. Yes, is a literal. Literals are either atoms or negated atoms, and since is an atom, it is also a literal. Yes, is a formula. Formulas can be literals, and since is a literal, it is also a formula. is not an atom, but it is a literal (as it is a negated atom) and therefore also a formula. is a formula, since the inner negation is a literal and any additional negation applied promotes it to a formula. In other words only negated atoms are literals but negated literals are formulas. This is especially important when we later discuss Negation Normal Form (NNF). 2025 11 22 Semantics & Intepretations 2025 11 22 https://kaierikniermann.github.io/notes/0007/ 0007 /notes/0007/ Semantics Definition We can define the semantic inference rules for propositional logic formulas under interpretations as follows inductively, starting with the base cases: Moving on to the inductive case we have Similarly, the rules for when an interpretation does not satisfy a formula are as follows: 2025 11 22 https://kaierikniermann.github.io/notes/0008/ 0008 /notes/0008/ Interpretation Definition We define an interpretation as a function which maps propositional variables in a formula to truth values, so formally We can evaluate a formula under an interpretation by substituting each propositional variable with its corresponding truth value given by . Naturally under different kinds of interpretations formulas can evaluate to different truth values. We can create a classifcation of formulas based on how many interpretations evaluate them to true or false. satisfiable: A formula is satisfiable if there exists at least one interpretation under which it evaluates to true. unsatisfying: A formula is unsatisfying if there exists at least one interpretation under which it evaluates to false. tautology: A formula is a tautology if it evaluates to true under every possible interpretation. contradiction: A formula is a contradiction if it evaluates to false under every possible interpretation. contingent: A formula is contingent if it is satisfiable and unsatisfying, i.e., there exists at least one interpretation under which it evaluates to true and at least one interpretation under which it evaluates to false. 2025 11 22 https://kaierikniermann.github.io/notes/0009/ 0009 /notes/0009/ Evaluating PL Formulae Quiz Consider the formula and interpretation Which of the following is true What about the formula under the same interpretation? 20251122Solution Theres two main ways you can usually approach questions like this, the more drawn out operational way and then just going by observation more or less. Starting out with the more pedantic approach we can try to construct a proof tree for the formula under the given interpretation. So considering the first formula we have: So we can see that the interpretation does not satisfy the formula. In other words for this assignment the formula does not hold true. Given that this is a somewhat simple formula we could also just see this by observation, i.e. For the second formula lets just go with the simpler approach again, so we have So in this case the formula is satisfied by the interpretation. 2025 11 22 https://kaierikniermann.github.io/notes/000a/ 000a /notes/000a/ Evaluating sat/unsat/valid Quiz Are the following formulas sat., unsat., or valid? 20251122Solution As a reminder lets recap the definitions: A formula is satisfiable if there exists at least one combination of true/false assignments to its variables that makes the formula true. A formula is unsatisfiable if there is no combination of true/false assignments to its variables that makes the formula true (i.e., it is always false). A formula is valid (or a tautology) if it is true under all possible combinations of true/false assignments to its variables. Now we can analyze each formula: For the lhs to be true both p and q must be true. However, if p is true then is false, making the implication false. If p is false then the implication is vacuously true regardless of what we set q to. Thus, this formula is satisfiable (e.g., when p is false) but not valid (e.g., when p and q are true). If both p and q are true then the lhs is true and so is the rhs by virtue of p being true. If p is false then the implication is vacuously true regardless of q. If q is false then the rhs is true regardless of p. Thus, this formula is valid as it is true for all combinations of truth values for p and q. The first part is true unless p is true and either q or r is false. The second part is true when p and q are true but r is false. Thus we can satisfy the entire formula by setting p and q to true and r to false. However, if we set p to false then the first part is vacuously true, but the second part becomes false. Thus, this formula is falsifiable (e.g., when p and q are true and r is false) but not valid (e.g., when p is false). If you want to be absolutely sure about these kinds of questions constructing truth tables is always a good idea, albeit a bit tedious for formulas with many variables so just doing a bit of analysis like above is usually sufficient 2025 11 22 https://kaierikniermann.github.io/notes/000b/ 000b /notes/000b/ Lecture 2 - Normal Forms & DPLL VU-VFS-2025 2025 11 22 Formula Equivalence 2025 11 22 https://kaierikniermann.github.io/notes/000c/ 000c /notes/000c/ Equivalence of Formulae Definition Two formulas and are said to be equivalent, written , if they have the same truth value under every interpretation. In other words, for every interpretation , if and only if . 2025 11 22 https://kaierikniermann.github.io/notes/000d/ 000d /notes/000d/ Normal Forms & DPLL - Equivalence Quiz Which of the following equivalences hold? 20251122Solution True. Both sides are always false. True. Both sides are always true. False. Left side is always false, right side is always true. True. This is De Morgan's law. Good to remember False. Left side is true when p is true, right side is true when either p or q is true. True. Double negation elimination. 2025 11 22 Negation Normal Forms 2025 11 22 https://kaierikniermann.github.io/notes/000e/ 000e /notes/000e/ Negation Normal Form (NNF) Definition A formula is in Negation Normal Form (NNF) if the negation operator is only applied to literals (i.e., propositional variables or their negations), and the only other allowed operators are conjunction and disjunction . A nice way to think about it is that we can never have the case where we need to apply De Morgan's laws to push negations further down the formula tree. So all negations come pre-distributed to the literals. 2025 11 22 https://kaierikniermann.github.io/notes/000f/ 000f /notes/000f/ Negation Normal Form (NNF) Quiz Which of the following formulas are in Negation Normal Form (NNF)? 20251122Solution No. The implication operator is not allowed in NNF. Yes. Negations are only applied to literals, and only and are used. No. The negation operator is applied to a non-literal formula . No. The double negation is not allowed in NNF. Important to remember since that can trip you up. 2025 11 22 Disjunctive Normal Form 2025 11 22 https://kaierikniermann.github.io/notes/000k/ 000k /notes/000k/ Distributing Conjunction Definition The distributive law of conjunction over disjunction states that for any formulas , , and , the following equivalence holds: 2025 11 22 https://kaierikniermann.github.io/notes/000j/ 000j /notes/000j/ Eliminating Implications and Biconditionals Definition To eliminate implications () and biconditionals () from a formula , we can use the following equivalences: 2025 11 22 https://kaierikniermann.github.io/notes/000h/ 000h /notes/000h/ Disjunctive Normal Form (DNF) Definition A formula is in Disjunctive Normal Form (DNF) if it is a disjunction of one or more conjunctions of one or more literals. In other words, can be expressed as a series of clauses connected by disjunctions (), where each clause is a series of literals connected by conjunctions (). A literal is either a propositional variable or its negation. Where each clause is of the form: 2025 11 22 https://kaierikniermann.github.io/notes/000l/ 000l /notes/000l/ Converting to DNF Quiz Convert the following formula into Disjunctive Normal Form (DNF): 20251122Solution 2025 11 22 Equisatisfiability 2025 11 22 https://kaierikniermann.github.io/notes/000q/ 000q /notes/000q/ Equisatisfiability Definition Two formulas are said to be equisatisfiable if either both formulas are satisfiable or both are unsatisfiable. In other words, there exists an assignment of truth values to the variables that makes one formula true if and only if there exists; not necessarily the same assignment; that makes the other formula true. Equisatisfiability is a weaker condition than logical equivalence, as equisatisfiable formulas may not have the same truth values under all assignments, but they share the same satisfiability status. 2025 11 22 https://kaierikniermann.github.io/notes/000r/ 000r /notes/000r/ Equisatisfiability Quiz If a formula and are equisatisfiable, then are they equivalent? 20251122Solution No. We can answer this in a few different ways. In the most direct sense they are just definitionally not the same thing, in that equivalence requires that both formulas have the same truth value under all interpretations, whereas equisatisfiability only requires that both formulas have a satisfying interpretation or both be unsatisfiable. Another way to see it is that in an abstract sense equivalence describes an object-level relationship between formulas, whereas equisatisfiability describes a meta-level relationship about the existence of satisfying interpretations. Thus, they are fundamentally different kinds of relationships. 2025 11 22 Tseitin Transformation 2025 11 22 https://kaierikniermann.github.io/notes/000n/ 000n /notes/000n/ Conjunctive Normal Form (CNF) Definition A formula is in Conjunctive Normal Form (CNF) if it is expressed as a conjunction of disjunctions of literals. In other words, a CNF formula is a series of clauses (disjunctions) connected by AND operators. Each clause contains literals (variables or their negations) connected by OR operators. For example, the formula is in CNF. Where each clause is of the form: 2025 11 22 https://kaierikniermann.github.io/notes/000m/ 000m /notes/000m/ Exponential Blow up problem Definition When converting a formula to Disjunctive Normal Form (DNF) or Conjunctive Normal Form (CNF), the size of the resulting formula can grow exponentially in the worst case. This is known as the exponential blow up problem. For example, a formula with variables can result in a DNF or CNF with up to clauses. 2025 11 22 https://kaierikniermann.github.io/notes/000s/ 000s /notes/000s/ Tseytin's Transformation Definition Tseytin's transformation is a method used in propositional logic to convert any given formula into an equisatisfiable formula in Conjunctive Normal Form (CNF). The key idea behind Tseytin's transformation is to introduce new variables to represent subformulas of the original formula, thereby avoiding an exponential increase in size that can occur with naive CNF conversion methods. There are two key properties of Tseytin's for a formula and its Tseytin transformation : unsatisfiability: is unsatisfiable if and only if is unsatisfiable. model correspondence: For every satisfying assignment (model) of , there exists a corresponding satisfying assignment of , and vice versa, when restricted to the original variables of . To demonstrate how it works lets consider the following formula Subformula identification: Identify the subformulas of and assign a new variable to each subformula. For our example, we can identify the following subformulas and assign new variables: Variable assignment: Assign new variables to each subformula: Equivalence clauses: For each subformula, create clauses that enforce the equivalence between the new variable and the subformula it represents. For our example, we would create the following clauses: Conjunct of clauses: Combine all the equivalence clauses into a single formula in CNF. The final formula will be the conjunction of all these clauses along with the clause that asserts the truth of the variable representing the entire formula (in this case, ): Conversion to CNF: Finally, convert the combined formula into CNF using standard techniques (like distributing disjunctions over conjunctions). The resulting formula will be in CNF and equisatisfiable to the original formula . For example if we consider the clause this can be converted to CNF as 2025 11 22 https://kaierikniermann.github.io/notes/000t/ 000t /notes/000t/ Tseytin's Transformation Quiz Lets consider the following formula Using Tseytin's transformation, convert the formula into an equisatisfiable formula in CNF. 20251122Solution For the sake of brevity, let's skip assume the subformula extraction is already done, and we created the following equivalence clauses: This gives us the following conjunct for the transformed formula: 2025 11 22 https://kaierikniermann.github.io/notes/000u/ 000u /notes/000u/ Lecture 3 - First Order Logic VU-VFS-2025 2025 11 22 Syntax 2025 11 22 https://kaierikniermann.github.io/notes/000v/ 000v /notes/000v/ FOL - Syntax Definition We can define a first order language as a tuple of 3 sets where: Constants (): the set of constants in the language. E.g., Function Symbols (): the set of function symbols in the language. E.g., Relation Symbols (): the set of relation symbols in the language. E.g., Using BNF we can define the syntax as follows Here the atom represents an atomic predicate applied to terms , where with an arity of 2025 11 22 https://kaierikniermann.github.io/notes/000w/ 000w /notes/000w/ First Order Logic - Syntax Quiz Which of the following are syntactically valid formulas in first order logic? 20251122Solution : Invalid, as is a function symbol and cannot stand alone as a formula. : Valid, as is a relation symbol applied to the term . : Valid, as is a term and is a relation symbol applied to that term. : Invalid, as is a formula, not a term, and cannot be an argument to . : Valid, as is a term, and applying again yields another term, which can be an argument to . 2025 11 22 Quantifiers & Scoping 2025 11 22 https://kaierikniermann.github.io/notes/000x/ 000x /notes/000x/ FOL - Quantifiers and Scoping Definition For quantifiers: Each variable occurring within the formula known as the scope is either: bound: if it is within the scope of a quantifier that binds it. E.g., in , the variable is bound. free: if it is not bound by any quantifier within the formula. E.g., in , the variable is free. 2025 11 22 https://kaierikniermann.github.io/notes/000y/ 000y /notes/000y/ Quantifiers and Scoping in FOL Quiz Consider the formula Is the bound or free? Is the first occurrence of bound or free? Is the second occurrence of bound or free? 20251122Solution is bound, as it is within the scope of the quantifier . The first occurrence of is bound, as it is within the scope of the quantifier . The second occurrence of is free, as it is not within the scope of any quantifier that binds it. 2025 11 22 Closed, Open & Ground Formulas 2025 11 22 https://kaierikniermann.github.io/notes/000z/ 000z /notes/000z/ Closed, Open, and Ground Formulas (FOL) Definition We have 3 important classifications of formulas in First Order Logic (FOL) based on the nature of their variables: Closed Formula: A formula with no free variables. All variables in the formula are bound by quantifiers. E.g., is a closed formula. Open Formula: A formula with at least one free variable. E.g., is an open formula since both and are free. Ground Formula: A formula with no variables at all. E.g., is a ground formula if and are constants. 2025 11 22 https://kaierikniermann.github.io/notes/0010/ 0010 /notes/0010/ FOL - Closed, Open, and Ground Formulas Quiz Consider the following formula Is this formula closed, open, or ground? 20251122Solution This formula is a closed formula because all variables within the formula are bound by quantifiers. The variable is bound by the quantifier , and both occurrences of are bound by their respective quantifiers and . There are no free variables in this formula. A nice example of a ground formula is something like this We can see here that there are no variables at all; , , and are not bound by any quantifiers, hence the formula is ground since we aren't substituting/quantifying over any variables. 2025 11 22 Term Evaluation 2025 11 22 https://kaierikniermann.github.io/notes/0012/ 0012 /notes/0012/ Interpretation (FOL) Definition In first order logic a Interpretation; similar to the case of propositional logic; is a mapping which assigns meaning to the syntax of the language. In this instance it's a mapping from constants, function symbols and predicate symbols to specific objects, functions and relations in a given domain. We can define an interpretation as a sort of piece wise function as follows: Where (sometimes also denoted as ) is the domain of discourse which is a non-empty set of objects over which the quantifiers range. Intuitively the domain of discourse represents what we wish to talk about in our interpretation. We can break this down into 3 parts: constants (): are mapped to specific elements in the domain . For example if is the constant and , then could be a valid mapping. function symbols (): are mapped to functions that take elements from the domain and return elements in the domain. For example if is a unary function symbol and , then where , , and could be a valid mapping. relation symbols (): are mapped to relations (or predicates) that take elements from the domain and return truth values . For example if is a binary relation symbol and , then where , , and could be a valid mapping. 2025 11 22 https://kaierikniermann.github.io/notes/0013/ 0013 /notes/0013/ Structures and Variable Assignments (FOL) Definition A structure for a first-order language consists of: A non-empty domain , which is the set of objects that the variables can refer to. An interpretation function that assigns meanings to the non-logical symbols in : For each constant symbol in , is an element of . For each n-ary function symbol in , is a function from to . For each n-ary predicate symbol in , is a subset of . A variable assignment for a structure is a function that assigns each variable to an element of the domain of the structure. That is, for each variable , . 2025 11 22 https://kaierikniermann.github.io/notes/0011/ 0011 /notes/0011/ Term evaluation (FOL) Definition In First Order Logic, terms are evaluated based on an interpretation and a variable assignment within a structure denoted as . The evaluation rules are as follows: If is a constant symbol , then . If is a variable , then . If is a function application , then 2025 11 22 https://kaierikniermann.github.io/notes/0014/ 0014 /notes/0014/ Term evaluation (FOL) Quiz Consider the following domain/universe of discourse, variable assignment, and interpretation: Universe Variable assignment Interpretation What is the evaluation of the following terms under the given interpretation and variable assignment? 20251122Solution 2025 11 22 Semantic Entailment 2025 11 22 https://kaierikniermann.github.io/notes/0015/ 0015 /notes/0015/ Semantic Entailment (FOL) Definition We evaluate formulas in first order logic under a structure which consists of a domain and an interpretation function. In addition, we need a variable assignment to evaluate formulas with free variables. To denote truth under a structure and variable assignment we write: True: If a formula evaluates to true under we write False: If a formula evaluates to false under we write We can define semantic entailment inductively as follows: 2025 11 22 https://kaierikniermann.github.io/notes/0016/ 0016 /notes/0016/ Semantic Entailment (FOL) Quiz Consider constants (free variables) and a unary function , and a binary predicate . Let and interpretation function be defined as follows: Under the structure and variable assignment what do the following formulas evaluate to? 20251122Solution evaluates to because and , and . evaluates to because and , and . evaluates to because and , and . 2025 11 22 Semantic argument method 2025 11 22 https://kaierikniermann.github.io/notes/0017/ 0017 /notes/0017/ Connectives and Quantifiers (FOL) Definition In addition to evaluating atomic formulas, we can define the evaluation of complex formulas using logical connectives and quantifiers as follows: For the proof rules of quantifiers we have two variants depending on whether we are dealing with free or bound variables: 2025 11 22 https://kaierikniermann.github.io/notes/0018/ 0018 /notes/0018/ Semantic Argument method (FOL) Definition In first order logic, the semantic argument method represents a proof by contradiction. The basic idea is as follows: We assume that our formula is not valid, i.e., Use the proof rules to derive a contradiction from this assumption. If we can indeed derive a contradiction, we conclude that our initial assumption was false, and therefore must be valid. We can express the semantic argument method via the following inference rule: So the idea here being that if we have a predicate and its negation both holding under the same interpretation and variable assignment, we can derive a contradiction. This allows us to conclude that our initial assumption (that the formula is not valid) must be false, thereby proving the validity of the formula. 2025 11 22 https://kaierikniermann.github.io/notes/0019/ 0019 /notes/0019/ Semantic Argument method (FOL) Quiz Consider the following formula: Using the semantic argument method, determine whether the formula is valid. 20251122Solution We begin by assuming that Since we have and its negation both holding under the same interpretation and variable assignment, we can derive a contradiction using the Contradiction rule from the semantic argument method. Therefore, our initial assumption that is not valid must be false. Hence, we conclude that the formula is valid. 2025 12 2 https://kaierikniermann.github.io/notes/0032/ 0032 /notes/0032/ Lecture 4 - First Order Theories VU-VFS-2025 2025 12 2 Signatures and Axioms 2025 12 2 https://kaierikniermann.github.io/notes/0033/ 0033 /notes/0033/ First Order Theory Definition A first order theory (FOT) is defined by two main components: A signature of a set of constant, function, and predicate symbols A set of axioms consisting of closed (i.e. no free variables) formulas over the signature We say that a formula constructed from only from the contents of the signature is a -formula. 2025 12 2 https://kaierikniermann.github.io/notes/0034/ 0034 /notes/0034/ Signatures and Axioms (FOL) Quiz Consider a theory withthe following signature: And the axiom: Are the following legal -formulas? 2025122Solution Yes No, there are no constants in the signature, so \text {joe} and \text {tom} are not valid terms. 2025 12 2 Models of Theories 2025 12 2 https://kaierikniermann.github.io/notes/0035/ 0035 /notes/0035/ Structure & Model of (FOT) Definition A structure which we denote as: Is a model of a theory (or -model) iff: where: is the universe or more commonly the domain is the interpretation which assigns some meaning to our formula 2025 12 2 https://kaierikniermann.github.io/notes/0036/ 0036 /notes/0036/ Models of Quiz consider a structure consisting of a universe and interpretation as follows: Are the following models of the theory or not: Is a model of If we change the interpretation to is the structure now a model of ? If we add the following axiom and we change the interpretation to then is the structure a model of ? 2025122Solution As a reminder we are working with the axiom: Clearly no, as if we take and we have that both and hold, violating the axiom. Here we are chaning or interpretation to just the relation holding. In this case the axiom is satisfied as there are no values of and such that both and hold. So yes this is a model of . No, as if we take , and we have that both and hold, but does not hold (so not in our interpretation for the relationship), violating the axiom. 2025 12 2 Satisfiability Modulo 2025 12 2 https://kaierikniermann.github.io/notes/0037/ 0037 /notes/0037/ Satisfiable & Valid modulo Definition We say that a formula is satisfiable modulo iff there exists a -model and a variable assignment such that: We say that a formula is valid modulo iff forall -models and all variable assignments we have: 2025 12 2 https://kaierikniermann.github.io/notes/0039/ 0039 /notes/0039/ FOL Validity vs Valid modulo Definition We can compare the two notions by understanding validity in modulo as a restriction of validity in FOL to only those models that are -models. So the implication of that is that if a formula is valid (true in all models), then its clearly also valid in the subset/restriction to only -models. However, the other way around does not hold, since a formula can be true in all -models, but false in some non--model. Hence we have the following: But the other way around does not hold in general: 2025 12 2 https://kaierikniermann.github.io/notes/0038/ 0038 /notes/0038/ Satisfiability in FOL vs FOT Quiz Consider some arbitrary first order theory If a formula is valid in FOL, then is it also valid in modulo ? If a formula is valid modulo , then is it also valid in FOL? 2025122Solution Yes, if its valid in FOL that means its valid in all models which includes those models that are -models. Hence its also valid modulo . No, a formula can be valid in all -models, but false in some non--model. Hence its not necessarily valid in FOL. 2025 12 2 Theory of Equality & Congruence 2025 12 2 https://kaierikniermann.github.io/notes/003a/ 003a /notes/003a/ Theory of Equality Definition The theory of equality is a first order theory over the signature which contains: Where is a binary relation symbol and is any constant function or predicate symbol. The axioms of the theory of equality are: 2025 12 2 https://kaierikniermann.github.io/notes/003b/ 003b /notes/003b/ Theory of Equality Quiz Consider the universe: which of the following interpetations of are allowd by the axioms of : 2025122Solution No, violates reflexivity axiom since neither nor are in the interpretation Yes, satisfies all axioms of equality Yes, satisfies all axioms of equality 2025 12 2 https://kaierikniermann.github.io/notes/003c/ 003c /notes/003c/ (Left & Right) Congruence Relations (FOT) Definition In the most general sense we say that a relation over a set is a congruence with respect to a function if for all such that for all we have: if we denote as a vector of elements we can rewrite this more succinctly as: In the case of first order theories we can then instantiate with things like equality or other relations defined in the theory. Additionally we can represent a function or predicate symbol from the signature of the theory. In the case of binary functions or predicates we can also define left and right congruence as follows: A relation is a left congruence with respect to a binary function or predicate if for all such that we have: A relation is a right congruence with respect to a binary function or predicate if for all such that we have: 2025 12 2 https://kaierikniermann.github.io/notes/003d/ 003d /notes/003d/ Function & Predicate congruence Quiz Consider the universe: and the interpretation: Does the interpetation satisfy the axioms of equality? Which interpretations for a function satisfy the axioms of congruence? 2025122Solution Yes, the interpretation satisfies the axioms of equality Going through them one by one: No, because and but yet Yes, because and and thus , similarly for Yes, because and and thus , similarly for 2025 12 2 Theory of Peano Arithmetic 2025 12 2 https://kaierikniermann.github.io/notes/003e/ 003e /notes/003e/ Theory of Peano Arithmetic Definition Peano Arithmetic (PA) is a first order theory over the signature which contains: Where is a constant symbol representing zero, is a unary function symbol representing the successor function, and are binary function symbols representing addition and multiplication respectively, and is a binary relation symbol representing equality. The axioms of Peano Arithmetic are: 2025 12 2 https://kaierikniermann.github.io/notes/003f/ 003f /notes/003f/ Theory of Peano Arithmetic Quiz Are the following well-formed 2025122Solution No, the theory of Peano Arithmetic does not include function symbols like , nor does it include numerals like or . All terms must be constructed using the constant symbol , the successor function , and the function symbols and . Yes, this is a well-formed formula. It uses only the symbols and constructs allowed in the theory of Peano Arithmetic. No, this is not a well-formed formula. The expression is not a valid term in Peano Arithmetic, as numerals like are not part of the language. Terms must be built using , , , and . A valid way to express the same idea would be . Or if we replace with then we could do 2025 12 2 Theory of Rationals & Integers 2025 12 2 https://kaierikniermann.github.io/notes/003i/ 003i /notes/003i/ Theory of Rationals Definition The theory of rationals is a first-order theory over the signature which contains: (Axioms ommitted for brevity.) Some important properties of are: Full theory is decidable but doubly exponential. Conjunctive quantifier-free fragment is efficiently decidable (polynomial time). is the basis for arithemtic reasoning in SMT solvers such as Z3. In practice the simplex algorithm is used. 2025 12 2 https://kaierikniermann.github.io/notes/003h/ 003h /notes/003h/ Theory of Presburger Arithmetic Definition Presburger Arithmetic (PA) is a first order theory over the signature which contains: Where and are constant symbols representing zero and one respectively, is a binary function symbol representing addition, and is a binary relation symbol representing equality. The axioms of Presburger Arithmetic are: Some important properties of : Validity in quantifer-free Presburger Arithmetic is decidable. Validity in full Presburger Arithmetic is decidable. Validity in Presburger Arithmetic has a super exponential complexity is complete, i.e. 2025 12 2 https://kaierikniermann.github.io/notes/003k/ 003k /notes/003k/ Theory of rationals Quiz Consider the following formula: Is this formula valid in Is this formula valid in 2025122Solution Yes, this formula is valid in . In the theory of rationals, we can find a rational number that satisfies the equation . Therefore, there exists an in the rationals that makes the equation true. No, this formula is not valid in . In the theory of integers, there is no integer that satisfies the equation , since is not an integer. Thus, there does not exist an integer that makes the equation true. 2025 12 2 Theory of Data structures 2025 12 2 https://kaierikniermann.github.io/notes/003l/ 003l /notes/003l/ Theory of Arrays Definition The theory of arrays is a first-order theory that models arrays as functions from indices to values. Its signature includes: where: : read operation, which takes an array and an index and returns the value at that index. : write operation, which takes an array, an index, and a value, and returns a new array with the value at the specified index updated. : equality relation, which checks if two arrays are identical. The axioms of the theory of arrays are: 2025 12 2 https://kaierikniermann.github.io/notes/003m/ 003m /notes/003m/ Theory of arrays Quiz Which of the following formula is valid/satisfiable/unsatisfiable ? 2025122Solution This formula is satisfiable. For example, if we have an array such that , then the formula holds true. This formula is valid. According to the Read-Over-Write axiom, when we write a value to an index in an array and then read from that same index, we get the value we just wrote. So regardless of the initial contents of array , after performing the write operation , reading from index will always yield hence making it always true (valid). This formula is unsatisfiable. According to the Read-Over-Write axiom, when we write a value to an index in an array and then read from that same index, we get the value we just wrote. Therefore, after performing the write operation , reading from index will always yield , making it impossible for it to equal . This formula is satisfiable. For example, if we have an array such that , then after performing the write operation , reading from index will yield . Thus, both parts of the conjunction can be true simultaneously though are not valid in all interpretations. 2025 12 2 https://kaierikniermann.github.io/notes/003n/ 003n /notes/003n/ Lecture 5 - Nano and Hoare Logic VU-VFS-2025 2025 12 2 Semantics and Evaluation 2025 12 4 https://kaierikniermann.github.io/notes/003t/ 003t /notes/003t/ Simple Imperative Language - Syntax Definition We define the syntax of a simple imperative programming language, using the followng bnf grammar: 2025 12 4 https://kaierikniermann.github.io/notes/003u/ 003u /notes/003u/ Simple Imperative Language - Semantics Definition We can divide the environmental big-step semantics of our simple language into three parts: Expression evaluation: Describes how arithmetic expressions are evaluated to numbers. Boolean expression evaluation: Describes how boolean expressions are evaluated to boolean values (true/false). Statement execution: Describes how statements are executed, transforming an initial state (environment) into a final state. The general big-step environmental evalutation rule is denoted as: Here: We have some starting term (which can be an expression, boolean expression, or statement), along with some state . The evaluation results in some value (which can be a number, boolean value, or new state). A quick aside here to deconstruct the term big-step environmental evaluation: We say that this evaluation is big-step as it assumes some arbitrary state of intermediate steps, meaning that within big step semantics we do not care about intermediate computation only about some input expression and the final output value. A simple analogue to make here is that big-step semantics are akin to a teacher asking you to only show ur final answer to a math problem rather than all the steps you took to get there. We say that this evaluation is environmental (as opposed to being substitution based) as we explicitly keep track of a state which maps variables to their values. This is in contrast to substitution based semantics where variable occurrences are replaced directly with their values in expressions. The state represents a mapping from variables (commonly strings) to their corresponding values (numbers). We denote the updated state after assigning a value to a variable as: This means that in the new state, the variable now maps to the number , while all other variable mappings remain unchanged from the original state . 2025 12 4 Expression evaluation 2025 12 4 Boolean expression evaluation 2025 12 4 Statement evaluation 2025 12 4 https://kaierikniermann.github.io/notes/003v/ 003v /notes/003v/ Simple Imperative Language - Evaluation Quiz What does the following evaluate to? What does the following evaluate to? What does the following evaluate to? Is the following a total function? Is the following a total function? 2025124Solution Starting in the state we evaluate to the state Starting in the state , we first evaluate the condition : Since the condition evaluates to true, we then evaluate the then-branch : We again start by evaluating the condition Since we can see that the body of the loop only decreases , we are stuck in an infinite loop: Yes, for every expression and state , there exists a number such that This follows from the fact that expressions are finite syntax trees built from a finite set of rules, and each rule can be evaluated in a finite number of steps. No, there exist statements and states for which there is no resulting state such that For example, consider the while-loop starting from the state . As shown in the previous question, this loop does not terminate, and thus there is no resulting state . 2025 12 2 Hoare Logic 2025 12 5 https://kaierikniermann.github.io/notes/003x/ 003x /notes/003x/ Hoare triple - partial correctness Definition The basic unit of reasoning or judgement of the partial correctness of a program is the Hoare triple denoted as: where: represents the precondition which must hold true before the execution of the statement . represents the postcondition which must hold true after the execution of the statement , provided that was true before execution. If we consider a variable state mapping variable names to integer values, then we can define the partial correctness condition of a Hoare triple as follows: What this says is that: if the precondition holds in the initial state , and if executing the statement from that state leads to a new state , then the postcondition must hold in the new state . In a more programmatic sense we can understand the pre and postconditions as assertions on the memory state , in other words they represent a function that evaluates to true or false based on the values of the variables in the state. Thus, we can rewrite the Hoare triple condition as: Or in lean equivalently as: abbrev Condition := Memory -> Prop def HoareTriple {P Q : Condition} (c : Stmt) : Prop := ∀ σ σ', P σ → (c, σ) ⇓ₛ σ' → Q σ' A note here is that we are using some custom notation for the big-step semantics relation. The notation here simply means the big step evaluation relation for statements. In general for a Hoare triple we denote its validity as: 2025 12 5 https://kaierikniermann.github.io/notes/003y/ 003y /notes/003y/ Hoare triple evaluation Quiz Asses the validity of each of the following Hoare triples. 2025125Solution Valid. If before execution, then after executing , will be . Invalid. While will be after execution, remains , so the post-condition does not hold. Valid. After execution, will be , satisfying the post-condition . Valid. The loop runs indefinitely, so the post-condition is vacuously true as the program never terminates. 2025 12 2 Partial vs Total correctness 2025 12 5 https://kaierikniermann.github.io/notes/003z/ 003z /notes/003z/ Hoare triple - total correctness Definition The classical hoare triple only captures the notion of partial correctness, meaning that if the program terminates, then the postcondition holds given that the precondition held before execution. However, it does not guarantee that the program will terminate. To capture both correctness and termination, we define the total correctness Hoare triple denoted as: The total correctness Hoare triple asserts that: Or equivalently viewing the conditions as assertions on memory states: The central difference we can observe here is with the usage of a conjunction with the postcondition as opposed to an implication. This means that for total correctness, if the precondition holds in the initial state , then there must exist a final state such that executing the statement from leads to and the postcondition holds in that final state. Whereas in the case of partial correctness, if we had non-termination, the postcondition could be vacuously true. For the sake of completeness let's also show how we might implement this in lean: def TotalHoareTriple {P Q : Condition} (c : Stmt) : Prop := ∀ σ, P σ → ∃ σ', (c, σ) ⇓ₛ σ' ∧ Q σ' 2025 12 5 https://kaierikniermann.github.io/notes/0040/ 0040 /notes/0040/ Understanding hoare triples Quiz What does express? What about ? What about ? When does hold? When does hold? 2025125Solution It states that no matter the initial state, if the program terminates, then the postcondition will hold. In other words, all terminating states end up in or satisfy . It states that if the precondition holds before execution of , then after execution (if it terminates), the postcondition will always be true. Since is always true, this Hoare triple is valid for any program and precondition . Since this is a total correctness Hoare triple, it states that if the precondition holds before execution of , then the program will always terminate, regardless of the final state. The postcondition is trivially satisfied since it is always true. In other words we terminate on all states satisfying . This Hoare triple holds if and only if the program never terminates for any initial state. Since the postcondition is , which is always false, the only way for the Hoare triple to be valid is if there are no terminating executions of . This Hoare triple holds for any program and postcondition , because the precondition is always false. Since there are no initial states that satisfy , the implication in the definition of the Hoare triple is vacuously true. 2025 12 2 Inference rules 2025 12 5 https://kaierikniermann.github.io/notes/0043/ 0043 /notes/0043/ Inference Rule Schema - Hoare logic Definition To denote the idea of syntactic consequence / inference within Hoare logic we use the notation: Which says that if we can derive the hoare triple and so on up to using the inference rules of Hoare logic, then we can derive the hoare triple . Inference rules without any hypotheses are considered base cases. 2025 12 5 https://kaierikniermann.github.io/notes/0045/ 0045 /notes/0045/ Hoare logic - assignment proof rule Quiz Consider the assignment and the postcondition 2]]>. What needs to hold before the assignment such that 2]]> holds afterwards? Consider and post-condition 10]]>. What do we need to know before the assignment such that i > 10 holds afterwards? 2025125Solution Let's write this out first as a hoare triple: 2\}]]>. Without even looking at the assignment rule it should be obvious that if we want 2]]> to hold after the assignment, then before the assignment we need 2]]>, since after the assignment will take the value of . So the hoare triple is valid when we have: 2\}\ x := y\ \{x > 2\}]]>. Similarly we write the hoare triple: 10\}]]>. To ensure that 10]]> holds after the assignment, we need to consider what value of before the assignment will lead to 10]]> afterwards. Since we are incrementing by 1, we need 10]]> before the assignment, so our hoare triple becomes 10\}\ i := i + 1 \{i > 10\}]]>. 2025 12 5 https://kaierikniermann.github.io/notes/0044/ 0044 /notes/0044/ Hoare triple inference rules - Nano language Definition The basic inference rules for the Hoare logic applied to the Nano language are as follows: 2025 12 6 https://kaierikniermann.github.io/notes/0046/ 0046 /notes/0046/ A hypothetical proof rule Quiz A friend suggests the following proof rule for assignments: Is the proof rule correct? 2025126Solution Now let's test out the rule on a particular hoare triple: To make the hoare triple valid we would have to use the following precondition: but let's now assume the following initial state: this does correctly entail our precondition, i.e. we have as necessary by virtue of vacous truth, then executing the statement we have: In the new context clearly is reassigned to 4, thus: But we can see that clearly violates our postcondition , which is to say, . The implication of this is that while the hoare triple is derivable it is not then necessarily also valid, in words this proof rule is unsound. For completeness let's also provide a proof of soundness. As a reminder soundness states that: If a hoare triple is derivable using the inference rules of our system, then it is valid (i.e. true in all interpretations.) Formally we express this as: If we instantiate this rule for our hypothetical assignment rule we must demonstrate the following: 2025126Proof Let be the initial state before the assignment . We must show that if , then, after executing , the resulting state satisfies (i.e. is valid for the assertions in the postcondition). Before the assignment we have , in other words this means that: so if the variable in the initial state evaluates to the same thing as some expression then our post postcondition is valid for this state. After the assignment we have a new state defined as: with everything else being unchanged, which is to say that Now we want to check if as desired, we proceed by a case analysis on the equality Case: , then by the precondition we have . Since only changes the value of to , and is satisfied by the initial state it follows that . Case: , then our precondition becomes vacuously true as the antecedent is false. However, as the assignment does terminate we do need to ensure that holds in the new state . However, since can be arbitrary we cannot guarantee that . Let's link the proof of soundness back to the example, so in our inital state we have that: Since this means that the equality is false we have that implication so the precondition is true. This corresponds precisely to the second case where . The issue we can then see which naturally follows is that in the new state clearly its the case that: In other words we had the case where our precondition was vacuously true thus erroneously implying upon termination the arbitrary must also hold. Clearly then this proof rule is incorrect as in the case of a vacuous truth we are able to generate unsound hoare triples. To compare this with the correct assignment rule we have: we can notice here that by removing the consequent of the logical implication we ensure that if the assertion of x being substituted / being equal to the expression e before the execution of the statement doesn't hold, then it correctly means that we indeed cannot suggest that after an assignment our assertion is somehow correct. 2025 12 6 https://kaierikniermann.github.io/notes/0047/ 0047 /notes/0047/ Assessing provability Quiz Using the correct proof rule for assignments, asses which of the hoare triples are provable i.e. valid. 2025126Solution Yes, since we have that for any state the substitution holds, thus our precondition holds and upon termination of the assignment clearly our postcondition then holds as well. Yes, again we that our post condition says so holds as our precondition is then No, again using our reasoning we have but then if we have we can generate Yes, this is just correct by definition of a substitution leaving irrelevant variables unaffected. 2025 12 2 Consequence 2025 12 6 https://kaierikniermann.github.io/notes/0048/ 0048 /notes/0048/ Precond. Strengthening & Postcond. Weakening Definition As a reminder in hoare logic we denote the consequence rule as follows: On a high level this is quite evidently just transitivity, which is to say that if some assertion holds and by implication holds, and upon successful termination of we have that holds and by implication holds, then we can transitively reason that would also hold for our program . What we can do here is decompose this rule into two separate rules: 2025126Precondition strengthening The idea of strengthening here comes from the fact that the rhs of an implication always at least denotes a more restrictive or strengthened condition on the memory state . So a basic example being clearly: 3 \to x > 2 ]]> So if we have that: 3) \to (x > 2) \\ \vdash \{x > 2\}\ s\ \{Q\} ]]> Which is to say that our hoare triple is derivable under the weaker precondition 2]]>, then clearly the same hoare triple is also derivable under the stronger pre-condition 3]]> as it implies our weaker condition, hence we can derive: 3\}\ s\ \{Q\} ]]> An example program we could take here would be something like: 2\}\ \texttt {if}\ (x > 2)\ \texttt {then}\ y := 2 \texttt {else}\ y := 3\ \{y := 2\} ]]> Clearly here the condition just requires that is larger than 2, if our precondition asserts that its larger than 3, the branch executes just the same and our postcondition holds. 2025126Postcondition weakening On a high level this says that if we can prove some postcondition , we can always relax this condition to something weaker. So in simpler terms if we have the fact that the postcondition holds for some more restrictive state, then we can naturally lessen the restrictions and have it still hold. 2025 12 6 https://kaierikniermann.github.io/notes/0049/ 0049 /notes/0049/ Postcondition Weakening examples Quiz Suppose we can prove: using the rule of post-condition weakening, which of the following can we prove? 2\}]]> 2025126Solution Yes, this is provable, removing a conjunct is a common way of weakening an expresison as we are removing one condition. Yes, this is provable, same reasoning as in (1) This is also provable, more or less same reasoning as before, here we are using the fact that 0 ]]> since obviously 0]]> No, this is not provable, while removing a conjunct does weaken our postcondition, if we then also quantify over all we make an assertion which is stronger then what the conjunct says, i.e. that for a specific , hence this is not provable. Yes, this is provable. We have the fact that so clearly this is the same as what we did for (1) just with no desugaring of existential syntax 2025 12 6 https://kaierikniermann.github.io/notes/004a/ 004a /notes/004a/ Lecture 6 - Hoare logic & Weakest preconditions VU-VFS-2025 2025 12 6 Loops & Invariants 2025 12 6 https://kaierikniermann.github.io/notes/004c/ 004c /notes/004c/ Checking valid invariants Quiz Consider the following code: i = 0; j = 0; n = 10; while i < n do i = i + 1; j = i + j Which of the following is a loop invariant? 2025126Solution Before the loop and , since that means is true we move on to checking it holds true after each loop iteration. What we can observe is that the loop condition is and during the loop we have , what this suggests is that clearly during the iteratons the invariant holds, additionally when we have that hence the invariant also holds upon the termination of the loop, i.e. after the final iteration, thus it's indeed a valid loop invariant. No, this is not a valid invariant, we can see that its very close to being right, but it doesnt account for the case after the final iteration and before we check the loop condition, i.e. where , hence its not a valid loop invariant because it does not hold true after each iteration. No, this is quite easy to see as it immediately fails even before we get into the loop as . 2025 12 6 https://kaierikniermann.github.io/notes/004d/ 004d /notes/004d/ Proving validity with invariants Quiz Let's consider the statement : while x < n do x = x + 1 Answer the following questions: Prove the validity of using the loop invariant Would also have worked as a loop invariant? If we changed the post condition to , what would that have changed? 2025126Solution As the usual piece of little assistance let's take a look at the while rule Here we can try to construct the proof tree first of all, instantiating our rule with the given invariant we have: Using the assignment rule we then want to prove the antecident here, so instantiating this with or postcondition we have in other words our precondition becomes Therefore the use the assignment rule we want we have to demonstrate since we have that we clearly have that Yes, let's again instantiate our rule since our postcondition for the assignmnet is a tautology, i.e. always valid, it will hold under substitution thus making the assignment trivially valid hence working as a correct loop invariant. Something we could observe in question (1) is that so this is a bit of a trick question in that with question 1 we are actually just using a postcondition weaking on this postcondition, hence this is naturally a valid postcondition. 2025 12 7 https://kaierikniermann.github.io/notes/004f/ 004f /notes/004f/ Invariant Definition In the most straightforward sense we say that an invariant is simply: A property that holds at all reachable states of the program Formally we can say if denotes our property and denotes our set of reachable states then we can say that is an invariant if: An important thing to note here is that an invariant by itself does not need to be checkable or syntactic in any sense, there are no requirements that must imply after each step. The distinction here is important because we can have something be an invariant though be insufficient as a proof rule. 2025 12 6 https://kaierikniermann.github.io/notes/004e/ 004e /notes/004e/ Inductive Invariant Definition An inductive invariant is a regular invariant, which is to say that it: is a property which holds at all reachable states of the program But it has the additional constraint that it must be closed under the transition relation. In other words if it holds before a step, it must also hold after the step. Formally we say that a property represents an inductive invariant if: As a base case it holds at program initialization In the inductive step we have in plain English: If the property holds on the state and after the small step evaluation we land in a new state then the property also holds in the new state . If both of the conditions hold then we we automatically have that: Which is to say that these conditions imply an inductive invariant is also an invariant. The prime example where we can see this is in the case of the while loop for hoare logic: Here the invariant is represented by the assertion on the memory state. What this rule says is that: If the assertion and the loop guard hold, and upon termination of we have that holds. Then we can lift the invariant out of the loop and say that it must hold for all loop iterations and upon termination of the loop we clearly have that our loop guard must be false and our invariant should still hold. This corresponds precisely to the notion of an inductive invariant as if we can demonstrate it holding for the execution and termination of a single statement - the base case - then we can derive the inductive case where it holds for all iterations. 2025 12 7 https://kaierikniermann.github.io/notes/004g/ 004g /notes/004g/ Finding inductive invariants Quiz Consider the following statement : while x < n do x := y; y := x + 1 Say that we wanted to prove the following Hoare triple: What is an inductive invariant which allows us to prove the triple? 2025127Solution For reference lets pull up the while rule again: One not entirely unreasonable albiet simple choice is to try out the post condition , its not too uncommon that a valid postcondition - or more often a variant of it - are in fact valid loop invariants. Testing this out it means we would have to prove the body: To see if this is inductive we can try and find a counterexample to demonstrate its not, and indeed we can see that would mean that would hold, and we could indeed step to a state though clearly we have that: Since we can see here that the unconstrained is causing is issues lets go with: Since this ensures that is correctly related to it means that we indeed have that as desired 2025 12 6 Arrays & Invariants 2025 12 2 https://kaierikniermann.github.io/notes/003l/ 003l /notes/003l/ Theory of Arrays Definition The theory of arrays is a first-order theory that models arrays as functions from indices to values. Its signature includes: where: : read operation, which takes an array and an index and returns the value at that index. : write operation, which takes an array, an index, and a value, and returns a new array with the value at the specified index updated. : equality relation, which checks if two arrays are identical. The axioms of the theory of arrays are: 2025 12 7 https://kaierikniermann.github.io/notes/004i/ 004i /notes/004i/ A hypothetical array inference rule Quiz Say we want to add arrays to our programming language, and we come up with the following inference rule to reason about assignments: Is this rule correct? 2025127Solution There are a few ways we can answer this, starting in with the most pedantic let's construct the proof tree and then see if we can come up with a counter example, we consider the following hoare triple: By the sequence and precondition strengthening rule we have that Of note here we are deriving through the following implications: Where we know that so we can use precondition strengthening to use as our precondition since it implies something we've already syntactically demonstrated to be provable. Clearly we have that the first assignment in the sequence holds by the naive assignment, same for the second assignment since it precondition reduces to the tautology , so the final rule is then derivable. But we can obviously see that it erroneously assumes that represents some kind of distinct index but, we can see that in the second assignment its aliased by the constant index which means that while we can derive the rule it is not semantically valid hence unsound. To compare this with the correct rule we have that: Now again let's try to derive the hoare triple we want to prove correct: To derive we want to find some assertion , applying the correct assignment rule to the second assignment we define as. we can think of this as defining the function: we can then do a case split on the equality using our defined function If then we have If we have Since it clearly must be the case that it implies that our assertion is equivalent to: Now testing this rule on the first hoare triple: By the assignment rule we must somehow be able to derive from the following: substituting in our we get after a reduction we have simplifying this we get Which is where the crux of our issue lies, the precondition of our Hoare triple was , but clearly here to derive our sequence of assignments we must have that i is not 1, hence this hoare triple is not derivable as its also clearly not valid. A simpler approach at establishing the same idea is by just directly working backwards so first we substitute for the assignment , then we update it for the assignment , then our precondition would imply that: We indeed cannot derive the triple with the precondition, as it should be trivially apparent that if after overwriting with we clearly cannot have . 2025 12 2 https://kaierikniermann.github.io/notes/003m/ 003m /notes/003m/ Theory of arrays Quiz Which of the following formula is valid/satisfiable/unsatisfiable ? 2025122Solution This formula is satisfiable. For example, if we have an array such that , then the formula holds true. This formula is valid. According to the Read-Over-Write axiom, when we write a value to an index in an array and then read from that same index, we get the value we just wrote. So regardless of the initial contents of array , after performing the write operation , reading from index will always yield hence making it always true (valid). This formula is unsatisfiable. According to the Read-Over-Write axiom, when we write a value to an index in an array and then read from that same index, we get the value we just wrote. Therefore, after performing the write operation , reading from index will always yield , making it impossible for it to equal . This formula is satisfiable. For example, if we have an array such that , then after performing the write operation , reading from index will yield . Thus, both parts of the conjunction can be true simultaneously though are not valid in all interpretations. 2025 12 10 https://kaierikniermann.github.io/notes/004j/ 004j /notes/004j/ Finding inductive invariants - arrays Quiz Consider the following while loop : while i < n do a[i] := 0; i := i + 1 Consider the following pre-and-post condition: 0\}\ W\ \{\forall j.\ 0 \leq j < n \to a[j] = 0\} ]]> What is an inductive invariant that shows correctness? 20251210Solution This is almost a sort of canonical example where the index replacement trick works really nicely. On a high level our postcondition asserts something about the array over the first indices, hence if we want to have an invariant which shows correctness, we can simply reframe our postcondition as an assertion up to the th position / iteration, in other words we simply replace with : 2025 12 6 Soundness & Completeness 2025 12 5 https://kaierikniermann.github.io/notes/0041/ 0041 /notes/0041/ Soundness & Completeness - Hoare triples Definition In a very general sense if we have a logical or formal system a core idea is that we only want to prove things that are actually true, and conversely if we find something that is true we would want to be able to prove it. This leads to two important properties of formal systems: Soundness is the property that everything provable within the system is in fact true, within the context of hoare logic it means that all hoare triples which we can syntactically derive using our inference rules are by implication valid (i.e. true in all interpretations), formally: Completeness is the property that everything that is true can be proven within the system, in the context of hoare logic it means that all valid hoare triples can be syntactically derived using our inference rules, formally: 2025 12 6 Weakest precondition 2025 12 10 https://kaierikniermann.github.io/notes/004k/ 004k /notes/004k/ Working backwards - weakest precondition Definition I'll split this explanation into 3 parts, first the basic intuition, then the pen-and-paper reasoning, and finally a more granular explanation. 2025 12 10 The idea Say we want to verify a hoare triple , the weakest precondition approach is that we: Start with our postcondition and, going backwards, we compute a formula called the weakest precondition of w.r.t the statement . has the property that it's the weakest condition which guarantees that will hold after the termination of . Therefore we can say that the triple is valid: 2025 12 10 The basic rules The basic rules can be recursively defined as follows: For assignments: For composition For conditionals 2025 12 10 The more detailed reasoning As a reminder, a Hoare triple: Is simply a kind of syntax sugar for the logical formula: So for all source and target states, if we terminate on then holds. Additionally, for different kinds of expressions we also have our constructions rules to ensure soundness, take for example assignment, our rule to only derive valid Hoare triples was: If we assume to be some variable expression in a context which has to evaluate to a number before assignment then we can write the above rule more pedantically as: The idea of backwards reasoning here is as follows: First we look at the big step evaluation , we know that if this assignment succeeded, it implies there must have been a successful evaluation of the term, we know this because the only way to have derived this step is by the following inference rule: Using what we've learned from (1) we apply the notion of inversion, i.e. if we know a conclusion to be true, we can assert the premises of that conclusion must have also been true, this in a sense gives us the premises to use as new judgements. Now looking at the expression we can clearly derive the precondition since we know the antecedent is true, as it must have been true to derive the big step evaluation. Since we have now demonstrated we can indeed provide sufficient reasoning to arrive at our conclusion this finishes the proof. The shorthand of the weakest precondition is nothing more than an expression of precisely this idea in a more concise fashion. Take for example . We again start from our post-condition then proceed with a case split or more accurately an inversion on the evaluation rule. The inversion naturally gives us two branches, the true and false branch. This represents the conjunction here, then with each conjunct the antecedent of the implication is represented by the true or false guard condition , the consequent in this instance is simply a recursive call on the and branch bodies. The main thing I'm trying to drive home here is that the weakest precondition idea is fundamentally just based on the concept of: Seeing how a term must have been derived Recursively going up the chain of any other sub-terms So in a straightforward way, it's nothing more than chaining together all the individual proof rules for the various hoare triples. To show an example in lean using a some nice macros to create a simple syntax: example (n : Num) : {{ ⟦ "x" ↦ n ⟧ }} tm{ x := x + 1 } {{ ⟦ "x" ↦ n + 1 ⟧ }} := by apply Hoare.assign' intro σ m hpre heval cases heval with | sum he1 he2 => cases he1; cases he2 simp [hpre] The hoare triple we are proving here corresponds to this in the normal syntax: We can see here to "prove" this hoare triple was valid we started by doing our standard case split on the assign - that's the - statement, then we were inside the addition, here we did a case split which gave us the lhs and rhs we were adding, after doing a case split on those two sides we could finally just simplify (and finalize) our proof using the fact that in evaluates to . 2025 12 10 https://kaierikniermann.github.io/notes/004m/ 004m /notes/004m/ Weakest precondition - while loop Definition In an abstract sense the weakest precondition for while loops is no different from that for most other syntactic constructs, to reason backward we apply inversion to the statement we are considering; in this case the while loop; and then simply recurse on the sub-terms. Though the while loop differentiates itself through the notion of invariants. Before we define how to compute the weakest precondition let's define the hoare rule again: The central thing to observe here is the invariant hypothesis which acts as the premise for the while loop formation, if we write expand it out a bit we get: So the idea, to reiterate again, is that if our invariant holds in the state and our loop condition evaluates to , then upon termination of i.e. the loop body we have that the invariant still holds. In the false case our proof becomes trivial through inversion we know there is some terminating state and we know the loop condition must have evaluated to false, hence we can immediately provide the conditions to fulfill the postcondition and thus create our valid hoare triple. The true case is a bit more complex, first let's look at the evaluation semantics for it We can see the final state is this means that the post-condition we want to prove for the true state is The main thing we leverage here is the invariant hypothesis, rewriting it as a function we have in addition to The idea is then that we use inversion to give us the evaluated terms, we plug those terms into the invariant hypothesis to get , then using , , and reflexivity (since ) we have created the proof that the invariant holds for the final memory state and the loop guard indeed evaluates to false. 2025 12 10 https://kaierikniermann.github.io/notes/004l/ 004l /notes/004l/ Computing weakest preconditions Quiz Consider the following statement: x := y + 1; if x > 0 then z := 1 else z := -1 Answer the following questions: What is 0)]]> What is Can we prove 0\}]]> What about -1\}\ s\ \{z > 0\}]]> 20251210Solution In an abstract sense the statement is a sequence of an assignment and an if statement, starting with the if statement we get: 0) \to \texttt {wp}(z := 1, Q) \land (x \leq 0) \to \texttt {wp}(z := -1, Q) ]]> Both of the assignments resolve to substitutions of 1 and -1, so we get 0) \to (z > 0)[z \mapsto 1] \land (x \leq 0) \to (z > 0)[z \mapsto -1] ]]> With sequences we know it's a nested pattern, i.e. , the second argument we already have, we know that here is just the assignment, so again we apply the subtitution 0) \to Q[z \mapsto 1] \land (x \leq 0) \to Q[z \mapsto -1])[x \mapsto (y + 1)] ]]> which reduces to 0) \to (1 > 0) &\land (y + 1 \leq 0) \to (-1 > 0)) \\ ((y + 1 > 0) \to \top &\land (y + 1 \leq 0) \to \bot ) \\ ((y + 1 > 0) \to \top &\land \neg (y + 1 \leq 0)) \\ ((y + 1 > 0) \to \top &\land (y + 1 > 0)) \\ ((y + 1 > 0) \to \top )& \\ (y + 1 > 0)& \\ \end {align} ]]> To skip ahead a slight bit, so we have 0) \to (z \leq 0)[z \mapsto 1] \land (x \leq 0) \to (z \leq 0)[z \mapsto -1] ]]> then substituting for the intial assignment of 0) \to (1 \leq 0) \land (y + 1 \leq 0) \to (-1 \leq 0) ]]> Here we just end up in the reverse case, i.e. 0) \to (\bot ) \land (y + 1 \leq 0) \to \top ]]> reduces now to The high level idea here is that we computed the weakest precondition for 0]]> already, it was 0) ]]> since it's the weakest we can only admit other preconditions if they imply the weakest one, so if we then look at the implication y \to (y + 1 > 0) ]]> we can trivially see that this implication does not hold, i.e. we cannot apply precondition strengthening here hence the rule does not allow us to prove the hoare triple. Same reasoning as above, but now it works since -1 \to y + 1 > 0 ]]> indeed makes sense 2025 12 11 https://kaierikniermann.github.io/notes/004n/ 004n /notes/004n/ Verification conditions in while loops Example Let's consider the following while loop: @pre x <= 0 while [x <= 6] (x <= 5) do x := x + 1 @post x = 6 if we denote the loop and its body as , then it corresponds to the following hoare triple: With the addition of the invariant , now the verification condition for the loop is expressed as: starting with the first conjunct with have: After we unfold the our goal reduces to: And we clearly know this is true just by inversion of the evaluation of the loop guard. Moving on to the second conjunct: This represents our termination condition, here we know by inversion of the loop guard again that the premise of our implication becomes: 5 \to x = 6 ]]> Our final conjunct is the verification condition on the assignment, so: Unfolding the call again we know this just resolves to as there are no verification conditions for assignment. Finally we also have to demonstrate that: unfolding the again gives Clearly we can see this trivially holds, i.e. our precondition is stronger than the invariant, hence by precondition strengthening, it is valid. 2025 12 11 How do we get there though? I do think it's worth telling this as a bit of a story, we start with the fundamental theorem for while loops: So this is just the expanded rule for constructing valid or sound while hoare triples, now this rule assumes that the invariant is the same as the precondition which is naturally not always the case, so it could be nice to have a rule which accounts for constructing valid while loops with invariants and custom preconditions. Same with custom post-conditions . If you want to be super pedantic you could show how this is just a combination of consequence + while rule. Anyway then, moving on we have the rule for soundness. Now depending on how you actually design your and code this rule can look slightly different, though I like this distinction, in this instance for the case of while loops simply returns the invariant , this means that again if we want to have a custom precondition for we'd want to verify we would extend the rule as: Thus for while loops it would become: Where the verification conditions would unfold to what we discussed before. A nice point to make here is that all of these rules are essentially derived from one another, which is to say that: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> In a conceptual sense verification conditions i.e. what we need to prove to demonstrate a hoare triple is valid, are simply a convenience mechanism derived from the fundamental logic of how we construct a hoare triple. 2025 12 12 https://kaierikniermann.github.io/notes/004p/ 004p /notes/004p/ Lecture 7 - VC's for functions and pointers VU-VFS-2025 2025 12 12 Assertions 2025 12 12 https://kaierikniermann.github.io/notes/004q/ 004q /notes/004q/ Assertions & Havoc Definition We introduce 3 new syntactic constructs with their associated hoare rules, these constructs are: The statement which if evaluates to The statement which tells us that evaluates to The statement which assigns a non-deterministic value to a variable 2025 12 12 Evaluation rules We introduce a new construct which denotes the failure state, as an alternative to . For the assumption we only have a rule, the idea being if the assumption holds then the statement is equivalent to a otherwise the execution gets stuck but doesn't fail. The idea with getting stuck being that since we aren't failing for the case of partial-correctness (failure or termination) it means we can simply ignore this case. The final big-step evaluation rule is for the havoc statement: 2025 12 12 Hoare rules In addition to our big-step evaluation rules we also have Hoare rules. 2025 12 12 A more detailed explanation A central thing to understand with assertions especially is that they integrate a result's monad into the big-step evaluation semantics, in addition to the Hoare logic. So the idea is now instead of the relationship being denoted by: It's now expressed as Where we can model as the following monad inductive Result (α : Type) | ok : α → Result α -- Normal termination with final state | fail : Result α -- Assertion failure / error state deriving Repr, DecidableEq At this point if you want to be pedantic it's worth mentioning that the implication is that we are lifting all other inference rules into the context of this result monad, though for pedagogical purposes its enough to just assume that just corresponds to i.e. evaluated into a non-fail state. The Hoare triple is where stuff becomes a bit more interesting. As a reminder, the classical hoare triple is basically just an alias for the logical formula: Naturally because we know are no longer evaluating into just but either an or state, it's worth asking how we actually represent that as a Hoare triple. We can start in much the same way as we do for the regular partial correctness hoare triple Here we then run into I guess a design choice as to how we proceed, the two main possibilities are: We fail sometimes succeed other times this would mean that: another way of seeing this is here we are disallowig failure meaning that for a hoare triple to be proven valid we must explicitly demonstrate as a side condition that we cannot fail otherwise our hoare triple is invalid. We never fail which would mean that: for this rule another way of seeing it is we are ignoring failure or filter success states since we are clearly only quantifying over those states that are successfull. The latter option seems to be generally more common in theoretical settings because it doesn't require explicitly accounting for failure states, they are just implicitly filtered out in the logic. 2025 12 12 https://kaierikniermann.github.io/notes/004r/ 004r /notes/004r/ Weakest precondition for assert and assume Quiz Answer the following: What's What's Given a statement , can we transform it into a statement such that: 20251212Solution We can remember that the weakest precondition is simply what we can derive reasoning backwards from the formulaic expression of a hoare triple. Considering our wp formula we have reasoning backwards we can start with a case split on the evaluation of the assertion, this leads to two cases evaluates to true, as this case trivially implies that the assertion evaluates into it means we must prove . The only way we can prove this is by having our weakest precondition be a witness to this assertion. evaluates to false, as this would imply a contradiction since the assertion evaluates to , more specifically we know have to prove the contradiction that , we know (i.e. have a hypothesis) by inversion that since we know has to be true to prove the contradiction we also must ensure the weakest precondition states that from these two cases we can conclude that two demonstrate the soundness of the weakest precondition for assert statements, it must be the case that the is the conjunction of the postcondition and the logical assertion that what is being asserted is indeed true, so we have that the more intuitive reasoning here is that should hold before and after as an assert should, just by design, not do anything to the memory, it's only an assertion after all. Additionally, the condition should hold true as definitionally describes a set of states where all terminating executions end in a state satisfying thus if does not evaluate to true, there is no terminating execution from . We can just use the more intuitive reasoning here, we know the weakest precondition characterizes a set of states where terminating executions end in a state satisfying . The only way for something being assumed to be true leading to some other else is it if implies something else, thus our becomes in terms of backward reasoning the idea is that essentially just adds a raw hypothesis but clearly that by itself doesn't somehow allow me to just manifest , the only way we could possibly get from being true is if we have a function which states that being true implies . 2025 12 15 https://kaierikniermann.github.io/notes/004u/ 004u /notes/004u/ Lecture 8 - Horn Clauses VU-VFS-2025 2025 12 15 Introduction & Syntax 2025 12 15 https://kaierikniermann.github.io/notes/004v/ 004v /notes/004v/ Horn clauses - Syntax Definition A Horn clause is a disjunctive clause (disjunction of literals) with at most one positive, i.e. unnegated literal. Often written in implication form as a conjunction of literals implying some literal called the head. Here: queries are relations over some vector of variables represents a formula in a first-order theory which does not contain queries is called the head and represents either a query in which case we also call the horn clause a definite class if it has the following shape or a fact if it has the following shape can also be in which case we refer to the horn clause as a gloal clause with the shape with the idea being that as opposed to assuming the query holds we now show that it holds Free variables are implicitly universally quantified over, so a horn clause like stands for 2025 12 15 https://kaierikniermann.github.io/notes/004w/ 004w /notes/004w/ Horn clauses - Semantics Definition 2025 12 16 https://kaierikniermann.github.io/notes/0050/ 0050 /notes/0050/ Horn clause - Solution Definition A solution is a function that maps queries to formulas in the background theory over the same variables. Formally we write and say that satisfies , if is true if we replace all queries by their solutions, written as an inference rule: We write and say that satisfies the set of clauses , if it satisfies all individual clauses, i.e: We say that is satisfiable, if 2025 12 16 https://kaierikniermann.github.io/notes/004z/ 004z /notes/004z/ Finding recursive Horn clauses Quiz Is the following set of horn clauses recursive? 0) &\to r(x) \\ p(x) \land (x < n) &\to \bot \end {align} ]]> 20251216Solution No, we can draw the dependency graph as follows '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> Yes, because the head depends on the query and vv. again as a graph we can draw it as follows '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> 2025 12 15 Application of Horn clauses 2025 12 19 https://kaierikniermann.github.io/notes/0059/ 0059 /notes/0059/ Normalizing Horn clauses Definition Something of note when dealing with weakets preconditions in terms of horn clauses is that we have to first normalize them to ensure they are in the correct horn format, which is to say we commonly have some horn clause in the form where represents an expression, to normalize these clauses we lift the expressions out of the parameters for the predicates and into the list of conjuncts, i.e.: So we create fresh variables and assign these to the respective expressions then use them in place of the expressions themselves. 2025 12 22 https://kaierikniermann.github.io/notes/005c/ 005c /notes/005c/ Strongest Postcondition Definition In the most straightforward sense the strongest postcondition, denoted or , denotes the exact or least set of final states which we land in after a successful execution. Set theoretically we can denote it as. We can also use a more logic way of expressing it as follows But the idea is in principle the same, it represents the set of states corresponding to some evaluated result based on some existing safe state. 2025 12 25 https://kaierikniermann.github.io/notes/005k/ 005k /notes/005k/ Computing the strongest post-condition Quiz Consider the following set of Horn clauses 2025 12 15 Abstraction 2025 12 22 https://kaierikniermann.github.io/notes/005d/ 005d /notes/005d/ Abstraction & Concretization function Definition In the most general sense we consider two domains, an abstract domain and a concrete domain . We have two functions the abstraction function and the concretization function Naturally we often instantiate these two domains for different scenarios. 2025 12 22 Example: Interval abstraction Let's consider a basic instance of abstraction where we think of the concrete domain as set's of numbers and the abstract domain as rangers or intervals of numbers which characterize these sets. So formally we say Our concrete domain is the power set of the natural real numbers ordered by set-inclusion so Our abstract domain is represented by intervals in addition to the symbols for true and false, so Our concretization function maps from an interval to all those numbers contained within the interval, so as an example Our abstraction function which takes a concrete element then maps this to the meet or conjunct of all abstract element in which the ordering with the concretization function holds, i.e. the idea is that it represents the most precise abstract representation which can capture the concrete element c. Operationally we can express this equivalently as so more plainly we can understand the abstraction function of just being the most exact combination i.e. meet / conjunction of intervals to express our concrete element. 2025 12 22 Example: Predicate abstraction A common application within the domain of logic and computer science is to consider the concrete domain as referring to formulas or equivalently set's of states, not too much unlike our power-set of numbers. With our abstract state then being a conjunct of predicates from some finite set which best characterize our concrete formulas. Each element in the abstract domain is some permutation of our finite predicate set , so we have each abstract element is defined by the conjunction hence our concretization function yields those set's of concrete states (or predicates representing these states) which satisfy . The abstraction function is then defined more or less the usual way, we take in a concrete set of states then aggregate those predicates which describe our concrete set of states most precisely. can equivalent formulation is Let's consider as an example Here we can define the abstraction function as follows 2025 12 22 https://kaierikniermann.github.io/notes/005e/ 005e /notes/005e/ Abstract strongest postcondition Definition 2025 12 22 The idea Our usual strongest postcondition can be understood as a mapping from a concrete domain to a concrete domain, i.e. Where represents our concrete domain, in the world of program logic this is typically assertions on the state of some memory environment. The idea behind the abstract , is that we have a function In other words we are considering the strongest postcondition from within the abstract domain. Intuitively this just means that our predicates or assertions on the memory states (or equivalently the set of states we characterize) will be expressed in abstract terms. 2025 12 22 In more detail The abstract strongest postcondition, denoted or is defined as Let's explain a bit on how we can derive this, we begin with the idea that for each and each statement we want: This expresses soundness in other words, the resulting set of states, generated by concretizing the abstraction must be contained within the prediction of the abstract transformer predicate . Then using the Galois connection we have between and which expresses the notion that is approximated by . We can rewrite our earlier soundness condition as: two again denote the same conceptual thing that our abstract predicate transformer is an over-approximation of the analogous transformer for the concrete domain. As we would preferably like to have the most precise approximation we choose equality. Or stated differently by definition the most precise abstracted approximation of the strongest post-condition we can have for some abstracted state is literally just this state concretized, and the resulting set abstracted. 2025 12 22 Correctness The most important property to remember about the abstract strongest post-condition is that if we do over-approximate an error state it does not allow us to conclude that the program is wrong. 2025 12 23 https://kaierikniermann.github.io/notes/005g/ 005g /notes/005g/ Lecture 9 - Solving Horn Clauses VU-VFS-2025 2025 12 23 https://kaierikniermann.github.io/notes/005h/ 005h /notes/005h/ Lecture 10 - Information Flow Types VU-VFS-2025 2025 12 23 The type system 2025 12 22 https://kaierikniermann.github.io/notes/005f/ 005f /notes/005f/ Information Flow Types - Rules Definition We define a typing judgement as Expressing that in the context expression has a label 2025 12 23 https://kaierikniermann.github.io/notes/005i/ 005i /notes/005i/ Lecture 11 - Information Flow & Side Channels VU-VFS-2025 2025 12 23 https://kaierikniermann.github.io/notes/005j/ 005j /notes/005j/ Lecture 12 - Refinement Types VU-VFS-2025 2026 2 11 https://kaierikniermann.github.io/notes/005l/ 005l /notes/005l/ Advanced Logic VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005n/ 005n /notes/005n/ Week 1 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/0062/ 0062 /notes/0062/ Lecture 1 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/0064/ 0064 /notes/0064/ Basic modal logic 2026 2 11 https://kaierikniermann.github.io/notes/006g/ 006g /notes/006g/ Examples of modal patterns Example Content 2026 2 11 https://kaierikniermann.github.io/notes/006i/ 006i /notes/006i/ Formulas of modal propositional logic Definition Definition text... 2026 2 11 https://kaierikniermann.github.io/notes/006j/ 006j /notes/006j/ Frame Definition Definition text... 2026 2 11 https://kaierikniermann.github.io/notes/006k/ 006k /notes/006k/ Frame examples Example Example content... 2026 2 11 https://kaierikniermann.github.io/notes/006l/ 006l /notes/006l/ Model and pointed model Definition 2026 2 11 https://kaierikniermann.github.io/notes/006m/ 006m /notes/006m/ Model example Example Example content... 2026 2 11 https://kaierikniermann.github.io/notes/006n/ 006n /notes/006n/ Local truth Definition Definition text... 2026 2 11 https://kaierikniermann.github.io/notes/006o/ 006o /notes/006o/ Local truth in a model Example Example content... 2026 2 11 https://kaierikniermann.github.io/notes/0065/ 0065 /notes/0065/ Dualities Definition Content 2026 2 11 https://kaierikniermann.github.io/notes/0068/ 0068 /notes/0068/ Syntax and semantics of prop1 2026 2 11 https://kaierikniermann.github.io/notes/0066/ 0066 /notes/0066/ Syntax of prop1 Definition Content 2026 2 11 https://kaierikniermann.github.io/notes/0067/ 0067 /notes/0067/ Semantics of prop1 Definition Content 2026 2 11 https://kaierikniermann.github.io/notes/006c/ 006c /notes/006c/ prop1 example Example Example content... 2026 2 11 https://kaierikniermann.github.io/notes/006e/ 006e /notes/006e/ Soundness and completeness Content 2026 2 11 https://kaierikniermann.github.io/notes/006a/ 006a /notes/006a/ Hilbert style proof system Definition 2026 2 11 https://kaierikniermann.github.io/notes/006d/ 006d /notes/006d/ Hilbert proof example Example Example content... 2026 2 11 https://kaierikniermann.github.io/notes/0063/ 0063 /notes/0063/ Lecture 2 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005o/ 005o /notes/005o/ Week 2 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005p/ 005p /notes/005p/ Week 3 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005q/ 005q /notes/005q/ Week 4 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005r/ 005r /notes/005r/ Week 5 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005s/ 005s /notes/005s/ Week 6 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005t/ 005t /notes/005t/ Week 7 VU-AL-2026 2026 2 11 https://kaierikniermann.github.io/notes/005m/ 005m /notes/005m/ Term Rewriting Systems VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005u/ 005u /notes/005u/ Week 1 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005v/ 005v /notes/005v/ Week 2 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005w/ 005w /notes/005w/ Week 3 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005x/ 005x /notes/005x/ Week 4 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005y/ 005y /notes/005y/ Week 5 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/005z/ 005z /notes/005z/ Week 6 VU-TRS-2026 2026 2 11 https://kaierikniermann.github.io/notes/0060/ 0060 /notes/0060/ Week 7 VU-TRS-2026 2025 11 23 https://kaierikniermann.github.io/notes/001a/ 001a /notes/001a/ Blog posts 2025 11 23 https://kaierikniermann.github.io/notes/001b/ 001b /notes/001b/ Understanding recursors with Lean4 Blog 2025 11 23 The recursor for natural numbers Before we define recursors, let's first introduce the idea of an inductive type. We'll do this by examining how lean defines natural numbers. inductive Nat where | zero : Nat | succ (n : Nat) : Nat 2025 11 23 The recursor for natural numbers Before we define recursors, let's first introduce the idea of an inductive type. We'll do this by examining how lean defines natural numbers. inductive Nat where | zero : Nat | succ (n : Nat) : Nat The idea here being that we can construct natural numbers by either using the constructor zero to get 0, or by applying the constructor succ to an existing natural number to get its successor. For example, we can construct 3 as follows: def three : Nat := Nat.succ (Nat.succ (Nat.succ Nat.zero)) We can equivalently express this definition using the type formation and term introduction rules: While this explanation for inductive types usually gives most people I think enough intuition to understand the basic notions of how to use them to construct something like natural numbers, I think it kind of misses the deeper idea of what an inductive type and by extension a recursor really is. To attempt to explain this we'll take a look into some categorical semantics behind inductive types. 20251123https://kaierikniermann.github.io/notes/001c/001c/notes/001c/Natural Number Object (NNO)Definition We assume that is a category with a terminal object . This category has a natural number object (NNO) if there exists an object together with two morphisms: such that, given any global element and any morphism , there exists a unique morphism such that the following diagram commutes: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> While at first this definition seems a bit needlessly abstract, it actually captures what the inductive type of natural numbers really is. The basic thing to recognize is that the two morphisms (just think of them as functions for now) in reality don't have anything to do with natural numbers directly. Instead, they act as a kind of blueprint for how we can use the properties or constraints of natural numbers to make anything. Here on a high level we can describe the two functions / constructors as follows: - The represents the abstract idea of having some starting point or base case. Within natural numbers this is represented by 0, but in reality it denotes an abstract concept of having a starting point. - This represents the abstract idea of being able to build upon existing things to create new things. Within natural numbers this is represented by the successor function. Now this might quite fairly still seem a bit confusing and abstract. How can we use properties to make anything?. To describe this more formally lets constrain ourselves to the category of sets, . If you are unfamiliar with category theory it's sufficient to think of this as just a collection of all kinds of sets and functions between them. 20251123https://kaierikniermann.github.io/notes/001e/001e/notes/001e/Natural Number Object (NNO) in SetExample In the category Set, the natural number object (NNO) can be represented by the set of natural numbers . If we take some arbitrary other set with some point (which can be identified with an element of ) and some function , we can define a unique function as follows: So in plain English what this is saying is that given any set where we have some starting point and some way of building upon existing elements of (the function ), we can use the properties of natural numbers to create a unique function that maps natural numbers to elements of in a way that respects our starting point and building function. A natural next question to have might be But what does it mean to respect the starting point and building function? Here I'd fast say intuitively you can just imagine construct which has some notion of a start and some way of building upon existing things. For example let's imagine the following graph: Clearly here with have: Starting point: Our start here is the node . Building function: Our building function i.e. successor mechanism here is just following the arrows to the next node. So our two morphisms then are: where maps to . where maps each node to the next node along the arrow. That is f(a) = b f(b) = c f(c) = d f(d) = e ... Creating a minimal replica of this in Lean we could do something like: inductive Node where | start : Node -- this will play the role of “a” | next : Node → Node def succNode (v : Node) : Node := Node. next v def natToNode : ℕ → Node | 0 => Node.start | n + 1 => succNode (natToNode n) So we can see our function here is represented by natToNode. Where the function maps 0 to a and each successor natural number to the next node along the arrow. Something you might notice here is that if our natToNode function is replaced by just an identity, i.e.: def natToNat : ℕ → ℕ | 0 => 0 | n + 1 => n + 1 Then we get just the natural numbers themselves as defined by their properties. This is precisely what's expressed by the earlier commutative diagram we say. The two arrows: Are just the natural numbers defined by their properties. So in a sense the natural numbers are the most basic instantiation of their own properties. So now a fair thing to wonder is: So what does this have to do with recursers? Well the key insight here is that our functions natToNat and natToNode both are our recursers for the natural numbers. A recursor is just a function that allows us to define functions out of an inductive type by specifying how to handle each constructor of the inductive type. So equivalently we can express our recursor for natural numbers as: def recNat {C : Type} (z : C) (s : C → C) : ℕ → C | 0 => z | n + 1 => s (recNat z s n) If we examine the actual type signature generated by #check Nat.rec we have: «Nat».rec.{u} {motive : ℕ → Sort u} (zero : motive «Nat».zero) (succ : (n : ℕ) → motive n → motive n.succ) (t : ℕ) : motive t In our examples above we can see that the motive is just the type we are mapping to (either or ), the zero is our starting point (either 0 or a) and the succ is our building function (either the successor function or following the arrows). So using the recursor we can rewrite our earlier natToNat and natToNode functions as: def natToNat : ℕ → ℕ := Nat.rec 0 -- | 0 => 0 (fun n => n + 1) -- | n + 1 => n + 1 def natToNode : ℕ → Node := Nat.rec Node.start -- | 0 => Node.start (fun n => succNode n) -- | n + 1 => succNode (natToNode n) This for the most part covers the basic idea of recursors for the sake of brevity I won't go into more instances of recursors for other inductive types though conceptually they work the same way. You specify how to handle each constructor of the inductive type and the recursor gives you a function that maps from the inductive type to whatever type you specified. 2025 11 23 The connection to induction A very important property of recursors emerges when we make the motive dependent. To elaborate on what that means let's first consider the situation of simple stepwise induction. 2025 11 23 https://kaierikniermann.github.io/notes/001f/ 001f /notes/001f/ Stepwise (Mathematical) Induction Definition Stepwise (mathematical/natural/ordinary) induction is a proof technique used to establish the truth of a statement for all natural numbers . The process involves two main steps: Base Case: Prove that the statement is true. Inductive Step: Assume that the statement is true for some arbitrary natural number (this assumption is called the inductive hypothesis). Then, using this assumption, prove that the statement is also true. If both the base case and the inductive step are successfully proven, we can conclude that the statement holds for all natural numbers . The concise formulation of this can be given by the induction principle. Something we can notice here just by superficial observation alone is that this seems to look an awful lot like the recursor for natural numbers we defined earlier. In fact, it is an application of the recursor for natural numbers for the dependent motive . To make this a little more concrete let's define a simple property over natural numbers: def P (n : ℕ) : Prop := n + 0 = n Now its important to note that in an abstract sense this is no different from any other function from natural numbers to some type. The dependency comes into play when we try to use the recursor i.e. the properties of naturals with this motive. def natToProp (n : ℕ) : (P n) := Nat.rec (motive := P) (by simp [P]) -- base case: P 0 (fun n ih => by simp [P]) -- inductive step: P n → P (n+1) n A few things we can observe here: The recursor here represents a dependent function, which is to say that the return type of the function depends on the input value. Contrasting this to the earlier case where the return type was always just or . Base case - Importantly here as opposed to providing a function that returns some value of type for the base case, we instead provide a proof that the property holds. Inductive step - Similarly for the inductive step we provide a function that takes an arbitrary natural number and a proof that holds (the inductive hypothesis) and returns a proof that holds. If we view this through the lens of the Curry-Howard correspondence it quite nicely illustrates how our proof here is just a program which constructs witnesses (valid proofs) for each natural number that the property holds. In the same way that our earlier recursor provided elements on the correct type, this dependent recursor provides proofs on the correct property. As this application of a recursor to a proposition represents said proposition being true for all natural numbers, we can equivalently use this within a theorem. theorem add_zero (n : ℕ) : n + 0 = n := natToProp n 2025 11 23 Case Study: Evaluating arithmetic expressions As a little kind of case study I want to give an example of an inductive type (and its recursor) that most people become familiar with; in a sense; as early as primary school: the operational semantics of binary operators. We'll start by defining some basic syntax for arithmetic expressions: inductive BinOp where | add : BinOp | sub : BinOp | mul : BinOp | div : BinOp inductive Expr where | const : ℕ → Expr | binop : BinOp → Expr → Expr → Expr So here we have defined a simple language of arithmetic expressions consisting of natural number constants and binary operations. This provides us with the means to construct expressions like: #check Expr.binop BinOp.add (Expr.const 10) (Expr.const 20) If we want to actually define the semantics of how to evaluate these expressions we'll need to define a set of rewrite rules that describe how we can take an expression and reduce it to a value i.e. evaluate it. To evaluate an expression we want to traverse the expression tree and whenever we encounter a binary operation with two constant operands we want to apply the operation and replace the entire sub-expression with the resulting constant. We express this as 3 rewrite rules: Left Evaluation: If the left operand of a binary operation can be reduced, then we reduce it. Right Evaluation: If the left operand is a constant and the right operand can be reduced, then we reduce the right operand. Operation Evaluation: If both operands are constants, we apply the binary operation and replace the entire sub-expression with the resulting constant. def eval_op : BinOp → (Nat → Nat → Nat) | .add => Nat.add | .sub => Nat.sub | .mul => Nat.mul | .div => Nat.div inductive Step : Expr -> Expr -> Prop | ST_BinOp1 (op : BinOp) (e₁ e₁' e₂ : Expr) (h : Step e₁ e₁') : Step (Expr.binop op e₁ e₂) (Expr.binop op e₁' e₂) | ST_BinOp2 (op : BinOp) (v₁ : Nat) (e₂ e₂' : Expr) (h : Step e₂ e₂') : Step (Expr.binop op (Expr.const v₁) e₂) (Expr.binop op (Expr.const v₁) e₂') | ST_BinOpConst (op : BinOp) (v₁ v₂ : Nat) : Step (Expr.binop op (Expr.const v₁) (Expr.const v₂)) (Expr.const (eval_op op v₁ v₂)) Since expressions can naturally require multiple evaluations steps it makes sense to define a multistep evaluation relation as the reflexive transitive closure of the single step evaluation relation defined above. This we can define as: abbrev MultiStep := Relation.ReflTransGen Step -- helper notation to express multi-step evaluation notation:50 e " ->ⁿ " e' => MultiStep e e' Let's also define a small helper syntax and macro to make it easier to write arithmetic expressions: 20251123A small arithmetic expression grammar declare_syntax_cat arithTm -- atoms syntax num : arithTm syntax "(" arithTm ")" : arithTm -- multiplicative level (higher precedence) syntax:70 arithTm:70 "*" arithTm:71 : arithTm syntax:70 arithTm:70 "/" arithTm:71 : arithTm -- additive level (lower precedence) syntax:60 arithTm:60 "+" arithTm:61 : arithTm syntax:60 arithTm:60 "-" arithTm:61 : arithTm syntax "ex{" arithTm "}" : term macro_rules -- numerals | `(ex{ $n:num }) => `(Expr.const $n) -- parentheses | `(ex{ ($t:arithTm) }) => `(ex{$t}) -- addition | `(ex{ $e₁:arithTm + $e₂:arithTm }) => `(Expr.binop BinOp.add (ex{$e₁}) (ex{$e₂})) -- subtraction | `(ex{ $e₁:arithTm - $e₂:arithTm }) => `(Expr.binop BinOp.sub (ex{$e₁}) (ex{$e₂})) -- multiplication | `(ex{ $e₁:arithTm * $e₂:arithTm }) => `(Expr.binop BinOp.mul (ex{$e₁}) (ex{$e₂})) -- division | `(ex{ $e₁:arithTm / $e₂:arithTm }) => `(Expr.binop BinOp.div (ex{$e₁}) (ex{$e₂})) 20251123Describing arithmetic evaluation Now say that we wanted to evaluate the expression on a high level what we would do is rewrite the multiplication to and then rewrite that to . Expressing this in lean we have: example : -- ((2 * 3) + 4) ->ⁿ 10 ex{ ((2 * 3) + 4) } ->ⁿ ex{ 10 } := .trans (rw_lhs (rw_const .mul 2 3)) (rw_const .add 6 4) Here we say that the expression after multiple steps evaluates to by first rewriting the left-hand side multiplication to and then rewriting that to . And we chain these operations together using the .trans constructor of the multistep evaluation relation. Now the question becomes, how do we define these rewrite steps? Intuitively we can imagine evaluation as being described by the following sort of graph +(lhs [op] rhs) | +-+(rw_lhs) ->ⁿ lhs' [op] rhs (1) reduce lhs some number of steps | +-+(rw_rhs) ->ⁿ lhs [op] rhs' (2) reduce rhs some number of steps | +- (rw_const) -> value (3) reduce both to a constant value The idea of each rule being that: rw_lhs: If the left-hand side can be reduced some number of steps we can reduce it while keeping the right-hand side the same. This corresponds to the ST_BinOp1 rule defined earlier. rw_rhs: If the left-hand side is a constant we can reduce the right-hand side some number of steps while keeping the left-hand side the same. This corresponds to the ST_BinOp2 rule defined earlier. rw_const: If both sides are constants we can apply the binary operation and reduce the entire expression to a single constant value. This corresponds to the ST_BinOpConst rule defined earlier. As these rules are defined over the structure of multistep evaluation our implementation of them will naturally be in terms of the inductive structure of a multistep relationship: lemma rw_lhs (lhs_rw : lhs ->ⁿ lhs') : (lhs [op] rhs) ->ⁿ (lhs' [op] rhs) := match lhs_rw with | .refl => .refl | .tail S₁ S₂ => (rw_lhs S₁).tail (.ST_BinOp1 S₂) lemma rw_rhs (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := match rhs_rw with | .refl => .refl | .tail S₁ S₂ => (rw_rhs S₁).tail (.ST_BinOp2 S₂) lemma rw_const (op : BinOp) (lhs rhs : Nat) : ((.const lhs) [op] (.const rhs)) ->ⁿ .const (eval_op op lhs rhs) := .single (.ST_BinOpConst op lhs rhs) Alternatively we can specify the left and right rewrite rules using the recursor or or head induction principle for multistep evaluation: lemma rw_rhs' (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := .rec (refl := .refl) (tail := by intro _ _ _ hcb ih exact ih.tail (.ST_BinOp2 hcb) ) rhs_rw lemma rw_rhs'' (rhs_rw : rhs ->ⁿ rhs') : ((.const lhs) [op] rhs) ->ⁿ ((.const lhs) [op] rhs') := .head_induction_on (refl := .refl) (head := by intro _ _ hac _ ih exact ih.head (.ST_BinOp2 hac) ) rhs_rw The motive function here is inferred by Lean via the Lemma, which allos us to avoid having to explicitly specify it. Other than this we can see that the recursors again simply correspond to providing methods to describe what to do for each of the constructors. 20251123Recursors describe usage So at this point you might, I think fairly ask yourself: Wait why are you spending so much time on this random example for recursors? The main reason is that to me it provides one of the most grounded direct examples of what it means for a recursor function to eliminate a term of an inductive type. In general in type theory we say that term elimination represents the natural deduction rules for how to use terms of a given type. Applied to our example we can see that these recursors precisely correspond to the rules of how we evaluate i.e. use arithmetic expressions. Each rewrite rule describes how we can take an expression and reduce it step by step until we reach a final value. So in a sense the recursor here eliminates the expression by providing a systematic way to break it down into its constituent parts and evaluate it. This is precisely the essence of what recursors do in type theory; they provide a way to systematically deconstruct and utilize terms of inductive types according to their defined structure and properties. 20251123Proving correct evaluation One of the wonderful things we then naturally get from these recursors is that we can use them to describe how a correct evaluation works. So given our evaluation function: @[simp] def eval : Expr -> Nat | Expr.const n => n | Expr.binop op e₁ e₂ => let v₁ := eval e₁ let v₂ := eval e₂ eval_op op v₁ v₂ We can use the recursors describing the rewrite rules to show that this evaluation function for our expressions both yields a constant and that we have some sequence of reduction steps (application of rewrite rules) to get to said constant. Or expressed formally: (e : Expr) : -- for any expression e (∃ v : Nat), -- there exists a value v (eval e = v) ∧ (e ->ⁿ (.const v)) -- such that eval e = v and e reduces to the constant v The proof of this statement works by induction on the structure of the expression e if our expression represents a constant then the proof is trivial as we can just take the value of the constant itself. If our expression represents a binary operation then same as we showed for the concrete example we just apply our recursors to first rewrite the lhs, then the rhs and finally apply the operation to get the final constant value. In full the proof looks like: theorem eval_correct (e : Expr) : ∃ v : Nat, (eval e = v) ∧ (e ->ⁿ (.const v)) := by induction e with | const n => exists n | binop op lhs rhs eval_lhs eval_rhs => rcases eval_lhs with ⟨lhs_v, ⟨rhs_is_v, lhs_rw⟩⟩ rcases eval_rhs with ⟨rhs_v, ⟨lhs_is_v, rhs_rw⟩⟩ simp [rhs_is_v, lhs_is_v] exact (rw_lhs lhs_rw).trans ( (rw_rhs rhs_rw).trans ( rw_const op lhs_v rhs_v ) ) In other words our proof for describing that our evaluation function is correct amounts to essentially simulating or describing quite literally how the evaluation works step by step using the recursors we defined earlier. To see precisely how rcases works here I'd recommend to paste the code into a Lean environment and examine the types of each of the intermediate values. 2025 11 28 https://kaierikniermann.github.io/notes/002r/ 002r /notes/002r/ Type universes in Lean4 Blog 2025 11 28 A brief overview 2025 11 28 Universe hierarchy In Lean4, types are organized into a hierarchy of universes (also referred to as sorts). Each universe is associated with a level, which is a natural number. The operator constructs a universe from a given level. To avoid things like Girard's paradox, Lean4 employs a stratified type system where each universe can only contain types from lower universes, we have the following hierarchy (1): has two main aliases used in Lean4: and . Here, (which is equivalent to ) is the universe of logical propositions, while (which is equivalent to ) represents a universe of types at level . So we can say: In general we can express the hierarchy for any universe level as follows: 2025 11 28 Predicative universes Except propositions, a type in a universe at level cannot quantify over types from strictly larger universes unless the whole result is lifted to a larger universe. In the case of types we have: To demonstrate some valid instance of this inference rule lets consider the following lean examples: example (α : Type 1) (β : Type 2) : Type 2 := α → β example (α : Type 2) (β : Type 1) : Type 2 := α → β Both of the above examples are valid because the resulting type is lifted to the maximum universe level of the input types. In general, we say that the behavior of the universes is called predicative meaning that objects may not be defined in terms of quantifiers ranging over that same object. 2025 11 28 Impredicative universes We can observe that a function type's universe is determined by the universes of its argument and return types. However, in the case of propositions we have a different behavior: Predicates, which are functions that return propositions, may have argument types in any universe, but the function itself remains in the universe. This behavior is called impredicative meaning that objects may be defined in terms of quantifiers ranging over that same object. The rule means that expressions such , which quantify over all propositions (including themselves), yield a proposition, that is: We can see some more examples of quantifying both over propositions and types as follows: /-- Quantifying over propositions yields a proposition -/ example : Prop := ∀ (P : Prop) (p1 p2 : P), p1 = p2 /-- Proposition quantifying over all type stays in Prop -/ example : Prop := ∀ (α : Type), ∀ (x : α), x = x example : Prop := ∀ (α : Type 5), ∀ (x : α), x = x 2025 11 28 The general rule We can combine these two rules to get a more general rule for function types that return types in any universe: Here the function type's universe is determined by the (impredicative max) imax of the universes of its argument and return types, where is defined as follows: 2025 11 28 The level grammar We can describe the level grammar via the following inductive type: inductive Level | zero : Level | succ : Level → Level | max : Level → Level → Level | imax : Level → Level → Level 2025 11 28 Universe Binding 2025 11 28 Explicit We can define functions and types that are universe polymorphic by introducing universe levels either explicitly or implicitly. An explicit universe level is specified directly in the definition, while an implicit universe level is inferred by Lean4. For example: /-- Explicit universe level -/ def map.{u v} {α : Type u} {β : Type v} (f : α → β) : List α → List β := | [] ⇒ [] | x :: xs => f x :: map f xs Here the map is declared with explicit universe levels and and instantiates the polymorphic . We can also define the same function with implicit universe levels as follows: universe u v def map {α : Type u} {β : Type v} (f : α → β) : List α → List β := ... 2025 11 28 Implicit By default in Lean4 the option is set to true, meaning that our universe levels will be inferred automatically meaning that we can simply write: def map {α : Type u} {β : Type v} (f : α → β) : List α → List β := ... Importantly automatic implicit parameter inference only works if the universe is mentioned in the header preceding the assignment, i.e: /-- Bad: unknown universe u -/ def L := List (Type u) /-- Good: universe u mentioned in header -/ def L.{u} := List (Type u) 2025 11 28 Implicit + fresh We can also go even further with implicit universes by allowing Lean4 to generate fresh universe levels for us. This is done by omitting the universe annotation and replacing it with a * suffix: /-- Fresh implicit universe levels -/ def map {α : Type*} {β : Type*} (f : α → β) : List α → List β := ... 2025 11 28 Universe Lifting Sometimes we may want to explicitly lift a type from one universe to a higher universe. Lean4 provides lifting operators which are wrappers around terms of a type that reside in a higher universe. There are two main lifting operators: : Lifts a proposition from to (i.e. ). : Lifts a type from to any number of levels. 2025 11 28 PLift The operator is used to lift propositions into the first type universe. It is defined as follows: structure PLift (α : Sort u) : Type u where /-- Wraps a proof/value to increase its type's universe lvl -/ up :: /-- Extracts a wrapped proof/value from a lifted prop/type. -/ down : α Some simple examples: #check False -- False : Prop #check PLift False -- PLift False : Type #check Nat -- Nat : Type #check PLift Nat -- PLift Nat : Type 1 example : PLift Prop := PLift.up True example : Prop := (PLift.down (PLift.up False)) example : List (PLift True) := [.up (by trivial), .up (by decide)] 2025 11 28 ULift The operator is used to lift types to higher universes. It is defined as follows: structure ULift.{r, s} (α : Type s) : Type (max s r) where /-- Wraps a value to increase its type's universe level. -/ up :: /-- Extracts a wrapped value from a universe-lifted type. -/ down : α Some simple examples: #check Nat -- Nat : Type #check ULift Nat -- ULift Nat : Type 1 #check ULift (ULift Nat) -- ULift (ULift Nat) : Type 2 example : ULift Nat := ULift.up 42 example : List (ULift Nat) := [.up 1, .up 2, .up 3] 2025 11 28 Example: Preorder Category A preorder relation is a binary relation that is reflexive and transitive. In Lean this is expressed as follows: class Preorder (α : Type*) extends LE α, LT α where le_refl : ∀ a : α, a ≤ a le_trans : ∀ a b c : α, a ≤ b → b ≤ c → a ≤ c lt := fun a b => a ≤ b ∧ ¬b ≤ a lt_iff_le_not_ge : ∀ a b : α, a < b ↔ a ≤ b ∧ ¬b ≤ a := by intros; rfl We can already see here that the preorder relation uses implicit universe polymorphism via the annotation. We can now construct a small category from a preorder relation as follows: open CategoryTheory instance {α : Type u} [Preorder α] : SmallCategory α where Hom a b := ULift <| PLift (a ≤ b) id a := .up <| .up <| le_refl a comp {a b c} f g := .up <| .up <| (le_trans f.down.down g.down.down) Let's break this down part by part starting with the homomorphism: 2025 11 28 Arrows For the case of the category definition, Lean fundamentally uses quivers to represent the homs between objects. Now before showing how lean defines them lets I think try and do it ourselves. So in this instance in an abstract sense we want the relationship to represent our morphism or arrow between two objects, so in a sense the following two are equivalent: So in the most straightforward sense what we can do is define any kind of "container" to represent our source and target objects under some label, we can define this naively as follows: class Graph (Obj : Type) where arrow (source : Obj) (target : Obj) : Type Now let's try to define an instance of such a graph on a preorder relation in which our objects simply live in : instance {α : Type} [Preorder α] : Graph α where arrow a b := a ≤ b -- arrow from a to b is the relation a ≤ b Here we are declaring an instance, this instance takes An implicit type parameter which is the type of our objects at the universe level 0. A type class constraint which ensures that the type has a preorder relation defined on it. In other words it guarantees that the relation is reflexive and transitive for all elements of type . And we provide the necessary implementation for the function by setting it to be the preorder relation . But what you will notice is that we have a problem here, namely that our preorder relation lives in the universe as it's obviously a logical relation, but our graph arrows need to live in (i.e. ). A first thought might be to just set the arrow type to be directly, in our definition of the class though this is rather restrictive as it means that any graph we wish to define can only ever have arrows representing propositions, what if we want to have arrows represent other types such as functions or numbers? One way to approach this is to use the operator to lift our preorder relation from to as follows: instance {α : Type} [Preorder α] : Graph α where arrow a b := PLift (a ≤ b) -- lift relation to Type 0 While this does work, and often is probably a reasonable way to go about things, much of Lean's mathlib employs universe polymorphic types to define various kinds of structures. Thus parameterizing over some universe level we define our polymorphic instance as: instance {α : Type u} [Preorder α] : Graph α where arrow a b := PLift (a ≤ b) But now we naturally run into another issue, namely that the class for our graph is now no longer universe polymorphic which leads to a universe level mismatch. The most straightforward fix here is to simply make the objects in the graph universe polymorphic as well: class Graph (Obj : Type u) where -- now polymorphic over u arrow (source : Obj) (target : Obj) : Type But this leads to another question, what level should the arrows live in? We've already seen that arrows can represent various different kinds of things different from the types of objects themselves, (e.g. is a proposition but clearly 2 and 3 are numbers). Now one approach is to simply leave the arrows in but this already is mildly annoying as it forces us to lift any arrows that don't naturally live in . Furthermore, we've already seen that having the type stuck at Prop is also not nice, so what we can do is make the arrows' universe polymorphic as well, though over a different universe level motivated by the aforementioned situation of different levels of arrows and objects: class Graph (Obj : Type u) where arrow (source : Obj) (target : Obj) : Sort v instance {α : Type u} [Preorder α] : Graph α where arrow a b := a ≤ b -- now lives in Sort 0 (i.e. Prop) But hold up, why are we lifting in the definition of the instance for the SmallCategory? Let's take a look at all the relevant type signatures: -- Quiver -- (V : Type u) where -- CategoryStruct -- (obj : Type u) : Type max u (v + 1) extends Quiver.{v + 1} obj -- Category -- (obj : Type u) : Type max u (v + 1) extends CategoryStruct.{v} obj -- SmallCategory -- (obj : Type u) : Type (u + 1) extends Category.{u} obj Let's break this down step by step starting first with the relationship between CategoryStruct and Quiver, for the sake of simplicity i'll abstract away some exact names and make all universes explicit: variable {α : Type m} [Preorder α] (a b c : α) class Box.{u, v} (obj : Type u) where pair : obj → obj → Sort v class A.{u, v} (obj : Type u) : Type max u (v + 1) extends (Box.{u, v + 1} obj) where I think an interesting question I first had here is with the extension of in why might you want to increase the universe level of the arrows by one? The main reason this is done in general is to essentially constrain the to never be zero. The implication of this being that our extended class can never have any pairs which live in . A good follow up to this might be, why would you not want things to live in ? In the most general sense some reasons are: is proof irrelevant: In Lean, propositions are considered proof irrelevant, meaning that all proofs of a given proposition are treated as equal. This can lead to loss of information when you want to be able to distinguish between different morphisms or in our simplified example pairs. is not computational: Propositions in Lean are not computationally relevant, meaning that they do not have computational content. If you want to perform computations or extract algorithms from your morphisms or pairs, having them in would prevent that. has limited structure: Propositions in Lean do not have the same rich structure as types in higher universes. If you need to work with morphisms or pairs that have additional structure (like being functions, sets, etc.), you would want them to live in a higher universe. As an example we can consider the following: -- @classname disables universe inference for that class variable (a₁ : @A.{m, v} α) #check (a₁.pair a b : Sort (v + 1)) -- Box.pair a b : Type v We can see here that the pair now lives in , meaning that if we had then our pairs would now live in . A natural byproduct of this choice - having arrows live in - is that the type of the structure itself must now live in the largest universe such that it can contain both the objects and the arrows. This is why we have the type signature for . Equivalently we can expand this as: -- since Type u = Sort (u + 1) and Type (v + 1) = Sort (v + 2) Sort (max (u + 1) (v + 2)) If we then create similarly abstract versions for the Category class (B) and SmallCategory class (C) we have: class B.{u, v} (obj : Type u) : Type max u (v + 1) extends A.{u, v} obj where class C.{u} (obj : Type u) : Type (u + 1) extends B.{u, u} obj where -- ^ can also type B.{u} (inferres v = u) We can see here that our SmallCategory (C) now constrains the arrows to live in the same universe as the objects by setting in the extension of . Thus, if we construct our pair, we have: variable (c : @C.{m} α) #check (c.pair a b : Sort (m + 1)) -- Box.pair a b : Type m 2025 11 28 Identity morphism Next up let's look at the identity morphism: id a := .up <| .up <| le_refl a The identity is defined as a function that quantifies over all objects in our category and returns an arrow from to . Naturally we then first want to construct our arrow, the identity arrow from to is simply the reflexivity property of the preorder relation , that is which we can get via . However since our arrows live in , we need to lift our relation twice, first using to lift it from to , and then again using to lift it from to . A note to make for people unfamiliar with the syntax here, the following pieces of code are equivalent: -- .up <| .up <| le_refl a == ULift.up (PLift.up (le_refl a)) 2025 11 28 Composition Finally let's look at the composition of arrows: comp {a b c} f g := .up <| .up <| (le_trans f.down.down g.down.down) The lifting portion here follows the same reasoning as the identity morphism, we need to lift the resulting relation from to . The actual composition is done via the transitivity property of the preorder relation . The thing is here that our input arrows and are both lifted types corresponding to: f : ULift (PLift (a ≤ b)) g : ULift (PLift (b ≤ c)) Thus to extract the actual preorder relations we need to use the method twice, first to go from to , and then again to go from to the actual relation in . Once we have the two relations extracted we can then apply the transitivity property to get the composed relation (which we then lift back up). 2025 11 29 https://kaierikniermann.github.io/notes/002u/ 002u /notes/002u/ A simple Bool category in Lean4 Blog 2025 11 27 https://kaierikniermann.github.io/notes/002m/ 002m /notes/002m/ Category Definition There are a few ways you can define a category. In the most basic intuitive sense a category consists of a collection of things called objects and binary relationships (or transitions) between those objects called morphisms (or arrows). We can combine these relationships by composing them, and for each object there is an identity morphism that acts as a neutral element for composition. (1) In the context of quivers a category can be defined as a quiver with a rule saying for how we can compose two edges that fit together to get a new edge. Furthermore, each vertex (object) has an edge starting and ending at that vertex (the identity morphism). The classical definition is something like this: 2025 11 27 The data A category consists of: A collection (or class (2)) of objects, denoted as or . A collection (or set (2)) of morphisms (or arrows), denoted or for . For every morphism , there are two associated objects: the source (or domain) and the target (or co-domain) . In standard function notation, we write where and . NLab has a nice convention where it denotes the source of a morphism as and the target as . For every pair of morphisms and (s.t. i.e. the morphisms type check), there is a composition morphism . Written out we can denote this as: in diagrammatic order this is often written as we can equivalently use a more graphical notation: '. \tikzset{between/.style n args={2}{/tikz/spath/at end path construction={ \tikzset{spath/split at keep middle={current}{#1}{#2}} }}} % TikZ arrowhead/tail styles. \tikzset{tail reversed/.code={\pgfsetarrowsstart{tikzcd to}}} \tikzset{2tail/.code={\pgfsetarrowsstart{Implies[reversed]}}} \tikzset{2tail reversed/.code={\pgfsetarrowsstart{Implies}}} % TikZ arrow styles. \tikzset{no body/.style={/tikz/dash pattern=on 0 off 1mm}} ]]> For every object there is an identity morphism: Note: Some additional notations for morphisms include , or . Additionally, people use the notation to denote the following disjoint union Which just expresses the idea that the collection of all morphisms in a category is made up of the morphisms between each pair of objects. 2025 11 27 The axioms The above are often called data of a category. In addition to this data, a category must satisfy the following axioms or (conditions): Morphisms need to be associative which means that for every triple of morphisms , , and the following holds: For each morphism the identity morphisms act as neutral elements for composition: This is also known as the left and right unit laws or just unity in general. 2025 11 27 Remarks A category such as the one described above is often also called a 1-category to distinguish it from higher categories such as 2-categories, n-categories. 2025 11 29 https://kaierikniermann.github.io/notes/002s/ 002s /notes/002s/ Isomorphism (morphisms) Definition A morphism is called an Isomorphism if there exists a morphism such that the following hold (1): Sometimes an isomorphism is also denoted 2025 11 29 The category Example 2025 11 29 The data We want to start off by defining the data of our category. On a high level we want to define a category with two objects, and . Starting with the object representation we have: /-- A wrapper type to make a custom category on Bool -/ structure BoolCat : Type where val : Bool deriving DecidableEq, Repr /-- The two objects -/ def BoolCat.tt : BoolCat := ⟨true⟩ def BoolCat.ff : BoolCat := ⟨false⟩ Next we want to define the morphisms between these objects. For each pair of objects we express 3 kinds of morphisms: the identity morphism, a morphism from to , from to . We can express this in Lean as follows: /-- Morphisms: we allow identity on each, plus iso between them -/ inductive BCHom : BoolCat → BoolCat → Type | id (b : BoolCat) : BCHom b b | swap : BCHom BoolCat.tt BoolCat.ff | swapInv : BCHom BoolCat.ff BoolCat.tt Formally what this describes is a kind of piecewise function: 2025 11 29 Composition and Category instance Now we have some notion of objects and morphisms between them, we can move on to defining composition of morphisms. def comp : {X Y Z : BoolCat} → BCHom Y Z → BCHom X Y → BCHom X Z | _, _, _, id _, f => f | _, _, _, f, id _ => f | _, _, _, swapInv, swap => id _ | _, _, _, swap, swapInv => id _ This defines composition by pattern matching on the possible morphism combinations. Note that we have to explicitly handle the cases where we compose and to get the identity morphism on the respective objects. To construct our category we have to provide proofs for the category axioms, namely associativity and identity. @[simp] theorem id_comp' {X Y : BoolCat} (f : BCHom X Y) : comp (id Y) f = f := by cases f <;> rfl @[simp] theorem comp_id' {X Y : BoolCat} (f : BCHom X Y) : comp f (id X) = f := by cases f <;> rfl theorem assoc' (f : BCHom W X) (g : BCHom X Y) (h : BCHom Y Z) : comp h (comp g f) = comp (comp h g) f := by cases f <;> cases g <;> cases h <;> rfl With all this in place we can finally define our category instance: instance : Category BoolCat where -- The data Hom := BCHom id := BCHom. id comp := fun f g => BCHom. comp g f -- Category laws id_comp := fun f => BCHom.comp_id' f comp_id := fun f => BCHom.id_comp' f assoc := fun f g h => BCHom.assoc' f g h 2025 11 29 Isomorphisms in the Bool category Since we clearly see that the morphisms and are inverses of each other, we can construct an isomorphism between the two objects and as follows: def ttFfIso : BoolCat.tt ≅ BoolCat.ff where hom := BCHom.swap inv := BCHom.swapInv hom_inv_id := rfl inv_hom_id := rfl We can see that lean uses a similar notation for isomorphism as we do in our notes, namely the symbol between the two objects. We can see that an isomorphism consists of a and an morphism along with proofs that composing them in either order yields the respective identity morphism. In Lean4 its defined as follows: structure Iso {C : Type u} [Category.{v} C] (X Y : C) where /-- The forward direction of an isomorphism. -/ hom : X ⟶ Y /-- The backwards direction of an isomorphism. -/ inv : Y ⟶ X /-- Composition is the identity on the source. -/ hom_inv_id : hom ≫ inv = 𝟙 X := by cat_disch /-- Composition, in reverse, is the identity on the target. -/ inv_hom_id : inv ≫ hom = 𝟙 Y := by cat_disch ... /-- Notation for an isomorphism in a category. -/ infixr:10 " ≅ " => Iso We can check out some properties of our isomorphism like so: -- Verify it's an isomorphism #check ttFfIso -- BoolCat.tt ≅ BoolCat.ff #check ttFfIso.hom -- BoolCat.tt ⟶ BoolCat.ff #check ttFfIso.inv -- BoolCat.ff ⟶ BoolCat.tt Furthermore we can also show the identity isomorphism : -- Every object is isomorphic to itself (trivially) def ttSelfIso : BoolCat.tt ≅ BoolCat.tt := Iso.refl _ #check ttSelfIso -- BoolCat.tt ≅ BoolCat.tt Finally for the sake of completeness we can also demonstrate the isomorphism laws in examples as so: -- The isomorphism laws example : ttFfIso.hom ≫ ttFfIso.inv = 𝟙 BoolCat.tt := ttFfIso.hom_inv_id example : ttFfIso.inv ≫ ttFfIso.hom = 𝟙 BoolCat.ff := ttFfIso.inv_hom_id Backlinks Related Contributions