“Category laws” in Haskell wiki

Question

According to Haskell wiki,

https://en.wikibooks.org/wiki/Haskell/Category_theory#Category_laws

Category laws There are three laws that categories need to follow. Firstly, and most simply, the composition of morphisms needs to be associative.

However,

Composition of relations is associative.

https://en.wikipedia.org/wiki/Composition_of_relations#Properties

the composition of functions is always associative.

https://en.wikipedia.org/wiki/Function_composition#Properties

So, in what scenario, Haskell community (or ones who wiki suppose) consider that the composition of morphisms is not associative breaking the rule?

Thanks.

Answer 1

You correctly identify function composition and relation composition as associative operations, and then appear to ask this question:

Since all the operations that we call composition are already proven to be associative, why do we make associativity a requirement of composition operations?

There are two subtle bugs in this question.

1. You assume that the collection of operations that we call composition only contains function and relation composition. But this is not so: I think I could, given time, write down 20-30 different classes of composition operations, with each class containing an infinite number of actual composition operations!
2. Your assumed causal relation is backwards. We do not start by calling a bunch of different things composition, and then deciding to demand that they be associative; rather, first we identify some conditions that we like (associativity, having an identity, being well-typed) and then allow ourselves to attach the label "composition" to any operation that fulfills those conditions.

Let's do some examples, in the style of point (2). We will first build up a mathematical structure of interest to us, then we will ask: can we call this a category if we want to?

Sets with function composition

Suppose I proposed the following mathematical structure:

• There is a big collection of objects, one for each set that's possible. (This statement can't be formulated in set theory! But that's okay. We don't have to work in set theory if we don't want to.)
• There is a collection of arrows for each pair of objects; namely, for sets X and Y, there is one arrow of type X -> Y for each function whose domain is X and whose codomain is Y.
• To compose two arrows, we use standard function composition from set theory.

Is this structure a category? As you correctly observed in your question, the answer is yes, because:

1. For any object X, we can create an arrow of type X -> X for which composing with other arrows does nothing (namely, the function that returns its input unchanged).
2. As you correctly observed, we can prove that function composition is associative.

Numbers with addition

Here is a somewhat simpler structure:

• There is a single object, named X.
• There is a collection of arrows of type X -> X; in this collection is one arrow for each natural number.
• To compose the arrows representing numbers m and n, produce the arrow representing the number m+n.

Notice that in this structure, the composition operation we have defined is neither function composition nor relation composition! The question we are asking now is: are we lying to ourselves when we attach the label composition to this operation, or is that a sensible thing to call it?

In this case, the answer is yes, we can call it composition (and call the whole structure a category), because:

1. We can create an arrow of type X -> X for which composing with other arrows does nothing (namely, the arrow representing the number 0).
2. As we all know, addition is associative.

Positive numbers with addition

How about this slight modification to the previous example:

• There is a single object, named X.
• There is a collection of arrows of type X -> X; in this collection is one arrow for each positive natural number.
• To compose the arrows representing numbers m and n, produce the arrow representing the number m+n.

Can I call this a category? Is this relation something to which I can attach the label "composition"? (Note that the operation itself is the same operation as before!) In this case, the answer is no, we should not call this structure a category, and we should not call this operation a composition, because although the operation is associative, there is no arrow which leaves other arrows unchanged when composing with them.

Numbers with weird exponentiation

One more structure:

• There is a single object, named X.
• There is a collection of arrows of type X -> X; in this collection is one arrow for each natural number.
• To compose arrows m and n:
  • If either of m or n is 0, return the other. For example, the composition of 0 and 1 is 1; the composition of 2 and 0 is 2; and the composition of 0 and 0 is 0.
  • Otherwise, take the exponentiation m^n.

Can we call this structure a category? Is the final operation something we could label as a "composition"? In this case, the answer is no, because although there is an arrow which leaves the others alone under composition (namely 0), the purported composition operation is not associative:

2^(1^2) = 2^1 = 2
(2^1)^2 = 2^2 = 4

With some work, we can cook up fancier examples that fail the category laws in even subtler ways (for example, by being associative, but only having one-sided identities). But by now I hope the pattern is clear: the category laws are desiderata that we use, and the decision we make in each case is about whether a mathematical structure we are interested in is something we can call a "category". (Of course, we are still allowed to be interested in it and study it even if the answer to that question is no!)

Answer 2

Here's a datatype/operation combination that is not a valid Category instance.

The datatype consists simply in a function annotated with some Int value:

import Prelude
import qualified Control.Category as C

data Subs a b = Subs Int (a -> b)

And here's the bogus Category instance. The composition performs subtraction of the annotations:

instance C.Category Subs where
    id = Subs 0 Prelude.id
    (Subs x f) . (Subs y g) = Subs (y - x) (f . g)

However, because subtraction is not associative, that instance is not valid!

main :: IO ()
main = do
    let Subs u _ = (Subs 3 id) C.. ((Subs 10 id) C.. (Subs 2 id))
        Subs v _ = ((Subs 3 id) C.. (Subs 10 id)) C.. (Subs 2 id)
    print u
    print v

This returns

-11
-5

showing that the order of composition matters, contrary to the Category laws.