-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Add higher kinded versions of Eq
, Order
, Show
#2308
Comments
Initial discussion about the old https://gitter.im/typelevel/cats?at=5b33fa45479ca26689854ba6 Looks like the reason to remove I believe we could leave these tests unchanged and still have This affects instances for any fixpoint data type like |
Also, maybe we don't need to support binary type constructors as well - the usecase in which I'm hitting this wall is |
Edit: No it doesn't. I was confused. |
I prepared a POC for solving it with Delay (which has its own problems), for anyone interested in the issue: #2316 |
I don't like the idea that having |
https://gist.github.com/xuwei-k/118230f49c6522bddfcf1ef137c11945 byname implicit (since Scala 2.13) |
You definitely don't want to be using |
guess we'll just have to wait for 2.13 ;) |
Closing, I suggest to wait with the original issue until 2.13 is available, then we can use lazy implicits to add an instance to cats. I'll post more in the issue. |
...or at least some of them.
Reasoning: in #2300, I was trying to implement
Eq[Cofree[S, A]]
using implicit instances ofEq[S[Cofree[S, A]]]
andEq[A]
. That would look like this:However, any attempt at e.g.
Eq[Cofree[List, Int]]
will fail compilation due to an diverging implicit expansion - and it makes sense, sinceEq[List[Cofree[List, A]]]
needs anEq[Cofree[List, A]]
, which is exactly what we're trying to construct.The same situation will happen if someone tries to implement
Order
orShow
.Since we don't have a mechanism for shapeless-style lazy implicits, it doesn't seem possible to implement such instances without changes outside of
Cofree
.One solution to this problem that I see is creating a higher kinded variant of
Eq
, similar toSemigroup
/SemigroupK
:I believe that's
Eq1
in Haskell: http://hackage.haskell.org/package/base-4.11.1.0/docs/Data-Functor-Classes.html#g:2Having that, we might remove the current instances of
Eq
for higher kinded types likeOption
:and replace them with instances of
EqK
:To make it possible to seamlessly get an
Eq[Option[A]]
for anA : Eq
, we could add a derivation method:or, alternatively (and this would probably make it possible to keep binary compatibility), add instances of
EqK
alongside the old instances, and make the old instances use the implementations fromEqK
instances underneath (the old instances could be removed later, at a point when we can break compatibility).The same thing could happen to
Order
andShow
.Another idea would be to introduce lazy implicits to Cats.
The text was updated successfully, but these errors were encountered: