Monoidal Functor is Applicative but where is the Monoid typeclass in the definition of Applicative?

applicative functor
functor, applicative, monad
applicative functor scala
haskell monad
applicative programming with effects
haskell fmap
haskell monoid

Applicative is a Monoidal Functor :

mappend :: f         -> f   -> f
$       ::  (a -> b) ->   a ->   b
<*>     :: f(a -> b) -> f a -> f b

But I don't see any reference about Monoid in the definition of the Applicative typeclass, could you tell me why ?

Definition :

class Functor f => Applicative (f :: * -> *) where
  pure :: a -> f a
  (<*>) :: f (a -> b) -> f a -> f b
  GHC.Base.liftA2 :: (a -> b -> c) -> f a -> f b -> f c
  (*>) :: f a -> f b -> f b
  (<*) :: f a -> f b -> f a
  {-# MINIMAL pure, ((<*>) | liftA2) #-}

No mention of that structural Monoid is provided in this definition, but when you do

> ("ab",(+1)) <*> ("cd", 5) 
>("abcd", 6)

You can clearly see the use of a Structural Monoid "(,) String" when implementing this instance of Applicative.

Another example to show that a "Structural Monoid" is used :

Prelude Data.Monoid> (2::Integer,(+1)) <*> (1::Integer,5)

<interactive>:35:1: error:
    • Could not deduce (Monoid Integer) arising from a use of ‘<*>’
      from the context: Num b
        bound by the inferred type of it :: Num b => (Integer, b)
        at <interactive>:35:1-36
    • In the expression: (2 :: Integer, (+ 1)) <*> (1 :: Integer, 5)
      In an equation for ‘it’:
          it = (2 :: Integer, (+ 1)) <*> (1 :: Integer, 5)

The monoid that's referred to with "monoidal functor" is not a Monoid monoid, i.e. a value-level monoid. It's a type-level monoid instead. Namely, the boring product monoid

type Mempty = ()
type a <> b = (a,b)

(You may notice that this is not strictly speaking a monoid; it's only if you consider ((a,b),c) and (a,(b,c)) as the same type. They are sure enough isomorphic.)

To see what this has to do with Applicative, resp. monoidal functors, we need to write the class in other terms.

class Functor f => Monoidal f where
  pureUnit :: f Mempty
  fzip :: f a -> f b -> f (a<>b)

-- an even more "general nonsense", equivalent formulation is
-- upure :: Mempty -> f Mempty
-- fzipt :: (f a<>f b) -> f (a<>b)
-- i.e. the functor maps a monoid to a monoid (in this case the same monoid).
-- That's really the mathematical idea behind this all.


class Functor f => Monoidal f where
  pureUnit :: f ()
  fzip :: f a -> f b -> f (a,b)

It's a simple exercise to define a generic instance of the standard Applicative class in terms of Monoidal, vice versa.

Regarding ("ab",(+1)) <*> ("cd", 5): that doesn't have much to do with Applicative in general, but only with the writer applicative specifically. The instance is

instance Monoid a => Monoidal ((,) a) where
  pureUnit = (mempty, ())
  fzip (p,a) (q,b) = (p<>q, (a,b))

Functors, Applicative Functors and Monoids, Typeclasses are open, which means that we can define our own data type, think about what it can act like and connect it with the typeclasses that define its  Applicative is a Monoidal Functor : mappend :: f -> f -> f $ :: (a -> b) -> a -> b <*> :: f(a -> b) -> f a -> f b But I don't see any reference about Monoid in the definition of the Applicative typeclass, could you tell me why ?

Applicatives are monoidal, Tags: Haskell, Applicative, monoids, typeclasses. Contents For both Functor and Applicative the type constructor must be of kind * -> * . Type constructor here means what it says: given a type argument, it constructs a type. It starts the definition of the Applicative class and it also introduces a class constraint. It says that if we want to make a type constructor part of the Applicative typeclass, it has to be in Functor first. That's why if we know that if a type constructor is part of the Applicative typeclass, it's also in Functor, so we can use fmap on it.

I wanted to complement Conor McBride's (pigworker) instructive answer with some more examples of Monoids found in Applicatives. It has been observed that the Applicative instance of some functors resembles a corresponding Monoid instance; for example, we have the following analogies:

Applicative → Monoid
List        → Product
Maybe       → All
Either a    → First a
State s     → Endo s

Following Conor's comment, we can understand why we have these correspondences. We use the following observations:

  1. The shape of an Applicative container forms a Monoid under the application operation <*>.
  2. The shape of a functor F is given by F 1 (where 1 denotes the unit ()).

For each of the Applicative functors listed above, we compute their shape by instantiating the functor with the unit element. We get that...

List has the shape of Nat:

List a = μ r . 1 + a × r
List 1 = μ r . 1 + 1 × r
       ≅ μ r . 1 + r
       ≅ Nat

Maybe has the shape of Bool:

Maybe a = 1 + a
Maybe 1 = 1 + 1
        ≅ Bool

Either has the shape of Maybe:

Either a b = a + b
Either a 1 = a + 1
           ≅ Maybe a

State has the shape of Endo:

State s a = (a × s) ^ s
State s 1 = (1 × s) ^ s
          ≅ s ^ s
          ≅ Endo s

The types of the shapes match precisely the types underlying the Monoids listed in the beginning. One thing still puzzles me: some of these types admit multiple Monoid instances (e.g., Bool can be made into a Monoid as All or Any) and I'm not entirely sure why we get one of the instances and not the other. My guess would be that this is related to the applicative laws and how they interact with the other component of the container – its positions.

Applicative monoids, In order to escape the need for flexible contexts, you'll have to define a It's going to be an applicative functor of monoids, so perhaps the use of the letter f, but the type itself doesn't constrain f to any type class. It seems that any applicative functor that contains monoidal values itself forms a monoid. A braided monoidal functor is a monoidal functor between braided monoidal categories (with braidings denoted ) such that the following diagram commutes for every pair of objects A, B in : A symmetric monoidal functor is a braided monoidal functor whose domain and codomain are symmetric monoidal categories .

Typeclassopedia, 7.1 Standard monad transformers; 7.2 Definition and laws What the heck is a monoid, and how is it different from a monad? Gain a deep intuition for each type class and its relationship to other type A somewhat newer addition to the pantheon of standard Haskell type classes, applicative functors  Applicative functors are the programming equivalent of lax monoidal functors with tensorial strength in category theory. Applicative functors were introduced in 2007 by Conor McBride and Ross Paterson in their paper Functional Pearl: applicative programming with effects.

Functortown: Applicative, This series covers the 'Applicative' typeclass and two of its close relatives, applicative functors, we look at the laws of the class and property testing them with as applicative functors and the connection between monoids and applicatives. at IO as an Applicative , what it means to say that functors compose, and how to  The existence of two legal implementations of (<*>) for lists which only differ in the sequencing of effects indicates that [] is a non-commutative applicative functor. A commutative applicative functor, by contrast, leaves no margin for ambiguity in that respect. More formally, a commutative applicative functor is one for which the following holds:

The Const Applicative and Monoids · in Code, The Applicative typeclass has a somewhat infamous reputation for having opaque laws. instance Functor IntConst where fmap _ (IntConst w) = IntConst w The fact that we have Applicative laws and expectations means we can look to fit the Applicative laws…and those properties are exactly monoidal  This module describes a structure intermediate between a functor and a monad (technically, a strong lax monoidal functor). Compared with monads, this interface lacks the full power of the binding operation >>=, but. it has more instances. it is sufficient for many uses, e.g. context-free parsing, or the Traversable class.

  • f has the wrong kind to be Monoid.
  • yeah but how could we express it in Applicative ? are we limited by what haskell can do ? I'd like to understand why we see nothing about Monoid when we look at the definition..
  • Because the term "monoidal functor" is one chunk that can't be broken into to pieces, "a monoid and a functor". It means a functor that acts on a monoidal category and preserves the monoidal structure of that category; and again here "monoidal category" is a single term that can't be broken in two.
  • Monoid does not cover all monoids that can be expressed in Haskell, but only those on ordinary types (that is, things with * kind, as Lee alludes to).
  • @NicolasHenin It is expressed in the instance declaration for a particular Applicative, namely, instance Monoid a => Applicative ((,) a); and the Monoid constraint in that instance declaration has no relation to the "monoidal-functor-ness" of Applicative as a concept.
  • Categorical monoids are only associative up to isomorphism, so it's OK.
  • I always find it awkward to pick a name (or an operator symbol) to talk about the f a -> f b -> f (a,b) combinator (or its uncurried version). fzip is not half bad -- in fact, I might end up adopting it.
  • @duplode well, I thought a lot about these names when I wrote the constrained Applicative class. (There I actually had to use uncurried and category-agnostic signatures, which makes it a whole lot more awkward.)
  • @leftaroundabout I had forgotten about looking in your constrained-categories while looking for existing names on Hackage (and, as you can imagine, my Hoogle/Hayoo searches by type signature didn't lead me to it).
  • It's a actually a concept of multiplication where you factorize the f, and this is maybe where the * from <*> is coming from.... and actually that operation of factorization is the application of the monoid on the functor structure I was talking about earlier... "that doesn't have much to do with Applicative in general," @leftaroundabout, I disagree with that statement, the functor in that context is (a,_) and then you need to provide a way to do that factorization with (,) and a together... This is why when you implement a applicative for tuple, a needs to be a monoid.
  • Who is the Hancock you are referencing?
  • One library that offers the AppM newtype at the very beginning of this answer is reducers, where it is called Ap.