Lean mathlib notes
Various implementation details are noted in the mathlib source, and referenced later on. We collect these notes here.
Design choices about smooth algebraic structures

All smooth algebraic structures on
G
areProp
valued classes that extendsmooth_manifold_with_corners I G
. This way we save users from adding both[smooth_manifold_with_corners I G]
and[has_smooth_mul I G]
to the assumptions. While many API lemmas hold true without thesmooth_manifold_with_corners I G
assumption, we're not aware of a mathematically interesting monoid on a topological manifold such that (a) the space is not asmooth_manifold_with_corners
; (b) the multiplication is smooth at(a, b)
in the chartsext_chart_at I a
,ext_chart_at I b
,ext_chart_at I (a * b)
. 
Because of
model_prod
we can't assume, e.g., that alie_group
is modelled onπ(π, E)
. So, we formulate the definitions and lemmas for any model. 
While smoothness of an operation implies its continuity, lemmas like
has_continuous_mul_of_smooth
can't be instances becausen otherwise Lean would have to search forhas_smooth_mul I G
with unknownπ
,E
,H
, andI : model_with_corners π E H
. If users needs[has_continuous_mul G]
in a proof about a smooth monoid, then they need to either add[has_continuous_mul G]
as an assumption (worse) or usehaveI
in the proof (better).
addition on function coercions
Terms containing @has_add.add (has_coe_to_fun.F ...) pi.has_add
seem to cause leanchecker to crash due to an outofmemory
condition.
As a workaround, we add a type annotation: (f + g : Vβ β Vβ)
bundled maps over different rings
Frequently, we find ourselves wanting to express a bilinear map M ββ[R] N ββ[R] P
or an
equivalence between maps (M ββ[R] N) ββ[R] (M' ββ[R] N')
where the maps have an associated ring
R
. Unfortunately, using definitions like these requires that R
satisfy comm_semiring R
, and
not just semiring R
. Using M ββ[R] N β+ P
and (M ββ[R] N) β+ (M' ββ[R] N')
avoids this
problem, but throws away structure that is useful for when we do have a commutative (semi)ring.
To avoid making this compromise, we instead state these definitions as M ββ[R] N ββ[S] P
or
(M ββ[R] N) ββ[S] (M' ββ[R] N')
and require smul_comm_class S R
on the appropriate modules. When
the caller has comm_semiring R
, they can set S = R
and smul_comm_class_self
will populate the
instance. If the caller only has semiring R
they can still set either R = β
or S = β
, and
add_comm_monoid.nat_smul_comm_class
or add_comm_monoid.nat_smul_comm_class'
will populate
the typeclass, which is still sufficient to recover a β+
or β+
structure.
An example of where this is used is linear_map.prod_equiv
.
category_theory universes
The typeclass category C
describes morphisms associated to objects of type C : Type u
.
The universe levels of the objects and morphisms are independent, and will often need to be
specified explicitly, as category.{v} C
.
Typically any concrete example will either be a small_category
, where v = u
,
which can be introduced as
universes u
variables {C : Type u} [small_category C]
or a large_category
, where u = v+1
, which can be introduced as
universes u
variables {C : Type (u+1)} [large_category C]
In order for the library to handle these cases uniformly,
we generally work with the unconstrained category.{v u}
,
for which objects live in Type u
and morphisms live in Type v
.
Because the universe parameter u
for the objects can be inferred from C
when we write category C
, while the universe parameter v
for the morphisms
can not be automatically inferred, through the category theory library
we introduce universe parameters with morphism levels listed first,
as in
universes v u
or
universes vβ vβ uβ uβ
when multiple independent universes are needed.
This has the effect that we can simply write category.{v} C
(that is, only specifying a single parameter) while u
will be inferred.
Often, however, it's not even necessary to include the .{v}
.
(Although it was in earlier versions of Lean.)
If it is omitted a "free" universe will be used.
classical lemma
We make decidability results that depends on classical.choice
noncomputable lemmas.
 We have to mark them as noncomputable, because otherwise Lean will try to generate bytecode
