This repository was archived by the owner on Jul 24, 2024. It is now read-only.
chore(category_theory/concrete_category): take an instance, rather than extending, category#2195
Merged
mergify[bot] merged 12 commits intomasterfrom Apr 2, 2020
Merged
chore(category_theory/concrete_category): take an instance, rather than extending, category#2195mergify[bot] merged 12 commits intomasterfrom
mergify[bot] merged 12 commits intomasterfrom
Conversation
…an extending, category
jcommelin
reviewed
Mar 19, 2020
Member
kim-em
added
the
awaiting-review
Collaborator
|
Fine with me--I'm not much of a fan of |
Collaborator
|
There are some not obviously related changes involving |
jcommelin
approved these changes
Apr 1, 2020
jcommelin
added
ready-to-merge
Member
|
I like the new |
butterthebuddha
pushed a commit
to butterthebuddha/mathlib
that referenced
this pull request
May 15, 2020
…an extending, category (leanprover-community#2195) chore(category_theory/concrete_category): take an instance, rather than extending, category (leanprover-community#2195) Our current design for `concrete_category` has it extend `category`. This PR changes that so that is takes an instance, instead. I want to do this because I ran into a problem defining `concrete_monoidal_category`, which is meant to be a monoidal category, whose faithful functor to Type is lax monoidal. (The prime example here is `Module R`, where there's a map `F(X) \otimes F(Y) \to F(X \otimes Y)`, but not the other way: here `F(X) \otimes F(Y)` is just the monoidal product in Type, i.e. cartesian product, and the function here is `(x, y) \mapsto x \otimes y`.) Now, `monoidal_category` does not extend `category`, but instead takes a typeclass, so with the old design `concrete_monoidal_category` was going to be a Frankenstein, extending `concrete_category` and taking a `[monoidal_category]` type class. However, when 3.7 landed this went horribly wrong, and even defining `concrete_monoidal_category` caused an unbounded typeclass search. So.... I've made everything simpler, and just not used `extends` at all. It's all just typeclasses. This makes some places a bit more verbose, as we have to summon lots of separate typeclasses, but besides that everything works smoothly. (Note, this PR makes the change to `concrete_category`, but does not yet introduce `concrete_monoidal_category`.)
butterthebuddha
pushed a commit
to butterthebuddha/mathlib
that referenced
this pull request
May 16, 2020
…an extending, category (leanprover-community#2195) chore(category_theory/concrete_category): take an instance, rather than extending, category (leanprover-community#2195) Our current design for `concrete_category` has it extend `category`. This PR changes that so that is takes an instance, instead. I want to do this because I ran into a problem defining `concrete_monoidal_category`, which is meant to be a monoidal category, whose faithful functor to Type is lax monoidal. (The prime example here is `Module R`, where there's a map `F(X) \otimes F(Y) \to F(X \otimes Y)`, but not the other way: here `F(X) \otimes F(Y)` is just the monoidal product in Type, i.e. cartesian product, and the function here is `(x, y) \mapsto x \otimes y`.) Now, `monoidal_category` does not extend `category`, but instead takes a typeclass, so with the old design `concrete_monoidal_category` was going to be a Frankenstein, extending `concrete_category` and taking a `[monoidal_category]` type class. However, when 3.7 landed this went horribly wrong, and even defining `concrete_monoidal_category` caused an unbounded typeclass search. So.... I've made everything simpler, and just not used `extends` at all. It's all just typeclasses. This makes some places a bit more verbose, as we have to summon lots of separate typeclasses, but besides that everything works smoothly. (Note, this PR makes the change to `concrete_category`, but does not yet introduce `concrete_monoidal_category`.)
cipher1024
pushed a commit
to cipher1024/mathlib
that referenced
this pull request
Mar 15, 2022
…an extending, category (leanprover-community#2195) chore(category_theory/concrete_category): take an instance, rather than extending, category (leanprover-community#2195) Our current design for `concrete_category` has it extend `category`. This PR changes that so that is takes an instance, instead. I want to do this because I ran into a problem defining `concrete_monoidal_category`, which is meant to be a monoidal category, whose faithful functor to Type is lax monoidal. (The prime example here is `Module R`, where there's a map `F(X) \otimes F(Y) \to F(X \otimes Y)`, but not the other way: here `F(X) \otimes F(Y)` is just the monoidal product in Type, i.e. cartesian product, and the function here is `(x, y) \mapsto x \otimes y`.) Now, `monoidal_category` does not extend `category`, but instead takes a typeclass, so with the old design `concrete_monoidal_category` was going to be a Frankenstein, extending `concrete_category` and taking a `[monoidal_category]` type class. However, when 3.7 landed this went horribly wrong, and even defining `concrete_monoidal_category` caused an unbounded typeclass search. So.... I've made everything simpler, and just not used `extends` at all. It's all just typeclasses. This makes some places a bit more verbose, as we have to summon lots of separate typeclasses, but besides that everything works smoothly. (Note, this PR makes the change to `concrete_category`, but does not yet introduce `concrete_monoidal_category`.)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit Message
chore(category_theory/concrete_category): take an instance, rather than extending, category (#2195)
Our current design for
concrete_categoryhas it extendcategory.This PR changes that so that is takes an instance, instead.
I want to do this because I ran into a problem defining
concrete_monoidal_category, which is meant to be a monoidal category, whose faithful functor to Type is lax monoidal. (The prime example here isModule R, where there's a mapF(X) \otimes F(Y) \to F(X \otimes Y), but not the other way: hereF(X) \otimes F(Y)is just the monoidal product in Type, i.e. cartesian product, and the function here is(x, y) \mapsto x \otimes y.)Now,
monoidal_categorydoes not extendcategory, but instead takes a typeclass, so with the old designconcrete_monoidal_categorywas going to be a Frankenstein, extendingconcrete_categoryand taking a[monoidal_category]type class. However, when 3.7 landed this went horribly wrong, and even definingconcrete_monoidal_categorycaused an unbounded typeclass search.So.... I've made everything simpler, and just not used
extendsat all. It's all just typeclasses. This makes some places a bit more verbose, as we have to summon lots of separate typeclasses, but besides that everything works smoothly.(Note, this PR makes the change to
concrete_category, but does not yet introduceconcrete_monoidal_category.)