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

many kernel algebraic typeclasses should be Invariant #1904

Closed
johnynek opened this issue Sep 10, 2017 · 8 comments
Closed

many kernel algebraic typeclasses should be Invariant #1904

johnynek opened this issue Sep 10, 2017 · 8 comments

Comments

@johnynek
Copy link
Contributor

If you have Invariant[M] and an isomorphism (or bijection) A => B, B => A then you can go between M[A] <=> M[B]. This can be very useful when combined with shapeless which can generate iso morphisms between case classes and tuples, etc...

However, Semigroup, Semilattice, Monoid, Group, etc... are left out of that as far as I can see.

It would be nice to have instances for those in object Invariant so they could be used without import.

@kailuowang
Copy link
Contributor

Shall we schedule this in RC1?

@johnynek
Copy link
Contributor Author

I would like to. I hate when we have obvious instances for our own types that we don't ship.

@LukaJCB
Copy link
Member

LukaJCB commented Sep 11, 2017

Hey @johnynek, can you elaborate a bit on what you mean by this? :)
Do you mean instances like Invariant[Group] etc.?
We do already have InvariantMonoidal which does extend Invariant, so we can already do

Monoid[A].imap(aToB)(bToA)

I don't think we have these for any of the other kernel classes apart from Semigroup and Monoid though.

@johnynek
Copy link
Contributor Author

Concretely:

  1. we usually put instances for cats owned types into companions. For Monoid we have an import. Should not need that. We should just put that into Invariant or InvariantMonodial object.
  2. we are missing many instances: e.g. all the ones I mentioned above. I'm not sure all are InvariantMonoidal. Monoid is, but some of the others may not (pure may or may not work for all cases).

@LukaJCB
Copy link
Member

LukaJCB commented Sep 11, 2017

I like the idea of having everything in object Invariant, but we'd break the API, no?
We could do something like object InvariantInstances extends MonoidInstances with SemigroupInstances, WDYT?

@johnynek
Copy link
Contributor Author

I think these are so rarely used, I don't mind breaking the API to make it consistent current cats practice before 1.0

@LukaJCB
Copy link
Member

LukaJCB commented Sep 14, 2017

I'll submit a PR soon :)

@LukaJCB
Copy link
Member

LukaJCB commented Oct 18, 2017

Fixed by #1914 :)

@LukaJCB LukaJCB closed this as completed Oct 18, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants