if Type is Monad than `ap` from Applicative should be sequential?

In documentation of Control.Monad at section class Applicative m => Monad m where is written: (<*>) = ap and ap is defined like this:

{- | In many situations, the 'liftM' operations can be replaced by uses of
'ap', which promotes function application.
>       return f `ap` x1 `ap` ... `ap` xn
is equivalent to
>       liftMn f x1 x2 ... xn
-}
ap       :: (Monad m) => m (a -> b) -> m a -> m b
ap m1 m2 = do { x1 <- m1; x2 <- m2; return (x1 x2) }
-- Since many Applicative instances define (<*>) = ap, we
-- cannot define ap = (<*>)

In Control.Applicative we read about <*>:

(<*>) :: f (a -> b) -> f a -> f b Sequential application.

To sum up if Monad is also Applicative then <*> should preserve sequentiality. Currently there is no word about this nor in Monad nor in Chain nor in Applicative laws.

So is it intentional?

If this should be stated in laws then here is current state of Future/Task/LazyPromise-es:

• @robotlolita/data.task invalid
• @rpominov/fun-task valid
• @Avaq/Fluture invalid
• ramda/ramda-fantasy#Future invalid
• @safareli/Free invalid? (it delegates .ap to target monad so not quite invalid but sort of invalid)
• fantasyland/fantasy-promises valid

---

I found it out just yesterday on tweet of @jdegoes

[rpominov]

Curious what if we just turn derivations into laws? E.g. add a second law for Chain:

u.chain(f => v.map(f)) is equivalent to v.ap(u)

[jdegoes]

Here’s an example:

foo :: forall m. (Applicative m) => m Unit
foo = void $ doA *> doB

foo :: forall m. (Monad m) => m Unit
foo = void $ doA *> doB

One intuitively expects the observable behavior of these two functions to be the same. But that’s not what happens if monad is inconsistent with applicative.

By the way, there are two ways to solve your problem: simply add a new type wrapper which is ONLY applicative, and not monadic; OR, add a new function to an applicative called zip (or par), which is similar to ap, but which does not promise consistency with monad.