Monoidal improvements

[adelbertc]

The major pieces of adding Monoidal are in place, per https://github.com/non/cats/pull/555

[ ] As it stands, Monoidal is defined with just product (no pure) and as such only has the associativity law. We should perhaps have something similar to Apply/Applicative where we have a Semigroupal (?) with product and Monoidal extends Semigroupal with pure. If we go that route.. we'll have two different pures that should really be the same thing - one for Monoidal the other for Applicative.
[ ] Documentation

[OlivierBlanvillain]

@julienrf I've just read through #555 changes and I have the following question, what's the reason to not implement the new product method introduced by Monoidal directly on Apply? I feel like all implementations of this method on types <: Apply could be factorized by the following, to be added directly on Apply:

def product[A, B](fa: F[A], fb: F[B]): F[(A, B)] =
  ap(fa)(map(fb)(b => (a => (a, b))))

[julienrf]

Hi Olivier,

I just followed this comment (though I didn’t run any sort of benchmark).

[OlivierBlanvillain]

@julienrf I'm really sorry for the stupid question, I didn't read through the discussion and only looked at the commit... I didn't run any benchmarks but was simply surprised by the addition of new abstract methods introduced on Apply, I now understand it's this way for performance reasons.

Did you consider the option of splitting MonoidalBuilder into 3? (I did something similar here, but the motivation was to improve error reporting because map/imap/contramap are all overloaded apply to be user facing). (I removed my table it did not make sense)

[julienrf]

Yes, adding Divide and Divisible would be a good idea.