-
Notifications
You must be signed in to change notification settings - Fork 263
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(Algebra/Module): Use coercion from SemilinearMapClass to SemilinearMap #10758
Conversation
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.
Looks good! Could you give explicit names to the instances before merging?
bors d+
✌️ Vierkantor can now approve this pull request. To approve and merge a pull request, simply reply with |
Previously coercions would go via DistribMulActionHom to LinearMap, we want to follow standard practice and make them go via the morphism class.
48ce955
to
12d70df
Compare
Everything builds so: bors merge |
…ilinearMap (#10758) This PR adds a coercion from any instance of `SemilinearMapClass` to `SemilinearMap`. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion from `f : AlgHom` to `LinearMap` would look like `f.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap`, now it should look like `SemilinearMapClass.semilinearMap f`. The new coercion instances are `CoeHead` since the left hand side is a free variable `F`. I redefined the existing `DistribMulActionHom → LinearMap` coercion in terms of the `SemilinearMapClass` coercion to ensure we don't get any diamonds.
Pull request successfully merged into master. Build succeeded: |
…ilinearMap (#10758) This PR adds a coercion from any instance of `SemilinearMapClass` to `SemilinearMap`. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion from `f : AlgHom` to `LinearMap` would look like `f.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap`, now it should look like `SemilinearMapClass.semilinearMap f`. The new coercion instances are `CoeHead` since the left hand side is a free variable `F`. I redefined the existing `DistribMulActionHom → LinearMap` coercion in terms of the `SemilinearMapClass` coercion to ensure we don't get any diamonds.
…ilinearMap (#10758) This PR adds a coercion from any instance of `SemilinearMapClass` to `SemilinearMap`. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion from `f : AlgHom` to `LinearMap` would look like `f.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap`, now it should look like `SemilinearMapClass.semilinearMap f`. The new coercion instances are `CoeHead` since the left hand side is a free variable `F`. I redefined the existing `DistribMulActionHom → LinearMap` coercion in terms of the `SemilinearMapClass` coercion to ensure we don't get any diamonds.
…ilinearMap (#10758) This PR adds a coercion from any instance of `SemilinearMapClass` to `SemilinearMap`. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion from `f : AlgHom` to `LinearMap` would look like `f.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap`, now it should look like `SemilinearMapClass.semilinearMap f`. The new coercion instances are `CoeHead` since the left hand side is a free variable `F`. I redefined the existing `DistribMulActionHom → LinearMap` coercion in terms of the `SemilinearMapClass` coercion to ensure we don't get any diamonds.
…ilinearMap (#10758) This PR adds a coercion from any instance of `SemilinearMapClass` to `SemilinearMap`. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion from `f : AlgHom` to `LinearMap` would look like `f.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap`, now it should look like `SemilinearMapClass.semilinearMap f`. The new coercion instances are `CoeHead` since the left hand side is a free variable `F`. I redefined the existing `DistribMulActionHom → LinearMap` coercion in terms of the `SemilinearMapClass` coercion to ensure we don't get any diamonds.
This PR adds a coercion from any instance of
SemilinearMapClass
toSemilinearMap
. This is the standard practice for other parts of the library, such as ring homs (see also the recent change #10368). I also expect this change will help with some rough edges in #6057. Previously, a coercion fromf : AlgHom
toLinearMap
would look likef.toNonUnitalAlgHom.toDistribMulActionHom.toLinearMap
, now it should look likeSemilinearMapClass.semilinearMap f
.The new coercion instances are
CoeHead
since the left hand side is a free variableF
. I redefined the existingDistribMulActionHom → LinearMap
coercion in terms of theSemilinearMapClass
coercion to ensure we don't get any diamonds.