-
Notifications
You must be signed in to change notification settings - Fork 340
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] - refactor: do not allow nsmul
and zsmul
to default automatically
#6262
Conversation
Could this be related to why Algebra.Category.ModuleCat.Limits compiles more slowly after #6144 ? Or are your changes colimit-only? |
@@ -161,6 +161,7 @@ instance pointwiseAddCommMonoid : AddCommMonoid (Submodule R M) | |||
zero_add _ := bot_sup_eq | |||
add_zero _ := sup_bot_eq | |||
add_comm _ _ := sup_comm | |||
nsmul := letI : Zero (Submodule R M) := ⟨⊥⟩; letI : Add (Submodule R M) := ⟨Sup.sup⟩; nsmulRec |
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.
Doesn't this indicate that it would be better to declare the Zero and Add instances separately?
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.
Does it matter if we're using letI
, because this just inlines everything.
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 think my patch behaves exactly the same as what we currently do, though I haven't checked. (Yours generates a smaller term.)
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've pulled this out as requested.
nsmul := letI : Zero α := ⟨⊥⟩; letI : Add α := ⟨(· ∆ ·)⟩; nsmulRec | ||
zsmul := letI : Zero α := ⟨⊥⟩; letI : Add α := ⟨(· ∆ ·)⟩; letI : Neg α := ⟨id⟩; zsmulRec |
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.
ditto
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 is a def
, so pulling these out is impractical.
This PR/issue depends on:
|
Ah, you were technically correct; the conflict marked was in |
!bench |
Here are the benchmark results for commit c85d804. Benchmark Metric Change
================================================================================
+ ~Mathlib.Algebra.Module.PID instructions -5.5%
+ ~Mathlib.CategoryTheory.Preadditive.FunctorCategory instructions -47.5%
+ ~Mathlib.CategoryTheory.Sites.Sheaf instructions -22.6%
+ ~Mathlib.RepresentationTheory.Action.Limits instructions -47.0%
+ ~Mathlib.RepresentationTheory.GroupCohomology.Basic instructions -20.5%
+ ~Mathlib.RepresentationTheory.GroupCohomology.Resolution instructions -7.2% |
Well that's a nice bonus bors merge |
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Pull request successfully merged into master. Build succeeded: |
nsmul
and zsmul
to default automaticallynsmul
and zsmul
to default automatically
I didn't compare the profiles before and after but I guess unification is not unfolding |
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
…6262) This PR removes the default values for `nsmul` and `zsmul`, forcing the user to populate them manually. The previous behavior can be obtained by writing `nsmul := nsmulRec` and `zsmul := zsmulRec`, which is now in the docstring for these fields. The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for `nsmulRec` in the source code. Arguably we should do the same thing for `intCast`, `natCast`, `pow`, and `zpow` too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR. Co-authored-by: Matthew Ballard <matt@mrb.email>
Follows on from #6262. Again, this does not attempt to fix any diamonds; it only identifies where they may be.
This PR removes the default values for
nsmul
andzsmul
, forcing the user to populate them manually.The previous behavior can be obtained by writing
nsmul := nsmulRec
andzsmul := zsmulRec
, which is now in the docstring for these fields.The motivation here is to make it more obvious when module diamonds are being introduced, or at least where they might be hiding; you can now simply search for
nsmulRec
in the source code.Arguably we should do the same thing for
intCast
,natCast
,pow
, andzpow
too, but diamonds are less common in those fields, so I'll leave them to a subsequent PR.This was particularly bad in light of leanprover/lean4#2387, which encouraged us (in order to avoid a performance issue) to write
{ nsmul := foo.nsmul, toY := foo.toY, z := z }
instead of{ foo with z := z }
; ifnsmul :=
is forgotten in this case, a new diamond is created.