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

fix the documentation of DeclareHandlingByNiceBasis #5325

Merged

Conversation

ThomasBreuer
Copy link
Contributor

Since pull request #3006 got merged, the statement about the implication installed by InstallHandlingByNiceBasis was not correct.

This change addresses issue #5322.

Since pull request gap-system#3006 go merged, the statement about the
implication installed by `InstallHandlingByNiceBasis` was not
correct.

This change addresses issue gap-system#5322.
@ThomasBreuer ThomasBreuer added kind: bug Issues describing general bugs, and PRs fixing them topic: documentation Issues and PRs related to documentation release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes labels Jan 16, 2023
Copy link
Member

@fingolfin fingolfin left a comment

Choose a reason for hiding this comment

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

Technically that means our changes to DeclareHandlingByNiceBasis were breaking.

To me that indicates we should...

  • carefully consider if we really want to introduce this breakage, or perhaps instead revert it (it may be "right", but is it worth the trouble? )
  • if we do, then we should document it explicitly as a breaking change in the release notes
  • ... and also check for affected packages. A quick grep show that it is used in fr, guava, quagroup, qpa.

@ThomasBreuer
Copy link
Contributor Author

@fingolfin The problem described in issue #5322 arises because the QPA2 package wants to install a NiceFreeLeftModule method with requirement only the filter that has been created by DeclareHandlingByNiceBasis. The mentioned packages fr, guava, quagroup, qpa do not install NiceFreeLeftModule methods.

I could modify the code such that the filters created by DeclareHandlingByNiceBasis again imply IsFreeLeftModule, then the problem from issue #5322 would disappear. The problem to be fixed was the implication to IsAttributeStoringRep.
(In general, I think it is not a good idea to "waste" a new simple filter by automatically restricting its context via implications.)

@fingolfin fingolfin enabled auto-merge (rebase) January 18, 2023 22:12
@fingolfin fingolfin merged commit 0adf6d1 into gap-system:master Jan 18, 2023
@ThomasBreuer ThomasBreuer deleted the TB_DeclareHandlingByNiceBasis_docu branch January 19, 2023 15:57
ThomasBreuer added a commit to ThomasBreuer/gap that referenced this pull request Jan 19, 2023
- Let the filters created by `DeclareHandlingByNiceBasis` imply
  `IsFreeLeftModule`.
  This was the case before the changes from gap-system#3006, and this change fixes
  the problem described in gap-system#5322, as I had sketched in the discussion of gap-system#5325.
- Document this change (following gap-system#5325).
- Increase the rank of `IsHandledByNiceBasis` by 2.
  Then we get back to the rank before the changes from gap-system#3006.
  This way, the `\in` method with second argument in
  `IsFreeLeftModule and IsHandledByNiceBasis` is again ranked higher than
  the one with second argument `IsFreeLeftModule and IsFiniteDimensional`.
  The bug described in issue gap-system#5334 which has been found because of the
  reordering of these two methods (due to gap-system#3006)
  gets fixed via pull request gap-system#5335,
  now we can return to the better method ordering.
  (I do not like uprankings, but I have no better idea to solve this problem.)
fingolfin pushed a commit that referenced this pull request Jan 19, 2023
- Let the filters created by `DeclareHandlingByNiceBasis` imply
  `IsFreeLeftModule`.
  This was the case before the changes from #3006, and this change fixes
  the problem described in #5322, as I had sketched in the discussion of #5325.
- Document this change (following #5325).
- Increase the rank of `IsHandledByNiceBasis` by 2.
  Then we get back to the rank before the changes from #3006.
  This way, the `\in` method with second argument in
  `IsFreeLeftModule and IsHandledByNiceBasis` is again ranked higher than
  the one with second argument `IsFreeLeftModule and IsFiniteDimensional`.
  The bug described in issue #5334 which has been found because of the
  reordering of these two methods (due to #3006)
  gets fixed via pull request #5335,
  now we can return to the better method ordering.
  (I do not like uprankings, but I have no better idea to solve this problem.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind: bug Issues describing general bugs, and PRs fixing them release notes: not needed PRs introducing changes that are wholly irrelevant to the release notes topic: documentation Issues and PRs related to documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants