-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - chore(category_theory/limits): Generalize universes for limits #10243
Conversation
The thing about abbreviation is that I can no longer write |
/-- | ||
`C` has all limits of size `v u` (`has_limits_of_size.{v u} C`) | ||
if it has limits of every shape `J : Type u` with `[category.{v} J]`. | ||
-/ | ||
class has_limits_of_size : Prop := | ||
(has_limits_of_shape : | ||
Π (J : Type v) [𝒥 : small_category J], has_limits_of_shape J C . tactic.apply_instance) | ||
Π (J : Type u₁) [𝒥 : category.{v₁} J], has_limits_of_shape J C . tactic.apply_instance) | ||
|
||
/-- `C` has all (small) limits if it has limits of every shape that is as big as its hom-sets. -/ | ||
abbreviation has_limits (C : Type u) [category.{v} C] : Prop := has_limits_of_size.{v v} C | ||
|
||
lemma has_limits.has_limits_of_shape {C : Type u} [category.{v} C] [has_limits C] | ||
(J : Type v) [category.{v} J] : | ||
has_limits_of_shape J C := has_limits_of_size.has_limits_of_shape J |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (and its dual) is the major definitional change in this PR.
has_limits
still means about the same thing, but lean seems to lose some ability to infer some types here and there and thus type and universe annotations needed to be added here and there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this claim. In several place I see that ulift
gets added. Certainly ulift X
is not defeq to X
, right? I think there are many definitional changes in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks a lot for taking this on! I thought it would be a very nasty can of worms. But it seems to go quite well 🐙
@@ -45,21 +45,21 @@ variables {C : Type u₁} [category.{v₁} C] | |||
|
|||
/-- The functorial version of `ulift.up`. -/ | |||
@[simps] | |||
def ulift.up : C ⥤ (ulift.{u₂} C) := | |||
def ulift.up_functor : C ⥤ (ulift.{u₂} C) := |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you change this name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It conflicts with _root_.ulift.up
in lots of files when I tried to import this into has_limits.lean
.
It (and the definitions using it) is never used outside of this file, so I thought it would be faster if I changed the name of this.
@@ -212,11 +223,12 @@ The isomorphism (in `Type`) between | |||
morphisms from a specified object `W` to the limit object, | |||
and cones with cone point `W`. | |||
-/ | |||
def limit.hom_iso (F : J ⥤ C) [has_limit F] (W : C) : (W ⟶ limit F) ≅ (F.cones.obj (op W)) := | |||
def limit.hom_iso (F : J ⥤ C) [has_limit F] (W : C) : | |||
ulift.{u₁} (W ⟶ limit F : Type v) ≅ (F.cones.obj (op W)) := |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will we also still need a version without ulift
for easy use when the universe variables are the same?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Based on the use case downstream, I think this works fine when composing with ulift_trivial
.
/-- | ||
`C` has all limits of size `v u` (`has_limits_of_size.{v u} C`) | ||
if it has limits of every shape `J : Type u` with `[category.{v} J]`. | ||
-/ | ||
class has_limits_of_size : Prop := | ||
(has_limits_of_shape : | ||
Π (J : Type v) [𝒥 : small_category J], has_limits_of_shape J C . tactic.apply_instance) | ||
Π (J : Type u₁) [𝒥 : category.{v₁} J], has_limits_of_shape J C . tactic.apply_instance) | ||
|
||
/-- `C` has all (small) limits if it has limits of every shape that is as big as its hom-sets. -/ | ||
abbreviation has_limits (C : Type u) [category.{v} C] : Prop := has_limits_of_size.{v v} C | ||
|
||
lemma has_limits.has_limits_of_shape {C : Type u} [category.{v} C] [has_limits C] | ||
(J : Type v) [category.{v} J] : | ||
has_limits_of_shape J C := has_limits_of_size.has_limits_of_shape J |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand this claim. In several place I see that ulift
gets added. Certainly ulift X
is not defeq to X
, right? I think there are many definitional changes in this PR.
/-- We can now write this for powers. -/ | ||
noncomputable example [has_finite_products C] (X : C) : C := ∏ (λ (i : fin 5), X) | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's really cool that this is now possible!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 🎉
bors merge
Co-authored-by: Andrew Yang <36414270+erdOne@users.noreply.github.com>
Build failed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks 🎉
bors merge
Co-authored-by: Andrew Yang <36414270+erdOne@users.noreply.github.com>
Pull request successfully merged into master. Build succeeded: |
Co-authored-by: Andrew Yang <36414270+erdOne@users.noreply.github.com>
Co-authored-by: Andrew Yang <36414270+erdOne@users.noreply.github.com>
Aware: ulift_functor ahead. Should I keep a universe unchanged version for these?
Update: only one occurrence downstream needed additional ulifts. I think its good for now.