Add spec for Pearing of Monad and Applicative

in purescript-parallel there are this classes:

-- | The `MonadPar` class abstracts over monads which support some notion of
-- | parallel composition.
-- |
-- | The `unit` and `par` functions should correspond to `pure` and `lift2` for
-- | some valid `Applicative` instance, but that instance need not arise from
-- | the underlying `Monad`.
class Monad m <= MonadPar m where
  par :: forall a b c. (a -> b -> c) -> m a -> m b -> m c

-- | The `MonadRace` class extends `MonadPar` to those monads which can be
-- | _raced_. That is, monads for which two computations can be executed in parallel
-- | returning the result from the computation which finishes first.
-- |
-- | The `stall` and `race` functions should satisfy the `Alternative` laws.
class MonadPar m <= MonadRace m where
  stall :: forall a. m a
  race :: forall a. m a -> m a -> m a

I think we should add them to fantasy land spec so that different implementations of Future/Task could implement them consistently such that libs like @safareli/Free and @DrBoolean/freeky could depend on them.

If we had this algebras we can also port Parallel using which we can transform any (Monad m, ChainRace m) into just Applicative which is concurant (i.e. we would be able to use lift and general functions over Applicative while still be concurant) which is awasome!

I think we should name use this names as they dont need structure to be a monad:

• ChainPar for MonadPar
• ChainRace for MonadRace

---

realted issues:

• fantasy-land#179
• @safareli/free#27

[safareli]

After reading this reddit thread i’m thinking that name Parallel or Concurent is not that precise as this spec shuold just pearing/isomorphism between some Monad and some Applicative.

This are example are not strictly related to concurrency/parallelism:

• List Monad and ZipList Applicative
• Either Monad and Validation Applicative

for now i don’t have a better name but will think on this.

[safareli]

This will be useful in Free monad like structures. for example one might have Free&FreeAp conforming to this spec user could switch from one to another when it’s appropriate, and then it could be folded down to some other Monad&Applicative pear Task/Future …

Or one might for example in one computation use Either then convert it to Validation and then back to Either (when error is monoid), but I see most use with Task/Future.