Remove redundant Monad requirement when Parallel is provided

[ceedubs]

I believe this will break binary compatibility, so it probably won't
be able to make it in until the eventual Cats 2.0. I'm not sure what the
current branch strategy is for this sort of thing (if we have one yet).

[LukaJCB]

Good catch, thank you! :)

[LukaJCB]

Is this going to be MiMa compatible though? 🤔

[ceedubs]

@LukaJCB see comment above :)

[LukaJCB]

Oh, duh, sorry about that!

[johnynek]

I wonder when we are breaking if we should do:

trait Parallel[M[_]] {
  type F[_]
}

Since F is generally only used as an intermediate type, this could make it easier to specify the types when you need to.

[kailuowang]

we don't have a branch strategy yet. we might have a cats 2.0 that is bin compat on scala 2.11 and 2.12.
So this may have to wait until Cats 3.0.

[johnynek]

Why call it 2.0 if it is binary compatible?

[kailuowang]

@johnynek, TBC it's just a possibility, we might be forced to drop scala 2.10 if we upgrade scalajs. We would want to reserver 1.x versions for 2.10 if we want to continue support 2.10 and back port features to it, which means that the main branch (with the latest scalajs and discipline (also dropping 2.10) will have to be on 2.x version numbers.

[LukaJCB]

I was also thinking about that @johnynek (RE: making F an abstract type member), this would make things easier a lot of the time I think, it might have some drawbacks in other situations that we haven't explored yet. IMO abstract type members are a really cool feature that Haskell/PureScript seem to lack and in hindsight I think we could have probably made that F an abstract type member.
Oh well, maybe in Cats 3.0 😄

[diesalbla]

@LukaJCB @ceedubs This looks like an old and deprecated PR. The current version has no Monad in parTraverse.

[tnielens]

I think this PR was still relevant. The issue noted that parTraverse has no Monad constraint while its syntax method in ParallelTraversableOps.parTraverse unnecessarily has one.