for them, and fail because it depends on
classical.choice
.  We make them lemmas, and not definitions, because otherwise later definitions will raise
"failed to generate bytecode" errors when writing something like
letI := classical.dec_eq _
. Cf. https://leanprovercommunity.github.io/archive/stream/113488general/topic/noncomputable.20theorem.html
coercion into rings
Coercions such as nat.cast_coe
that go from a concrete structure such as
β
to an arbitrary ring Ξ±
should be set up as follows:
@[priority 900] instance : has_coe_t β Ξ± := β¨...β©
It needs to be has_coe_t
instead of has_coe
because otherwise typeclass
inference would loop when constructing the transitive coercion β β β β β β ...
.
The reduced priority is necessary so that it doesn't conflict with instances
such as has_coe_t Ξ± (option Ξ±)
.
For this to work, we reduce the priority of the coe_base
and coe_trans
instances because we want the instances for has_coe_t
to be tried in the
following order:
has_coe_t
instances declared in mathlib (such ashas_coe_t Ξ± (with_top Ξ±)
, etc.)coe_base
, which contains instances such ashas_coe (fin n) n
nat.cast_coe : has_coe_t β Ξ±
etc.coe_trans
If coe_trans
is tried first, then nat.cast_coe
doesn't get a chance to apply.
custom simps projection
You can specify custom projections for the @[simps]
attribute.
To do this for the projection my_structure.original_projection
by adding a declaration
my_structure.simps.my_projection
that is definitionally equal to
my_structure.original_projection
but has the projection in the desired (simpnormal) form.
Then you can call
initialize_simps_projections (original_projection β my_projection, ...)
to register this projection.
Running initialize_simps_projections
without arguments is not necessary, it has the same effect
if you just add @[simps]
to a declaration.
If you do anything to change the default projections, make sure to call either @[simps]
or
initialize_simps_projections
in the same file as the structure declaration. Otherwise, you might
have a file that imports the structure, but not your custom projections.
decidable arguments
As mathlib is primarily classical,
if the type signature of a def
or lemma
does not require any decidable
instances to state,
it is preferable not to introduce any decidable
instances that are needed in the proof
as arguments, but rather to use the classical
tactic as needed.
In the other direction, when decidable
instances do appear in the type signature,
it is better to use explicitly introduced ones rather than allowing Lean to automatically infer
classical ones, as these may cause instance mismatch errors later.
decidable namespace
In most of mathlib, we use the law of excluded middle (LEM) and the axiom of choice (AC) freely.
The decidable
namespace contains versions of lemmas from the root namespace that explicitly
attempt to avoid the axiom of choice, usually by adding decidability assumptions on the inputs.
You can check if a lemma uses the axiom of choice by using #print axioms foo
and seeing if
classical.choice
appears in the list.
dsimp, simp
Many proofs in the category theory library use the dsimp, simp
pattern,
which typically isn't necessary elsewhere.
One would usually hope that the same effect could be achieved simply with simp
.
The essential issue is that composition of morphisms involves dependent types.
When you have a chain of morphisms being composed, say f : X βΆ Y
and g : Y βΆ Z
,
then simp
can operate succesfully on the morphisms
(e.g. if f
is the identity it can strip that off).
However if we have an equality of objects, say Y = Y'
,
then simp
can't operate because it would break the typing of the composition operations.
We rarely have interesting equalities of objects
(because that would be "evil"  anything interesting should be expressed as an isomorphism
and tracked explicitly),
except of course that we have plenty of definitional equalities of objects.
dsimp
can apply these safely, even inside a composition.
After dsimp
has cleared up the object level, simp
can resume work on the morphism level 
but without the dsimp
step, because simp
looks at expressions syntactically,
the relevant lemmas might not fire.
There's no bound on how many times you potentially could have to switch back and forth,
if the simp
introduced new objects we again need to dsimp
.
In practice this does occur, but only rarely, because simp
tends to shorten chains of compositions
(i.e. not introduce new objects at all).
forgetful inheritance
Suppose that one can put two mathematical structures on a type, a rich one R
and a poor one
P
, and that one can deduce the poor structure from the rich structure through a map F
(called a
forgetful functor) (think R = metric_space
and P = topological_space
). A possible
implementation would be to have a type class rich
containing a field R
, a type class poor
containing a field P
, and an instance from rich
to poor
. However, this creates diamond
problems, and a better approach is to let rich
extend poor
and have a field saying that
F R = P
.
To illustrate this, consider the pair metric_space
/ topological_space
. Consider the topology
on a product of two metric spaces. With the first approach, it could be obtained by going first from
each metric space to its topology, and then taking the product topology. But it could also be
obtained by considering the product metric space (with its sup distance) and then the topology
coming from this distance. These would be the same topology, but not definitionally, which means
that from the point of view of Lean's kernel, there would be two different topological_space
instances on the product. This is not compatible with the way instances are designed and used:
there should be at most one instance of a kind on each type. This approach has created an instance
diamond that does not commute definitionally.
The second approach solves this issue. Now, a metric space contains both a distance, a topology, and a proof that the topology coincides with the one coming from the distance. When one defines the product of two metric spaces, one uses the sup distance and the product topology, and one has to give the proof that the sup distance induces the product topology. Following both sides of the instance diamond then gives rise (definitionally) to the product topology on the product space.
Another approach would be to have the rich type class take the poor type class as an instance parameter. It would solve the diamond problem, but it would lead to a blow up of the number of type classes one would need to declare to work with complicated classes, say a real inner product space, and would create exponential complexity when working with products of such complicated spaces, that are avoided by bundling things carefully as above.
Note that this description of this specific case of the product of metric spaces is oversimplified
compared to mathlib, as there is an intermediate typeclass between metric_space
and
topological_space
called uniform_space
. The above scheme is used at both levels, embedding a
topology in the uniform space structure, and a uniform structure in the metric space structure.
Note also that, when P
is a proposition, there is no such issue as any two proofs of P
are
definitionally equivalent in Lean.
To avoid boilerplate, there are some designs that can automatically fill the poor fields when
creating a rich structure if one doesn't want to do something special about them. For instance,
in the definition of metric spaces, default tactics fill the uniform space fields if they are
not given explicitly. One can also have a helper function creating the rich structure from a
structure with less fields, where the helper function fills the remaining fields. See for instance
uniform_space.of_core
or real_inner_product.of_core
.
For more details on this question, called the forgetful inheritance pattern, see Competing inheritance paths in dependent type theory: a case study in functional analysis.
referenced by: [1] [2] [3] [4] [5] [6] [7]function coercion
Many structures such as bundled morphisms coerce to functions so that you can
transparently apply them to arguments. For example, if e : Ξ± β Ξ²
and a : Ξ±
then you can write e a
and this is elaborated as βe a
. This type of
coercion is implemented using the has_coe_to_fun
type class. There is one
important consideration:
If a type coerces to another type which in turn coerces to a function,
then it must implement has_coe_to_fun
directly:
structure sparkling_equiv (Ξ± Ξ²) extends Ξ± β Ξ²
 if we add a `has_coe` instance,
