Introduce Monoidal

[julienrf]

#795 renamed Monoidal into Cartesian and introduced new laws for Applicative. To push further this work and have a proper support of Monoidal invariant and contravariant structures, I think we should follow these steps:

• Introduce a Monoidal typeclass

trait Monoidal[F[_]] extends Cartesian[F] {
  def unit: F[Unit]
}

• Move the identity laws from ApplicativeLaws to MonoidalLaws
• Define Applicative (resp. ApplicativeLaws) in terms of Monoidal (resp. MonoidalLaws)
• Implement Monoidal for as many data types as possible (e.g. Applicative but also Show, Const, etc.)

[mpilquist]

👍 for adding a type class that is Cartesian with a pure. Does anyone have any examples on where we would abstract over a type constructor using Monoidal? I.e., is the primary motivation of providing it free theorems or is there some other utility?

I'm not sold on the name Monoidal. I mentioned this in the other PR -- feels like too loose of reasoning, though I'm happy to be wrong here. 😄

[julienrf]

@mpilquist Yes, I’ve already written something like the following:

trait Something[F[_], A] {
  …
}
object Something {
    implicit def monoidal[F[A]](implicit F: Monoidal[F]): Monoidal[Something[F, ?]] = …
}

Basically, my Something typeclass was essentially a wrapper around an F[_] type, and I derived a Monoidal[Something[F, ?]] from an existing Monoidal[F].

(edit: It was actually Cartesian, not Monoidal)

[julienrf]

I also use it here: https://github.com/julienrf/play-products/blob/master/src/main/scala/julienrf/products/Builder.scala#L11 (Play’s FunctionalCanBuild is our Cartesian).

[julienrf]

@mpilquist I don’t remember if we already debate of this, but what would be your opinion on having a member unit: F[Unit] instead of pure[A](a: A): F[A]? unit is sufficient to check the laws and maybe less constraining than pure (ie. maybe for some type F[?] it is not possible to implement pure but it is possible to implement unit).

[mpilquist]

@julienrf I'm neutral on unit vs pure. I can see benefits to either approach. I initially was leaning towards pure but the more I think about it, I think unit might be better.

[julienrf]

That’s what I think too!

[travisbrown]

👍 (with unit rather than pure), and I don't personally mind the name Monoidal.

[mpilquist]

I'm fine with the name Monoidal since I have no better suggestion.

[ceedubs]

👍 sounds like there's agreement - let's go for it.

I'm wondering if adding unit as opposed to pure might allow this to be extended by contravariant types such as Divisible. I haven't thought this through yet.

[non]

What is the rationale for having Monoidal and also Applicative? Is there a reason we can't have Applicative extend Cartesian with pure and also ap, implemented in terms of product and pure? If we had both, I guess we would only provide instances of Monoidal to avoid ambiguity?

[mpilquist]

@non To get Applicative, you need Monoidal + Functor.

[non]

Aha, right! That makes total sense. Ignore me! 😄

[ceedubs]

@non yeah, I think my comment about divisible was bogus. I almost deleted it yesterday, but I decided it's okay to be wrong on the internet :P

[travisbrown]

@julienrf I just noticed your edit to this comment—does that mean you don't have a practical use case for this new type class right now? I was thinking it'd be a good idea to get this into 0.4.0 if you did, but if not I'd be a lot happier to let this wait.

[julienrf]

We can let this wait.

[ceedubs]

Is this effectively taken care of now?

[ceedubs]

I'm going to close this out as a stale issue. I think that we are pretty stable on this front, with ContravariantMonoidal and friends.