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(Algebra/Module): Use coercion from SemilinearMapClass to SemilinearMap #10758

Closed
wants to merge 2 commits into from

Conversation

Vierkantor
Copy link
Contributor

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.


Open in Gitpod

Copy link
Contributor

@dupuisf dupuisf left a 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+

Mathlib/Algebra/Module/LinearMap/Basic.lean Outdated Show resolved Hide resolved
@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Mar 18, 2024

✌️ Vierkantor can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

Previously coercions would go via DistribMulActionHom to LinearMap, we want to follow standard practice and make them go via the morphism class.
@Vierkantor
Copy link
Contributor Author

Everything builds so:

bors merge

@github-actions github-actions bot added the ready-to-merge This PR has been sent to bors. label Apr 3, 2024
mathlib-bors bot pushed a commit that referenced this pull request Apr 3, 2024
…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.
@mathlib-bors
Copy link
Contributor

mathlib-bors bot commented Apr 3, 2024

Pull request successfully merged into master.

Build succeeded:

@mathlib-bors mathlib-bors bot changed the title refactor(Algebra/Module): Use coercion from SemilinearMapClass to SemilinearMap [Merged by Bors] - refactor(Algebra/Module): Use coercion from SemilinearMapClass to SemilinearMap Apr 3, 2024
@mathlib-bors mathlib-bors bot closed this Apr 3, 2024
@mathlib-bors mathlib-bors bot deleted the semilinear_coe branch April 3, 2024 18:01
101damnations pushed a commit that referenced this pull request Apr 5, 2024
Louddy pushed a commit that referenced this pull request Apr 15, 2024
…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.
atarnoam pushed a commit that referenced this pull request Apr 16, 2024
…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.
uniwuni pushed a commit that referenced this pull request Apr 19, 2024
…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.
callesonne pushed a commit that referenced this pull request Apr 22, 2024
…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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
delegated 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.

None yet

4 participants