instance {Ξ± Ξ²} : has_coe (sparkling_equiv Ξ± Ξ²) (Ξ± β Ξ²) :=
β¨sparkling_equiv.to_equivβ©
 then a `has_coe_to_fun` instance **must** be added as well:
instance {Ξ± Ξ²} : has_coe_to_fun (sparkling_equiv Ξ± Ξ²) :=
β¨Ξ» _, Ξ± β Ξ², Ξ» f, f.to_equiv.to_funβ©
(Rationale: if we do not declare the direct coercion, then βe a
is not in
simpnormal form. The lemma coe_fn_coe_base
will unfold it to ββe a
. This
often causes loops in the simplifier.)
implicit instance arguments
There are places where typeclass arguments are specified with implicit {}
brackets instead of
the usual []
brackets. This is done when the instances can be inferred because they are implicit
arguments to the type of one of the other arguments. When they can be inferred from these other
arguments, it is faster to use this method than to use type class inference.
For example, when writing lemmas about (f : Ξ± β+* Ξ²)
, it is faster to specify the fact that Ξ±
and Ξ²
are semiring
s as {rΞ± : semiring Ξ±} {rΞ² : semiring Ξ²}
rather than the usual
[semiring Ξ±] [semiring Ξ²]
.
is_R_or_C instance
This instance generates a typeclass problem with a metavariable ?m
that should satisfy
is_R_or_C ?m
. Since this can only be satisfied by β
or β
, this does not cause problems.
likely generated binder names
In surface Lean, we can write anonymous Ξ binders (i.e. binders where the argument is not named) using the function arrow notation:
inductive test : Type
 intro : unit β test
