Skip to content
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

Closed
wants to merge 32 commits into from

Conversation

eric-wieser
Copy link
Member

@eric-wieser eric-wieser commented Jul 31, 2023

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.


Open in Gitpod

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 }; if nsmul := is forgotten in this case, a new diamond is created.

@eric-wieser eric-wieser added WIP Work in progress t-algebra Algebra (groups, rings, fields, etc) labels Jul 31, 2023
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot added the blocked-by-other-PR This PR depends on another PR to Mathlib (this label is automatically managed by a bot) label Jul 31, 2023
@kbuzzard
Copy link
Member

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
Copy link
Contributor

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?

Copy link
Member

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.

Copy link
Member Author

@eric-wieser eric-wieser Jul 31, 2023

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.)

Copy link
Member Author

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.

Comment on lines +459 to +460
nsmul := letI : Zero α := ⟨⊥⟩; letI : Add α := ⟨(· ∆ ·)⟩; nsmulRec
zsmul := letI : Zero α := ⟨⊥⟩; letI : Add α := ⟨(· ∆ ·)⟩; letI : Neg α := ⟨id⟩; zsmulRec
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ditto

Copy link
Member Author

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.

Mathlib/Algebra/Ring/BooleanRing.lean Outdated Show resolved Hide resolved
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot removed the blocked-by-other-PR This PR depends on another PR to Mathlib (this label is automatically managed by a bot) label Aug 2, 2023
@leanprover-community-mathlib4-bot
Copy link
Collaborator

This PR/issue depends on:

@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot added the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Aug 2, 2023
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot removed the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Aug 2, 2023
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot added the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Aug 10, 2023
@leanprover-community-mathlib4-bot leanprover-community-mathlib4-bot removed the merge-conflict The PR has a merge conflict with master, and needs manual merging. (this label is managed by a bot) label Sep 15, 2023
@eric-wieser
Copy link
Member Author

Ah, you were technically correct; the conflict marked was in Counterexamples, as was the build failure. Now fixed.

@eric-wieser
Copy link
Member Author

!bench

@leanprover-bot
Copy link
Collaborator

Here are the benchmark results for commit c85d804.
There were significant changes against commit cb921c1:

  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%

@eric-wieser
Copy link
Member Author

Well that's a nice bonus

bors merge

@github-actions github-actions bot added ready-to-merge This PR has been sent to bors. and removed awaiting-review labels Mar 9, 2024
mathlib-bors bot pushed a commit that referenced this pull request Mar 9, 2024
…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>
@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Mar 9, 2024

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title refactor: do not allow nsmul and zsmul to default automatically [Merged by Bors] - refactor: do not allow nsmul and zsmul to default automatically Mar 9, 2024
@mathlib-bors mathlib-bors bot closed this Mar 9, 2024
@mathlib-bors mathlib-bors bot deleted the eric-wieser/no-nsmul-default branch March 9, 2024 10:41
@mattrobball
Copy link
Collaborator

I didn't compare the profiles before and after but I guess unification is not unfolding + now in some checks?

mathlib-bors bot pushed a commit that referenced this pull request Mar 9, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
kbuzzard pushed a commit that referenced this pull request Mar 12, 2024
…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>
kbuzzard pushed a commit that referenced this pull request Mar 12, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
dagurtomas pushed a commit that referenced this pull request Mar 22, 2024
…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>
dagurtomas pushed a commit that referenced this pull request Mar 22, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
utensil pushed a commit that referenced this pull request Mar 26, 2024
…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>
utensil pushed a commit that referenced this pull request Mar 26, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
Louddy pushed a commit that referenced this pull request Apr 15, 2024
…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>
Louddy pushed a commit that referenced this pull request Apr 15, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
uniwuni pushed a commit that referenced this pull request Apr 19, 2024
…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>
uniwuni pushed a commit that referenced this pull request Apr 19, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
callesonne pushed a commit that referenced this pull request Apr 22, 2024
…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>
callesonne pushed a commit that referenced this pull request Apr 22, 2024
Follows on from #6262.
Again, this does not attempt to fix any diamonds; it only identifies where they may be.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready-to-merge This PR has been sent to bors. t-algebra Algebra (groups, rings, fields, etc)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants