## Foundations #

We have seen all the ingredients of the foundations of mathematics as implemented in Lean. Our goal now is to:

- Systematically review them.
- Put them in the context of what we mean by foundations of mathematics.
- Separate the foundations from the syntax parsing and elaboration which help us work efficiently with Lean.

### Foundations of foundations #

The starting assumption is that we are in agreement with the meaning of syntax, including pattern matching and substitution. For example, we can understand the following definition is valid in Lean, assuming we know what `ℕ`

means:

```
def cube : ℕ → ℕ := fun n → n * n * n
```

and that we can deduce from the above that `cube 3 = 3 * 3 * 3`

.

We have **rules** for foundations based on syntax. We also assume that the rules can be checked *mechanically*, i.e., by a computer program, and we are convinced that some such program is correct. For a flexible syntax, this is a non-trivial task. So we may want to restrict to a simpler syntax (as we will when we consider *classical foundations*).

We have to also check that we correctly represent the corresponding "real world" concept.

### Context, Rules, Terms #

We assume that at any point we have a **Context**. In Lean this means that we have terms that we can refer to by name, and that these terms have a type, though this may be an *expression*.

In any context, we have **Rules** to

- form
*expressions*from*terms*and*expressions*, with a well-formed expression representing a term. - make two kinds of
**judgments**:`e : t`

means that`e`

is an expression of type`t`

.`e = e'`

means that`e`

and`e'`

are equal expressions.

### Generative grammars #

Expressions and Rules are based on a *generative* grammar. Thus, we do not specify whether an expression or judgement is valid or not. Instead, we specify how we can make well-formed expressions and valid judgements.

### Local Contexts #

In addition to the names in the context, we can have some names that are only valid in a particular expression. These are called **local variables**.

### Initial Context #

Even an empty Lean file does not have an empty context. Instead the context has Foundational Types.

### Axioms #

We can add axioms to the context. This means that we introduce a term and give an expression for its type. This should be done with care so that the context does not become inconsistent.

### Rules for Lean #

The rules for Lean let us introduce expressions and at the same time make judgements about them.

- Function types
- Function application
- Function definitions by λ-abstraction.
- Π-types
- Dependent function definition and application
- Inductive types
- Indexed inductive types

### Propositions as Types #

Remarkably, the same set of rules let us encode both objects of mathematics and statements about them. The statements (called **propositions**) are encoded as types with a proof of the proposition being a term of that type.

Logical connectives are encoded as *function types*, *Π-types*, and *inductive types*. The rules for deduction follow from the rules for Lean.

In Lean, there is an additional rule for a proposition `α : Prop`

, namely if `p : α`

and `q : α`

then `p = q`

.

We use various rules:

- Given types
`α`

and`β`

, we can form the type of functions from`α`

to`β`

, written`α → β`

. - We can form a function application
`f x`

from a function`f`

and an argument`x`

. - We can form a function definition
`fun x ↦ e`

from a variable`x`

and an expression`e`

, where`e`

is defined in the local context with the additional expression`x`

. - When defining a function using
`x ↦ e`

, we also introduce a rule that the function applied to`a`

is the result of substituting`a`

for`x`

in`e`

. - In the definition below, types should match.
- Often Lean can infer some of the types.

A `theorem`

is just like a definition, except

- The type must be a proposition, i.e. the type of the type must be
`Prop`

. - The type must be fully inferred from the left-hand side.
- The value is then a proof of the proposition.

## Π-types #

These can be viewed as:

- products of a family of types indexed by a type.
- a type corresponding to functions whose codomain
*depends*on the argument. - these are sections of a bundle.

We consider an example

We define a dependent function associating to a natural number `n`

the tuple of `n`

natural numbers `(n, n-1, ..., 0)`

.

- this has type
`(n: ℕ) → NatTuple (n + 1)`

.

## Equations

- descending 0 = (0, ())
- descending (Nat.succ n) = (n + 1, descending n)