-
-
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
Type class composition #968
Comments
We currently use cats.data.Prod for product composition - for consistency, and for reasons outlined in typelevel#968, I think we should use a cats.data.Compose data type for nested composition. I did the usual type classes first. No tests are added intentionally, putting this up as a proof of concept. If nobody yells at me for a couple of days I'll assume everything is OK and I'll clean things up, add comments, tests, etc.
@adelbertc I think that we can close this out now, right? |
I still want to figure out what we want to do with the Bifunctor and
|
@adelbertc I'm inclined to hold off on things like |
Let me take a look to make sure there's no inconsistencies, otherwise fine
|
Okie dokes |
A couple type classes like
Functor
,Apply
,Bitraverse
, etc support two kinds of composition:F[G[_]]
and(F[_], G[_])
. Let's call the former "nested composition" and the latter "product composition."For type classes of kind
(* -> *) -> *
(e.g. Functor, Apply) we have nested composition as a method on the type class, e.g.but for product composition we delegate to
cats.data.Prod
.I like the use of
cats.data.Prod
since it doesn't require you to have to call a method to get the instance, and then either declare a local implicit or pass in the instance explicitly. Explicit dictionary passing can easily become more cumbersome when fancier types are involved.Proposal 1: To that end I propose we remove
compose
in favor of aCompose
data type, something like:We also have nested and product composition for type classes of kind
((*, *) -> *) -> *
(e.g. Bifunctor). Again, nested composition is defined on the type class itself, with no product composition yet defined (pending #906). For product composition we could goBiProd
(like in that PR) but I've never found a need for it and I put it together mostly to be consistent with the type classes abstracting over unary type constructors.We could similarly have
BiCompose
as well. But then what of type classes over n-ary type constructors? Moreover, the definitions and instances get tedious and mechanical, and this is where I think kittens (cc @milessabin ) comes into play. It seems most use cases will rely on the unary constructor type classes, so to that end..Proposal 2: Remove
compose
on binary constructor type classes and close theBiProd
PR in favor or delegating work to Kittens. Alternatively, haveBiProd
andBiCompose
since we have theBifunctor
etc. type classes already, and we'll draw the line there.Thoughts?
The text was updated successfully, but these errors were encountered: