Zulip Chat Archive

Stream: mathlib4

Topic: Yoneda lemma related


Luc Duponcheel (Sep 30 2025 at 17:08):

Hello folks,

I'd like to contribute to mathlib4.
More precisely, in short, I have proved a specific Yoneda
lemma (for, what I call, Functional Categories), that I want
to make part of mathlib4.

So, naturally, I had a look at
https://github.com/leanprover-community/mathlib4/blob/master/Mathlib/CategoryTheory/Yoneda.lean.

The code contains an overwhelming amount of Yoneda-related theorems.

I may be wrong, but I did not find the theorem that I thought
was the Yoneda lemma I knew.

I saw coyonedaEquiv which is really cool!

But

  1. coyonedaEquiv does not explicitly prove that
    fun _ x ↦ F.map x ξ is a natural transformation.
    Again, I may be wrong, maybe it somehow proves it implicitly.

  2. coyonedaEquiv does not really deals with how
    both sides of the bijection relate to each other.

The code below deals with both 1. and 2. .

If the Mathlib experts know that the code is already dealt
with by the (overwhelming amount of) Yoneda-related theorems,
then, really, sorry for posting all this.

If not, then I would be more than willing to, somehow, add them to
mathlib4. Perhaps as a pull request?

Here is my code

Code listing

Lawrence Wu (llllvvuu) (Sep 30 2025 at 21:17):

No need to apologize, the Zulip is the right place to ask given you already browsed the library. #Is there code for X? may be even better.

Christian Merten (Sep 30 2025 at 21:24):

The first two definitions exist in mathlib, as you note yourself.
Your coyoneda_1 can be proven by

  simp [ FunctorToTypes.naturality]

and your coyoneda_2 can be proven by

  simp

Luc Duponcheel (Sep 30 2025 at 21:28):

Christian Merten, thx, I'll give it a try.

Anyway, the general Yoneda Lemma was just a first try.
My main goal is to write my specific Yoneda Lemma (for Functional Categories) in Lean.

Thanks for the constructive answer. Much appreciated.

Luc Duponcheel (Sep 30 2025 at 22:10):

Christian Merten,

Thanks so much. You are my hero!

The code below, more in sync with the
Mathlib naming conventions, indeed, does the trick.

Impressive!

Frankly, with all those (co)yoneda theorems in
Mathlib/CategoryTheory/Yoneda.lean
it does not really come as a surprise
that my two theorems do not need a calc proof.

Do you think it is useful to add them to
Mathlib/CategoryTheory/Yoneda.lean
anyway (perhaps with a more approriate comment)?

Agreed, they deal with the how, while most other
ones deal with the what.

Code listing

The formulation and proof of my own specific
coyoneda will be another challenge ... .

I'll start with calc proofs and extract as many
intermediate lemmas as possible.

Joël Riou (Oct 01 2025 at 09:45):

If these lemmas appeared to be super useful in order to prove other significant things, they could be considered for inclusion, but so far, I do not think there is a need for the addition of these two lemmas.

Luc Duponcheel (Oct 02 2025 at 13:51):

Christian and Joël,

Greetings from the Lean workshop.

Thanks for your comments.

No my lemmas are not super useful in order to prove significant things that
cannot be proven by the existing ones.

However, the second one, slightly changed, (see code below) proves that invFun ξ satisfies the natural transformation law. As far as I understand, coyonedaEquiv, only deals with the "two-sided inverse" aspect.

But, then again, maybe some other theorem in the Yoneda.lean file already, explicitly or implicitly, proves that invFun ξ satisfies the natural transformation law.

Btw, I would have expected that I needed to help simp with Functor.map_comp, but it does not seem to be necessary.

Code listing

Joël Riou (Oct 02 2025 at 14:06):

I do not know what you are trying to say, but in the definition of coyonedaEquiv, the line invFun ξ := { app := fun _ x ↦ F.map x ξ } construct a natural transformation: the code only gives the data of the app field, because the proof of the naturality field is filled automatically. There is no point stating this as a separate lemma.

Luc Duponcheel (Oct 02 2025 at 18:39):

Thanks so much Joël,

So do you mean that the fact the signature of my invFun definition mentions NaTransautomatically (not to say automagically) proves that the naturality law is satified? I was not aware of that specific power of Lean. I am relatively new.

Joël Riou (Oct 02 2025 at 18:43):

The naturality is part of the "axioms" that are satisfied by any object of type NatTrans F G. If one constructs something in NatTrans F G, then it must be a natural transformation.
In the category theory part of mathlib, many obvious and not so obvious commutativity of diagrams are proven automatically.

Luc Duponcheel (Oct 02 2025 at 18:45):

OK, poof by construction at type level. Cool.

Chris Henson (Oct 02 2025 at 18:50):

To answer the "automatically" question a bit more, in Lean you can in a typeclass definition specify a tactic that will be tried by default when not otherwise specified. Much of the category theory in Mathlib does this. To be specific in the above example, NatTrans is given some specified data app, and the naturality field is inferred by a tactic cat_disch that will call automation like aesop and simp.

Luc Duponcheel (Oct 02 2025 at 18:59):

Ok, I saw this cat_dish several times when browsing the source code, but I was not aware of its power. Thanks again Chris and Joël. I am still learning while trying, at the same time, to be creative as well. For my own specific Yoneda-like lemma for FunctionalCategory I can then, most probably, do similar things. Anyway, I will first start with a "low profile" calc based proof and then provide as much "high profile" features Ihat I understand. You are my heros.

Luc Duponcheel (Oct 14 2025 at 14:04):

Hello, folks,

I am a little bit ashamed to ask this question.

I thought I was becoming an experienced calc
based theorem prover, but now I am stuck with
(what I thought of as) two easy have's.

The MWE code below starts with minimal "low-profile"
Category and Functor stuff, and continues with my own
minimal PreFunctionalCategory.

I prove a theorem using the two have's
(they use sorry).

The first have corresponds to the definition of
toGlobal, so I would expect to be able to replace
sorry by rfl.

The second have uses the instance : Category function,
and I would also expect to be able to replace sorry
by rfl.

All comments are welcome.

Code listing

Luc Duponcheel (Oct 14 2025 at 22:01):

FYI : I could solve the problem using two sub-optimal hacks. I'll post the code tomorrow. I'm gonna :sleeping: now


Last updated: Dec 20 2025 at 21:32 UTC