After elaboration, however, every binder must have a name, so Lean generates
one. In the example, the binder in the type of intro
is anonymous, so Lean
gives it the name αΎ°
:
test.intro : β (αΎ° : unit), test
When there are multiple anonymous binders, they are named αΎ°_1
, αΎ°_2
etc.
Thus, when we want to know whether the user named a binder, we can check whether the name follows this scheme. Note, however, that this is not reliable. When the user writes (for whatever reason)
inductive test : Type
 intro : β (αΎ° : unit), test
we cannot tell that the binder was, in fact, named.
The function name.is_likely_generated_binder_name
checks if
a name is of the form αΎ°
, αΎ°_1
, etc.
lower instance priority
Certain instances always apply during typeclass resolution. For example, the instance
add_comm_group.to_add_group {Ξ±} [add_comm_group Ξ±] : add_group Ξ±
applies to all typeclass
resolution problems of the form add_group _
, and typeclass inference will then do an
exhaustive search to find a commutative group. These instances take a long time to fail.
Other instances will only apply if the goal has a certain shape. For example
int.add_group : add_group β€
or
add_group.prod {Ξ± Ξ²} [add_group Ξ±] [add_group Ξ²] : add_group (Ξ± Γ Ξ²)
. Usually these instances
will fail quickly, and when they apply, they are almost the desired instance.
For this reason, we want the instances of the second type (that only apply in specific cases) to
always have higher priority than the instances of the first type (that always apply).
See also #1561.
Therefore, if we create an instance that always applies, we set the priority of these instances to 100 (or something similar, which is below the default value of 1000).
referenced by: [1]module definition
Modules are defined as an abbreviation
for semimodules,
if the base semiring is a ring.
(A previous definition made module
a structure
defined to be semimodule
.)
This has as advantage that modules are completely transparent
for type class inference, which means that all instances for semimodules
are immediately picked up for modules as well.
A cosmetic disadvantage is that one can not extend modules as such,
in definitions such as normed_space
.
The solution is to extend semimodule
instead.
no instance on morphisms
We have lemmas stating that the composition of two morphisms is again a morphism.
Since composition is reducible, type class inference will always succeed in applying these
instances. For example when the goal is just β’ is_mul_hom f
the instance is_mul_hom.comp
will still succeed, unifying f
with f β (Ξ» x, x)
. This causes type class inference to loop.
To avoid this, we do not make these lemmas instances.
nolint_ge
Currently, the linter forbids the use of >
and β₯
in definitions and
statements, as they cause problems in rewrites.
They are still allowed in statements such as bounded (β₯)
or β Ξ΅ > 0
or β¨ n β₯ m
,
and the linter allows that.
If you write a pattern where you bind two or more variables, like β n m > 0
, the linter will
flag this as illegal, but it is also allowed. In this case, add the line
@[nolint ge_or_gt]  see Note [nolint_ge]
open expressions
Some declarations work with open expressions, i.e. an expr that has free variables.
Terms will free variables are not welltyped, and one should not use them in tactics like
infer_type
or unify
. You can still do syntactic analysis/manipulation on them.
The reason for working with open types is for performance: instantiating variables requires
iterating through the expression. In one performance test pi_binders
was more than 6x
quicker than mk_local_pis
(when applied to the type of all imported declarations 100x).
operator precedence of big operators
There is no established mathematical convention
for the operator precedence of big operators like β
and β
.
We will have to make a choice.
Online discussions, such as https://math.stackexchange.com/q/185538/30839
seem to suggest that β
and β
should have the same precedence,
and that this should be somewhere between *
and +
.
The latter have precedence levels 70
and 65
respectively,
and we therefore choose the level 67
.
In practice, this means that parentheses should be placed as follows:
β k in K, (a k + b k) = β k in K, a k + β k in K, b k β
β k in K, a k * b k = (β k in K, a k) * (β k in K, b k)
(Example taken from page 490 of Knuth's Concrete Mathematics.)
partiallyapplied ext lemmas
When possible, ext
lemmas are stated without a full set of arguments. As an example, for bundled
homs f
, g
, and of
, f.comp of = g.comp of β f = g
is a better ext
lemma than
(β x, f (of x) = g (of x)) β f = g
, as the former allows a second typespecific extensionality
lemmas to be applied to f.comp of = g.comp of
.
If the domain of of
is β
or β€
and of
is a ring_hom
, such a lemma could then make the goal
f (of 1) = g (of 1)
.
For bundled morphisms, there is a ext
lemma that always applies of the form
(β x, βf x = βg x) β f = g
. When adding typespecific ext
lemmas like the one above, we want
these to be tried first. This happens automatically since the typespecific lemmas are inevitably
defined later.
simpnormal form
This note gives you some tips to debug any errors that the simpnormal form linter raises.
The reason that a lemma was considered faulty is because its lefthand side is not in simpnormal form. These lemmas are hence never used by the simplifier.
This linter gives you a list of other simp lemmas: look at them!
Here are some tips depending on the error raised by the linter:

'the lefthand side reduces to XYZ': you should probably use XYZ as the lefthand side.

'simp can prove this': This typically means that lemma is a duplicate, or is shadowed by another lemma:
2a. Always put more general lemmas after specific ones:
And not the other way around! The simplifier always picks the last matching lemma.
2b. You can also use
@[priority]
instead of moving simplemmas around in the file.Tip: the default priority is 1000. Use
@[priority 1100]
instead of moving a lemma down, and@[priority 900]
instead of moving a lemma up.2c. Conditional simp lemmas are tried last. If they are shadowed just remove the
simp
attribute.2d. If two lemmas are duplicates, the linter will complain about the first one. Try to fix the second one instead! (You can find it among the other simp lemmas the linter prints out!)

'try_for tactic failed, timeout': This typically means that there is a loop of simp lemmas. Try to apply squeeze_simp to the righthand side (removing this lemma from the simp set) to see what lemmas might be causing the loop.
Another trick is to
set_option trace.simplify.rewrite true
and then applytry_for 10000 { simp }
to the righthand side. You will see a periodic sequence of lemma applications in the trace message.
use has_coe_t
We use the class has_coe_t
instead of has_coe
if the first argument is a variable,
or if the second argument is a variable not occurring in the first.
Using has_coe
would cause looping of typeclass inference. See
https://leanprover.zulipchat.com/#narrow/stream/113488general/topic/remove.20all.20instances.20with.20variable.20domain
user attribute parameters
For performance reasons, it is inadvisable to use user_attribute.get_param
.
The parameter is stored as a reflected expression. When calling get_param
,
the stored parameter is evaluated using eval_expr
, which first compiles the
expression into VM bytecode. The unevaluated expression is available using
user_attribute.get_param_untyped
.
In particular, user_attribute.get_param
MUST NEVER BE USED in the
implementation of an attribute cache. This is because calling eval_expr
disables the attribute cache.
There are several possible workarounds:
 Set a different attribute depending on the parameter.
 Use your own evaluation function instead of
eval_expr
, such as e.g.expr.to_nat
.  Write your own
has_reflect Param
instance (using a more efficient serialization format). Theuser_attribute
code unfortunately checks whether the expression has the correct type, but you can use`(id %%e : Param)
to pretend that your expressione
has typeParam
.
vector space definition
Vector spaces are defined as an abbreviation
for semimodules,
if the base ring is a field.
(A previous definition made vector_space
a structure
defined to be module
.)
This has as advantage that vector spaces are completely transparent
for type class inference, which means that all instances for semimodules
are immediately picked up for vector spaces as well.
A cosmetic disadvantage is that one can not extend vector spaces as such,
in definitions such as normed_space
.
The solution is to extend semimodule
instead.