
<html>

  <head>


    <meta http-equiv="content-type" content="text/html; charset=UTF-8">

  </head>

  <body>

    <p>Hello folks,<br>

      <br>

      base 4.14 has the following instance for `Compose f g`:<br>

      <br>

    </p>

    <pre>instance (Alternative f, Applicative g) => Alternative (Compose f g) where

    empty = Compose empty

    (<|>) = coerce ((<|>) :: f (g a) -> f (g a) -> f (g a))

      :: forall a . Compose f g a -> Compose f g a -> Compose f g a


</pre>

    This instance doesn't really do anything with the `Applicative g`

    constraint it is demanding. It's also kind of unclear what utility

    it delivers, given that the resulting Alternative instance is

    indistinguishable from the outer functor's Alternative instance. In

    other words: `getCompose $ Compose x <|> Compose y == x

    <|> y`.<br>

    <br>

    It seems to me a more useful instance would be:<br>

    <br>

    <pre>instance (Applicative f, Alternative g) => Alternative (Compose f g) where

    empty = Compose $ pure empty

    (<|>) = _ $ liftA2 (<|>)


</pre>

    This is also nicer in a mathematical sense: `Applicative` functors

    correspond to lax monoidal functors from `Hask, (- , -), ()` to

    `Hask, (-, -), ()`. We can interpret `Alternative`s as lax monoidal

    functors from `Hask, Either - -, Void` to `Hask, (-, -), ()`.

    Compatible lax monoidal functors compose, but if you think about the

    relevant "types" of the functors a bit, you'll realize that while we

    can compose an `Applicative` after an `Alternative` to get another

    `Alternative`, the reverse does not work. Hence the instance we have

    today, which has no choice but to just ignore the `Applicative`

    constraint it is demanding.<br>

    <br>

    Does it make sense to replace the instance we have today with the

    `pure empty`, `liftA2 (<|>)` one?<br>

    <br>

    Thanks,<br>

    Asad<br>

  </body>

</html>