Monoid module:Data

A type a is a Monoid if it provides an associative function (<>) that lets you combine any two values of type a into one, and a neutral element (mempty) such that

a <> mempty == mempty <> a == a

A Monoid is a Semigroup with the added requirement of a neutral element. Thus any Monoid is a Semigroup, but not the other way around.

Examples

The Sum monoid is defined by the numerical addition operator and `0` as neutral element:

>>> mempty :: Sum Int
Sum {getSum = 0}

>>> Sum 1 <> Sum 2 <> Sum 3 <> Sum 4 :: Sum Int
Sum {getSum = 10}

We can combine multiple values in a list into a single value using the mconcat function. Note that we have to specify the type here since Int is a monoid under several different operations:

>>> mconcat [1,2,3,4] :: Sum Int
Sum {getSum = 10}

>>> mconcat [] :: Sum Int
Sum {getSum = 0}

Another valid monoid instance of Int is Product It is defined by multiplication and `1` as neutral element:

>>> Product 1 <> Product 2 <> Product 3 <> Product 4 :: Product Int
Product {getProduct = 24}

>>> mconcat [1,2,3,4] :: Product Int
Product {getProduct = 24}

>>> mconcat [] :: Product Int
Product {getProduct = 1}

The class of monoids (types with an associative binary operation that has an identity). Instances should satisfy the following:

• Right identity x <> mempty = x
• Left identity mempty <> x = x
• Associativity x <> (y <> z) = (x <> y) <> z (Semigroup law)
• Concatenation mconcat = foldr (<>) mempty

You can alternatively define mconcat instead of mempty, in which case the laws are:

• Unit mconcat (pure x) = x
• Multiplication mconcat (join xss) = mconcat (fmap mconcat xss)
• Subclass mconcat (toList xs) = sconcat xs

The method names refer to the monoid of lists under concatenation, but there are many other instances. Some types can be viewed as a monoid in more than one way, e.g. both addition and multiplication on numbers. In such cases we often define newtypes and make those instances of Monoid, e.g. Sum and Product. NOTE: Semigroup is a superclass of Monoid since base-4.11.0.0.

The class of monoids (types with an associative binary operation that has an identity). Instances should satisfy the following:

• Right identity x <> mempty = x
• Left identity mempty <> x = x
• Associativity x <> (y <> z) = (x <> y) <> z (Semigroup law)
• Concatenation mconcat = foldr (<>) mempty

The method names refer to the monoid of lists under concatenation, but there are many other instances. Some types can be viewed as a monoid in more than one way, e.g. both addition and multiplication on numbers. In such cases we often define newtypes and make those instances of Monoid, e.g. Sum and Product. NOTE: Semigroup is a superclass of Monoid since base-4.11.0.0.

TextShow instances for Monoid-related newtypes. Since: 2

Bidirectional transforms for Data.Monoid.

A linear monoid is a linear semigroup with an identity on the binary operation. Laws (same as Monoid): * ∀ x ∈ G, x <> mempty = mempty <> x = x

Eliminator functions for data types in Data.Monoid. All of these are re-exported from Data.Eliminator with the following exceptions:

• First and Last are not re-exported from Data.Eliminator, as they clash with eliminators of the same names in Data.Eliminator.Functor and Data.Eliminator.Semigroup.
• Sum and Product are not re-exported from Data.Eliminator, as they clash with eliminators of the same names in Data.Eliminator.Functor.

Extension of Monoid that allows testing a value for equality with mempty. The following law must hold:

null x == (x == mempty)

Furthermore, the performance of this method should be constant, i.e., independent of the length of its argument.

For base < 4.11, the Monoid' constraint is a synonym for things which are instances of both Semigroup and Monoid. For base version 4.11 and onwards, Monoid has Semigroup as a superclass already, so for backwards compatibility Monoid' is provided as a synonym for Monoid.

This module provides a HashMap variant which uses the value's Monoid instance to accumulate conflicting entries when merging Maps. While some functions mirroring those of HashMap are provided here for convenience, more specialized needs will likely want to use either the Newtype or Wrapped instances to manipulate the underlying Map.

A HashMap with monoidal accumulation

This module provides a IntMap variant which uses the value's Monoid instance to accumulate conflicting entries when merging Maps. While some functions mirroring those of IntMap are provided here for convenience, more specialized needs will likely want to use either the Newtype or Wrapped instances to manipulate the underlying Map.

An IntMap with monoidal accumulation

This module provides a Map variant which uses the value's Monoid instance to accumulate conflicting entries when merging Maps. While some functions mirroring those of Map are provided here for convenience, more specialized needs will likely want to use either the Newtype or Wrapped instances to manipulate the underlying Map.

A Map with monoidal accumulation

Utility newtype wrapper to make Map's Monoid also use the element's Monoid.

A (Monoidal m u arr) is a profunctor arr that can be sequenced with the bifunctor m. In rough terms, you can combine two function-like things to one function-like thing that holds both input and output types with the bifunctor m.

This class effectively gives us a way to generate a value of f a based on an i a, for Tensor t i. Having this ability makes a lot of interesting functions possible when used with biretract from SemigroupIn that weren't possible without it: it gives us a "base case" for recursion in a lot of cases. Essentially, we get an i ~> f, pureT, where we can introduce an f a as long as we have an i a. Formally, if we have Tensor t i, we are enriching the category of endofunctors with monoid structure, turning it into a monoidal category. Different choices of t give different monoidal categories. A functor f is known as a "monoid in the (monoidal) category of endofunctors on t" if we can biretract:

t f f ~> f

and also pureT:

i ~> f

This gives us a few interesting results in category theory, which you can stil reading about if you don't care:

• All functors are monoids in the monoidal category on :+:
• The class of functors that are monoids in the monoidal category on :*: is exactly the functors that are instances of Plus.
• The class of functors that are monoids in the monoidal category on Day is exactly the functors that are instances of Applicative.
• The class of functors that are monoids in the monoidal category on Comp is exactly the functors that are instances of Monad.

This is the meaning behind the common adage, "monads are just monoids in the category of endofunctors". It means that if you enrich the category of endofunctors to be monoidal with Comp, then the class of functors that are monoids in that monoidal category are exactly what monads are. However, the adage is a little misleading: there are many other ways to enrich the category of endofunctors to be monoidal, and Comp is just one of them. Similarly, the class of functors that are monoids in the category of endofunctors enriched by Day are Applicative. Note that instances of this class are intended to be written with t and i to be fixed type constructors, and f to be allowed to vary freely:

instance Monad f => MonoidIn Comp Identity f

Any other sort of instance and it's easy to run into problems with type inference. If you want to write an instance that's "polymorphic" on tensor choice, use the WrapHBF and WrapF newtype wrappers over type variables, where the third argument also uses a type constructor:

instance MonoidIn (WrapHBF t) (WrapF i) (MyFunctor t i)

This will prevent problems with overloaded instances.