Skip to content

IsCommutativeMonoid should use IsMonoid not IsSemigroup #239

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

Closed
MatthewDaggitt opened this issue Mar 12, 2018 · 5 comments
Closed

IsCommutativeMonoid should use IsMonoid not IsSemigroup #239

MatthewDaggitt opened this issue Mar 12, 2018 · 5 comments

Comments

@MatthewDaggitt
Copy link
Contributor

MatthewDaggitt commented Mar 12, 2018

Obviously Maybe a case of mis-subclassing. It leads to unobvious requirements and also makes the record much longer than it needs to be.

record IsCommutativeMonoid {a ℓ} {A : Set a} (≈ : Rel A ℓ)
(_∙_ : Op₂ A) (ε : A) : Set (a ⊔ ℓ) where
open FunctionProperties
field
isSemigroup : IsSemigroup ≈ _∙_
identityˡ : LeftIdentity ε _∙_
comm : Commutative _∙_

@MatthewDaggitt
Copy link
Contributor Author

Likewise with IsCommutativeSemiring

@gallais
Copy link
Member

gallais commented Mar 12, 2018

I think the point of this is that an IsCommutativeX can be used anywhere an X is
expected thanks to subtyping. Not sure whether it'd still be the case if everything was
packed up in a subfield.

That being said, I'm not sure how useful the subtyping aspect is.

@MatthewDaggitt
Copy link
Contributor Author

Ooh I hadn't considered that. Apologies for my too hasty comment.

Hang on, does that mean identityˡ : LeftIdentity ε _∙_ is a subtype of identity : Identity ε ∙?

@andreasabel
Copy link
Member

andreasabel commented Mar 12, 2018

I could imagine the reason is that in the presence of commutativity, left identity implies right identity, thus, there is less proof obligations to build a commutative monoid.

Unless there are strong reasons for change, I'd advise to leave it as-is. (Maybe add documentation to not fall into the same trap again.)

@MatthewDaggitt
Copy link
Contributor Author

Unless there are strong reasons for change, I'd advise to leave it as-is. (Maybe add documentation to not fall into the same trap again.)

Agreed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants