Type class composition

[adelbertc]

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.

trait Functor[F[_]] {
  def compose[G[_]: Functor]: Functor[Lambda[X => F[G[X]]]]
}

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 a Compose data type, something like:

final case class Compose[F[_], G[_], A](fga: F[G[A]])

---

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 go BiProd (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 the BiProd PR in favor or delegating work to Kittens. Alternatively, have BiProd and BiCompose since we have the Bifunctor etc. type classes already, and we'll draw the line there.

Thoughts?

[ceedubs]

@adelbertc I think that we can close this out now, right?

[adelbertc]

I still want to figure out what we want to do with the Bifunctor and
friends classes
On Jun 11, 2016 11:24, "Cody Allen" [email protected] wrote:

@adelbertc https://github.com/adelbertc I think that we can close this
out now, right?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#968 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABRW9I55y91VlvzSPze-RFqTUCHnUvjAks5qKv1WgaJpZM4H-1jp
.

[ceedubs]

@adelbertc I'm inclined to hold off on things like Biprod and BiNested until someone has a compelling use-case for them. When I try to come up with use-cases, they all seem pretty contrived. This ticket is currently part of the 1.0 milestone, and to me these don't seem like items that should block a 1.0 release. WDYT?

[adelbertc]

Let me take a look to make sure there's no inconsistencies, otherwise fine
by me. I'll move the ticket out
On Jun 15, 2016 5:20 AM, "Cody Allen" [email protected] wrote:

@adelbertc https://github.com/adelbertc I'm inclined to hold off on
things like Biprod and BiNested until someone has a compelling use-case
for them. When I try to come up with use-cases, they all seem pretty
contrived. This ticket is currently part of the 1.0 milestone, and to me
these don't seem like items that should block a 1.0 release. WDYT?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#968 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ABRW9EKyNXFjKuOKWkNzcu74NMAzlsYgks5qL-4AgaJpZM4H-1jp
.

[adelbertc]

@ceedubs This should do it: #1133

[adelbertc]

Okie dokes