# User:Michiexile/MATH198/Lecture 3

IMPORTANT NOTE: THESE NOTES ARE STILL UNDER DEVELOPMENT. PLEASE WAIT UNTIL AFTER THE LECTURE WITH HANDING ANYTHING IN, OR TREATING THE NOTES AS READY TO READ.

## Contents

### 1 Functors

We've spent quite a bit of time talking about categories, and special entities in them - morphisms and objects, and special kinds of them, and properties we can find.

And one of the main messages visible so far is that as soon as we have an algebraic structure, and homomorphisms, this forms a category. More importantly, many algebraic structures, and algebraic theories, can be captured by studying the structure of the category they form.

So obviously, in order to understand Category Theory, one key will be to understand homomorphisms between categories.

#### 1.1 Homomorphisms of categories

A category is a graph, so a homomorphism of a category should be a homomorphism of a graph that respect the extra structure. Thus, we are led to the definition:

Definition A functor $F:C\to D$ from a category C to a category D is a graph homomorphism F0,F1 between the underlying graphs such that for every object $X\in C_0$:

• $F_1(1_X) = 1_{F_0(X)}$
• F1(gf) = F1(g)F1(f)

Note: We shall consistently use F in place of F0 and F1. The context should be able to tell you whether you are mapping an object or a morphism at any given moment.

##### 1.1.1 Examples and non-examples
• Monoid homomorphisms
• Monotone functions between posets
• Pick a basis for every vectorspace, send $V\mapsto\dim V$ and $f:V\to W$ to the matrix representing that morphism in the chosen bases.

#### 1.2 Interpreting functors in Haskell

One example of particular interest to us is the category Hask. A functor in Hask is something that takes a type, and returns a new type. Not only that, we also require that it takes arrows and return new arrows. So let's pick all this apart for a minute or two.

Taking a type and returning a type means that you are really building a polymorphic type class: you have a family of types parametrized by some type variable. For each type
a
, the functor dataFa = ... will produce a new type,
F a
. This, really, is all we need to reflect the action of F0. The action of F1 in turn is recovered by requiring the parametrized type
F a
to implement the
Functor
typeclass. This typeclass requires you to implement a function
fmap::(a -> b) -> F a -> F b
. This function, as the signature indicates, takes a function
f :: a -> b
and returns a new function
fmap f :: F a -> F b
.

The rules we expect a Functor to obey seem obvious: translating from the categorical intuition we arrive at the rules

• fmap id = id
and
• fmap (g . f) = fmap g . fmap f
Now, the real power of a
Functor
still isn't obvious with this viewpoint. The real power comes in approaching it less categorically. A Haskell functor is a polymorphic type. In a way, it is an prototypical polymorphic type. We have some type, and we change it, in a meaningful way. And the existence of the
Functor
typeclass demands of us that we find a way to translate function applications into the
Functor
image. We can certainly define a boring Functor, such as
data Boring a = Boring
instance Functor Boring where
fmap f = const Boring
but this is not particularly useful. Almost all
Functor
instances will take your type and include it into something different, something useful. And it does this in a way that allows you to lift functions acting on the type it contains, so that they transform them in their container. And the choice of words here is deliberate. Functors can be thought of as data containers, their parameters declaring what they contain, and the
fmap
implementation allowing access to the contents. Lists, trees with node values, trees with leaf values,
Maybe
,
Either
all are
Functor
s in obvious manners.
data List a = Nil | Cons a (List a)
instance Functor List where
fmap f Nil = Nil
fmap f (Cons x lst) = Cons (f x) (fmap f lst)

data Maybe a = Nothing | Just a
instance Functor Maybe where
fmap f Nothing = Nothing
fmap f (Just x) = Just (f x)

data Either b a = Left b | Right a
instance Functor (Either b) where
fmap f (Left x) = Left x
fmap f (Right y) = Right (f y)

data LeafTree a = Leaf a | Node [LeafTree a]
instance Functor LeafTree where
fmap f (Node subtrees) = Node (map (fmap f) subtrees)
fmap f (Leaf x) = Leaf (f x)

data NodeTree a = Leaf | Node a [NodeTree a]
instance Functor NodeTree where
fmap f Leaf = Leaf
fmap f (Node x subtrees) = Node (f x) (map (fmap f) subtrees)

### 2 The category of categories

We define a category Cat by setting objects to be all small categories, and arrows to be all functors between them. Being graph homomorphisms, functors compose, their composition fulfills all requirements on forming a category. It is sometimes useful to argue about a category CAT of all small and most large categories. The issue here is that allowing $CAT\in CAT_0$ opens up for set-theoretical paradoxes.

#### 2.1 Isomorphisms in Cat and equivalences of categories

The definition of an isomorphism holds as is in Cat. However, isomorphisms of categories are too restrictive a concept.

To see this, recall the category Monoid, where each object is a monoid, and each arrow is a monoid homomorphism. We can form a one-object category out of each monoid, and the method to do this is functorial - i.e. does the right thing to arrows to make the whole process a functor.

Specifically, if $h:M\to N$ is a monoid homomorphism, we create a new functor $C(h):C(M)\to C(N)$ by setting C(h)[0]( * ) = * and C(h)[1](m) = h(m). This creates a functor from Monoid to Cat. The domain can be further restricted to a full subcategory OOC of Cat, consisting of all the 1-object categories. We can also define a functor $U:OOC\to Monoid$ by U(C) = C[1] with the monoidal structure on U(C) given by the composition in C. For an arrow $F:A\to B$ we define U(F) = F[1].

These functors take a monoid, builds a one-object category, and hits all of them; and takes a one-object category and builds a monoid. Both functors respect the monoidal structures - yet these are not an isomorphism pair. The clou here is that our construction of C(M) from M requires us to choose something for the one object of the category. And choosing different objects gives us different categories.

Thus, the composition CU is not the identity; there is no guarantee that we will pick the object we started with in the construction in C. Nevertheless, we would be inclined to regard the categories Monoid and OOC as essentially the same. The solution is to introduce a different kind of sameness: Definition A functor $F:C\to D$ is an equivalence of categories if there is a functor $G:D\to C$ and:

• A family $u_C:C\to G(F(C))$ of isomorphisms in C indexed by the objects of C, such that for every arrow $f:C\to C': G(F(f)) = u_{C'}\circ f\circ u_C^{-1}$.
• A family $u_D:D\to F(G(D))$ of isomorphisms in D indexed by the objects of D, such that for every arrow $f:D\to D': F(G(f)) = u_{D'}\circ f\circ u_D^{-1}$.

The functor G in the definition is called a pseudo-inverse of F.

#### 2.2 Natural transformations

The families of morphisms required in the definition of an equivalence show up in more places. Suppose we have two functors $F:A\to B$ and $G:A\to B$. Definition A natural transformation $\alpha:F\to G$ is a family of arrows $\alpha a:F(a)\to G(a)$ indexed by the objects of A such that for any arrow $s:a\to b$ in $G(s)\circ\alpha a = \alpha b\circ F(s)$ (draw diagram)

The commutativity of the corresponding diagram is called the naturality condition on α, and the arrow αa is called the component of the natural transformation α at the object a.

Given two natural transformations $\alpha: F\to G$ and $\beta: G\to H$, we can define a composition $\beta\circ\alpha$ componentwise as $(\beta\circ\alpha)(a) = \beta a \circ \alpha a$.

Proposition The composite of two natural transformations is also a natural transformation.

Proposition Given two categories C,D the collection of all functors $C\to D$ form a category Func(C,D) with objects functors and morphisms natural transformations between these functors.

### 3 Properties of functors

The process of forming homsets within a category C gives, for any object A, two different functors Hom(A, − ): $X\mapsto Hom(A,X)$ and $Hom(-,A): X\mapsto Hom(X,A)$. Functoriality for Hom(A, − ) is easy: Hom(A,f) is the map that takes some $g:A\to X$ and transforms it into $fg:A\to Y$.

Functoriality for Hom( − ,A) is more involved. We can view this as a functor either from Cop, or as a different kind of functor. If we just work with Cop, then no additional definitions are needed - but we need an intuition for the dual categories.

Alternatively, we introduce a new concept of a contravariant functor. A contravariant functor $F:C\to D$ is some map of categories, just like a functor is, but such that F(1[X]) = 1[F(X)], as usual, but such that for a $f:A\to B$, the functor image is some $F(f):F(B)\to F(A)$, and the composition is F(gf) = F(f)F(g). The usual kind of functors are named covariant.

• Full
• Faithful

### 4 Applications for functors

• CS applications
• State machines and monoid actions

### 5 Homework

• * Recall that a category is called discrete if it has no arrows other than the identities. Show that a small category A is discrete if and only if every set function $A_0\to B_0$, for every small category B, is the object part of a unique functor $A\to B$. Analogously, we define a small category B to be indiscrete if for every small category A, every set function $A_0\to B_0$ is the object part of a unique functor $A\to B$. Characterise indiscrete categories by the objects and arrows they have.
• Show that the category of vectorspaces is equivalent to the category with objects integers and arrows matrices.
• Prove the propositions in the section on natural transformations.
• Prove that
listToMaybe :: [a] -> Maybe a
is a natural transformation from the list functor to the maybe functor. Is
catMaybes
a natural transformation? Between which functors? Find three more natural transformations defined in the standard Haskell library.