sundarj · August 22, 2017 13:44
diff --git a/bartosz-milewski--category-theory.html b/bartosz-milewski--category-theory.html
 <style>
 body {
  background-color: #f5f5f5;
  color: #1f1f1f;
  font: 110%/1.5 sans-serif;
  max-width: 75ch;
  margin: 0 auto;
  padding: 1em;
  box-sizing: border-box;
 }
 pre {
  overflow: auto;
 }
 img {
  max-width: 100%;
  height: auto;
 }
 </style>

 <h2 class="post-title">
 			Category Theory for Programmers: The&nbsp;Preface		</h2><h2>Table of Contents</h2><h3>Part One</h3><ol>
 <li><a title="Category: The Essence of Composition" href="https://bartoszmilewski.com/2014/11/04/category-the-essence-of-composition/" target="_blank">Category: The Essence of Composition</a></li>
 <li><a title="Types and Functions" href="https://bartoszmilewski.com/2014/11/24/types-and-functions/" target="_blank">Types and Functions</a></li>
 <li><a title="Categories Great and Small" href="https://bartoszmilewski.com/2014/12/05/categories-great-and-small/" target="_blank">Categories Great and Small</a></li>
 <li><a title="Kleisli Categories" href="https://bartoszmilewski.com/2014/12/23/kleisli-categories/" target="_blank">Kleisli Categories</a></li>
 <li><a title="Products and Coproducts" href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" target="_blank">Products and Coproducts</a></li>
 <li><a title="Simple Algebraic Data Types" href="https://bartoszmilewski.com/2015/01/13/simple-algebraic-data-types/" target="_blank">Simple Algebraic Data Types</a></li>
 <li><a title="Functors" href="https://bartoszmilewski.com/2015/01/20/functors/" target="_blank">Functors</a></li>
 <li><a title="Functoriality" href="https://bartoszmilewski.com/2015/02/03/functoriality/" target="_blank">Functoriality</a></li>
 <li><a title="Function Types" href="https://bartoszmilewski.com/2015/03/13/function-types/" target="_blank">Function Types</a></li>
 <li><a title="Natural Transformations" href="https://bartoszmilewski.com/2015/04/07/natural-transformations/" target="_blank">Natural Transformations</a></li>
 </ol><h3>Part Two</h3><ol>
 <li><a title="Category Theory and Declarative Programming" href="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/" target="_blank">Declarative Programming</a></li>
 <li><a href="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/" target="_blank">Limits and Colimits</a></li>
 <li><a href="https://bartoszmilewski.com/2015/07/21/free-monoids/" target="_blank">Free Monoids</a></li>
 <li><a href="https://bartoszmilewski.com/2015/07/29/representable-functors/" target="_blank">Representable Functors</a></li>
 <li><a href="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/" target="_blank">The Yoneda Lemma</a></li>
 <li><a href="https://bartoszmilewski.com/2015/10/28/yoneda-embedding/" target="_blank">Yoneda Embedding</a></li>
 </ol><h3>Part Three</h3><ol>
 <li><a href="https://bartoszmilewski.com/2015/11/17/its-all-about-morphisms/" target="_blank">It’s All About Morphisms</a></li>
 <li><a href="https://bartoszmilewski.com/2016/04/18/adjunctions/" target="_blank">Adjunctions</a></li>
 <li><a href="https://bartoszmilewski.com/2016/06/15/freeforgetful-adjunctions/" target="_blank">Free/Forgetful Adjunctions</a></li>
 <li><a href="https://bartoszmilewski.com/2016/11/21/monads-programmers-definition/" target="_blank">Monads: Programmer’s Definition</a></li>
 <li><a href="https://bartoszmilewski.com/2016/11/30/monads-and-effects/" target="_blank">Monads and Effects</a></li>
 <li><a href="https://bartoszmilewski.com/2016/12/27/monads-categorically/" target="_blank">Monads Categorically</a></li>
 <li><a href="https://bartoszmilewski.com/2017/01/02/comonads/" target="_blank">Comonads</a></li>
 <li><a href="https://bartoszmilewski.com/2017/02/28/f-algebras/" target="_blank">F-Algebras</a></li>
 <li><a href="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/" target="_blank">Algebras for Monads</a></li>
 <li><a href="https://bartoszmilewski.com/2017/03/29/ends-and-coends/" target="_blank">Ends and Coends</a></li>
 <li><a href="https://bartoszmilewski.com/2017/04/17/kan-extensions/" target="_blank">Kan Extensions</a></li>
 <li><a href="https://bartoszmilewski.com/2017/05/13/enriched-categories/" target="_blank">Enriched Categories</a></li>
 <li><a href="https://bartoszmilewski.com/2017/07/22/topoi/" target="_blank">Topoi</a></li>
 <li>Lawvere Theories</li>
 </ol><p>You may also watch me <a href="https://www.youtube.com/playlist?list=PLbgaMIhjbmEnaH_LTkxLI7FMa2HsnawM_" target="_blank">teaching this material</a> to a live audience.</p><h1>Preface</h1><p>I will attempt, in the space of a few paragraphs, to convince you that this book is written for you, and whatever objections you might have to learning one of the most abstract branches of mathematics in your “copious spare&nbsp;time” are totally unfounded.</p><p>My optimism is based on several observations. First, category theory is a treasure trove&nbsp;of extremely useful programming ideas. Haskell programmers have been tapping this resource&nbsp;for a long time, and the ideas are slowly percolating into other languages, but this process is too slow. We need to speed it up.</p><p>Second, there are many different kinds of math, and they appeal to different audiences. You might be allergic to calculus or algebra, but it doesn’t mean you won’t enjoy category theory. I would go as far as to&nbsp;argue&nbsp;that category theory is the kind of math that is particularly well suited for the minds of programmers. That’s because category theory — rather than dealing with particulars — deals with structure. It deals with the kind of structure that makes programs composable.</p><p>Composition is at the very root of category theory — it’s part of the definition of the category itself. And I will argue strongly that composition is the essence of programming. We’ve been composing things forever, long before some great engineer came up with the idea of a subroutine. Some time ago the principles of structural programming revolutionized programming&nbsp;because they made blocks of code composable. Then came object oriented programming, which is all about composing objects. Functional programming is not only about composing functions and algebraic data structures — it makes concurrency composable — something that’s virtually impossible with other programming paradigms.</p><p>Third, I have a secret weapon, a butcher’s knife, with which I will butcher math to make it more palatable to programmers. When you’re a professional mathematician, you have to be very careful to get all your assumptions straight, qualify every statement properly, and construct all your proofs rigorously. This makes mathematical papers and books extremely hard to read for an outsider. I’m a physicist by training, and in physics we made amazing advances using informal reasoning. Mathematicians laughed at the Dirac delta function, which was made up on the spot by the great physicist P. A. M. Dirac to solve some differential equations. They stopped laughing when they discovered a completely new branch of calculus called distribution theory that formalized Dirac’s insights.</p><p>Of course when using hand-waving arguments you run the risk of saying something blatantly wrong, so I will try to make sure that there is solid mathematical theory behind informal arguments in this book. I do have a worn-out copy of Saunders Mac Lane’s <em>Category Theory for the Working Mathematician</em> on my nightstand.</p><p>Since this is category theory <i>for programmers</i> I will illustrate all major concepts using computer code. You are probably aware that functional languages are closer to math than the more popular imperative languages. They also offer more abstracting power. So a natural temptation would be to say: You must learn Haskell before the bounty of category theory becomes available to you. But that would imply that category theory has no application outside of functional programming and that’s simply not true. So I will provide a lot of C++ examples. Granted, you’ll have to overcome some ugly syntax, the patterns might not stand out from the background of verbosity, and you might be forced to do some copy and paste in lieu of higher abstraction, but that’s just the lot of a C++ programmer.</p><p>But you’re not off the hook as far as Haskell is concerned. You don’t have to become a Haskell programmer, but you need it as a language for sketching and documenting ideas to be implemented in C++. That’s exactly how I got started with Haskell. I found its terse syntax and powerful type system a great help in understanding and implementing C++ templates, data structures, and algorithms. But since I can’t expect the readers to already know Haskell, I will introduce it slowly and explain everything as I go.</p><p>If you’re an experienced programmer, you might be asking yourself: I’ve been coding for so long without worrying about category theory or functional methods, so what’s changed? Surely you can’t help but notice that there’s been a steady stream of new functional features invading imperative languages. Even Java, the bastion of object-oriented programming, let the lambdas in C++ has recently been evolving at a frantic pace — a new standard every few years — trying to catch up with the changing world. All this activity is in preparation for a disruptive change or, as we physicist call it, a phase transition. If you keep heating water, it will eventually start boiling. We are now in the position of a frog that must decide if it should continue swimming in increasingly hot water, or start looking for some alternatives.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg"><img data-attachment-id="3468" data-permalink="https://bartoszmilewski.com/2014/10/28/category-theory-for-programmers-the-preface/img_1299/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg" data-orig-size="758,539" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1414054980&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.00092850510677809&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="IMG_1299" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=300&amp;h=213" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=510" class="aligncenter wp-image-3468 size-medium" style="border:1px solid #000000;" src="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=300&amp;h=213" alt="IMG_1299" width="300" height="213" srcset="https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=300&amp;h=213 300w, https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=600&amp;h=426 600w, https://bartoszmilewski.files.wordpress.com/2014/10/img_1299.jpg?w=150&amp;h=107 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>One of the forces that are driving the big change is the multicore revolution. The prevailing programming paradigm, object oriented programming, doesn’t buy you anything in the realm of concurrency and parallelism, and instead encourages dangerous and buggy design. Data hiding, the basic premise of object orientation, when combined with sharing and mutation, becomes a recipe for data races. The idea of combining a mutex with the data it protects is nice but, unfortunately, locks don’t compose, and lock hiding makes deadlocks more likely and harder to debug.</p><p>But even in the absence of concurrency, the growing complexity of software systems is testing the limits of scalability of the imperative paradigm. To put it simply, side effects are getting out of hand. Granted, functions that have side effects are often convenient and easy to write. Their effects can in principle be encoded in their names and in the comments. A function called SetPassword or WriteFile is obviously mutating some state and generating side effects, and we are used to dealing with that. It’s only when we start composing functions that have side effects on top of other functions that have side effects, and so on, that things start getting hairy. It’s not that side effects are inherently bad — it’s the fact that they are hidden from view that makes them impossible to manage at larger scales. Side effects don’t scale, and imperative programming is all about side effects.</p><p>Changes in hardware and the growing complexity of software are forcing us to rethink the foundations of programming. Just like the builders of Europe’s great gothic cathedrals we’ve been honing our craft to the limits of material and structure. There is an unfinished gothic <a href="http://en.wikipedia.org/wiki/Beauvais_Cathedral" target="_blank">cathedral in Beauvais</a>, France, that stands witness to this deeply human struggle with limitations. It was intended to beat all previous records of height and lightness, but it suffered a series of collapses. Ad hoc measures like iron rods and wooden supports keep it from disintegrating, but obviously a lot of things went wrong. From a modern perspective, it’s a miracle that so many gothic structures had been successfully completed without the help of modern material science, computer modelling, finite element analysis, and general math and physics. I hope future generations will be as admiring of the programming skills we’ve been displaying in building complex operating systems, web servers, and the internet infrastructure. And, frankly, they should, because we’ve done all this based on very flimsy theoretical foundations. We have to fix those foundations if we want to move forward.</p><p>Next: <a href="https://bartoszmilewski.com/2014/11/04/category-the-essence-of-composition/">Category: The Essence of Composition</a>.</p>

 <h2 class="post-title">
 			Category: The Essence of&nbsp;Composition		</h2><p>A category is an embarrassingly simple concept. A category consists of objects and arrows that go between them. That’s why categories are so easy to represent pictorially. An object can be drawn as a circle or a point, and an arrow… is an arrow. (Just for variety, I will occasionally draw objects as piggies and arrows as fireworks.) But the essence of a category is composition. Or, if you prefer, the essence of composition is a category. Arrows compose, so if you have an arrow from object A to object B, and another arrow from object B to object C, then there must be an arrow — their composition — that goes from A to C.</p><p>&nbsp;</p><h2>Arrows as Functions</h2><p>Is this already too much abstract nonsense? Do not despair. Let’s talk concretes. Think of arrows, which are also called <em>morphisms</em>, as functions. You have a function f that takes an argument of type A and returns a B. You have another function g that takes a B and returns a C. You can compose them by passing the result of f to g. You have just defined a new function that takes an A and returns a C.</p><p>In math, such composition is denoted by a small circle between functions: g∘f. Notice the right to left order of composition. For some people this is confusing. You may be familiar with the pipe notation in Unix, as in:</p><pre>lsof | grep Chrome</pre><p>or the chevron <code>&gt;&gt;</code> in F#, which both go from left to right. But in mathematics and in Haskell functions compose right to left. It helps if you read g∘f as “g <em>after</em> f.”</p><p>Let’s make this even more explicit by writing some C code. We have one function <code>f</code> that takes an argument of type <code>A</code> and returns a value of type <code>B</code>:</p><pre>B f(A a);</pre><p>and another:</p><pre>C g(B b);</pre><p>Their composition is:</p><pre>C g_after_f(A a)
 {
    return g(f(a));
 }</pre><p>Here, again, you see right-to-left composition: <code>g(f(a))</code>; this time in C.</p><p>I wish I could tell you that there is a template in the C++ Standard Library that takes two functions and returns their composition, but there isn’t one. So let’s try some Haskell for a change. Here’s the declaration of a function from A to B:</p><pre>f :: A -&gt; B</pre><p>Similarly:</p><pre>g :: B -&gt; C</pre><p>Their composition is:</p><pre>g . f</pre><p>Once you see how simple things are in Haskell, the inability to express straightforward functional concepts in C++ is a little embarrassing. In fact, Haskell will let you use Unicode characters so you can write composition as:</p><pre>g ∘ f</pre><p>You can even use Unicode double colons and arrows:</p><pre>f ∷ A → B</pre><p>So here’s the first Haskell lesson: Double colon means “has the type of…” A function type is created by inserting an arrow between two types. You compose two functions by inserting a period between them (or a Unicode circle).</p><h2>Properties of Composition</h2><p>There are two extremely important properties that the composition in any category must satisfy.</p><p>1. Composition is associative. If you have three morphisms, f, g, and h, that can be composed (that is, their objects match end-to-end), you don’t need parentheses to compose them. In math notation this is expressed as:</p><pre>h∘(g∘f) = (h∘g)∘f = h∘g∘f</pre><p>In (pseudo) Haskell:</p><pre>f :: A -&gt; B
 g :: B -&gt; C
 h :: C -&gt; D
 h . (g . f) == (h . g) . f == h . g . f</pre><p>(I said “pseudo,” because equality is not defined for functions.)</p><p>Associativity is pretty obvious when dealing with functions, but it may be not as obvious in other categories.</p><p>2. For every object A there is an arrow which is a unit of composition. This arrow loops from the object to itself. Being a unit of composition means that, when composed with any arrow that either starts at A or ends at A, respectively, it gives back the same arrow. The unit arrow for object A is called id<sub>A</sub> (identity on A). In math notation, if f goes from A to B then</p><pre>f∘id<sub>A</sub> = f</pre><p>and</p><pre>id<sub>B</sub>∘f = f</pre><p>When dealing with functions, the identity arrow is implemented as the identity function that just returns back its argument. The implementation is the same for every type, which means this function is universally polymorphic. In C++ we could define it as a template:</p><pre>template&lt;class T&gt; T id(T x) { return x; }</pre><p>Of course, in C++ nothing is that simple, because you have to take into account not only what you’re passing but also how (that is, by value, by reference, by const reference, by move, and so on).</p><p>In Haskell, the identity function is part of the standard library (called Prelude). Here’s its declaration and definition:</p><pre>id :: a -&gt; a
 id x = x</pre><p>As you can see, polymorphic functions in Haskell are a piece of cake. In the declaration, you just replace the type with a type variable. Here’s the trick: names of concrete types always start with a capital letter, names of type variables start with a lowercase letter. So here <code>a</code> stands for all types.</p><p>Haskell function definitions consist of the name of the function followed by formal parameters — here just one, <code>x</code>. The body of the function follows the equal sign. This terseness is often shocking to newcomers but you will quickly see that it makes perfect sense. Function definition and function call are the bread and butter of functional programming so their syntax is reduced to the bare minimum. Not only are there no parentheses around the argument list but there are no commas between arguments (you’ll see that later, when we define functions of multiple arguments).</p><p>The body of a function is always an expression — there are no statements in functions. The result of a function is this expression — here, just <code>x</code>.</p><p>This concludes our second Haskell lesson.</p><p>The identity conditions can be written (again, in pseudo-Haskell) as:</p><pre>f . id == f
 id . f == f</pre><p>You might be asking yourself the question: Why would anyone bother with the identity function — a function that does nothing? Then again, why do we bother with the number zero? Zero is a symbol for nothing. Ancient Romans had a number system without a zero and they were able to build excellent roads and aqueducts, some of which survive to this day.</p><p>Neutral values like zero or <code>id</code> are extremely useful when working with symbolic variables. That’s why Romans were not very good at algebra, whereas the Arabs and the Persians, who were familiar with the concept of zero, were. So the identity function becomes very handy as an argument to, or a return from, a higher-order function. Higher order functions are what make symbolic manipulation of functions possible. They are the algebra of functions.</p><p>To summarize: A category consists of objects and arrows (morphisms). Arrows can be composed, and the composition is associative. Every object has an identity arrow that serves as a unit under composition.</p><h2>Composition is the Essence of Programming</h2><p>Functional programmers have a peculiar way of approaching problems. They start by asking very Zen-like questions. For instance, when designing an interactive program, they would ask: What is interaction? When implementing Conway’s Game of Life, they would probably ponder about the meaning of life. In this spirit, I’m going to ask: What is programming? At the most basic level, programming is about telling the computer what to do. “Take the contents of memory address x and add it to the contents of the register EAX.” But even when we program in assembly, the instructions we give the computer are an expression of something more meaningful. We are solving a non-trivial problem (if it were trivial, we wouldn’t need the help of the computer). And how do we solve problems? We decompose bigger problems into smaller problems. If the smaller problems are still too big, we decompose them further, and so on. Finally, we write code that solves all the small problems. And then comes the essence of programming: we compose those pieces of code to create solutions to larger problems. Decomposition wouldn’t make sense if we weren’t able to put the pieces back together.</p><p>This process of hierarchical decomposition and recomposition is not imposed on us by computers. It reflects the limitations of the human mind. Our brains can only deal with a small number of concepts at a time. One of the most cited papers in psychology, <a href="http://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two" target="_blank">The Magical Number Seven, Plus or Minus Two</a>, postulated that we can only keep 7 ± 2 “chunks” of information in our minds. The details of our understanding of the human short-term memory might be changing, but we know for sure that it’s limited. The bottom line is that we are unable to deal with the soup of objects or the spaghetti of code. We need structure not because well-structured programs are pleasant to look at, but because otherwise our brains can’t process them efficiently. We often describe some piece of code as elegant or beautiful, but what we really mean is that it’s easy to process by our limited human minds. Elegant code creates chunks that are just the right size and come in just the right number for our mental digestive system to assimilate them.</p><p>So what are the right chunks for the composition of programs? Their surface area has to increase slower than their volume. (I like this analogy because of the intuition that the surface area of a geometric object grows with the square of its size — slower than the volume, which grows with the cube of its size.) The surface area is the information we need in order to compose chunks. The volume is the information we need in order to implement them. The idea is that, once a chunk is implemented, we can forget about the details of its implementation and concentrate on how it interacts with other chunks. In object-oriented programming, the surface is the class declaration of the object, or its abstract interface. In functional programming, it’s the declaration of a function. (I’m simplifying things a bit, but that’s the gist of it.)</p><p>Category theory is extreme in the sense that it actively discourages us from looking inside the objects. An object in category theory is an abstract nebulous entity. All you can ever know about it is how it relates to other object — how it connects with them using arrows. This is how internet search engines rank web sites by analyzing incoming and outgoing links (except when they cheat). In object-oriented programming, an idealized object is only visible through its abstract interface (pure surface, no volume), with methods playing the role of arrows. The moment you have to dig into the implementation of the object in order to understand how to compose it with other objects, you’ve lost the advantages of your programming paradigm.</p><h2>Challenges</h2><ol>
 <li>Implement, as best as you can, the identity function in your favorite language (or the second favorite, if your favorite language happens to be Haskell).</li>
 <li>Implement the composition function in your favorite language. It takes two functions as arguments and returns a function that is their composition.</li>
 <li>Write a program that tries to test that your composition function respects identity.</li>
 <li>Is the world-wide web a category in any sense? Are links morphisms?</li>
 <li>Is Facebook a category, with people as objects and friendships as morphisms?</li>
 <li>When is a directed graph a category?</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2014/11/24/types-and-functions/">Types and Functions</a>.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408050213" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Types and Functions		</h2><p>The category of types and functions plays an important role in programming, so let’s talk about what types are and why we need them.</p><h2>Who Needs Types?</h2><p>There seems to be some controversy about the advantages of static vs. dynamic and strong vs. weak typing. Let me illustrate these choices with a thought experiment. Imagine millions of monkeys at computer keyboards happily hitting random keys, producing programs, compiling, and running them.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg"><img data-attachment-id="3485" data-permalink="https://bartoszmilewski.com/2014/11/04/category-the-essence-of-composition/img_1329/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg" data-orig-size="944,1095" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1414488332&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;125&quot;,&quot;shutter_speed&quot;:&quot;0.0083333333333333&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="IMG_1329" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=259" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=510" class="aligncenter wp-image-3485 size-medium" style="border:1px solid #000000;" src="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=258&amp;h=300" alt="IMG_1329" width="258" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=258&amp;h=300 258w, https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=516&amp;h=600 516w, https://bartoszmilewski.files.wordpress.com/2014/10/img_1329.jpg?w=129&amp;h=150 129w" sizes="(max-width: 258px) 100vw, 258px"></a></p><p>With machine language, any combination of bytes produced by monkeys would be accepted and run. But with higher level languages, we do appreciate the fact that a compiler is able to detect lexical and grammatical errors. Lots of monkeys will go without bananas, but the remaining programs will have a better chance of being useful. Type checking provides yet another barrier against nonsensical programs. Moreover, whereas in a dynamically typed language, type mismatches would be discovered at runtime, in strongly typed statically checked languages type mismatches are discovered at compile time, eliminating lots of incorrect programs before they have a chance to run.</p><p>So the question is, do we want to make monkeys happy, or do we want to produce correct programs?</p><p>The usual goal in the typing monkeys thought experiment is the production of the complete works of Shakespeare. Having a spell checker and a grammar checker in the loop would drastically increase the odds. The analog of a type checker would go even further by making sure that, once Romeo is declared a human being, he doesn’t sprout leaves or trap photons in his powerful gravitational field.</p><h2>Types Are About Composability</h2><p>Category theory is about composing arrows. But not any two arrows can be composed. The target object of one arrow must be the same as the source source object of the next arrow. In programming we pass the results on one function to another. The program will not work if the target function is not able to correctly interpret the data produced by the source function. The two ends must fit for the composition to work. The stronger the type system of the language, the better this match can be described and mechanically verified.</p><p>The only serious argument I hear against strong static type checking is that it might eliminate some programs that are semantically correct. In practice, this happens extremely rarely and, in any case, every language provides some kind of a backdoor to bypass the type system when that’s really necessary. Even Haskell has <code>unsafeCoerce</code>. But such devices should by used judiciously. Franz Kafka’s character, Gregor Samsa, breaks the type system when he metamorphoses into a giant bug, and we all know how it ends.</p><p>Another argument I hear a lot is that dealing with types imposes too much burden on the programmer. I could sympathize with this sentiment after having to write a few declarations of iterators in C++ myself, except that there is a technology called <em>type inference</em> that lets the compiler deduce most of the types from the context in which they are used. In C++, you can now declare a variable <code>auto</code> and let the compiler figure out its type.</p><p>In Haskell, except on rare occasions, type annotations are purely optional. Programmers tend to use them anyway, because they can tell a lot about the semantics of code, and they make compilation errors easier to understand. It’s a common practice in Haskell to start a project by designing the types. Later, type annotations drive the implementation and become compiler-enforced comments.</p><p>Strong static typing is often used as an excuse for not testing the code. You may sometimes hear Haskell programmers saying, “If it compiles, it must be correct.” Of course, there is no guarantee that a type-correct program is correct in the sense of producing the right ouput. The result of this cavalier attitude is that in several studies Haskell didn’t come as strongly ahead of the pack in code quality as one would expect. It seems that, in the commercial setting, the pressure to fix bugs is applied only up to a certain quality level, which has everything to do with the economics of software development and the tolerance of the end user, and very little to do with the programming language or methodology. A better criterion would be to measure how many projects fall behind schedule or are delivered with drastically reduced functionality.</p><p>As for the argument that unit testing can replace strong typing, consider the common refactoring practice in strongly typed languages: changing the type of an argument of a particular function. In a strongly typed language, it’s enough to modify the declaration of that function and then fix all the build breaks. In a weakly typed language, the fact that a function now expects different data cannot be propagated to call sites. Unit testing may catch some of the mismatches, but testing is almost always a probabilistic rather than a deterministic process. Testing is a poor substitute for proof.</p><h2>What Are Types?</h2><p>The simplest intuition for types is that they are sets of values. The type <code>Bool</code> (remember, concrete types start with a capital letter in Haskell) is a two-element set of <code>True</code> and <code>False</code>. Type <code>Char</code> is a set of all Unicode characters like <code>'a'</code> or <code>'ą'</code>.</p><p>Sets can be finite or infinite. The type of <code>String</code>, which is a synonym for a list of <code>Char</code>, is an example of an infinite set.</p><p>When we declare <code>x</code> to be an <code>Integer</code>:</p><pre>x :: Integer</pre><p>we are saying that it’s an element of the set of integers. <code>Integer</code> in Haskell is an infinite set, and it can be used to do arbitrary precision arithmetic. There is also a finite-set <code>Int</code> that corresponds to machine type, just like the C++ <code>int</code>.</p><p>There are some subtleties that make this identification of types and sets tricky. There are problems with polymorphic functions that involve circular definitions, and with the fact that you can’t have a set of all sets; but as I promised, I won’t be a stickler for math. The great thing is that there is a category of sets, which is called <strong>Set</strong>, and we’ll just work with it. In <strong>Set</strong>, objects are sets and morphisms (arrows) are functions.</p><p><strong>Set</strong> is a very special category, because we can actually peek inside its objects and get a lot of intuitions from doing that. For instance, we know that an empty set has no elements. We know that there are special one-element sets. We know that functions map elements of one set to elements of another set. They can map two elements to one, but not one element to two. We know that an identity function maps each element of a set to itself, and so on. The plan is to gradually forget all this information and instead express all those notions in purely categorical terms, that is in terms of objects and arrows.</p><p>In the ideal world we would just say that Haskell types are sets and Haskell functions are mathematical functions between sets. There is just one little problem: A mathematical function does not execute any code — it just knows the answer. A Haskell function has to calculate the answer. It’s not a problem if the answer can be obtained in a finite number of steps — however big that number might be. But there are some calculations that involve recursion, and those might never terminate. We can’t just ban non-terminating functions from Haskell because distinguishing between terminating and non-terminating functions is undecidable — the famous halting problem. That’s why computer scientists came up with a brilliant idea, or a major hack, depending on your point of view, to extend every type by one more special value called the <em>bottom</em> and denoted by <code>_|_</code>, or Unicode ⊥. This “value” corresponds to a non-terminating computation. So a function declared as:</p><pre>f :: Bool -&gt; Bool</pre><p>may return <code>True</code>, <code>False</code>, or <code>_|_</code>; the latter meaning that it would never terminate.</p><p>Interestingly, once you accept the bottom as part of the type system, it is convenient to treat every runtime error as a bottom, and even allow functions to return the bottom explicitly. The latter is usually done using the expression <code>undefined</code>, as in:</p><pre>f :: Bool -&gt; Bool
 f x = undefined</pre><p>This definition type checks because <code>undefined</code> evaluates to bottom, which is a member of any type, including <code>Bool</code>. You can even write:</p><pre>f :: Bool -&gt; Bool
 f = undefined</pre><p>(without the <code>x</code>) because the bottom is also a member of the type <code>Bool-&gt;Bool</code>.</p><p>Functions that may return bottom are called partial, as opposed to total functions, which return valid results for every possible argument.</p><p>Because of the bottom, you’ll see the category of Haskell types and functions referred to as <strong>Hask</strong> rather than <strong>Set</strong>. From the theoretical point of view, this is the source of never-ending complications, so at this point I will use my butcher’s knife and terminate this line of reasoning. From the pragmatic point of view, it’s okay to ignore non-terminating functions and bottoms, and treat <strong>Hask</strong> as bona fide <strong>Set</strong> (see Bibliography at the end).</p><h2>Why Do We Need a Mathematical Model?</h2><p>As a programmer you are intimately familiar with the syntax and grammar of your programming language. These aspects of the language are usually described using formal notation at the very beginning of the language spec. But the meaning, or semantics, of the language is much harder to describe; it takes many more pages, is rarely formal enough, and almost never complete. Hence the never ending discussions among language lawyers, and a whole cottage industry of books dedicated to the exegesis of the finer points of language standards.</p><p>There are formal tools for describing the semantics of a language but, because of their complexity, they are mostly used with simplified academic languages, not real-life programming behemoths. One such tool called <em>operational semantics</em> describes the mechanics of program execution. It defines a formalized idealized interpreter. The semantics of industrial languages, such as C++, is usually described using informal operational reasoning, often in terms of an “abstract machine.”</p><p>The problem is that it’s very hard to prove things about programs using operational semantics. To show a property of a program you essentially have to “run it” through the idealized interpreter.</p><p>It doesn’t matter that programmers never perform formal proofs of correctness. We always “think” that we write correct programs. Nobody sits at the keyboard saying, “Oh, I’ll just throw a few lines of code and see what happens.” We think that the code we write will perform certain actions that will produce desired results. We are usually quite surprised when it doesn’t. That means we do reason about programs we write, and we usually do it by running an interpreter in our heads. It’s just really hard to keep track of all the variables. Computers are good at running programs — humans are not! If we were, we wouldn’t need computers.</p><p>But there is an alternative. It’s called <em>denotational semantics</em> and it’s based on math. In denotational semantics every programing construct is given its mathematical interpretation. With that, if you want to prove a property of a program, you just prove a mathematical theorem. You might think that theorem proving is hard, but the fact is that we humans have been building up mathematical methods for thousands of years, so there is a wealth of accumulated knowledge to tap into. Also, as compared to the kind of theorems that professional mathematicians prove, the problems that we encounter in programming are usually quite simple, if not trivial.</p><p>Consider the definition of a factorial function in Haskell, which is a language quite amenable to denotational semantics:</p><pre>fact n = product [1..n]</pre><p>The expression <code>[1..n]</code> is a list of integers from 1 to n. The function <code>product</code> multiplies all elements of a list. That’s just like a definition of factorial taken from a math text. Compare this with C:</p><pre>int fact(int n) {
    int i;
    int result = 1;
    for (i = 2; i &lt;= n; ++i)
        result *= i;
    return result;
 }</pre><p>Need I say more?</p><p>Okay, I’ll be the first to admit that this was a cheap shot! A factorial function has an obvious mathematical denotation. An astute reader might ask: What’s the mathematical model for reading a character from the keyboard or sending a packet across the network? For the longest time that would have been an awkward question leading to a rather convoluted explanation. It seemed like denotational semantics wasn’t the best fit for a considerable number of important tasks that were essential for writing useful programs, and which could be easily tackled by operational semantics. The breakthrough came from category theory. Eugenio Moggi discovered that computational effect can be mapped to monads. This turned out to be an important observation that not only gave denotational semantics a new lease on life and made pure functional programs more usable, but also shed new light on traditional programming. I’ll talk about monads later, when we develop more categorical tools.</p><p>One of the important advantages of having a mathematical model for programming is that it’s possible to perform formal proofs of correctness of software. This might not seem so important when you’re writing consumer software, but there are areas of programming where the price of failure may be exorbitant, or where human life is at stake. But even when writing web applications for the health system, you may appreciate the thought that functions and algorithms from the Haskell standard library come with proofs of correctness.</p><h2>Pure and Dirty Functions</h2><p>The things we call functions in C++ or any other imperative language, are not the same things mathematicians call functions. A mathematical function is just a mapping of values to values.</p><p>We can implement a mathematical function in a programming language: Such a function, given an input value will calculate the output value. A function to produce a square of a number will probably multiply the input value by itself. It will do it every time it’s called, and it’s guaranteed to produce the same output every time it’s called with the same input. The square of a number doesn’t change with the phases of the Moon.</p><p>Also, calculating the square of a number should not have a side effect of dispensing a tasty treat for your dog. A “function” that does that cannot be easily modelled as a mathematical function.</p><p>In programming languages, functions that always produce the same result given the same input and have no side effects are called <em>pure functions</em>. In a pure functional language like Haskell all functions are pure. Because of that, it’s easier to give these languages denotational semantics and model them using category theory. As for other languages, it’s always possible to restrict yourself to a pure subset, or reason about side effects separately. Later we’ll see how monads let us model all kinds of effects using only pure functions. So we really don’t lose anything by restricting ourselves to mathematical functions.</p><h2>Examples of Types</h2><p>Once you realize that types are sets, you can think of some rather exotic types. For instance, what’s the type corresponding to an empty set? No, it’s not C++ <code>void</code>, although this type <em>is</em> called <code>Void</code> in Haskell. It’s a type that’s not inhabited by any values. You can define a function that takes <code>Void</code>, but you can never call it. To call it, you would have to provide a value of the type <code>Void</code>, and there just aren’t any. As for what this function can return, there are no restrictions whatsoever. It can return any type (although it never will, because it can’t be called). In other words it’s a function that’s polymorphic in the return type. Haskellers have a name for it:</p><pre>absurd :: Void -&gt; a</pre><p>(Remember, <code>a</code> is a type variable that can stand for any type.) The name is not coincidental. There is deeper interpretation of types and functions in terms of logic called the Curry-Howard isomorphism. The type <code>Void</code> represents falsity, and the type of the function <code>absurd</code> corresponds to the statement that from falsity follows anything, as in the Latin adage “ex falso sequitur quodlibet.”</p><p>Next is the type that corresponds to a singleton set. It’s a type that has only one possible value. This value just “is.” You might not immediately recognise it as such, but that is the C++ <code>void</code>. Think of functions from and to this type. A function from <code>void</code> can always be called. If it’s a pure function, it will always return the same result. Here’s an example of such a function:</p><pre>int f44() { return 44; }</pre><p>You might think of this function as taking “nothing”, but as we’ve just seen, a function that takes “nothing” can never be called because there is no value representing “nothing.” So what does this function take? Conceptually, it takes a dummy value of which there is only one instance ever, so we don’t have to mention it explicitly. In Haskell, however, there is a symbol for this value: an empty pair of parentheses, <code>()</code>. So, by a funny coincidence (or is it a coincidence?), the call to a function of void looks the same in C++ and in Haskell. Also, because of the Haskell’s love of terseness, the same symbol <code>()</code> is used for the type, the constructor, and the only value corresponding to a singleton set. So here’s this function in Haskell:</p><pre>f44 :: () -&gt; Integer
 f44 () = 44</pre><p>The first line declares that <code>f44</code> takes the type <code>()</code>, pronounced “unit,” into the type <code>Integer</code>. The second line defines <code>f44</code> by pattern matching the only constructor for unit, namely <code>()</code>, and producing the number 44. You call this function by providing the unit value <code>()</code>:</p><pre>f44 ()</pre><p>Notice that every function of unit is equivalent to picking a single element from the target type (here, picking the <code>Integer</code> 44). In fact you could think of <code>f44</code> as a different representation for the number 44. This is an example of how we can replace explicit mention of elements of a set by talking about functions (arrows) instead. Functions from unit to any type A are in one-to-one correspondence with the elements of that set A.</p><p>What about functions with the <code>void</code> return type, or, in Haskell, with the unit return type? In C++ such functions are used for side effects, but we know that these are not real functions in the mathematical sense of the word. A pure function that returns unit does nothing: it discards its argument.</p><p>Mathematically, a function from a set A to a singleton set maps every element of A to the single element of that singleton set. For every A there is exactly one such function. Here’s this function for <code>Integer</code>:</p><pre>fInt :: Integer -&gt; ()
 fInt x = ()</pre><p>You give it any integer, and it gives you back a unit. In the spirit of terseness, Haskell lets you use the wildcard pattern, the underscore, for an argument that is discarded. This way you don’t have to invent a name for it. So the above can be rewritten as:</p><pre>fInt :: Integer -&gt; ()
 fInt _ = ()</pre><p>Notice that the implementation of this function not only doesn’t depend on the value passed to it, but it doesn’t even depend on the type of the argument.</p><p>Functions that can be implemented with the same formula for any type are called parametrically polymorphic. You can implement a whole family of such functions with one equation using a type parameter instead of a concrete type. What should we call a polymorphic function from any type to unit type? Of course we’ll call it <code>unit</code>:</p><pre>unit :: a -&gt; ()
 unit _ = ()</pre><p>In C++ you would write this function as:</p><pre>template&lt;class T&gt;
 void unit(T) {}</pre><p>Next in the typology of types is a two-element set. In C++ it’s called <code>bool</code> and in Haskell, predictably, <code>Bool</code>. The difference is that in C++ <code>bool</code> is a built-in type, whereas in Haskell it can be defined as follows:</p><pre>data Bool = True | False</pre><p>(The way to read this definition is that <code>Bool</code> is either <code>True</code> or <code>False</code>.) In principle, one should also be able to define a Boolean type in C++ as an enumeration:</p><pre>enum bool {
    true,
    false
 };</pre><p>but C++ <code>enum</code> is secretly an integer. The C++11 “<code>enum class</code>” could have been used instead, but then you would have to qualify its values with the class name, as in <code>bool::true</code> and <code>bool::false</code>, not to mention having to include the appropriate header in every file that uses it.</p><p>Pure functions from <code>Bool</code> just pick two values from the target type, one corresponding to <code>True</code> and another to <code>False</code>.</p><p>Functions to <code>Bool</code> are called <i>predicates</i>. For instance, the Haskell library <code>Data.Char</code> is full of predicates like <code>isAlpha</code> or <code>isDigit</code>. In C++ there is a similar library <code></code> that defines, among others, <code>isalpha</code> and <code>isdigit</code>, but these return an <code>int</code> rather than a Boolean. The actual predicates are defined in <code>std::ctype</code> and have the form <code>ctype::is(alpha, c)</code>, <code>ctype::is(digit, c)</code>, etc.</p><h2>Challenges</h2><ol>
 <li>Define a higher-order function (or a function object) <code>memoize</code> in your favorite language. This function takes a pure function <code>f</code> as an argument and returns a function that behaves almost exactly like <code>f</code>, except that it only calls the original function once for every argument, stores the result internally, and subsequently returns this stored result every time it’s called with the same argument. You can tell the memoized function from the original by watching its performance. For instance, try to memoize a function that takes a long time to evaluate. You’ll have to wait for the result the first time you call it, but on subsequent calls, with the same argument, you should get the result immediately.</li>
 <li>Try to memoize a function from your standard library that you normally use to produce random numbers. Does it work?</li>
 <li>Most random number generators can be initialized with a seed. Implement a function that takes a seed, calls the random number generator with that seed, and returns the result. Memoize that function. Does it work?</li>
 <li>Which of these C++ functions are pure? Try to memoize them and observe what happens when you call them multiple times: memoized and not.
 <ol>
 <li>The factorial function from the example in the text.</li>
 <li>
 <pre>std::getchar()</pre>
 </li>
 <li>
 <pre>bool f() {
    std::cout &lt;&lt; "Hello!" &lt;&lt; std::endl;
    return true;
 }</pre>
 </li>
 <li>
 <pre>int f(int x)
 {
    static int y = 0;
    y += x;
    return y;
 }</pre>
 </li>
 </ol>
 </li>
 <li>How many different functions are there from <code>Bool</code> to <code>Bool</code>? Can you implement them all?</li>
 <li>Draw a picture of a category whose only objects are the types <code>Void</code>, <code>()</code> (unit), and <code>Bool</code>; with arrows corresponding to all possible functions between these types. Label the arrows with the names of the functions.</li>
 </ol><h2>Bibliography</h2><ol>
 <li>Nils Anders Danielsson, John Hughes, Patrik Jansson, Jeremy Gibbons, <a href="http://www.cs.ox.ac.uk/jeremy.gibbons/publications/fast+loose.pdf" target="_blank">Fast and Loose Reasoning is Morally Correct</a>. This paper provides justification for ignoring bottoms in most contexts.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2014/12/05/categories-great-and-small/">Categories Great and Small</a><br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408093438" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Categories Great and&nbsp;Small		</h2><p>You can get real appreciation for categories by studying a variety of examples. Categories come in all shapes and sizes and often pop up in unexpected places. We’ll start with something really simple.</p><h2>No Objects</h2><p>The most trivial category is one with zero objects and, consequently, zero morphisms. It’s a very sad category by itself, but it may be important in the context of other categories, for instance, in the category of all categories (yes, there is one). If you think that an empty set makes sense, then why not an empty category?</p><h2>Simple Graphs</h2><p>You can build categories just by connecting objects with arrows. You can imagine starting with any directed graph and making it into a category by simply adding more arrows. First, add an identity arrow at each node. Then, for any two arrows such that the end of one coincides with the beginning of the other (in other words, any two <em>composable</em> arrows), add a new arrow to serve as their composition. Every time you add a new arrow, you have to also consider its composition with any other arrow (except for the identity arrows) and itself. You usually end up with infinitely many arrows, but that’s okay.</p><p>Another way of looking at this process is that you’re creating a category, which has an object for every node in the graph, and all possible <em>chains</em> of composable graph edges as morphisms. (You may even consider identity morphisms as special cases of chains of length zero.)</p><p>Such a category is called a <em>free category</em> generated by a given graph. It’s an example of a free construction, a process of completing a given structure by extending it with a minimum number of items to satisfy its laws (here, the laws of a category). We’ll see more examples of it in the future.</p><h2>Orders</h2><p>And now for something completely different! A category where a morphism is a relation between objects: the relation of being less than or equal. Let’s check if it indeed is a category. Do we have identity morphisms? Every object is less than or equal to itself: check! Do we have composition? If a &lt;= b and b &lt;= c then a &lt;= c: check! Is composition associative? Check! A set with a relation like this is called a <em>preorder</em>, so a preorder is indeed a category.</p><p>You can also have a stronger relation, that satisfies an additional condition that, if a &lt;= b and b &lt;= a then a must be the same as b. That’s called a <em>partial order</em>.</p><p>Finally, you can impose the condition that any two objects are in a relation with each other, one way or another; and that gives you a <em>linear order</em> or <em>total order</em>.</p><p>Let’s characterize these ordered sets as categories. A preorder is a category where there is at most one morphism going from any object a to any object b. Another name for such a category is “thin.” A preorder is a thin category.</p><p>A set of morphisms from object a to object b in a category C is called a <em>hom-set</em> and is written as C(a, b) (or, sometimes, Hom<sub>C</sub>(a, b)). So every hom-set in a preorder is either empty or a singleton. That includes the hom-set C(a, a), the set of morphisms from a to a, which must be a singleton, containing only the identity, in any preorder. You may, however, have cycles in a preorder. Cycles are forbidden in a partial order.</p><p>It’s very important to be able to recognize preorders, partial orders, and total orders because of sorting. Sorting algorithms, such as quicksort, bubble sort, merge sort, etc., can only work correctly on total orders. Partial orders can be sorted using topological sort.</p><h2>Monoid as Set</h2><p>Monoid is an embarrassingly simple but amazingly powerful concept. It’s the concept behind basic arithmetics: Both addition and multiplication form a monoid. Monoids are ubiquitous in programming. They show up as strings, lists, foldable data structures, futures in concurrent programming, events in functional reactive programming, and so on.</p><p>Traditionally, a monoid is defined as a set with a binary operation. All that’s required from this operation is that it’s associative, and that there is one special element that behaves like a unit with respect to it.</p><p>For instance, natural numbers with zero form a monoid under addition. Associativity means that:</p><pre>(a + b) + c = a + (b + c)</pre><p>(In other words, we can skip parentheses when adding numbers.)</p><p>The neutral element is zero, because:</p><pre>0 + a = a</pre><p>and</p><pre>a + 0 = a</pre><p>The second equation is redundant, because addition is commutative (a + b = b + a), but commutativity is not part of the definition of a monoid. For instance, string concatenation is not commutative and yet it forms a monoid. The neutral element for string concatenation, by the way, is an empty string, which can be attached to either side of a string without changing it.</p><p>In Haskell we can define a type class for monoids — a type for which there is a neutral element called <code>mempty</code> and a binary operation called <code>mappend</code>:</p><pre>class Monoid m where
    mempty  :: m
    mappend :: m -&gt; m -&gt; m</pre><p>The type signature for a two-argument function, <code>m-&gt;m-&gt;m</code>, might look strange at first, but it will make perfect sense after we talk about currying. You may interpret a signature with multiple arrows in two basic ways: as a function of multiple arguments, with the rightmost type being the return type; or as a function of one argument (the leftmost one), returning a function. The latter interpretation may be emphasized by adding parentheses (which are redundant, because the arrow is right-associative), as in: <code>m-&gt;(m-&gt;m)</code>. We’ll come back to this interpretation in a moment.</p><p>Notice that, in Haskell, there is no way to express the monoidal properties of <code>mempty</code> and <code>mappend</code> (i.e., the fact that <code>mempty</code> is neutral and that <code>mappend</code> is associative). It’s the responsibility of the programmer to make sure they are satisfied.</p><p>Haskell classes are not as intrusive as C++ classes. When you’re defining a new type, you don’t have to specify its class up front. You are free to procrastinate and declare a given type to be an instance of some class much later. As an example, let’s declare <code>String</code> to be a monoid by providing the implementation of <code>mempty</code> and <code>mappend</code> (this is, in fact, done for you in the standard Prelude):</p><pre>instance Monoid String where
    mempty = ""
    mappend = (++)</pre><p>Here, we have reused the list concatenation operator <code>(++)</code>, because a <code>String</code> is just a list of characters.</p><p>A word about Haskell syntax: Any infix operator can be turned into a two-argument function by surrounding it with parentheses. Given two strings, you can concatenate them by inserting <code>++</code> between them:</p><pre>"Hello " ++ "world!"</pre><p>or by passing them as two arguments to the parenthesized <code>(++)</code>:</p><pre>(++) "Hello " "world!"</pre><p>Notice that arguments to a function are not separated by commas or surrounded by parentheses. (This is probably the hardest thing to get used to when learning Haskell.)</p><p>It’s worth emphasizing that Haskell lets you express equality of functions, as in:</p><pre>mappend = (++)</pre><p>Conceptually, this is different than expressing the equality of values produced by functions, as in:</p><pre>mappend s1 s2 = (++) s1 s2</pre><p>The former translates into equality of morphisms in the category <b>Hask</b> (or <b>Set</b>, if we ignore bottoms, which is the name for never-ending calculations). Such equations are not only more succinct, but can often be generalized to other categories. The latter is called <em>extensional</em> equality, and states the fact that for any two input strings, the outputs of <code>mappend</code> and <code>(++)</code> are the same. Since the values of arguments are sometimes called <em>points</em> (as in: the value of f at point x), this is called point-wise equality. Function equality without specifying the arguments is described as <em>point-free</em>. (Incidentally, point-free equations often involve composition of functions, which is symbolized by a point, so this might be a little confusing to the beginner.)</p><p>The closest one can get to declaring a monoid in C++ would be to use the (proposed) syntax for concepts.</p><pre>template&lt;class T&gt;
  T mempty = delete;

 template&lt;class T&gt;
  T mappend(T, T) = delete;

 template&lt;class M&gt;
  concept bool Monoid = requires (M m) {
    { mempty&lt;M&gt; } -&gt; M;
    { mappend(m, m); } -&gt; M;
  };</pre><p>The first definition uses a value template (also proposed). A polymorphic value is a family of values — a different value for every type.</p><p>The keyword <code>delete</code> means that there is no default value defined: It will have to be specified on a case-by-case basis. Similarly, there is no default for <code>mappend</code>.</p><p>The concept <code>Monoid</code> is a predicate (hence the <code>bool</code> type) that tests whether there exist appropriate definitions of <code>mempty</code> and <code>mappend</code> for a given type <code>M</code>.</p><p>An instantiation of the Monoid concept can be accomplished by providing appropriate specializations and overloads:</p><pre>template&lt;&gt;
 std::string mempty&lt;std::string&gt; = {""};

 std::string mappend(std::string s1, std::string s2) {
    return s1 + s2;
 }</pre><h2>Monoid as Category</h2><p>That was the “familiar” definition of the monoid in terms of elements of a set. But as you know, in category theory we try to get away from sets and their elements, and instead talk about objects and morphisms. So let’s change our perspective a bit and think of the application of the binary operator as “moving” or “shifting” things around the set.</p><p>For instance, there is the operation of adding 5 to every natural number. It maps 0 to 5, 1 to 6, 2 to 7, and so on. That’s a function defined on the set of natural numbers. That’s good: we have a function and a set. In general, for any number n there is a function of adding n — the “adder” of n.</p><p>How do adders compose? The composition of the function that adds 5 with the function that adds 7 is a function that adds 12. So the composition of adders can be made equivalent to the rules of addition. That’s good too: we can replace addition with function composition.</p><p>But wait, there’s more: There is also the adder for the neutral element, zero. Adding zero doesn’t move things around, so it’s the identity function in the set of natural numbers.</p><p>Instead of giving you the traditional rules of addition, I could as well give you the rules of composing adders, without any loss of information. Notice that the composition of adders is associative, because the composition of functions is associative; and we have the zero adder corresponding to the identity function.</p><p>An astute reader might have noticed that the mapping from integers to adders follows from the second interpretation of the type signature of <code>mappend</code> as <code>m-&gt;(m-&gt;m)</code>. It tells us that <code>mappend</code> maps an element of a monoid set to a function acting on that set.</p><p>Now I want you to forget that you are dealing with the set of natural numbers and just think of it as a single object, a blob with a bunch of morphisms — the adders. A monoid is a single object category. In fact the name monoid comes from Greek <em>mono</em>, which means single. Every monoid can be described as a single object category with a set of morphisms that follow appropriate rules of composition.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg"><img data-attachment-id="3683" data-permalink="https://bartoszmilewski.com/2014/12/05/categories-great-and-small/monoid/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg" data-orig-size="503,640" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1418319899&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.02&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Monoid" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=236&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=503" class="aligncenter wp-image-3683 size-medium" style="border:1px solid #000000;" src="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=236&amp;h=300" alt="Monoid" width="236" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=236&amp;h=300 236w, https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=472&amp;h=600 472w, https://bartoszmilewski.files.wordpress.com/2014/12/monoid.jpg?w=118&amp;h=150 118w" sizes="(max-width: 236px) 100vw, 236px"></a></p><p>String concatenation is an interesting case, because we have a choice of defining right appenders and left appenders (or <em>prependers</em>, if you will). The composition tables of the two models are a mirror reverse of each other. You can easily convince yourself that appending “bar” after “foo” corresponds to prepending “foo” after prepending “bar”.</p><p>You might ask the question whether every categorical monoid — a one-object category — defines a unique set-with-binary-operator monoid. It turns out that we can always extract a set from a single-object category. This set is the set of morphisms — the adders in our example. In other words, we have the hom-set M(m, m) of the single object m in the category M. We can easily define a binary operator in this set: The monoidal product of two set-elements is the element corresponding to the composition of the corresponding morphisms. If you give me two elements of M(m, m) corresponding to <code>f</code> and <code>g</code>, their product will correspond to the composition <code>g∘f</code>. The composition always exists, because the source and the target for these morphisms are the same object. And it’s associative by the rules of category. The identity morphism is the neutral element of this product. So we can always recover a set monoid from a category monoid. For all intents and purposes they are one and the same.</p><p>There is just one little nit for mathematicians to pick: morphisms don’t have to form a set. In the world of categories there are things larger than sets. A category in which morphisms between any two objects form a set is called locally small. As promised, I will be mostly ignoring such subtleties, but I thought I should mention them for the record.</p><p>A lot of interesting phenomena in category theory have their root in the fact that elements of a hom-set can be seen both as morphisms, which follow the rules of composition, and as points in a set. Here, composition of morphisms in M translates into monoidal product in the set M(m, m).</p><h2>Acknowledgments</h2><p>I’d like to thank Andrew Sutton for rewriting my C++ monoid concept code according to his and Bjarne Stroustrup’s latest proposal.</p><h2>Challenges</h2><ol>
 <li>Generate a free category from:
 <ol>
 <li>A graph with one node and no edges</li>
 <li>A graph with one node and one (directed) edge (hint: this edge can be composed with itself)</li>
 <li>A graph with two nodes and a single arrow between them</li>
 <li>A graph with a single node and 26 arrows marked with the letters of the alphabet: a, b, c … z.</li>
 </ol>
 </li>
 <li>What kind of order is this?
 <ol>
 <li>A set of sets with the inclusion relation: A is included in B if every element of A is also an element of B.</li>
 <li>C++ types with the following subtyping relation: T1 is a subtype of T2 if a pointer to T1 can be passed to a function that expects a pointer to T2 without triggering a compilation error.</li>
 </ol>
 </li>
 <li>Considering that Bool is a set of two values True and False, show that it forms two (set-theoretical) monoids with respect to, respectively, operator <code>&amp;&amp;</code> (AND) and <code>||</code> (OR).</li>
 <li>Represent the Bool monoid with the AND operator as a category: List the morphisms and their rules of composition.</li>
 <li>Represent addition modulo 3 as a monoid category.</li>
 </ol><p>Next: A programming example of pure functions that do logging using <a title="Kleisli Categories" href="https://bartoszmilewski.com/2014/12/23/kleisli-categories/">Kleisli categories</a>.</p>

 <h2 class="post-title">
 			Kleisli Categories		</h2><h2>Composition of Logs</h2><p>You’ve seen how to model types and pure functions as a category. I also mentioned that there is a way to model side effects, or non-pure functions, in category theory. Let’s have a look at one such example: functions that log or trace their execution. Something that, in an imperative language, would likely be implemented by mutating some global state, as in:</p><pre><span class="red">string logger;</span>

 bool negate(bool b) {
     <span class="red">logger += "Not so! ";</span>
     return !b;
 }</pre><p>You know that this is not a pure function, because its memoized version would fail to produce a log. This function has <em>side effects</em>.</p><p>In modern programming, we try to stay away from global mutable state as much as possible — if only because of the complications of concurrency. And you would never put code like this in a library.</p><p>Fortunately for us, it’s possible to make this function pure. You just have to pass the log explicitly, in and out. Let’s do that by adding a string argument, and pairing regular output with a string that contains the updated log:</p><pre>pair&lt;bool, <span class="red">string</span>&gt; negate(bool b, <span class="red">string logger</span>) {
     return make_pair(!b, logger + "Not so! ");
 }</pre><p>This function is pure, it has no side effects, it returns the same pair every time it’s called with the same arguments, and it can be memoized if necessary. However, considering the cumulative nature of the log, you’d have to memoize all possible histories that can lead to a given call. There would be a separate memo entry for:</p><pre>negate(true, "It was the best of times. ");</pre><p>and</p><pre>negate(true, "It was the worst of times. ");</pre><p>and so on.</p><p>It’s also not a very good interface for a library function. The callers are free to ignore the string in the return type, so that’s not a huge burden; but they are forced to pass a string as input, which might be inconvenient.</p><p>Is there a way to do the same thing less intrusively? Is there a way to separate concerns? In this simple example, the main purpose of the function <code>negate</code> is to turn one Boolean into another. The logging is secondary. Granted, the message that is logged is specific to the function, but the task of aggregating the messages into one continuous log is a separate concern. We still want the function to produce a string, but we’d like to unburden it from producing a log. So here’s the compromise solution:</p><pre>pair&lt;bool, string&gt; negate(bool b) {
     return make_pair(!b, "Not so! ");
 }</pre><p>The idea is that the log will be aggregated <em>between</em> function calls.</p><p>To see how this can be done, let’s switch to a slightly more realistic example. We have one function from string to string that turns lower case characters to upper case:</p><pre>string toUpper(string s) {
    string result;
    int (*toupperp)(int) = &amp;toupper; // toupper is overloaded
    transform(begin(s), end(s), back_inserter(result), toupperp);
    return result;
 }</pre><p>and another that splits a string into a vector of strings, breaking it on whitespace boundaries:</p><pre>vector&lt;string&gt; toWords(string s) {
    return words(s);
 }</pre><p>The actual work is done in the auxiliary function <code>words</code>:</p><pre>vector&lt;string&gt; words(string s) {
    vector&lt;string&gt; result{""};
    for (auto i = begin(s); i != end(s); ++i)
    {
        if (isspace(*i))
            result.push_back("");
        else
            <span class="skimlinks-unlinked">result.back</span>() += *i;
    }
    return result;
 }</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg"><img data-attachment-id="3712" data-permalink="https://bartoszmilewski.com/2014/12/23/kleisli-categories/piggyback/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg" data-orig-size="300,320" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1418768745&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;100&quot;,&quot;shutter_speed&quot;:&quot;0.016666666666667&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="PiggyBack" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=176&amp;h=188" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=300" class="  alignright wp-image-3712" src="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=176&amp;h=188" alt="PiggyBack" width="176" height="188" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=176&amp;h=188 176w, https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=141&amp;h=150 141w, https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg?w=281&amp;h=300 281w, https://bartoszmilewski.files.wordpress.com/2014/12/piggyback.jpg 300w" sizes="(max-width: 176px) 100vw, 176px"></a></p><p>We want to modify the functions <code>toUpper</code> and <code>toWords</code> so that they piggyback a message string on top of their regular return values.</p><p>We will “embellish” the return values of these functions. Let’s do it in a generic way by defining a template <code>Writer</code> that encapsulates a pair whose first component is a value of arbitrary type <code>A</code> and the second component is a string:</p><pre>template&lt;class A&gt;
 using Writer = pair&lt;A, string&gt;;</pre><p>Here are the embellished functions:</p><pre>Writer&lt;string&gt; toUpper(string s) {
    string result;
    int (*toupperp)(int) = &amp;toupper;
    transform(begin(s), end(s), back_inserter(result), toupperp);
    return make_pair(result, "toUpper ");
 }

 Writer&lt;vector&lt;string&gt;&gt; toWords(string s) {
    return make_pair(words(s), "toWords ");
 }</pre><p>We want to compose these two functions into another embellished function that uppercases a string and splits it into words, all the while producing a log of those actions. Here’s how we may do it:</p><pre>Writer&lt;vector&lt;string&gt;&gt; process(string s) {
    auto p1 = toUpper(s);
    auto p2 = toWords(p1.first);
    return make_pair(p2.first, <span class="red">p1.second + p2.second</span>);
 }</pre><p>We have accomplished our goal: The aggregation of the log is no longer the concern of the individual functions. They produce their own messages, which are then, externally, concatenated into a larger log.</p><p>Now imagine a whole program written in this style. It’s a nightmare of repetitive, error-prone code. But we are programmers. We know how to deal with repetitive code: we abstract it! This is, however, not your run of the mill abstraction — we have to abstract <em>function composition</em> itself. But composition is the essence of category theory, so before we write more code, let’s analyze the problem from the categorical point of view.</p><h2>The Writer Category</h2><p>The idea of embellishing the return types of a bunch of functions in order to piggyback some additional functionality turns out to be very fruitful. We’ll see many more examples of it. The starting point is our regular category of types and functions. We’ll leave the types as objects, but redefine our morphisms to be the embellished functions.</p><p>For instance, suppose that we want to embellish the function <code>isEven</code> that goes from <code>int</code> to <code>bool</code>. We turn it into a morphism that is represented by an embellished function. The important point is that this morphism is still considered an arrow between the objects <code>int</code> and <code>bool</code>, even though the embellished function returns a pair:</p><pre>pair&lt;bool, string&gt; isEven(int n) {
     return make_pair(n % 2 == 0, "isEven ");
 }</pre><p>By the laws of a category, we should be able to compose this morphism with another morphism that goes from the object <code>bool</code> to whatever. In particular, we should be able to compose it with our earlier <code>negate</code>:</p><pre>pair&lt;bool, string&gt; negate(bool b) {
     return make_pair(!b, "Not so! ");
 }</pre><p>Obviously, we cannot compose these two morphisms the same way we compose regular functions, because of the input/output mismatch. Their composition should look more like this:</p><pre>pair&lt;bool, string&gt; isOdd(int n) {
    pair&lt;bool, string&gt; p1 = isEven(n);
    pair&lt;bool, string&gt; p2 = negate(p1.first);
    return make_pair(p2.first, p1.second + p2.second);
 }</pre><p>So here’s the recipe for the composition of two morphisms in this new category we are constructing:</p><ol>
 <li>Execute the embellished function corresponding to the first morphism</li>
 <li>Extract the first component of the result pair and pass it to the embellished function corresponding to the second morphism</li>
 <li>Concatenate the second component (the string) of of the first result and the second component (the string) of the second result</li>
 <li>Return a new pair combining the first component of the final result with the concatenated string.</li>
 </ol><p>If we want to abstract this composition as a higher order function in C++, we have to use a template parameterized by three types corresponding to three objects in our category. It should take two embellished functions that are composable according to our rules, and return a third embellished function:</p><pre>template&lt;class A, class B, class C&gt;
 function&lt;Writer&lt;C&gt;(A)&gt; compose(function&lt;Writer&lt;B&gt;(A)&gt; m1,
                               function&lt;Writer&lt;C&gt;(B)&gt; m2)
 {
    return [m1, m2](A x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
 }</pre><p>Now we can go back to our earlier example and implement the composition of <code>toUpper</code> and <code>toWords</code> using this new template:</p><pre>Writer&lt;vector&lt;string&gt;&gt; process(string s) {
   return compose&lt;string, string, vector&lt;string&gt;&gt;(toUpper, toWords)(s);
 }</pre><p>There is still a lot of noise with the passing of types to the <code>compose</code> template. This can be avoided as long as you have a C++14-compliant compiler that supports generalized lambda functions with return type deduction (credit for this code goes to Eric Niebler):</p><pre>auto const compose = [](auto m1, auto m2) {
    return [m1, m2](auto x) {
        auto p1 = m1(x);
        auto p2 = m2(p1.first);
        return make_pair(p2.first, p1.second + p2.second);
    };
 };</pre><p>In this new definition, the implementation of <code>process</code> simplifies to:</p><pre>Writer&lt;vector&lt;string&gt;&gt; process(string s){
   return compose(toUpper, toWords)(s);
 }</pre><p>But we are not finished yet. We have defined composition in our new category, but what are the identity morphisms? These are not our regular identity functions! They have to be morphisms from type A back to type A, which means they are embellished functions of the form:</p><pre>Writer&lt;A&gt; identity(A);</pre><p>They have to behave like units with respect to composition. If you look at our definition of composition, you’ll see that an identity morphism should pass its argument without change, and only contribute an empty string to the log:</p><pre>template&lt;class A&gt;
 Writer&lt;A&gt; identity(A x) {
    return make_pair(x, "");
 }</pre><p>You can easily convince yourself that the category we have just defined is indeed a legitimate category. In particular, our composition is trivially associative. If you follow what’s happening with the first component of each pair, it’s just a regular function composition, which is associative. The second components are being concatenated, and concatenation is also associative.</p><p>An astute reader may notice that it would be easy to generalize this construction to any monoid, not just the string monoid. We would use <code>mappend</code> inside <code>compose</code> and <code>mempty</code> inside <code>identity</code> (in place of <code>+</code> and <code>""</code>). There really is no reason to limit ourselves to logging just strings. A good library writer should be able to identify the bare minimum of constraints that make the library work — here the logging library’s only requirement is that the log have monoidal properties.</p><h2>Writer in Haskell</h2><p>The same thing in Haskell is a little more terse, and we also get a lot more help from the compiler. Let’s start by defining the <code>Writer</code> type:</p><pre>type Writer a = (a, String)</pre><p>Here I’m just defining a type alias, an equivalent of a <code>typedef</code> (or <code>using</code>) in C++. The type <code>Writer</code> is parameterized by a type variable <code>a</code> and is equivalent to a pair of <code>a</code> and <code>String</code>. The syntax for pairs is minimal: just two items in parentheses, separated by a comma.</p><p>Our morphisms are functions from an arbitrary type to some <code>Writer</code> type:</p><pre>a -&gt; Writer b</pre><p>We’ll declare the composition as a funny infix operator, sometimes called the “fish”:</p><pre>(&gt;=&gt;) :: (a -&gt; Writer b) -&gt; (b -&gt; Writer c) -&gt; (a -&gt; Writer c)</pre><p>It’s a function of two arguments, each being a function on its own, and returning a function. The first argument is of the type <code>(a-&gt;Writer b)</code>, the second is <code>(b-&gt;Writer c)</code>, and the result is <code>(a-&gt;Writer c)</code>.</p><p>Here’s the definition of this infix operator — the two arguments <code>m1</code> and <code>m2</code> appearing on either side of the fishy symbol:</p><pre>m1 &gt;=&gt; m2 = \x -&gt;
    let (y, s1) = m1 x
        (z, s2) = m2 y
    in (z, s1 ++ s2)</pre><p>The result is a lambda function of one argument <code>x</code>. The lambda is written as a backslash — think of it as the Greek letter λ with an amputated leg.</p><p>The <code>let</code> expression lets you declare auxiliary variables. Here the result of the call to <code>m1</code> is pattern matched to a pair of variables <code>(y, s1)</code>; and the result of the call to <code>m2</code>, with the argument <code>y</code> from the first pattern, is matched to <code>(z, s2)</code>.</p><p>It is common in Haskell to pattern match pairs, rather than use accessors, as we did in C++. Other than that there is a pretty straightforward correspondence between the two implementations.</p><p>The overall value of the <code>let</code> expression is specified in its <code>in</code> clause: here it’s a pair whose first component is <code>z</code> and the second component is the concatenation of two strings, <code>s1++s2</code>.</p><p>I will also define the identity morphism for our category, but for reasons that will become clear much later, I will call it <code>return</code>.</p><pre>return :: a -&gt; Writer a
 return x = (x, "")</pre><p>For completeness, let’s have the Haskell versions of the embellished functions <code>upCase</code> and <code>toWords</code>:</p><pre>upCase :: String -&gt; Writer String
 upCase s = (map toUpper s, "upCase ")</pre><pre>toWords :: String -&gt; Writer [String]
 toWords s = (words s, "toWords ")</pre><p>The function <code>map</code> corresponds to the C++ <code>transform</code>. It applies the character function <code>toUpper</code> to the string <code>s</code>. The auxiliary function <code>words</code> is defined in the standard Prelude library.</p><p>Finally, the composition of the two functions is accomplished with the help of the fish operator:</p><pre>process :: String -&gt; Writer [String]
 process = upCase &gt;=&gt; toWords</pre><h2>Kleisli Categories</h2><p>You might have guessed that I haven’t invented this category on the spot. It’s an example of the so called Kleisli category — a category based on a monad. We are not ready to discuss monads yet, but I wanted to give you a taste of what they can do. For our limited purposes, a Kleisli category has, as objects, the types of the underlying programming language. Morphisms from type A to type B are functions that go from A to a type derived from B using the particular embellishment. Each Kleisli category defines its own way of composing such morphisms, as well as the identity morphisms with respect to that composition. (Later we’ll see that the imprecise term “embellishment” corresponds to the notion of an endofunctor in a category.)</p><p>The particular monad that I used as the basis of the category in this post is called the <em>writer monad</em> and it’s used for logging or tracing the execution of functions. It’s also an example of a more general mechanism for embedding effects in pure computations. You’ve seen previously that we could model programming-language types and functions in the category of sets (disregarding bottoms, as usual). Here we have extended this model to a slightly different category, a category where morphisms are represented by embellished functions, and their composition does more than just pass the output of one function to the input of another. We have one more degree of freedom to play with: the composition itself. It turns out that this is exactly the degree of freedom which makes it possible to give simple denotational semantics to programs that in imperative languages are traditionally implemented using side effects.</p><h2>Challenge</h2><p>A function that is not defined for all possible values of its argument is called a partial function. It’s not really a function in the mathematical sense, so it doesn’t fit the standard categorical mold. It can, however, be represented by a function that returns an embellished type <code>optional</code>:</p><pre>template&lt;class A&gt; class optional {
    bool _isValid;
    A    _value;
 public:
    optional()    : _isValid(false) {}
    optional(A v) : _isValid(true), _value(v) {}
    bool isValid() const { return _isValid; }
    A value() const { return _value; }
 };</pre><p>As an example, here’s the implementation of the embellished function <code>safe_root</code>:</p><pre>optional&lt;double&gt; safe_root(double x) {
    if (x &gt;= 0) return optional&lt;double&gt;{sqrt(x)};
    else return optional&lt;double&gt;{};
 }</pre><p>Here’s the challenge:</p><ol>
 <li>Construct the Kleisli category for partial functions (define composition and identity).</li>
 <li>Implement the embellished function <code>safe_reciprocal</code> that returns a valid reciprocal of its argument, if it’s different from zero.</li>
 <li>Compose <code>safe_root</code> and <code>safe_reciprocal</code> to implement <code>safe_root_reciprocal</code> that calculates <code>sqrt(1/x)</code> whenever possible.</li>
 </ol><h2>Acknowledgments</h2><p>I’m grateful to Eric Niebler for reading the draft and providing the clever implementation of <code>compose</code> that uses advanced features of C++14 to drive type inference. I was able to cut the whole section of old fashioned template magic that did the same thing using type traits. Good riddance! I’m also grateful to Gershom Bazerman for useful comments that helped me clarify some important points.</p><p>Next: <a href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/">Products and Coproducts</a>.</p>

 <h2 class="post-title">
 			Products and Coproducts		</h2><h2>Follow the Arrows</h2><p>The Ancient Greek playwright Euripides once said: “Every man is like the company he is wont to keep.” We are defined by our relationships. Nowhere is this more true than in category theory. If we want to single out a particular object in a category, we can only do this by describing its pattern of relationships with other objects (and itself). These relationships are defined by morphisms.</p><p>There is a common construction in category theory called the <em>universal construction</em> for defining objects in terms of their relationships. One way of doing this is to pick a pattern, a particular shape constructed from objects and morphisms, and look for all its occurrences in the category. If it’s a common enough pattern, and the category is large, chances are you’ll have lots and lots of hits. The trick is to establish some kind of ranking among those hits, and pick what could be considered the best fit.</p><p>This process is reminiscent of the way we do web searches. A query is like a pattern. A very general query will give you large <em>recall</em>: lots of hits. Some may be relevant, others not. To eliminate irrelevant hits, you refine your query. That increases its <em>precision</em>. Finally, the search engine will rank the hits and, hopefully, the one result that you’re interested in will be at the top of the list.</p><h2>Initial Object</h2><p>The simplest shape is a single object. Obviously, there are as many instances of this shape as there are objects in a given category. That’s a lot to choose from. We need to establish some kind of ranking and try to find the object that tops this hierarchy. The only means at our disposal are morphisms. If you think of morphisms as arrows, then it’s possible that there is an overall net flow of arrows from one end of the category to another. This is true in ordered categories, for instance in partial orders. We could generalize that notion of object precedence by saying that object <em>a</em> is “more initial” than object <em>b</em> if there is an arrow (a morphism) going from <em>a</em> to <em>b</em>. We would then define <em>the</em> initial object as one that has arrows going to all other objects. Obviously there is no guarantee that such an object exists, and that’s okay. A bigger problem is that there may be too many such objects: The recall is good, but precision is lacking. The solution is to take a hint from ordered categories — they allow at most one arrow between any two objects: there is only one way of being less-than or equal-to another object. Which leads us to this definition of the initial object:</p><p class="box2">The <strong>initial object</strong> is the object that has one and only one morphism going to any object in the category.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg"><img data-attachment-id="3763" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/initial/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg" data-orig-size="608,640" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437747&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0038759689922481&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Initial" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=285&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=510" class="aligncenter size-medium wp-image-3763" src="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=285&amp;h=300" alt="Initial" width="285" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=285&amp;h=300 285w, https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=570&amp;h=600 570w, https://bartoszmilewski.files.wordpress.com/2014/12/initial.jpg?w=143&amp;h=150 143w" sizes="(max-width: 285px) 100vw, 285px"></a></p><p>However, even that doesn’t guarantee the uniqueness of the initial object (if one exists). But it guarantees the next best thing: uniqueness <em>up to isomorphism</em>. Isomorphisms are very important in category theory, so I’ll talk about them shortly. For now, let’s just agree that uniqueness up to isomorphism justifies the use of “the” in the definition of the initial object.</p><p>Here are some examples: The initial object in a partially ordered set (often called a <em>poset</em>) is its least element. Some posets don’t have an initial object — like the set of all integers, positive and negative, with less-than-or-equal relation for morphisms.</p><p>In the category of sets and functions, the initial object is the empty set. Remember, an empty set corresponds to the Haskell type <code>Void</code> (there is no corresponding type in C++) and the unique polymorphic function from <code>Void</code> to any other type is called <code>absurd</code>:</p><pre>absurd :: Void -&gt; a</pre><p>It’s this family of morphisms that makes <code>Void</code> the initial object in the category of types.</p><h2>Terminal Object</h2><p>Let’s continue with the single-object pattern, but let’s change the way we rank the objects. We’ll say that object <em>a</em> is “more terminal” than object <em>b</em> if there is a morphism going from <em>b</em> to <em>a</em> (notice the reversal of direction). We’ll be looking for an object that’s more terminal than any other object in the category. Again, we will insist on uniqueness:</p><p class="box2">The <strong>terminal object</strong> is the object with one and only one morphism coming to it from any object in the category.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg"><img data-attachment-id="3765" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/final/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg" data-orig-size="640,635" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437747&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0038759689922481&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Final" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=300&amp;h=298" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=510" class="aligncenter size-medium wp-image-3765" src="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=300&amp;h=298" alt="Final" width="300" height="298" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=300&amp;h=298 300w, https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=600&amp;h=596 600w, https://bartoszmilewski.files.wordpress.com/2014/12/final.jpg?w=150&amp;h=150 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>And again, the terminal object is unique, up to isomorphism, which I will show shortly. But first let’s look at some examples. In a poset, the terminal object, if it exists, is the biggest object. In the category of sets, the terminal object is a singleton. We’ve already talked about singletons — they correspond to the <code>void</code> type in C++ and the unit type <code>()</code> in Haskell. It’s a type that has only one value — implicit in C++ and explicit in Haskell, denoted by <code>()</code>. We’ve also established that there is one and only one pure function from any type to the unit type:</p><pre>unit :: a -&gt; ()
 unit _ = ()</pre><p>so all the conditions for the terminal object are satisfied.</p><p>Notice that in this example the uniqueness condition is crucial, because there are other sets (actually, all of them, except for the empty set) that have incoming morphisms from every set. For instance, there is a Boolean-valued function (a predicate) defined for every type:</p><pre>yes :: a -&gt; Bool
 yes _ = True</pre><p>But <code>Bool</code> is not a terminal object. There is at least one more <code>Bool</code>-valued function from every type:</p><pre>no :: a -&gt; Bool
 no _ = False</pre><p>Insisting on uniqueness gives us just the right precision to narrow down the definition of the terminal object to just one type.</p><h2>Duality</h2><p>You can’t help but to notice the symmetry between the way we defined the initial object and the terminal object. The only difference between the two was the direction of morphisms. It turns out that for any category C we can define the <em>opposite category</em> C<sup>op</sup> just by reversing all the arrows. The opposite category automatically satisfies all the requirements of a category, as long as we simultaneously redefine composition. If original morphisms <code>f::a-&gt;b</code> and <code>g::b-&gt;c</code> composed to <code>h::a-&gt;c</code> with <code>h=g∘f</code>, then the reversed morphisms <code>f<sup>op</sup>::b-&gt;a</code> and <code>g<sup>op</sup>::c-&gt;b</code> will compose to <code>h<sup>op</sup>::c-&gt;a</code> with <code>h<sup>op</sup>=f<sup>op</sup>∘g<sup>op</sup></code>. And reversing the identity arrows is a (pun alert!) no-op.</p><p>Duality is a very important property of categories because it doubles the productivity of every mathematician working in category theory. For every construction you come up with, there is its opposite; and for every theorem you prove, you get one for free. The constructions in the opposite category are often prefixed with “co”, so you have products and coproducts, monads and comonads, cones and cocones, limits and colimits, and so on. There are no cocomonads though, because reversing the arrows twice gets us back to the original state.</p><p>It follows then that a terminal object is the initial object in the opposite category.</p><h2>Isomorphisms</h2><p>As programmers, we are well aware that defining equality is a nontrivial task. What does it mean for two objects to be equal? Do they have to occupy the same location in memory (pointer equality)? Or is it enough that the values of all their components are equal? Are two complex numbers equal if one is expressed as the real and imaginary part, and the other as modulus and angle? You’d think that mathematicians would have figured out the meaning of equality, but they haven’t. They have the same problem of multiple competing definitions for equality. There is the propositional equality, intensional equality, extensional equality, and equality as a path in homotopy type theory. And then there are the weaker notions of isomorphism, and even weaker of equivalence.</p><p>The intuition is that isomorphic objects look the same — they have the same shape. It means that every part of one object corresponds to some part of another object in a one-to-one mapping. As far as our instruments can tell, the two objects are a perfect copy of each other. Mathematically it means that there is a mapping from object <em>a</em> to object <em>b</em>, and there is a mapping from object <em>b</em> back to object <em>a</em>, and they are the inverse of each other. In category theory we replace mappings with morphisms. An isomorphism is an invertible morphism; or a pair of morphisms, one being the inverse of the other.</p><p>We understand the inverse in terms of composition and identity: Morphism <em>g</em> is the inverse of morphism <em>f</em> if their composition is the identity morphism. These are actually two equations because there are two ways of composing two morphisms:</p><pre>f . g = id
 g . f = id</pre><p>When I said that the initial (terminal) object was unique up to isomorphism, I meant that any two initial (terminal) objects are isomorphic. That’s actually easy to see. Let’s suppose that we have two initial objects i<sub>1</sub> and i<sub>2</sub>. Since i<sub>1</sub> is initial, there is a unique morphism <em>f</em> from i<sub>1</sub> to i<sub>2</sub>. By the same token, since i<sub>2</sub> is initial, there is a unique morphism <em>g</em> from i<sub>2</sub> to i<sub>1</sub>. What’s the composition of these two morphisms?</p><p>The composition <em>g∘f</em> must be a morphism from i<sub>1</sub> to i<sub>1</sub>. But i<sub>1</sub> is initial so there can only be one morphism going from i<sub>1</sub> to i<sub>1</sub>. Since we are in a category, we know that there is an identity morphism from i<sub>1</sub> to i<sub>1</sub>, and since there is room for only one, that must be it. Therefore <em>g∘f</em> is equal to identity. Similarly, <em>f∘g</em> must be equal to identity, because there can be only one morphism from i<sub>2</sub> back to i<sub>2</sub>. This proves that <em>f</em> and <em>g</em> must be the inverse of each other. Therefore any two initial objects are isomorphic.</p><p>Notice that in this proof we used the uniqueness of the morphism from the initial object to itself. Without that we couldn’t prove the “up to isomorphism” part. But why do we need the uniqueness of <em>f</em> and <em>g</em>? Because not only is the initial object unique up to isomorphism, it is unique up to <em>unique</em> isomorphism. In principle, there could be more than one isomorphism between two objects, but that’s not the case here. This “uniqueness up to unique isomorphism” is the important property of all universal constructions.</p><h2>Products</h2><p>The next universal construction is that of a product. We know what a cartesian product of two sets is: it’s a set of pairs. But what’s the pattern that connects the product set with its constituent sets? If we can figure that out, we’ll be able to generalize it to other categories.</p><p>All we can say is that there are two functions, the projections, from the product to each of the constituents. In Haskell, these two functions are called <code>fst</code> and <code>snd</code> and they pick, respectively, the first and the second component of a pair:</p><pre>fst :: (a, b) -&gt; a
 fst (x, y) = x</pre><pre>snd :: (a, b) -&gt; b
 snd (x, y) = y</pre><p>Here, the functions are defined by pattern matching their arguments: the pattern that matches any pair is <code>(x, y)</code>, and it extracts its components into variables <code>x</code> and <code>y</code>.</p><p>These definitions can be simplified even further with the use of wildcards:</p><pre>fst (x, _) = x
 snd (_, y) = y</pre><p>In C++, we would use template functions, for instance:</p><pre>template&lt;class A, class B&gt;
 A fst(pair&lt;A, B&gt; const &amp; p) {
    return p.first;
 }</pre><p>Equipped with this seemingly very limited knowledge, let’s try to define a pattern of objects and morphisms in the category of sets that will lead us to the construction of a product of two sets, <em>a</em> and <em>b</em>. This pattern consists of an object <em>c</em> and two morphisms <em>p</em> and <em>q</em> connecting it to <em>a</em> and <em>b</em>, respectively:</p><pre>p :: c -&gt; a
 q :: c -&gt; b</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg"><img data-attachment-id="3767" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productpattern/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg" data-orig-size="417,276" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductPattern" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=417" class="aligncenter wp-image-3767 size-thumbnail" src="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=150&amp;h=99" alt="ProductPattern" width="150" height="99" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=150&amp;h=99 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=300&amp;h=198 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>All <em>c</em>s that fit this pattern will be considered candidates for the product. There may be lots of them.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg"><img data-attachment-id="3770" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productcandidates/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg" data-orig-size="640,323" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductCandidates" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg?w=510" class="aligncenter size-thumbnail wp-image-3770" src="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg?w=150&amp;h=76" alt="ProductCandidates" width="150" height="76" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg?w=150&amp;h=76 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productcandidates.jpg?w=300&amp;h=152 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>For instance, let’s pick, as our constituents, two Haskell types, <code>Int</code> and <code>Bool</code>, and get a sampling of candidates for their product.</p><p>Here’s one: <code>Int</code>. Can <code>Int</code> be considered a candidate for the product of <code>Int</code> and <code>Bool</code>? Yes, it can — and here are its projections:</p><pre>p :: Int -&gt; Int
 p x = x

 q :: Int -&gt; Bool
 q _ = True</pre><p>That’s pretty lame, but it matches the criteria.</p><p>Here’s another one: <code>(Int, Int, Bool)</code>. It’s a tuple of three elements, or a triple. Here are two morphisms that make it a legitimate candidate (we are using pattern matching on triples):</p><pre>p :: (Int, Int, Bool) -&gt; Int
 p (x, _, _) = x

 q :: (Int, Int, Bool) -&gt; Bool
 q (_, _, b) = b</pre><p>You may have noticed that while our first candidate was too small — it only covered the <code>Int</code> dimension of the product; the second was too big — it spuriously duplicated the <code>Int</code> dimension.</p><p>But we haven’t explored yet the other part of the universal construction: the ranking. We want to be able to compare two instances of our pattern. We want to compare one candidate object <em>c</em> and its two projections <em>p</em> and <em>q</em> with another candidate object <em>c’</em> and its two projections <em>p’</em> and <em>q’</em>. We would like to say that <em>c</em> is “better” than <em>c’</em> if there is a morphism <em>m</em> from <em>c’</em> to <em>c</em> — but that’s too weak. We also want its projections to be “better,” or “more universal,” than the projections of <em>c’</em>. What it means is that the projections <em>p’</em> and <em>q’</em> can be reconstructed from <em>p</em> and <em>q</em> using <em>m</em>:</p><pre>p’ = p . m
 q’ = q . m</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg"><img data-attachment-id="3772" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg" data-orig-size="541,440" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=510" class="aligncenter size-thumbnail wp-image-3772" src="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=150&amp;h=122" alt="ProductRanking" width="150" height="122" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=150&amp;h=122 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>Another way of looking at these equation is that <em>m</em> <em>factorizes</em> <em>p’</em> and <em>q’</em>. Just pretend that these equations are in natural numbers, and the dot is multiplication: <em>m</em> is a common factor shared by <em>p’</em> and <em>q’</em>.</p><p>Just to build some intuitions, let me show you that the pair <code>(Int, Bool)</code> with the two canonical projections, <code>fst</code> and <code>snd</code> is indeed <em>better</em> than the two candidates I presented before.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/not-a-product.jpg"><img data-attachment-id="4863" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/not-a-product/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/not-a-product.jpg" data-orig-size="320,221" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1437595644&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Not a product" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/not-a-product.jpg?w=212&amp;h=150" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/not-a-product.jpg?w=320" class="aligncenter wp-image-4863 " src="https://bartoszmilewski.files.wordpress.com/2015/01/not-a-product.jpg?w=212&amp;h=150" alt="Not a product" width="212" height="150"></a></p><p>The mapping <code>m</code> for the first candidate is:</p><pre>m :: Int -&gt; (Int, Bool)
 m x = (x, True)</pre><p>Indeed, the two projections, <code>p</code> and <code>q</code> can be reconstructed as:</p><pre>p x = fst (m x) = x
 q x = snd (m x) = True</pre><p>The <code>m</code> for the second example is similarly uniquely determined:</p><pre>m (x, _, b) = (x, b)</pre><p>We were able to show that <code>(Int, Bool)</code> is better than either of the two candidates. Let’s see why the opposite is not true. Could we find some <code>m'</code> that would help us reconstruct <code>fst</code> and <code>snd</code> from <code>p</code> and <code>q</code>?</p><pre>fst = p . m’
 snd = q . m’</pre><p>In our first example, <code>q</code> always returned <code>True</code> and we know that there are pairs whose second component is <code>False</code>. We can’t reconstruct <code>snd</code> from <code>q</code>.</p><p>The second example is different: we retain enough information after running either <code>p</code> or <code>q</code>, but there is more than one way to factorize <code>fst</code> and <code>snd</code>. Because both <code>p</code> and <code>q</code> ignore the second component of the triple, our <code>m’</code> can put anything in it. We can have:</p><pre>m’ (x, b) = (x, x, b)</pre><p>or</p><pre>m’ (x, b) = (x, 42, b)</pre><p>and so on.</p><p>Putting it all together, given any type <code>c</code> with two projections <code>p</code> and <code>q</code>, there is a unique <code>m</code> from <code>c</code> to the cartesian product <code>(a, b)</code> that factorizes them. In fact, it just combines <code>p</code> and <code>q</code> into a pair.</p><pre>m :: c -&gt; (a, b)
 m x = (p x, q x)</pre><p>That makes the cartesian product <code>(a, b)</code> our best match, which means that this universal construction works in the category of sets. It picks the product of any two sets.</p><p>Now let’s forget about sets and define a product of two objects in any category using the same universal construction. Such product doesn’t always exist, but when it does, it is unique up to a unique isomorphism.</p><p class="box2">A <strong>product</strong> of two objects <em>a</em> and <em>b</em> is the object <em>c</em> equipped with two projections such that for any other object <em>c’</em> equipped with two projections there is a unique morphism <em>m</em> from <em>c’</em> to <em>c</em> that factorizes those projections.</p><p>A (higher order) function that produces the factorizing function <code>m</code> from two candidates is sometimes called the <em>factorizer</em>. In our case, it would be the function:</p><pre>factorizer :: (c -&gt; a) -&gt; (c -&gt; b) -&gt; (c -&gt; (a, b))
 factorizer p q = \x -&gt; (p x, q x)</pre><h2>Coproduct</h2><p>Like every construction in category theory, the product has a dual, which is called the coproduct. When we reverse the arrows in the product pattern, we end up with an object <em>c</em> equipped with two <em>injections</em>, <code>i</code> and <code>j</code>: morphisms from <em>a</em> and <em>b</em> to <em>c</em>.</p><pre>i :: a -&gt; c
 j :: b -&gt; c</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg"><img data-attachment-id="3774" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/coproductpattern/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg" data-orig-size="616,385" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437206&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;100&quot;,&quot;shutter_speed&quot;:&quot;0.0083333333333333&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="CoproductPattern" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg?w=510" class="aligncenter size-thumbnail wp-image-3774" src="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg?w=150&amp;h=94" alt="CoproductPattern" width="150" height="94" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg?w=150&amp;h=94 150w, https://bartoszmilewski.files.wordpress.com/2014/12/coproductpattern.jpg?w=300&amp;h=188 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>The ranking is also inverted: object <em>c</em> is “better” than object <em>c’</em> that is equipped with the injections <em>i’</em> and <em>j’</em> if there is a morphism <em>m</em> from <em>c</em> to <em>c’</em> that factorizes the injections:</p><pre>i' = m . i
 j' = m . j</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg"><img data-attachment-id="3775" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/coproductranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg" data-orig-size="575,479" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="CoproductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=510" class="aligncenter size-thumbnail wp-image-3775" src="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=150&amp;h=125" alt="CoproductRanking" width="150" height="125" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=150&amp;h=125 150w, https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=300&amp;h=250 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>The “best” such object, one with a unique morphism connecting it to any other pattern, is called a coproduct and, if it exists, is unique up to unique isomorphism.</p><p class="box2">A <strong>coproduct</strong> of two objects <em>a</em> and <em>b</em> is the object <em>c</em> equipped with two injections such that for any other object <em>c’</em> equipped with two injections there is a unique morphism <em>m</em> from <em>c</em> to <em>c’</em> that factorizes those injections.</p><p>In the category of sets, the coproduct is the <em>disjoint union</em> of two sets. An element of the disjoint union of <em>a</em> and <em>b</em> is either an element of <em>a</em> or an element of <em>b</em>. If the two sets overlap, the disjoint union contains two copies of the common part. You can think of an element of a disjoint union as being tagged with an identifier that specifies its origin.</p><p>For a programmer, it’s easier to understand a coproduct in terms of types: it’s a tagged union of two types. C++ supports unions, but they are not tagged. It means that in your program you have to somehow keep track which member of the union is valid. To create a tagged union, you have to define a tag — an enumeration — and combine it with the union. For instance, a tagged union of an <code>int</code> and a <code>char const *</code> could be implemented as:</p><pre>struct Contact {
    enum { isPhone, isEmail } tag;
    union { int phoneNum; char const * emailAddr; };
 };</pre><p>The two injections can either be implemented as constructors or as functions. For instance, here’s the first injection as a function <code>PhoneNum</code>:</p><pre>Contact PhoneNum(int n) {
    Contact c;
    c.tag = isPhone;
    c.phoneNum = n;
    return c;
 }</pre><p>It injects an integer into <code>Contact</code>.</p><p>A tagged union is also called a <em>variant</em>, and there is a very general implementation of a variant in the boost library, <code>boost::variant</code>.</p><p>In Haskell, you can combine any data types into a tagged union by separating data constructors with a vertical bar. The <code>Contact</code> example translates into the declaration:</p><pre>data Contact = PhoneNum Int | EmailAddr String</pre><p>Here, <code>PhoneNum</code> and <code>EmailAddr</code> serve both as constructors (injections), and as tags for pattern matching (more about this later). For instance, this is how you would construct a contact using a phone number:</p><pre>helpdesk :: Contact;
 helpdesk = PhoneNum 2222222</pre><p>Unlike the canonical implementation of the product that is built into Haskell as the primitive pair, the canonical implementation of the coproduct is a data type called <code>Either</code>, which is defined in the standard Prelude as:</p><pre>Either a b = Left a | Right b</pre><p>It is parameterized by two types, <code>a</code> and <code>b</code> and has two constructors: <code>Left</code> that takes a value of type <code>a</code>, and <code>Right</code> that takes a value of type <code>b</code>.</p><p>Just as we’ve defined the factorizer for a product, we can define one for the coproduct. Given a candidate type <code>c</code> and two candidate injections <code>i</code> and <code>j</code>, the factorizer for <code>Either</code> produces the factoring function:</p><pre>factorizer :: (a -&gt; c) -&gt; (b -&gt; c) -&gt; Either a b -&gt; c
 factorizer i j (Left a)  = i a
 factorizer i j (Right b) = j b</pre><h2>Asymmetry</h2><p>We’ve seen two set of dual definitions: The definition of a terminal object can be obtained from the definition of the initial object by reversing the direction of arrows; in a similar way, the definition of the coproduct can be obtained from that of the product. Yet in the category of sets the initial object is very different from the final object, and coproduct is very different from product. We’ll see later that product behaves like multiplication, with the terminal object playing the role of one; whereas coproduct behaves more like the sum, with the initial object playing the role of zero. In particular, for finite sets, the size of the product is the product of the sizes of individual sets, and the size of the coproduct is the sum of the sizes.</p><p>This shows that the category of sets is not symmetric with respect to the inversion of arrows.</p><p>Notice that while the empty set has a unique morphism to any set (the <code>absurd</code> function), it has no morphisms coming back. The singleton set has a unique morphism coming to it from any set, but it <em>also</em> has outgoing morphisms to every set (except for the empty one). As we’ve seen before, these outgoing morphisms from the terminal object play a very important role of picking elements of other sets (the empty set has no elements, so there’s nothing to pick).</p><p>It’s the relationship of the singleton set to the product that sets it apart from the coproduct. Consider using the singleton set, represented by the unit type <code>()</code>, as yet another — vastly inferior — candidate for the product pattern. Equip it with two projections <code>p</code> and <code>q</code>: functions from the singleton to each of the constituent sets. Each selects a concrete element from either set. Because the product is universal, there is also a (unique) morphism <code>m</code> from our candidate, the singleton, to the product. This morphism selects an element from the product set — it selects a concrete pair. It also factorizes the two projections:</p><pre>p = fst . m
 q = snd . m</pre><p>When acting on the singleton value <code>()</code>, the only element of the singleton set, these two equations become:</p><pre>p () = fst (m ())
 q () = snd (m ())</pre><p>Since <code>m ()</code> is the element of the product picked by <code>m</code>, these equations tell use that the element picked by <code>p</code> from the first set, <code>p ()</code>, is the first component of the pair picked by <code>m</code>. Similarly, <code>q ()</code> is equal to the second component. This is in total agreement with our understanding that elements of the product are pairs of elements from the constituent sets.</p><p>There is no such simple interpretation of the coproduct. We could try the singleton set as a candidate for a coproduct, in an attempt to extract the elements from it, but there we would have two injections going into it rather than two projections coming out of it. They’d tell us nothing about their sources (in fact, we’ve seen that they ignore the input parameter). Neither would the unique morphism from the coproduct to our singleton. The category of sets just looks very different when seen from the direction of the initial object than it does when seen from the terminal end.</p><p>This is not an intrinsic property of sets, it’s a property of functions, which we use as morphisms in <b>Set</b>. Functions are, in general, asymmetric. Let me explain.</p><p>A function must be defined for every element of its domain set (in programming, we call it a <em>total</em> function), but it doesn’t have to cover the whole codomain. We’ve seen some extreme cases of it: functions from a singleton set — functions that select just a single element in the codomain. (Actually, functions from an empty set are the real extremes.) When the size of the domain is much smaller than the size of the codomain, we often think of such functions as embedding the domain in the codomain. For instance, we can think of a function from a singleton set as embedding its single element in the codomain. I call them <em>embedding</em> functions, but mathematicians prefer to give a name to the opposite: functions that tightly fill their codomains are called <em>surjective</em> or <em>onto</em>.</p><p>The other source of asymmetry is that functions are allowed to map many elements of the domain set into one element of the codomain. They can collapse them. The extreme case are functions that map whole sets into a singleton. You’ve seen the polymorphic <code>unit</code> function that does just that. The collapsing can only be compounded by composition. A composition of two collapsing functions is even more collapsing than the individual functions. Mathematicians have a name for non-collapsing functions: they call them <em>injective</em> or <em>one-to-one</em></p><p>Of course there are some functions that are neither embedding nor collapsing. They are called <em>bijections</em> and they are truly symmetric, because they are invertible. In the category of sets, an isomorphism is the same as a bijection.</p><h2>Challenges</h2><ol>
 <li>Show that the terminal object is unique up to unique isomorphism.</li>
 <li>What is a product of two objects in a poset? Hint: Use the universal construction.</li>
 <li>What is a coproduct of two objects in a poset?</li>
 <li>Implement the equivalent of Haskell <code>Either</code> as a generic type in your favorite language (other than Haskell).</li>
 <li>Show that <code>Either</code> is a “better” coproduct than <code>int</code> equipped with two injections:
 <pre>int i(int n) { return n; }
 int j(bool b) { return b? 0: 1; }</pre>
 <p>Hint: Define a function</p>
 <pre>int m(Either const &amp; e);</pre>
 <p>that factorizes <code>i</code> and <code>j</code>.</p></li>
 <li>Continuing the previous problem: How would you argue that <code>int</code> with the two injections <code>i</code> and <code>j</code> cannot be “better” than <code>Either</code>?</li>
 <li>Still continuing: What about these injections?
 <pre>int i(int n) {
    if (n &lt; 0) return n;
    return n + 2;
 }
 int j(bool b) { return b? 0: 1; }</pre>
 </li>
 <li>Come up with an inferior candidate for a coproduct of <code>int</code> and <code>bool</code> that cannot be better than <code>Either</code> because it allows multiple acceptable morphisms from it to <code>Either</code>.</li>
 </ol><p>Next: <a title="Simple Algebraic Data Types" href="https://bartoszmilewski.com/2015/01/13/simple-algebraic-data-types/">Simple Algebraic Data Types</a>.</p><h2>Bibliography</h2><ol>
 <li>The Catsters, <a href="https://www.youtube.com/watch?v=upCSDIO9pjc" target="_blank">Products and Coproducts</a> video.</li>
 </ol><h2>Acknowledments</h2><p>I’m grateful to Gershom Bazerman for reviewing this post before publication and for stimulating discussions.</p>

 <h2 class="post-title">
 			Simple Algebraic Data&nbsp;Types		</h2><p>We’ve seen two basic ways of combining types: using a product and a coproduct. It turns out that a lot of data structures in everyday programming can be built using just these two mechanisms. This fact has important practical consequences. Many properties of data structures are composable. For instance, if you know how to compare values of basic types for equality, and you know how to generalize these comparisons to product and coproduct types, you can automate the derivation of equality operators for composite types. In Haskell you can automatically derive equality, comparison, conversion to and from string, and more, for a large subset of composite types.</p><p>Let’s have a closer look at product and sum types as they appear in programming.</p><h2>Product Types</h2><p>The canonical implementation of a product of two types in a programming language is a pair. In Haskell, a pair is a primitive type constructor; in C++ it’s a relatively complex template defined in the Standard Library. </p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg"><img data-attachment-id="3942" data-permalink="https://bartoszmilewski.com/2015/01/13/simple-algebraic-data-types/pair/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg" data-orig-size="409,278" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1421165754&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Pair" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg?w=409" src="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg?w=150&amp;h=102" alt="Pair" width="150" height="102" class="aligncenter size-thumbnail wp-image-3942" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg?w=150&amp;h=102 150w, https://bartoszmilewski.files.wordpress.com/2015/01/pair.jpg?w=300&amp;h=204 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>Pairs are not strictly commutative: a pair <code>(Int, Bool)</code> cannot be substituted for a pair <code>(Bool, Int)</code>, even though they carry the same information. They are, however, commutative up to isomorphism — the isomorphism being given by the <code>swap</code> function (which is its own inverse):</p><pre>swap :: (a, b) -&gt; (b, a)
 swap (x, y) = (y, x)</pre><p>You can think of the two pairs as simply using a different format for storing the same data. It’s just like big endian vs. little endian. </p><p>You can combine an arbitrary number of types into a product by nesting pairs inside pairs, but there is an easier way: nested pairs are equivalent to tuples. It’s the consequence of the fact that different ways of nesting pairs are isomorphic. If you want to combine three types in a product, <code>a</code>, <code>b</code>, and <code>c</code>, in this order, you can do it in two ways:</p><pre>((a, b), c)</pre><p>or</p><pre>(a, (b, c))</pre><p>These types are different — you can’t pass one to a function that expects the other — but their elements are in one-to-one correspondence. There is a function that maps one to another:</p><pre>alpha :: ((a, b), c) -&gt; (a, (b, c))
 alpha ((x, y), z) = (x, (y, z))</pre><p>and this function is invertible:</p><pre>alpha_inv :: (a, (b, c)) -&gt; ((a, b), c)
 alpha_inv  (x, (y, z)) = ((x, y), z)</pre><p>so it’s an isomorphism. These are just different ways of repackaging the same data.</p><p>You can interpret the creation of a product type as a binary operation on types. From that perspective, the above isomorphism looks very much like the associativity law we’ve seen in monoids: </p><pre>(a * b) * c = a * (b * c)</pre><p>Except that, in the monoid case, the two ways of composing products were equal, whereas here they are only equal “up to isomorphism.” </p><p>If we can live with isomorphisms, and don’t insist on strict equality, we can go even further and show that the unit type, <code>()</code>, is the unit of the product the same way 1 is the unit of multiplication. Indeed, the pairing of a value of some type <code>a</code> with a unit doesn’t add any information.  The type:</p><pre>(a, ())</pre><p>is isomorphic to <code>a</code>. Here’s the isomorphism:</p><pre>rho :: (a, ()) -&gt; a
 rho (x, ()) = x</pre><pre>rho_inv :: a -&gt; (a, ())
 rho_inv x = (x, ())</pre><p>These observations can be formalized by saying that <b>Set</b> (the category of sets) is a <em>monoidal category</em>. It’s a category that’s also a monoid, in the sense that you can multiply objects (here, take their cartesian product). I’ll talk more about monoidal categories, and give the full definition in the future.</p><p>There is a more general way of defining product types in Haskell — especially, as we’ll see soon, when they are combined with sum types. It uses named constructors with multiple arguments. A pair, for instance, can be defined alternatively as:</p><pre>data Pair a b = P a b</pre><p>Here, <code>Pair a b</code> is the name of the type paremeterized by two other types, <code>a</code> and <code>b</code>; and <code>P</code> is the name of the data constructor. You define a pair type by passing two types to the <code>Pair</code> type constructor. You construct a pair value by passing two values of appropriate types to the constructor <code>P</code>. For instance, let’s define a value <code>stmt</code> as a pair of <code>String</code> and <code>Bool</code>:</p><pre>stmt :: Pair String Bool
 stmt = P "This statements is" False</pre><p>The first line is the type declaration. It uses the type constructor <code>Pair</code>, with <code>String</code> and <code>Bool</code> replacing <code>a</code> and the <code>b</code> in the generic definition of <code>Pair</code>. The second line defines the actual value by passing a concrete string and a concrete Boolean to the data constructor <code>P</code>. Type constructors are used to construct types; data constructors, to construct values.</p><p>Since the name spaces for type and data constructors are separate in Haskell, you will often see the same name used for both, as in:</p><pre>data Pair a b = Pair a b</pre><p>And if you squint hard enough, you may even view the built-in pair type as a variation on this kind of declaration, where the name <code>Pair</code> is replaced with the binary operator <code>(,)</code>. In fact you can use <code>(,)</code> just like any other named constructor and create pairs using prefix notation:</p><pre>stmt = (,) "This statement is" False</pre><p>Similarly, you can use <code>(,,)</code> to create triples, and so on.</p><p>Instead of using generic pairs or tuples, you can also define specific named product types, as in:</p><pre>data Stmt = Stmt String Bool</pre><p>which is just a product of <code>String</code> and <code>Bool</code>, but it’s given its own name and constructor. The advantage of this style of declaration is that you may define many types that have the same content but different meaning and functionality, and which cannot be substituted for each other. </p><p>Programming with tuples and multi-argument constructors can get messy and error prone — keeping track of which component represents what. It’s often preferable to give names to components. A product type with named fields is called a record in Haskell, and a <code>struct</code> in C. </p><h3>Records</h3><p>Let’s have a look at a simple example. We want to describe chemical elements by combining two strings, name and symbol; and an integer, the atomic number; into one data structure. We can use a tuple <code>(String, String, Int)</code> and remember which component represents what. We would extract components by pattern matching, as in this function that checks if the symbol of the element is the prefix of its name (as in <strong>He</strong> being the prefix of <strong>Helium</strong>):</p><pre>startsWithSymbol :: (String, String, Int) -&gt; Bool
 startsWithSymbol (name, symbol, _) = isPrefixOf symbol name</pre><p>This code is error prone, and is hard to read and maintain. It’s much better to define a record:</p><pre>data Element = Element { name         :: String
                       , symbol       :: String
                       , atomicNumber :: Int }</pre><p>The two representations are isomorphic, as witnessed by these two conversion functions, which are the inverse of each other:</p><pre>tupleToElem :: (String, String, Int) -&gt; Element
 tupleToElem (n, s, a) = Element { name = n
                                , symbol = s
                                , atomicNumber = a }</pre><pre>elemToTuple :: Element -&gt; (String, String, Int)
 elemToTuple e = (name e, symbol e, atomicNumber e)</pre><p>Notice that the names of record fields also serve as functions to access these fields. For instance, <code>atomicNumber e</code> retrieves the <code>atomicNumber</code> field from <code>e</code>. We use <code>atomicNumber</code> as a function of the type:</p><pre>atomicNumber :: Element -&gt; Int</pre><p>With the record syntax for <code>Element</code>, our function <code>startsWithSymbol</code> becomes more readable:</p><pre>startsWithSymbol :: Element -&gt; Bool
 startsWithSymbol e = isPrefixOf (symbol e) (name e)</pre><p>We could even use the Haskell trick of turning the function <code>isPrefixOf</code> into an infix operator by surrounding it with backquotes, and make it read almost like a sentence:</p><pre>startsWithSymbol e = symbol e `isPrefixOf` name e</pre><p>The parentheses could be omitted in this case, because an infix operator has lower precedence than a function call.</p><h2>Sum Types</h2><p>Just as the product in the category of sets gives rise to product types, the coproduct gives rise to sum types. The canonical implementation of a sum type in Haskell is:</p><pre>data Either a b = Left a | Right b</pre><p>And like pairs, <code>Either</code>s are commutative (up to isomorphism), can be nested, and the nesting order is irrelevant (up to isomorphism). So we can, for instance, define a sum equivalent of a triple:</p><pre>data OneOfThree a b c = Sinistral a | Medial b | Dextral c</pre><p>and so on.</p><p>It turns out that <b>Set</b> is also a (symmetric) monoidal category with respect to coproduct. The role of the binary operation is played by the disjoint sum, and the role of the unit element is played by the initial object. In terms of types, we have <code>Either</code> as the monoidal operator and <code>Void</code>, the uninhabited type, as its neutral element. You can think of <code>Either</code> as plus, and <code>Void</code> as zero. Indeed, adding <code>Void</code> to a sum type doesn’t change its content. For instance:</p><pre>Either a Void</pre><p>is isomorphic to <code>a</code>. That’s because there is no way to construct a <code>Right</code> version of this type — there isn’t a value of type <code>Void</code>. The only inhabitants of <code>Either a Void</code> are constructed using the <code>Left</code> constructors and they simply encapsulate a value of type <code>a</code>. So, symbolically, <code>a + 0 = a</code>.</p><p>Sum types are pretty common in Haskell, but their C++ equivalents, unions or variants, are much less common. There are several reasons for that.</p><p>First of all, the simplest sum types are just enumerations and are implemented using <code>enum</code> in C++. The equivalent of the Haskell sum type:</p><pre>data Color = Red | Green | Blue</pre><p>is the C++:</p><pre>enum { Red, Green, Blue };</pre><p>An even simpler sum type:</p><pre>data Bool = True | False</pre><p>is the primitive <code>bool</code> in C++.</p><p>Simple sum types that encode the presence or absence of a value are variously implemented in C++ using special tricks and “impossible” values, like empty strings, negative numbers, null pointers, etc. This kind of optionality, if deliberate, is expressed in Haskell using the <code>Maybe</code> type:</p><pre>data Maybe a = Nothing | Just a</pre><p>The <code>Maybe</code> type is a sum of two types. You can see this if you separate the two constructors into individual types. The first one would look like this:</p><pre>data NothingType = Nothing</pre><p>It’s an enumeration with one value called <code>Nothing</code>. In other words, it’s a singleton, which is equivalent to the unit type <code>()</code>. The second part:</p><pre>data JustType a = Just a</pre><p>is just an encapsulation of the type <code>a</code>. We could have encoded <code>Maybe</code> as:</p><pre>data Maybe a = Either () a</pre><p>More complex sum types are often faked in C++ using pointers. A pointer can be either null, or point to a value of specific type. For instance, a Haskell list type, which can be defined as a (recursive) sum type:</p><pre>List a = Nil | Cons a (List a)</pre><p>can be translated to C++ using the null pointer trick to implement the empty list:</p><pre>template&lt;class A&gt;
 class List {
    Node&lt;A&gt; * _head;
 public:
    List() : _head(nullptr) {}  // Nil
    List(A a, List&lt;A&gt; l)        // Cons
      : _head(new Node&lt;A&gt;(a, l))
    {}
 };</pre><p>Notice that the two Haskell constructors <code>Nil</code> and <code>Cons</code> are translated into two overloaded <code>List</code> constructors with analogous arguments (none, for <code>Nil</code>; and a value and a list for <code>Cons</code>). The <code>List</code> class doesn’t need a tag to distinguish between the two components of the sum type. Instead it uses the special <code>nullptr</code> value for <code>_head</code> to encode <code>Nil</code>.</p><p>The main difference, though, between Haskell and C++ types is that Haskell data structures are immutable. If you create an object using one particular constructor, the object will forever remember which constructor was used and what arguments were passed to it. So a <code>Maybe</code> object that was created as <code>Just "energy"</code> will never turn into <code>Nothing</code>. Similarly, an empty list will forever be empty, and a list of three elements will always have the same three elements. </p><p>It’s this immutability that makes construction reversible. Given an object, you can always disassemble it down to parts that were used in its construction. This deconstruction is done with pattern matching and it reuses constructors as patterns. Constructor arguments, if any, are replaced with variables (or other patterns). </p><p>The <code>List</code> data type has two constructors, so the deconstruction of an arbitrary <code>List</code> uses two patterns corresponding to those constructors. One matches the empty <code>Nil</code> list, and the other a <code>Cons</code>-constructed list. For instance, here’s the definition of a simple function on <code>List</code>s:</p><pre>maybeTail :: List a -&gt; Maybe (List a)
 maybeTail Nil = Nothing
 maybeTail (Cons _ t) = Just t</pre><p>The first part of the definition of <code>maybeTail</code> uses the <code>Nil</code> constructor as pattern and returns <code>Nothing</code>. The second part uses the <code>Cons</code> constructor as pattern. It replaces the first constructor argument with a wildcard, because we are not interested in it. The second argument to <code>Cons</code> is bound to the variable <code>t</code> (I will call these things variables even though, strictly speaking, they never vary: once bound to an expression, a variable never changes). The return value is <code>Just t</code>. Now, depending on how your <code>List</code> was created, it will match one of the clauses. If it was created using <code>Cons</code>, the two arguments that were passed to it will be retrieved (and the first discarded). </p><p>Even more elaborate sum types are implemented in C++ using polymorphic class hierarchies. A family of classes with a common ancestor may be understood as one variant type, in which the vtable serves as a hidden tag. What in Haskell would be done by pattern matching on the constructor, and by calling specialized code, in C++ is accomplished by dispatching a call to a virtual function based on the vtable pointer.</p><p>You will rarely see <code>union</code> used as a sum type in C++ because of severe limitations on what can go into a union. You can’t even put a <code>std::string</code> into a union because it has a copy constructor. </p><h2>Algebra of Types</h2><p>Taken separately, product and sum types can be used to define a variety of useful data structures, but the real strength comes from combining the two. Once again we are invoking the power of composition. </p><p>Let’s summarize what we’ve discovered so far. We’ve seen two commutative monoidal structures underlying the type system: We have the sum types with <code>Void</code> as the neutral element, and the product types with the unit type, <code>()</code>, as the neutral element. We’d like to think of them as analogous to addition and multiplication. In this analogy, <code>Void</code> would correspond to zero, and unit, <code>()</code>, to one. </p><p>Let’s see how far we can stretch this analogy. For instance, does multiplication by zero give zero? In other words, is a product type with one component being <code>Void</code> isomorphic to <code>Void</code>? For example, is it possible to create a pair of, say <code>Int</code> and <code>Void</code>? </p><p>To create a pair you need two values. Although you can easily come up with an integer, there is no value of type <code>Void</code>. Therefore, for any type <code>a</code>, the type <code>(a, Void)</code> is uninhabited — has no values — and is therefore equivalent to <code>Void</code>. In other words, <code>a*0 = 0</code>.</p><p>Another thing that links addition and multiplication is the distributive property:</p><pre>a * (b + c) = a * b + a * c</pre><p>Does it also hold for product and sum types? Yes, it does — up to isomorphisms, as usual. The left hand side corresponds to the type:</p><pre>(a, Either b c)</pre><p>and the right hand side corresponds to the type:</p><pre>Either (a, b) (a, c)</pre><p>Here’s the function that converts them one way:</p><pre>prodToSum :: (a, Either b c) -&gt; Either (a, b) (a, c)
 prodToSum (x, e) =
    case e of
      Left  y -&gt; Left  (x, y)
      Right z -&gt; Right (x, z)</pre><p>and here’s one that goes the other way:</p><pre>sumToProd :: Either (a, b) (a, c) -&gt; (a, Either b c)
 sumToProd e =
    case e of
      Left  (x, y) -&gt; (x, Left  y)
      Right (x, z) -&gt; (x, Right z)</pre><p>The <code>case of</code> statement is used for pattern matching inside functions. Each pattern is followed by an arrow and the expression to be evaluated when the pattern matches. For instance, if you call <code>prodToSum</code> with the value:</p><pre>prod1 :: (Int, Either String Float)
 prod1 = (2, Left "Hi!")</pre><p>the <code>e</code> in <code>case e of</code> will be equal to <code>Left "Hi!"</code>. It will match the pattern <code>Left  y</code>, substituting <code>"Hi!"</code> for <code>y</code>. Since the <code>x</code> has already been matched to <code>2</code>, the result of the <code>case of</code> clause, and the whole function, will be <code>Left (2, "Hi!")</code>, as expected.</p><p>I’m not going to prove that these two functions are the inverse of each other, but if you think about it, they must be! They are just trivially re-packing the contents of the two data structures. It’s the same data, only different format.</p><p>Mathematicians have a name for such two intertwined monoids: it’s called a <em>semiring</em>. It’s not a full <em>ring</em>, because we can’t define subtraction of types. That’s why a semiring is sometimes called a <em>rig</em>, which is a pun on “ring without an <em>n</em>” (negative). But barring that, we can get a lot of mileage from translating statements about, say, natural numbers, which form a ring, to statements about types. Here’s a translation table with some entries of interest:</p><p>The list type is quite interesting, because it’s defined as a solution to an equation. The type we are defining appears on both sides of the equation:</p><pre>List a = Nil | Cons a (List a)</pre><p>If we do our usual substitutions, and also replace <code>List a</code> with <code>x</code>, we get the equation:</p><pre>x = 1 + a * x</pre><p>We can’t solve it using traditional algebraic methods because we can’t subtract or divide types. But we can try a series of substitutions, where we keep replacing <code>x</code> on the right hand side with <code>(1 + a*x)</code>, and use the distributive property. This leads to the following series:</p><pre>x = 1 + a*<span class="red">x</span>
 x = 1 + a*(1 + a*<span class="red">x</span>) = 1 + a + a*a*<span class="red">x</span>
 x = 1 + a + a*a*(1 + a*<span class="red">x</span>) = 1 + a + a*a + a*a*a*<span class="red">x</span>
 ...
 x = 1 + a + a*a + a*a*a + a*a*a*a...</pre><p>We end up with an infinite sum of products (tuples), which can be interpreted as: A list is either empty, <code>1</code>; or a singleton, <code>a</code>; or a pair, <code>a*a</code>; or a triple, <code>a*a*a</code>; etc… Well, that’s exactly what a list is — a string of <code>a</code>s! </p><p>There’s much more to lists than that, and we’ll come back to them and other recursive data structures after we learn about functors and fixed points.</p><p>Solving equations with symbolic variables — that’s algebra! It’s what gives these types their name: algebraic data types.</p><p>Finally, I should mention one very important interpretation of the algebra of types. Notice that a product of two types <code>a</code> and <code>b</code> must contain both a value of type <code>a</code> <em>and</em> a value of type <code>b</code>, which means both types must be inhabited. A sum of two types, on the other hand, contains either a value of type <code>a</code> <em>or</em> a value of type <code>b</code>, so it’s enough if one of them is inhabited. Logical <em>and</em> and <em>or</em> also form a semiring, and it too can be mapped into type theory:</p><p>This analogy goes deeper, and is the basis of the Curry-Howard isomorphism between logic and type theory. We’ll come back to it when we talk about function types.</p><h2>Challenges</h2><ol>
 <li>Show the isomorphism between <code>Maybe a</code> and <code>Either () a</code>.</li>
 <li>Here’s a sum type defined in Haskell:
 <pre>data Shape = Circle Float
           | Rect Float Float</pre>
 <p>When we want to define a function like <code>area</code> that acts on a <code>Shape</code>, we do it by pattern matching on the two constructors:</p>
 <pre>area :: Shape -&gt; Float
 area (Circle r) = pi * r * r
 area (Rect d h) = d * h</pre>
 <p>Implement <code>Shape</code> in C++ or Java as an interface and create two classes: <code>Circle</code> and <code>Rect</code>. Implement <code>area</code> as a virtual function.
 </p></li>
 <li>Continuing with the previous example: We can easily add a new function <code>circ</code> that calculates the circumference of a <code>Shape</code>. We can do it without touching the definition of <code>Shape</code>:
 <pre>circ :: Shape -&gt; Float
 circ (Circle r) = 2.0 * pi * r
 circ (Rect d h) = 2.0 * (d + h)</pre>
 <p>Add <code>circ</code> to your C++ or Java implementation. What parts of the original code did you have to touch?</p></li>
 <li>Continuing further: Add a new shape, <code>Square</code>, to <code>Shape</code> and make all the necessary updates. What code did you have to touch in Haskell vs. C++ or Java? (Even if you’re not a Haskell programmer, the modifications should be pretty obvious.)</li>
 <li>Show that <code>a + a = 2 * a</code> holds for types (up to isomorphism). Remember that <code>2</code> corresponds to <code>Bool</code>, according to our translation table.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/01/20/functors/" title="Functors">Functors</a>.</p><h3>Acknowledments</h3><p>Thanks go to Gershom Bazerman for reviewing this post and helpful comments.</p>

 <h2 class="post-title">
 			Functors		</h2><p>At the risk of sounding like a broken record, I will say this about functors: A functor is a very simple but powerful idea. Category theory is just full of those simple but powerful ideas. A functor is a mapping between categories. Given two categories, C and D, a functor F maps objects in C to objects in D — it’s a function on objects. If <em>a</em> is an object in C, we’ll write its image in D as <em>F a</em> (no parentheses). But a category is not just objects — it’s objects and morphisms that connect them. A functor also maps morphisms — it’s a function on morphisms. But it doesn’t map morphisms willy-nilly — it preserves connections. So if a morphism <em>f</em> in C connects object <em>a</em> to object <em>b</em>,</p><pre>f :: a -&gt; b</pre><p>the image of <em>f</em> in D, <em>F f</em>, will connect the image of <em>a</em> to the image of <em>b</em>:</p><pre>F f :: F a -&gt; F b</pre><p>(This is a mixture of mathematical and Haskell notation that hopefully makes sense by now. I won’t use parentheses when applying functors to objects or morphisms.) <a href="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg"><img data-attachment-id="3944" data-permalink="https://bartoszmilewski.com/2015/01/20/functors/functor-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg" data-orig-size="548,481" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1421165754&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Functor" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg?w=300&amp;h=263" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg?w=510" class="aligncenter wp-image-3944 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg?w=300&amp;h=263" alt="Functor" width="300" height="263" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg?w=300&amp;h=263 300w, https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg?w=150&amp;h=132 150w, https://bartoszmilewski.files.wordpress.com/2015/01/functor.jpg 548w" sizes="(max-width: 300px) 100vw, 300px"></a> As you can see, a functor preserves the structure of a category: what’s connected in one category will be connected in the other category. But there’s something more to the structure of a category: there’s also the composition of morphisms. If <em>h</em> is a composition of <em>f</em> and <em>g</em>:</p><pre>h = g . f</pre><p>we want its image under F to be a composition of the images of <em>f</em> and <em>g</em>:</p><pre>F h = F g . F f</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg"><img data-attachment-id="3947" data-permalink="https://bartoszmilewski.com/2015/01/20/functors/functorcompos/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg" data-orig-size="384,417" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1421165754&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FunctorCompos" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg?w=276&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg?w=384" class="aligncenter size-medium wp-image-3947" src="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg?w=276&amp;h=300" alt="FunctorCompos" width="276" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg?w=276&amp;h=300 276w, https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg?w=138&amp;h=150 138w, https://bartoszmilewski.files.wordpress.com/2015/01/functorcompos.jpg 384w" sizes="(max-width: 276px) 100vw, 276px"></a> Finally, we want all identity morphisms in C to be mapped to identity morphisms in D:</p><pre>F id<sub>a</sub> = id<sub>F a</sub></pre><p>Here, <em>id<sub>a</sub></em> is the identity at the object <em>a</em>, and <em>id<sub>F a</sub></em> the identity at <em>F a</em>. <a href="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg"><img data-attachment-id="3949" data-permalink="https://bartoszmilewski.com/2015/01/20/functors/functorid/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg" data-orig-size="302,402" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1421165754&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FunctorId" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg?w=225&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg?w=302" class="aligncenter size-medium wp-image-3949" src="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg?w=225&amp;h=300" alt="FunctorId" width="225" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg?w=225&amp;h=300 225w, https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg?w=113&amp;h=150 113w, https://bartoszmilewski.files.wordpress.com/2015/01/functorid.jpg 302w" sizes="(max-width: 225px) 100vw, 225px"></a> Note that these conditions make functors much more restrictive than regular functions. Functors must preserve the structure of a category. If you picture a category as a collection of objects held together by a network of morphisms, a functor is not allowed to introduce any tears into this fabric. It may smash objects together, it may glue multiple morphisms into one, but it may never break things apart. This no-tearing constraint is similar to the continuity condition you might know from calculus. In this sense functors are “continuous” (although there exists an even more restrictive notion of continuity for functors). Just like functions, functors may do both collapsing and embedding. The embedding aspect is more prominent when the source category is much smaller than the target category. In the extreme, the source can be the trivial singleton category — a category with one object and one morphism (the identity). A functor from the singleton category to any other category simply selects an object in that category. This is fully analogous to the property of morphisms from singleton sets selecting elements in target sets. The maximally collapsing functor is called the constant functor Δ<sub>c</sub>. It maps every object in the source category to one selected object <em>c</em> in the target category. It also maps every morphism in the source category to the identity morphism <em>id<sub>c</sub></em>. It acts like a black hole, compacting everything into one singularity. We’ll see more of this functor when we discuss limits and colimits.</p><h2>Functors in Programming</h2><p>Let’s get down to earth and talk about programming. We have our category of types and functions. We can talk about functors that map this category into itself — such functors are called endofunctors. So what’s an endofunctor in the category of types? First of all, it maps types to types. We’ve seen examples of such mappings, maybe without realizing that they were just that. I’m talking about definitions of types that were parameterized by other types. Let’s see a few examples.</p><h3>The Maybe Functor</h3><p>The definition of <code>Maybe</code> is a mapping from type <code>a</code> to type <code>Maybe a</code>:</p><pre>data Maybe a = Nothing | Just a</pre><p>Here’s an important subtlety: <code>Maybe</code> itself is not a type, it’s a <em>type constructor</em>. You have to give it a type argument, like <code>Int</code> or <code>Bool</code>, in order to turn it into a type. <code>Maybe</code> without any argument represents a function on types. But can we turn <code>Maybe</code> into a functor? (From now on, when I speak of functors in the context of programming, I will almost always mean endofunctors.) A functor is not only a mapping of objects (here, types) but also a mapping of morphisms (here, functions). For any function from <code>a</code> to <code>b</code>:</p><pre>f :: a -&gt; b</pre><p>we would like to produce a function from <code>Maybe a</code> to <code>Maybe b</code>. To define such a function, we’ll have two cases to consider, corresponding to the two constructors of <code>Maybe</code>. The <code>Nothing</code> case is simple: we’ll just return <code>Nothing</code> back. And if the argument is <code>Just</code>, we’ll apply the function <code>f</code> to its contents. So the image of <code>f</code> under <code>Maybe</code> is the function:</p><pre>f’ :: Maybe a -&gt; Maybe b
 f’ Nothing = Nothing
 f’ (Just x) = Just (f x)</pre><p>(By the way, in Haskell you can use apostrophes in variables names, which is very handy in cases like these.) In Haskell, we implement the morphism-mapping part of a functor as a higher order function called <code>fmap</code>. In the case of <code>Maybe</code>, it has the following signature:</p><pre>fmap :: (a -&gt; b) -&gt; (Maybe a -&gt; Maybe b)</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg"><img data-attachment-id="3950" data-permalink="https://bartoszmilewski.com/2015/01/20/functors/functormaybe/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg" data-orig-size="469,342" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1421165754&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FunctorMaybe" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg?w=300&amp;h=219" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg?w=469" class="aligncenter size-medium wp-image-3950" src="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg?w=300&amp;h=219" alt="FunctorMaybe" width="300" height="219" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg?w=300&amp;h=219 300w, https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg?w=150&amp;h=109 150w, https://bartoszmilewski.files.wordpress.com/2015/01/functormaybe.jpg 469w" sizes="(max-width: 300px) 100vw, 300px"></a> We often say that <code>fmap</code> <em>lifts</em> a function. The lifted function acts on <code>Maybe</code> values. As usual, because of currying, this signature may be interpreted in two ways: as a function of one argument — which itself is a function <code>(a-&gt;b)</code> — returning a function <code>(Maybe a -&gt; Maybe b)</code>; or as a function of two arguments returning <code>Maybe b</code>:</p><pre>fmap :: (a -&gt; b) -&gt; Maybe a -&gt; Maybe b</pre><p>Based on our previous discussion, this is how we implement <code>fmap</code> for <code>Maybe</code>:</p><pre>fmap _ Nothing = Nothing
 fmap f (Just x) = Just (f x)</pre><p>To show that the type constructor <code>Maybe</code> together with the function <code>fmap</code> form a functor, we have to prove that <code>fmap</code> preserves identity and composition. These are called “the functor laws,” but they simply ensure the preservation of the structure of the category.</p><h3>Equational Reasoning</h3><p>To prove the functor laws, I will use <em>equational reasoning</em>, which is a common proof technique in Haskell. It takes advantage of the fact that Haskell functions are defined as equalities: the left hand side equals the right hand side. You can always substitute one for another, possibly renaming variables to avoid name conflicts. Think of this as either inlining a function, or the other way around, refactoring an expression into a function. Let’s take the identity function as an example:</p><pre>id x = x</pre><p>If you see, for instance, <code>id y</code> in some expression, you can replace it with <code>y</code> (inlining). Further, if you see <code>id</code> applied to an expression, say <code>id (y + 2)</code>, you can replace it with the expression itself <code>(y + 2)</code>. And this substitution works both ways: you can replace any expression <code>e</code> with <code>id e</code> (refactoring). If a function is defined by pattern matching, you can use each sub-definition independently. For instance, given the above definition of <code>fmap</code> you can replace <code>fmap f Nothing</code> with <code>Nothing</code>, or the other way around. Let’s see how this works in practice. Let’s start with the preservation of identity:</p><pre>fmap id = id</pre><p>There are two cases to consider: <code>Nothing</code> and <code>Just</code>. Here’s the first case (I’m using Haskell pseudo-code to transform the left hand side to the right hand side):</p><pre>  fmap id Nothing
 = { definition of fmap }
  Nothing
 = { definition of id }
  id Nothing</pre><p>Notice that in the last step I used the definition of <code>id</code> backwards. I replaced the expression <code>Nothing</code> with <code>id Nothing</code>. In practice, you carry out such proofs by “burning the candle at both ends,” until you hit the same expression in the middle — here it was <code>Nothing</code>. The second case is also easy:</p><pre>  fmap id (Just x)
 = { definition of fmap }
  Just (id x)
 = { definition of id }
  Just x
 = { definition of id }
  id (Just x)</pre><p>Now, lets show that <code>fmap</code> preserves composition:</p><pre>fmap (g . f) = fmap g . fmap f</pre><p>First the <code>Nothing</code> case:</p><pre>  fmap (g . f) Nothing
 = { definition of fmap }
  Nothing
 = { definition of fmap }
  fmap g Nothing
 = { definition of fmap }
  fmap g (fmap f Nothing)</pre><p>And then the <code>Just</code> case:</p><pre>  fmap (g . f) (Just x)
 = { definition of fmap }
  Just ((g . f) x)
 = { definition of composition }
  Just (g (f x))
 = { definition of fmap }
  fmap g (Just (f x))
 = { definition of fmap }
  fmap g (fmap f (Just x))
 = { definition of composition }
  (fmap g . fmap f) (Just x)</pre><p>It’s worth stressing that equational reasoning doesn’t work for C++ style “functions” with side effects. Consider this code:</p><pre>int square(int x) {
    return x * x;
 }

 int counter() {
    static int c = 0;
    return c++;
 }

 double y = square(counter());</pre><p>Using equational reasoning, you would be able to inline <code>square</code> to get:</p><pre>double y = counter() * counter();</pre><p>This is definitely not a valid transformation, and it will not produce the same result. Despite that, the C++ compiler will try to use equational reasoning if you implement <code>square</code> as a macro, with disastrous results.</p><h3>Optional</h3><p>Functors are easily expressed in Haskell, but they can be defined in any language that supports generic programming and higher-order functions. Let’s consider the C++ analog of <code>Maybe</code>, the template type <code>optional</code>. Here’s a sketch of the implementation (the actual implementation is much more complex, dealing with various ways the argument may be passed, with copy semantics, and with the resource management issues characteristic of C++):</p><pre>template&lt;class T&gt;
 class optional {
    bool _isValid; // the tag
    T    _v;
 public:
    optional()    : _isValid(false) {}         // Nothing
    optional(T x) : _isValid(true) , _v(x) {}  // Just
    bool isValid() const { return _isValid; }
    T val() const { return _v; }
 };</pre><p>This template provides one part of the definition of a functor: the mapping of types. It maps any type <code>T</code> to a new type <code>optional&lt;T&gt;</code>. Let’s define its action on functions:</p><pre>template&lt;class A, class B&gt;
 std::function&lt;optional&lt;B&gt;(optional&lt;A&gt;)&gt;
 <span class="red">fmap</span>(std::function&lt;B(A)&gt; f)
 {
    return [f](optional&lt;A&gt; opt) {
        if (!opt.isValid())
            return optional&lt;B&gt;{};
        else
            return optional&lt;B&gt;{ f(<span class="skimlinks-unlinked">opt.val</span>()) };
    };
 }</pre><p>This is a higher order function, taking a function as an argument and returning a function. Here’s the uncurried version of it:</p><pre>template&lt;class A, class B&gt;
 optional&lt;B&gt; <span class="red">fmap</span>(std::function&lt;B(A)&gt; f, optional&lt;A&gt; opt) {
    if (!opt.isValid())
        return optional&lt;B&gt;{};
    else
        return optional&lt;B&gt;{ f(<span class="skimlinks-unlinked">opt.val</span>()) };
 }</pre><p>There is also an option of making <code>fmap</code> a template method of <code>optional</code>. This embarrassment of choices makes abstracting the functor pattern in C++ a problem. Should functor be an interface to inherit from (unfortunately, you can’t have template virtual functions)? Should it be a curried or an uncurried free template function? Can the C++ compiler correctly infer the missing types, or should they be specified explicitly? Consider a situation where the input function <code>f</code> takes an <code>int</code> to a <code>bool</code>. How will the compiler figure out the type of <code>g</code>:</p><pre>auto g = fmap(f);</pre><p>especially if, in the future, there are multiple functors overloading <code>fmap</code>? (We’ll see more functors soon.)</p><h3>Typeclasses</h3><p>So how does Haskell deal with abstracting the functor? It uses the typeclass mechanism. A typeclass defines a family of types that support a common interface. For instance, the class of objects that support equality is defined as follows:</p><pre>class Eq a where
    (==) :: a -&gt; a -&gt; Bool</pre><p>This definition states that type <code>a</code> is of the class <code>Eq</code> if it supports the operator <code>(==)</code> that takes two arguments of type <code>a</code> and returns a <code>Bool</code>. If you want to tell Haskell that a particular type is <code>Eq</code>, you have to declare it an <em>instance</em> of this class and provide the implementation of <code>(==)</code>. For example, given the definition of a 2D <code>Point</code> (a product type of two <code>Float</code>s):</p><pre>data Point = Pt Float Float</pre><p>you can define the equality of points:</p><pre>instance Eq Point where
    (Pt x y) == (Pt x' y') = x == x' &amp;&amp; y == y'</pre><p>Here I used the operator <code>(==)</code> (the one I’m defining) in the infix position between the two patterns <code>(Pt x y)</code> and <code>(Pt x' y')</code>. The body of the function follows the single equal sign. Once <code>Point</code> is declared an instance of <code>Eq</code>, you can directly compare points for equality. Notice that, unlike in C++ or Java, you don’t have to specify the <code>Eq</code> class (or interface) when defining <code>Point</code> — you can do it later in client code. Typeclasses are also Haskell’s only mechanism for overloading functions (and operators). We will need that for overloading <code>fmap</code> for different functors. There is one complication, though: a functor is not defined as a type but as a mapping of types, a type constructor. We need a typeclass that’s not a family of types, as was the case with <code>Eq</code>, but a family of type constructors. Fortunately a Haskell typeclass works with type constructors as well as with types. So here’s the definition of the <code>Functor</code> class:</p><pre>class Functor f where
    fmap :: (a -&gt; b) -&gt; f a -&gt; f b</pre><p>It stipulates that <code>f</code> is a <code>Functor</code> if there exists a function <code>fmap</code> with the specified type signature. The lowercase <code>f</code> is a type variable, similar to type variables <code>a</code> and <code>b</code>. The compiler, however, is able to deduce that it represents a type constructor rather than a type by looking at its usage: acting on other types, as in <code>f a</code> and <code>f b</code>. Accordingly, when declaring an instance of <code>Functor</code>, you have to give it a type constructor, as is the case with <code>Maybe</code>:</p><pre>instance Functor Maybe where
    fmap _ Nothing = Nothing
    fmap f (Just x) = Just (f x)</pre><p>By the way, the <code>Functor</code> class, as well as its instance definitions for a lot of simple data types, including <code>Maybe</code>, are part of the standard Prelude library.</p><h3>Functor in C++</h3><p>Can we try the same approach in C++? A type constructor corresponds to a template class, like <code>optional</code>, so by analogy, we would parameterize <code>fmap</code> with a <em>template template parameter</em> <code>F</code>. This is the syntax for it:</p><pre>template&lt;<span class="red">template&lt;class&gt; F</span>, class A, class B&gt;
 F&lt;B&gt; fmap(std::function&lt;B(A)&gt;, F&lt;A&gt;);</pre><p>We would like to be able to specialize this template for different functors. Unfortunately, there is a prohibition against partial specialization of template functions in C++. You can’t write:</p><pre>template&lt;class A, class B&gt;
 optional&lt;B&gt; fmap&lt;<span class="red">optional</span>&gt;(std::function&lt;B(A)&gt; f, optional&lt;A&gt; opt)</pre><p>Instead, we have to fall back on function overloading, which brings us back to the original definition of the uncurried <code>fmap</code>:</p><pre>template&lt;class A, class B&gt;
 optional&lt;B&gt; fmap(std::function&lt;B(A)&gt; f, optional&lt;A&gt; opt)
 {
    if (!opt.isValid())
        return optional&lt;B&gt;{};
    else
        return optional&lt;B&gt;{ f(<span class="skimlinks-unlinked">opt.val</span>()) };
 }</pre><p>This definition works, but only because the second argument of <code>fmap</code> selects the overload. It totally ignores the more generic definition of <code>fmap</code>.</p><h3>The List Functor</h3><p>To get some intuition as to the role of functors in programming, we need to look at more examples. Any type that is parameterized by another type is a candidate for a functor. Generic containers are parameterized by the type of the elements they store, so let’s look at a very simple container, the list:</p><pre>data List a = Nil | Cons a (List a)</pre><p>We have the type constructor <code>List</code>, which is a mapping from any type <code>a</code> to the type <code>List a</code>. To show that <code>List</code> is a functor we have to define the lifting of functions: Given a function <code>a-&gt;b</code> define a function <code>List a -&gt; List b</code>:</p><pre>fmap :: (a -&gt; b) -&gt; (List a -&gt; List b)</pre><p>A function acting on <code>List a</code> must consider two cases corresponding to the two list constructors. The <code>Nil</code> case is trivial — just return <code>Nil</code> — there isn’t much you can do with an empty list. The <code>Cons</code> case is a bit tricky, because it involves recursion. So let’s step back for a moment and consider what we are trying to do. We have a list of <code>a</code>, a function <code>f</code> that turns <code>a</code> to <code>b</code>, and we want to generate a list of <code>b</code>. The obvious thing is to use <code>f</code> to turn each element of the list from <code>a</code> to <code>b</code>. How do we do this in practice, given that a (non-empty) list is defined as the <code>Cons</code> of a head and a tail? We apply <code>f</code> to the head and apply the lifted (<code>fmap</code>ped) <code>f</code> to the tail. This is a recursive definition, because we are defining lifted <code>f</code> in terms of lifted <code>f</code>:</p><pre>fmap f (Cons x t) = Cons (f x) (fmap f t)</pre><p>Notice that, on the right hand side, <code>fmap f</code> is applied to a list that’s shorter than the list for which we are defining it — it’s applied to its tail. We recurse towards shorter and shorter lists, so we are bound to eventually reach the empty list, or <code>Nil</code>. But as we’ve decided earlier, <code>fmap f</code> acting on <code>Nil</code> returns <code>Nil</code>, thus terminating the recursion. To get the final result, we combine the new head <code>(f x)</code> with the new tail <code>(fmap f t)</code> using the <code>Cons</code> constructor. Putting it all together, here’s the instance declaration for the list functor:</p><pre>instance Functor List where
    fmap _ Nil = Nil
    fmap f (Cons x t) = Cons (f x) (fmap f t)</pre><p>If you are more comfortable with C++, consider the case of a <code>std::vector</code>, which could be considered the most generic C++ container. The implementation of <code>fmap</code> for <code>std::vector</code> is just a thin encapsulation of <code>std::transform</code>:</p><pre>template&lt;class A, class B&gt;
 std::vector&lt;B&gt; fmap(std::function&lt;B(A)&gt; f, std::vector&lt;A&gt; v)
 {
    std::vector&lt;B&gt; w;
    std::transform( std::begin(v)
                  , std::end(v)
                  , std::back_inserter(w)
                  , f);
    return w;
 }</pre><p>We can use it, for instance, to square the elements of a sequence of numbers:</p><pre>std::vector&lt;int&gt; v{ 1, 2, 3, 4 };
 auto w = fmap([](int i) { return i*i; }, v);
 std::copy( std::begin(w)
         , std::end(w)
         , std::ostream_iterator(std::cout, ", "));</pre><p>Most C++ containers are functors by virtue of implementing iterators that can be passed to <code>std::transform</code>, which is the more primitive cousin of <code>fmap</code>. Unfortunately, the simplicity of a functor is lost under the usual clutter of iterators and temporaries (see the implementation of <code>fmap</code> above). I’m happy to say that the new proposed C++ range library makes the functorial nature of ranges much more pronounced.</p><h3>The Reader Functor</h3><p>Now that you might have developed some intuitions — for instance, functors being some kind of containers — let me show you an example which at first sight looks very different. Consider a mapping of type <code>a</code> to the type of a function returning <code>a</code>. We haven’t really talked about function types in depth — the full categorical treatment is coming — but we have some understanding of those as programmers. In Haskell, a function type is constructed using the arrow type constructor <code>(-&gt;)</code> which takes two types: the argument type and the result type. You’ve already seen it in infix form, <code>a-&gt;b</code>, but it can equally well be used in prefix form, when parenthesized:</p><pre>(-&gt;) a b</pre><p>Just like with regular functions, type functions of more than one argument can be partially applied. So when we provide just one type argument to the arrow, it still expects another one. That’s why:</p><pre>(-&gt;) a</pre><p>is a type constructor. It needs one more type <code>b</code> to produce a complete type <code>a-&gt;b</code>. As it stands, it defines a whole family of type constructors parameterized by <code>a</code>. Let’s see if this is also a family of functors. Dealing with two type parameters can get a bit confusing, so let’s do some renaming. Let’s call the argument type <code>r</code> and the result type <code>a</code>, in line with our previous functor definitions. So our type constructor takes any type <code>a</code> and maps it into the type <code>r-&gt;a</code>. To show that it’s a functor, we want to lift a function <code>a-&gt;b</code> to a function that takes <code>r-&gt;a</code> and returns <code>r-&gt;b</code>. These are the types that are formed using the type constructor <code>(-&gt;) r</code> acting on, respectively, <code>a</code> and <code>b</code>. Here’s the type signature of <code>fmap</code> applied to this case:</p><pre>fmap :: (a -&gt; b) -&gt; (r -&gt; a) -&gt; (r -&gt; b)</pre><p>We have to solve the following puzzle: given a function <code>f::a-&gt;b</code> and a function <code>g::r-&gt;a</code>, create a function <code>r-&gt;b</code>. There is only one way we can compose the two functions, and the result is exactly what we need. So here’s the implementation of our <code>fmap</code>:</p><pre>instance Functor ((-&gt;) r) where
    fmap f g = f . g</pre><p>It just works! If you like terse notation, this definition can be reduced further by noticing that composition can be rewritten in prefix form:</p><pre>fmap f g = (.) f g</pre><p>and the arguments can be omitted to yield a direct equality of two functions:</p><pre>fmap = (.)</pre><p>This combination of the type constructor <code>(-&gt;) r</code> with the above implementation of <code>fmap</code> is called the reader functor.</p><h2>Functors as Containers</h2><p>We’ve seen some examples of functors in programming languages that define general-purpose containers, or at least objects that contain some value of the type they are parameterized over. The reader functor seems to be an outlier, because we don’t think of functions as data. But we’ve seen that pure functions can be memoized, and function execution can be turned into table lookup. Tables are data. Conversely, because of Haskell’s laziness, a traditional container, like a list, may actually be implemented as a function. Consider, for instance, an infinite list of natural numbers, which can be compactly defined as:</p><pre>nats :: [Integer]
 nats = [1..]</pre><p>In the first line, a pair of square brackets is the Haskell’s built-in type constructor for lists. In the second line, square brackets are used to create a list literal. Obviously, an infinite list like this cannot be stored in memory. The compiler implements it as a function that generates <code>Integer</code>s on demand. Haskell effectively blurs the distinction between data and code. A list could be considered a function, and a function could be considered a table that maps arguments to results. The latter can even be practical if the domain of the function is finite and not too large. It would not be practical, however, to implement <code>strlen</code> as table lookup, because there are infinitely many different strings. As programmers, we don’t like infinities, but in category theory you learn to eat infinities for breakfast. Whether it’s a set of all strings or a collection of all possible states of the Universe, past, present, and future — we can deal with it! So I like to think of the functor object (an object of the type generated by an endofunctor) as containing a value or values of the type over which it is parameterized, even if these values are not physically present there. One example of a functor is a C++ <code>std::future</code>, which may at some point contain a value, but it’s not guaranteed it will; and if you want to access it, you may block waiting for another thread to finish execution. Another example is a Haskell <code>IO</code> object, which may contain user input, or the future versions of our Universe with “Hello World!” displayed on the monitor. According to this interpretation, a functor object is something that may contain a value or values of the type it’s parameterized upon. Or it may contain a recipe for generating those values. We are not at all concerned about being able to access the values — that’s totally optional, and outside of the scope of the functor. All we are interested in is to be able to manipulate those values using functions. If the values can be accessed, then we should be able to see the results of this manipulation. If they can’t, then all we care about is that the manipulations compose correctly and that the manipulation with an identity function doesn’t change anything. Just to show you how much we don’t care about being able to access the values inside a functor object, here’s a type constructor that ignores completely its argument <code>a</code>:</p><pre>data Const c a = Const c</pre><p>The <code>Const</code> type constructor takes two types, <code>c</code> and <code>a</code>. Just like we did with the arrow constructor, we are going to partially apply it to create a functor. The data constructor (also called <code>Const</code>) takes just one value of type <code>c</code>. It has no dependence on <code>a</code>. The type of <code>fmap</code> for this type constructor is:</p><pre>fmap :: (a -&gt; b) -&gt; Const c a -&gt; Const c b</pre><p>Because the functor ignores its type argument, the implementation of <code>fmap</code> is free to ignore its function argument — the function has nothing to act upon:</p><pre>instance Functor (Const c) where
    fmap _ (Const v) = Const v</pre><p>This might be a little clearer in C++ (I never thought I would utter those words!), where there is a stronger distinction between type arguments — which are compile-time — and values, which are run-time:</p><pre>template&lt;class C, class A&gt;
 struct Const {
    Const(C v) : _v(v) {}
    C _v;
 };</pre><p>The C++ implementation of <code>fmap</code> also ignores the function argument and essentially re-casts the <code>Const</code> argument without changing its value:</p><pre>template&lt;class C, class A, class B&gt;
 Const&lt;C, B&gt; fmap(std::function&lt;B(A)&gt; f, Const&lt;C, A&gt; c) {
    return Const&lt;C, B&gt;{c._v};
 }</pre><p>Despite its weirdness, the <code>Const</code> functor plays an important role in many constructions. In category theory, it’s a special case of the Δ<sub>c</sub> functor I mentioned earlier — the endo-functor case of a black hole. We’ll be seeing more of it it in the future.</p><h2>Functor Composition</h2><p>It’s not hard to convince yourself that functors between categories compose, just like functions between sets compose. A composition of two functors, when acting on objects, is just the composition of their respective object mappings; and similarly when acting on morphisms. After jumping through two functors, identity morphisms end up as identity morphisms, and compositions of morphisms finish up as compositions of morphisms. There’s really nothing much to it. In particular, it’s easy to compose endofunctors. Remember the function <code>maybeTail</code>? I’ll rewrite it using the Haskell’s built in implementation of lists:</p><pre>maybeTail :: [a] -&gt; Maybe [a]
 maybeTail [] = Nothing
 maybeTail (x:xs) = Just xs</pre><p>(The empty list constructor that we used to call <code>Nil</code> is replaced with the empty pair of square brackets <code>[]</code>. The <code>Cons</code> constructor is replaced with the infix operator <code>:</code> (colon).) The result of <code>maybeTail</code> is of a type that’s a composition of two functors, <code>Maybe</code> and <code>[]</code>, acting on <code>a</code>. Each of these functors is equipped with its own version of <code>fmap</code>, but what if we want to apply some function <code>f</code> to the contents of the composite: a <code>Maybe</code> list? We have to break through two layers of functors. We can use <code>fmap</code> to break through the outer <code>Maybe</code>. But we can’t just send <code>f</code> inside <code>Maybe</code> because <code>f</code> doesn’t work on lists. We have to send <code>(fmap f)</code> to operate on the inner list. For instance, let’s see how we can square the elements of a <code>Maybe</code> list of integers:</p><pre>square x = x * x

 mis :: Maybe [Int]
 mis = Just [1, 2, 3]

 mis2 = fmap (fmap square) mis</pre><p>The compiler, after analyzing the types, will figure out that, for the outer <code>fmap</code>, it should use the implementation from the <code>Maybe</code> instance, and for the inner one, the list functor implementation. It may not be immediately obvious that the above code may be rewritten as:</p><pre>mis2 = (fmap . fmap) square mis</pre><p>But remember that <code>fmap</code> may be considered a function of just one argument:</p><pre>fmap :: (a -&gt; b) -&gt; (f a -&gt; f b)</pre><p>In our case, the second <code>fmap</code> in <code>(fmap . fmap)</code> takes as its argument:</p><pre>square :: Int -&gt; Int</pre><p>and returns a function of the type:</p><pre>[Int] -&gt; [Int]</pre><p>The first <code>fmap</code> then takes that function and returns a function:</p><pre>Maybe [Int] -&gt; Maybe [Int]</pre><p>Finally, that function is applied to <code>mis</code>. So the composition of two functors is a functor whose <code>fmap</code> is the composition of the corresponding <code>fmap</code>s. Going back to category theory: It’s pretty obvious that functor composition is associative (the mapping of objects is associative, and the mapping of morphisms is associative). And there is also a trivial identity functor in every category: it maps every object to itself, and every morphism to itself. So functors have all the same properties as morphisms in some category. But what category would that be? It would have to be a category in which objects are categories and morphisms are functors. It’s a category of categories. But a category of <em>all</em> categories would have to include itself, and we would get into the same kinds of paradoxes that made the set of all sets impossible. There is, however, a category of all <em>small</em> categories called <strong>Cat</strong> (which is big, so it can’t be a member of itself). A small category is one in which objects form a set, as opposed to something larger than a set. Mind you, in category theory, even an infinite uncountable set is considered “small.” I thought I’d mention these things because I find it pretty amazing that we can recognize the same structures repeating themselves at many levels of abstraction. We’ll see later that functors form categories as well.</p><h2>Challenges</h2><ol>
 <li>Can we turn the <code>Maybe</code> type constructor into a functor by defining:
 <pre>fmap _ _ = Nothing</pre>
 <p>which ignores both of its arguments? (Hint: Check the functor laws.)</p></li>
 <li>Prove functor laws for the reader functor. Hint: it’s really simple.</li>
 <li>Implement the reader functor in your second favorite language (the first being Haskell, of course).</li>
 <li>Prove the functor laws for the list functor. Assume that the laws are true for the tail part of the list you’re applying it to (in other words, use <em>induction</em>).</li>
 </ol><h2>Acknowledgments</h2><p>Gershom Bazerman is kind enough to keep reviewing these posts. I’m grateful for his patience and insight. </p><p><em>Next: <a href="https://bartoszmilewski.com/2015/02/03/functoriality/" title="Functoriality">Functoriality</a></em></p>

 <h2 class="post-title">
 			Functoriality		</h2><p>Now that you know what a functor is, and have seen a few examples, let’s see how we can build larger functors from smaller ones. In particular it’s interesting to see which type constructors (which correspond to mappings between objects in a category) can be extended to functors (which include mappings between morphisms).</p><h2>Bifunctors</h2><p>Since functors are morphisms in <em>Cat</em> (the category of categories), a lot of intuitions about morphisms — and functions in particular — apply to functors as well. For instance, just like you can have a function of two arguments, you can have a functor of two arguments, or a <em>bifunctor</em>. On objects, a bifunctor maps every pair of objects, one from category C, and one from category D, to an object in category E. Notice that this is just saying that it’s a mapping from a <em>cartesian product</em> of categories C×D to E.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg"><img data-attachment-id="4068" data-permalink="https://bartoszmilewski.com/2015/02/03/functoriality/bifunctor/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg" data-orig-size="313,298" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1422307639&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Bifunctor" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg?w=300&amp;h=286" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg?w=313" class="aligncenter size-medium wp-image-4068" src="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg?w=300&amp;h=286" alt="Bifunctor" width="300" height="286" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg?w=300&amp;h=286 300w, https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg?w=150&amp;h=143 150w, https://bartoszmilewski.files.wordpress.com/2015/01/bifunctor.jpg 313w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>That’s pretty straightforward. But functoriality means that a bifunctor has to map morphisms as well. This time, though, it must map a pair of morphisms, one from C and one from D, to a morphism in E. </p><p>Again, a pair of morphisms is just a single morphism in the product category C×D. We define a morphism in a cartesian product of categories as a pair of morphisms which goes from one pair of objects to another pair of objects. These pairs of morphisms can be composed in the obvious way:</p><pre>(f, g) ∘ (f', g') = (f ∘ f', g ∘ g')</pre><p>The composition is associative and it has an identity — a pair of identity morphisms <em>(id, id)</em>. So a cartesian product of categories is indeed a category.</p><p>But an easier way to think about bifunctors is that they are functors in both arguments. So instead of translating functorial laws — associativity and identity preservation — from functors to bifunctors, it’s enough to check them separately for each argument. If you have a mapping from a pair of categories to a third category, and you prove that it is functorial in each argument separately (i.e., keeping the other argument constant), then the mapping is automatically a bifunctor. By <em>functorial</em> I mean that it acts on morphisms like an honest functor.</p><p>Let’s define a bifunctor in Haskell. In this case all three categories are the same: the category of Haskell types. A bifunctor is a type constructor that takes two type arguments. Here’s the definition of the <code>Bifunctor</code> typeclass taken directly from the library <code>Control.Bifunctor</code>:</p><pre>class Bifunctor <span class="red">f</span> where
    bimap :: (a -&gt; c) -&gt; (b -&gt; d) -&gt; <span class="red">f a b</span> -&gt; <span class="red">f c d</span>
    bimap g h = first g . second h
    first :: (a -&gt; c) -&gt; <span class="red">f a b</span> -&gt; <span class="red">f c b</span>
    first g = bimap g id
    second :: (b -&gt; d) -&gt; <span class="red">f a b</span> -&gt; <span class="red">f a d</span>
    second = bimap id</pre><p>The type variable <code>f</code> represents the bifunctor. You can see that in all type signatures it’s always applied to two type arguments. The first type signature defines <code>bimap</code>: a mapping of two functions at once. The result is a lifted function, <code>(f a b -&gt; f c d)</code>, operating on types generated by the bifunctor’s type constructor. There is a default implementation of <code>bimap</code> in terms of <code>first</code> and <code>second</code>, which shows that it’s enough to have functoriality in each argument separately to be able to define a bifunctor.</p><p>The two other type signatures, <code>first</code> and <code>second</code>, are the two <code>fmap</code>s witnessing the functoriality of <code>f</code> in the first and the second argument, respectively.</p><p>The typeclass definition provides default implementations for both of them in terms of <code>bimap</code>. </p><p>When declaring an instance of <code>Bifunctor</code>, you have a choice of either implementing <code>bimap</code> and accepting the defaults for <code>first</code> and <code>second</code>, or implementing both <code>first</code> and <code>second</code> and accepting the default for <code>bimap</code> (of course, you may implement all three of them, but then it’s up to you to make sure they are related to each other in this manner).</p><h2>Product and Coproduct Bifunctors</h2><p>An important example of a bifunctor is the categorical product — a product of two objects that is defined by a <a href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" title="Products and Coproducts" target="_blank">universal construction</a>. If the product exists for any pair of objects, the mapping from those objects to the product is bifunctorial. This is true in general, and in Haskell in particular. Here’s the <code>Bifunctor</code> instance for a pair constructor — the simplest product type:</p><pre>instance Bifunctor (,) where
    bimap f g (x, y) = (f x, g y)</pre><p>There isn’t much choice: <code>bimap</code> simply applies the first function to the first component, and the second function to the second component of a pair. The code pretty much writes itself, given the types:</p><pre>bimap :: (a -&gt; c) -&gt; (b -&gt; d) -&gt; (a, b) -&gt; (c, d)</pre><p>The action of the bifunctor here is to make pairs of types, for instance: </p><pre>(,) a b = (a, b)</pre><p>By duality, a coproduct, if it’s defined for every pair of objects in a category, is also a bifunctor. In Haskell, this is exemplified by the <code>Either</code> type constructor being an instance of <code>Bifunctor</code>:</p><pre>instance Bifunctor Either where
    bimap f _ (Left x)  = Left (f x)
    bimap _ g (Right y) = Right (g y)</pre><p>This code also writes itself.</p><p>Now, remember when we talked about monoidal categories? A monoidal category defines a binary operator acting on objects, together with a unit object. I mentioned that <code>Set</code> is a monoidal category with respect to cartesian product, with the singleton set as a unit. And it’s also a monoidal category with respect to disjoint union, with the empty set as a unit. What I haven’t mentioned is that one of the requirements for a monoidal category is that the binary operator be a bifunctor. This is a very important requirement — we want the monoidal product to be compatible with the structure of the category, which is defined by morphisms. We are now one step closer to the full definition of a monoidal category (we still need to learn about naturality, before we can get there).</p><h2>Functorial Algebraic Data Types</h2><p>We’ve seen several examples of parameterized data types that turned out to be functors — we were able to define <code>fmap</code> for them. Complex data types are constructed from simpler data types. In particular, algebraic data types (ADTs) are created using sums and products. We have just seen that sums and products are functorial. We also know that functors compose. So if we can show that the basic building blocks of ADTs are functorial, we’ll know that parameterized ADTs are functorial too.</p><p>So what are the building blocks of parameterized algebraic data types? First, there are the items that have no dependency on the type parameter of the functor, like <code>Nothing</code> in <code>Maybe</code>, or <code>Nil</code> in <code>List</code>. They are equivalent to the <code>Const</code> functor. Remember, the <code>Const</code> functor ignores its type parameter (really, the <em>second</em> type parameter, which is the one of interest to us, the first one being kept constant).</p><p>Then there are the elements that simply encapsulate the type parameter itself, like <code>Just</code> in <code>Maybe</code>. They are equivalent to the identity functor. I mentioned the identity functor previously, as the identity morphism in <em>Cat</em>, but didn’t give its definition in Haskell. Here it is:</p><pre>data Identity a = Identity a</pre><pre>instance Functor Identity where
    fmap f (Identity x) = Identity (f x)</pre><p>You can think of <code>Identity</code> as the simplest possible container that always stores just one (immutable) value of type <code>a</code>.</p><p>Everything else in algebraic data structures is constructed from these two primitives using products and sums.</p><p>With this new knowledge, let’s have a fresh look at the <code>Maybe</code> type constructor:</p><pre>data Maybe a = Nothing | Just a</pre><p>It’s a sum of two types, and we now know that the sum is functorial. The first part, <code>Nothing</code> can be represented as a <code>Const ()</code> acting on <code>a</code> (the first type parameter of <code>Const</code> is set to unit — later we’ll see more interesting uses of <code>Const</code>). The second part is just a different name for the identity functor. We could have defined <code>Maybe</code>, up to isomorphism, as:</p><pre>type Maybe a = Either (Const () a) (Identity a)</pre><p>So <code>Maybe</code> is the composition of the bifunctor <code>Either</code> with two functors, <code>Const ()</code> and <code>Identity</code>. (<code>Const</code> is really a bifunctor, but here we always use it partially applied.)</p><p>We’ve already seen that a composition of functors is a functor — we can easily convince ourselves that the same is true of bifunctors. All we need is to figure out how a composition of a bifunctor with two functors works on morphisms. Given two morphisms, we simply lift one with one functor and the other with the other functor. We then lift the resulting pair of lifted morphisms with the bifunctor.</p><p>We can express this composition in Haskell. Let’s define a data type that is parameterized by a bifunctor <code>bf</code> (it’s a type variable that is a type constructor that takes two types as arguments), two functors <code>fu</code> and <code>gu</code> (type constructors that take one type variable each), and two regular types <code>a</code> and <code>b</code>. We apply <code>fu</code> to <code>a</code> and <code>gu</code> to <code>b</code>, and then apply <code>bf</code> to the resulting two types:</p><pre>newtype BiComp bf fu gu a b = BiComp (bf (fu a) (gu b))</pre><p>That’s the composition on objects, or types. Notice how in Haskell we apply type constructors to types, just like we apply functions to arguments. The syntax is the same. </p><p>If you’re getting a little lost, try applying <code>BiComp</code> to <code>Either</code>, <code>Const ()</code>, <code>Identity</code>, <code>a</code>, and <code>b</code>, in this order. You will recover our bare-bone version of <code>Maybe b</code> (<code>a</code> is ignored).</p><p>The new data type <code>BiComp</code> is a bifunctor in <code>a</code> and <code>b</code>, but only if <code>bf</code> is itself a <code>Bifunctor</code> and <code>fu</code> and <code>gu</code> are <code>Functor</code>s. The compiler must know that there will be a definition of <code>bimap</code> available for <code>bf</code>, and definitions of <code>fmap</code> for <code>fu</code> and <code>gu</code>. In Haskell, this is expressed as a precondition in the instance declaration: a set of class constraints followed by a double arrow:</p><pre>instance <span class="red">(Bifunctor bf, Functor fu, Functor gu) =&gt;</span>
  Bifunctor (BiComp bf fu gu) where
    bimap f1 f2 (BiComp x) = BiComp ((<span class="red">bimap</span> (<span class="red">fmap</span> f1) (<span class="red">fmap</span> f2)) x)
 </pre><p>The implementation of <code>bimap</code> for <code>BiComp</code> is given in terms of <code>bimap</code> for <code>bf</code> and the two <code>fmap</code>s for <code>fu</code> and <code>gu</code>. The compiler automatically infers all the types and picks the correct overloaded functions whenever <code>BiComp</code> is used. </p><p>The <code>x</code> in the definition of <code>bimap</code> has the type:</p><pre>bf (fu a) (gu b)</pre><p>which is quite a mouthful. The outer <code>bimap</code> breaks through the outer <code>bf</code> layer, and the two <code>fmap</code>s dig under <code>fu</code> and <code>gu</code>, respectively. If the types of <code>f1</code> and <code>f2</code> are:</p><pre>f1 :: a -&gt; a'
 f2 :: b -&gt; b'</pre><p>then the final result is of the type <code>bf (fu a') (gu b')</code>:</p><pre>bimap (fu a -&gt; fu a') -&gt; (gu b -&gt; gu b')
  -&gt; bf (fu a) (gu b) -&gt; bf (fu a') (gu b')</pre><p>If you like jigsaw puzzles, these kinds of type manipulations can provide hours of entertainment.</p><p>So it turns out that we didn’t have to prove that <code>Maybe</code> was a functor — this fact followed from the way it was constructed as a sum of two functorial primitives.</p><p>A perceptive reader might ask the question: If the derivation of the <code>Functor</code> instance for algebraic data types is so mechanical, can’t it be automated and performed by the compiler? Indeed, it can, and it is. You need to enable a particular Haskell extension by including this line at the top of your source file:</p><pre>{-# LANGUAGE DeriveFunctor #-}</pre><p>and then add <code>deriving Functor</code> to your data structure:</p><pre>data Maybe a = Nothing | Just a
  deriving Functor</pre><p>and the corresponding <code>fmap</code> will be implemented for you.</p><p>The regularity of algebraic data structures makes it possible to derive instances not only of <code>Functor</code> but of several other type classes, including the <code>Eq</code> type class I mentioned before. There is also the option of teaching the compiler to derive instances of your own typeclasses, but that’s a bit more advanced. The idea though is the same: You provide the behavior for the basic building blocks and sums and products, and let the compiler figure out the rest.</p><h2>Functors in C++</h2><p>If you are a C++ programmer, you obviously are on your own as far as implementing functors goes. However, you should be able to recognize some types of algebraic data structures in C++. If such a data structure is made into a generic template, you should be able to quickly implement <code>fmap</code> for it.</p><p>Let’s have a look at a tree data structure, which we would define in Haskell as a recursive sum type:</p><pre>data Tree a = Leaf a | Node (Tree a) (Tree a)
    deriving Functor</pre><p>As I mentioned before, one way of implementing sum types in C++ is through class hierarchies. It would be natural, in an object-oriented language, to implement <code>fmap</code> as a virtual function of the base class <code>Functor</code> and then override it in all subclasses. Unfortunately this is impossible because <code>fmap</code> is a template, parameterized not only by the type of the object it’s acting upon (the <code>this</code> pointer) but also by the return type of the function that’s been applied to it. Virtual functions cannot be templatized in C++. We’ll implement <code>fmap</code> as a generic free function, and we’ll replace pattern matching with <code>dynamic_cast</code>.</p><p>The base class must define at least one virtual function in order to support dynamic casting, so we’ll make the destructor virtual (which is a good idea in any case):</p><pre>template&lt;class T&gt;
 struct Tree {
    virtual ~Tree() {};
 };</pre><p>The <code>Leaf</code> is just an <code>Identity</code> functor in disguise:</p><pre>template&lt;class T&gt;
 struct Leaf : public Tree&lt;T&gt; {
    T _label;
    Leaf(T l) : _label(l) {}
 };</pre><p>The <code>Node</code> is a product type:</p><pre>template&lt;class T&gt;
 struct Node : public Tree&lt;T&gt; {
    Tree&lt;T&gt; * _left;
    Tree&lt;T&gt; * _right;
    Node(Tree&lt;T&gt; * l, Tree&lt;T&gt; * r) : _left(l), _right(r) {}
 };</pre><p>When implementing <code>fmap</code> we take advantage of dynamic dispatching on the type of the <code>Tree</code>. The <code>Leaf</code> case applies the <code>Identity</code> version of <code>fmap</code>, and the <code>Node</code> case is treated like a bifunctor composed with two copies of the <code>Tree</code> functor. As a C++ programmer, you’re probably not used to analyzing code in these terms, but it’s a good exercise in categorical thinking.</p><pre>template&lt;class A, class B&gt;
 Tree&lt;B&gt; * fmap(std::function&lt;B(A)&gt; f, Tree&lt;A&gt; * t)
 {
    Leaf&lt;A&gt; * pl = dynamic_cast &lt;Leaf&lt;A&gt;*&gt;(t);
    if (pl)
        return new Leaf&lt;B&gt;(f (pl-&gt;_label));
    Node&lt;A&gt; * pn = dynamic_cast&lt;Node&lt;A&gt;*&gt;(t);
    if (pn)
        return new Node&lt;B&gt;( fmap&lt;A&gt;(f, pn-&gt;_left)
                          , fmap&lt;A&gt;(f, pn-&gt;_right));
    return nullptr;
 }</pre><p>For simplicity, I decided to ignore memory and resource management issues, but in production code you would probably use smart pointers (unique or shared, depending on your policy).</p><p>Compare it with the Haskell implementation of <code>fmap</code>:</p><pre>instance Functor Tree where
    fmap f (Leaf a) = Leaf (f a)
    fmap f (Node t t') = Node (fmap f t) (fmap f t')</pre><p>This implementation can also be automatically derived by the compiler.</p><h2>The Writer Functor</h2><p>I promised that I would come back to the <a href="https://bartoszmilewski.com/2014/12/23/kleisli-categories/" title="Kleisli Categories" target="_blank">Kleisli category</a> I described earlier. Morphisms in that category were represented as “embellished” functions returning the <code>Writer</code> data structure.</p><pre>type Writer a = (a, String)</pre><p>I said that the embellishment was somehow related to endofunctors. And, indeed, the <code>Writer</code> type constructor is functorial in <code>a</code>. We don’t even have to implement <code>fmap</code> for it, because it’s just a simple product type.</p><p>But what’s the relation between a Kleisli category and a functor — in general? A Kleisli category, being a category, defines composition and identity. Let’ me remind you that the composition is given by the fish operator:</p><pre>(&gt;=&gt;) :: (a -&gt; Writer b) -&gt; (b -&gt; Writer c) -&gt; (a -&gt; Writer c)
 m1 &gt;=&gt; m2 = \x -&gt;
    let (y, s1) = m1 x
        (z, s2) = m2 y
    in (z, s1 ++ s2)</pre><p>and the identity morphism by a function called <code>return</code>:</p><pre>return :: a -&gt; Writer a
 return x = (x, "")</pre><p>It turns out that, if you look at the types of these two functions long enough (and I mean, <em>long</em> enough), you can find a way to combine them to produce a function with the right type signature to serve as <code>fmap</code>. Like this:</p><pre>fmap f = id &gt;=&gt; (\x -&gt; return (f x))</pre><p>Here, the fish operator combines two functions: one of them is the familiar <code>id</code>, and the other is a lambda that applies <code>return</code> to the result of acting with <code>f</code> on the lambda’s argument. The hardest part to wrap your brain around is probably the use of <code>id</code>. Isn’t the argument to the fish operator supposed to be a function that takes a “normal” type and returns an embellished type? Well, not really. Nobody says that <code>a</code> in <code>a -&gt; Writer b</code> must be a “normal” type. It’s a type variable, so it can be anything, in particular it can be an embellished type, like <code>Writer b</code>.</p><p>So <code>id</code> will take <code>Writer a</code> and turn it into <code>Writer a</code>. The fish operator will fish out the value of <code>a</code> and pass it as <code>x</code> to the lambda. There, <code>f</code> will turn it into a <code>b</code> and <code>return</code> will embellish it, making it <code>Writer b</code>. Putting it all together, we end up with a function that takes <code>Writer a</code> and returns <code>Writer b</code>, exactly what <code>fmap</code> is supposed to produce.</p><p>Notice that this argument is very general: you can replace <code>Writer</code> with any type constructor. As long as it supports a fish operator and <code>return</code>, you can define <code>fmap</code> as well. So the embellishment in the Kleisli category is always a functor. (Not every functor, though, gives rise to a Kleisli category.)</p><p>You might wonder if the <code>fmap</code> we have just defined is the same <code>fmap</code> the compiler would have derived for us with <code>deriving Functor</code>. Interestingly enough, it is. This is due to the way Haskell implements polymorphic functions. It’s called <em>parametric polymorphism</em>, and it’s a source of so called <em>theorems for free</em>. One of those theorems says that, if there is an implementation of <code>fmap</code> for a given type constructor, one that preserves identity, then it must be unique.</p><h2>Covariant and Contravariant Functors</h2><p>Now that we’ve reviewed the writer functor, let’s go back to the reader functor. It was based on the partially applied function-arrow type constructor:</p><pre>(-&gt;) r</pre><p>We can rewrite it as a type synonym:</p><pre>type Reader r a = r -&gt; a</pre><p>for which the <code>Functor</code> instance, as we’ve seen before, reads:</p><pre>instance Functor (Reader r) where
    fmap f g = f . g</pre><p>But just like the pair type constructor, or the <code>Either</code> type constructor, the function type constructor takes two type arguments. The pair and <code>Either</code> were functorial in both arguments — they were bifunctors. Is the function constructor a bifunctor too?</p><p>Let’s try to make it functorial in the first argument. We’ll start with a type synonym — it’s just like the <code>Reader</code> but with the arguments flipped:</p><pre>type Op r a = a -&gt; r</pre><p>This time we fix the return type, <code>r</code>, and vary the argument type, <code>a</code>. Let’s see if we can somehow match the types in order to implement <code>fmap</code>, which would have the following type signature:</p><pre>fmap :: (a -&gt; b) -&gt; (a -&gt; r) -&gt; (b -&gt; r)</pre><p>With just two functions taking <code>a</code> and returning, respectively, <code>b</code> and <code>r</code>, there is simply no way to build a function taking <code>b</code> and returning <code>r</code>! It would be different if we could somehow invert the first function, so that it took <code>b</code> and returned <code>a</code> instead. We can’t invert an arbitrary function, but we can go to the opposite category.</p><p>A short recap: For every category <em>C</em> there is a dual category <em>C<sup>op</sup></em>. It’s a category with the same objects as <em>C</em>, but with all the arrows reversed. </p><p>Consider a functor that goes between <em>C<sup>op</sup></em> and some other category <em>D</em>:<br>
 <em>F :: C<sup>op</sup> → D</em><br>
 Such a functor maps a morphism <em>f<sup>op</sup> :: a → b</em> in <em>C<sup>op</sup></em> to the morphism <em>F f<sup>op</sup> :: F a → F b</em> in <em>D</em>. But the morphism <em>f<sup>op</sup></em> secretly corresponds to some morphism <em>f :: b → a</em> in the original category <em>C</em>. Notice the inversion.</p><p>Now, <em>F</em> is a regular functor, but there is another mapping we can define based on <em>F</em>, which is not a functor — let’s call it <em>G</em>. It’s a mapping from <em>C</em> to <em>D</em>. It maps objects the same way <em>F</em> does, but when it comes to mapping morphisms, it reverses them. It takes a morphism <em>f :: b → a</em> in <em>C</em>, maps it first to the opposite morphism <em>f<sup>op</sup> :: a → b</em> and then uses the functor F on it, to get <em>F f<sup>op</sup> :: F a → F b</em>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg"><img data-attachment-id="4077" data-permalink="https://bartoszmilewski.com/2015/02/03/functoriality/contravariant/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg" data-orig-size="530,522" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1422308064&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Contravariant" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg?w=300&amp;h=295" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg?w=510" class="aligncenter size-medium wp-image-4077" src="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg?w=300&amp;h=295" alt="Contravariant" width="300" height="295" srcset="https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg?w=300&amp;h=295 300w, https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg?w=150&amp;h=148 150w, https://bartoszmilewski.files.wordpress.com/2015/01/contravariant.jpg 530w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Considering that <em>F a</em> is the same as <em>G a</em> and <em>F b</em> is the same as <em>G b</em>, the whole trip can be described as:<br>
 <em>G f :: (b → a) → (G a → G b)</em><br>
 It’s a “functor with a twist.” A mapping of categories that inverts the direction of morphisms in this manner is called a <em>contravariant functor</em>. Notice that a contravariant functor is just a regular functor from the opposite category. The regular functors, by the way — the kind we’ve been studying thus far — are called <em>covariant</em> functors.</p><p>Here’s the typeclass defining a contravariant functor (really, a contravariant <em>endo</em>functor) in Haskell:</p><pre>class Contravariant f where
    contramap :: (b -&gt; a) -&gt; (f a -&gt; f b)</pre><p>Our type constructor <code>Op</code> is an instance of it:</p><pre>instance Contravariant (Op r) where
    -- (b -&gt; a) -&gt; Op r a -&gt; Op r b
    contramap f g = g . f</pre><p>Notice that the function <code>f</code> inserts itself <em>before</em> (that is, to the right of) the contents of <code>Op</code> — the function <code>g</code>.</p><p>The definition of <code>contramap</code> for <code>Op</code> may be made even terser, if you notice that it’s just the function composition operator with the arguments flipped. There is a special function for flipping arguments, called <code>flip</code>:</p><pre>flip :: (a -&gt; b -&gt; c) -&gt; (b -&gt; a -&gt; c)
 flip f y x = f x y</pre><p>With it, we get:</p><pre>contramap = flip (.)</pre><h2>Profunctors</h2><p>We’ve seen that the function-arrow operator is contravariant in its first argument and covariant in the second. Is there a name for such a beast? It turns out that, if the target category is <strong>Set</strong>, such a beast is called a <em>profunctor</em>. Because a contravariant functor is equivalent to a covariant functor from the opposite category, a profunctor is defined as:<br>
 <i>C<sup>op</sup> × D → Set</i></p><p>Since, to first approximation, Haskell types are sets, we apply the name <code>Profunctor</code> to a type constructor <code>p</code> of two arguments, which is contra-functorial in the first argument and functorial in the second. Here’s the appropriate typeclass taken from the <code>Data.Profunctor</code> library:</p><pre>class Profunctor p where
  dimap :: (a -&gt; b) -&gt; (c -&gt; d) -&gt; p b c -&gt; p a d
  dimap f g = lmap f . rmap g
  lmap :: (a -&gt; b) -&gt; p b c -&gt; p a c
  lmap f = dimap f id
  rmap :: (b -&gt; c) -&gt; p a b -&gt; p a c
  rmap = dimap id</pre><p>All three functions come with default implementations. Just like with <code>Bifunctor</code>, when declaring an instance of <code>Profunctor</code>, you have a choice of either implementing <code>dimap</code> and accepting the defaults for <code>lmap</code> and <code>rmap</code>, or implementing both <code>lmap</code> and <code>rmap</code> and accepting the default for <code>dimap</code>.</p><p>Now we can assert that the function-arrow operator is an instance of a <code>Profunctor</code>:</p><pre>instance Profunctor (-&gt;) where
  dimap ab cd bc = cd . bc . ab
  lmap = flip (.)
  rmap = (.)</pre><p>Profunctors have their application in the Haskell lens library. We’ll see them again when we talk about ends and coends.</p><h2>Challenges</h2><ol>
 <li>Show that the data type:
 <pre>data Pair a b = Pair a b</pre>
 <p>is a bifunctor. For additional credit implement all three methods of <code>Bifunctor</code> and use equational reasoning to show that these definitions are compatible with the default implementations whenever they can be applied.</p></li>
 <li>Show the isomorphism between the standard definition of <code>Maybe</code> and this desugaring:
 <pre>type Maybe' a = Either (Const () a) (Identity a)</pre>
 <p>Hint: Define two mappings between the two implementations. For additional credit, show that they are the inverse of each other using equational reasoning.</p></li>
 <li>Let’s try another data structure. I call it a <code>PreList</code> because it’s a precursor to a <code>List</code>. It replaces recursion with a type parameter <code>b</code>.
 <pre>data PreList a b = Nil | Cons a b</pre>
 <p>You could recover our earlier definition of a <code>List</code> by recursively applying <code>PreList</code> to itself (we’ll see how it’s done when we talk about fixed points).</p>
 <p>Show that <code>PreList</code> is an instance of <code>Bifunctor</code>.</p></li>
 <li>Show that the following data types define bifunctors in <code>a</code> and <code>b</code>:
 <pre>data K2 c a b = K2 c</pre>
 <pre>data Fst a b = Fst a</pre>
 <pre>data Snd a b = Snd b</pre>
 <p>For additional credit, check your solutions agains Conor McBride’s paper <a href="http://strictlypositive.org/CJ.pdf" target="_blank">Clowns to the Left of me, Jokers to the Right</a>.</p></li>
 <li>Define a bifunctor in a language other than Haskell. Implement <code>bimap</code> for a generic pair in that language.</li>
 <li>Should <code>std::map</code> be considered a bifunctor or a profunctor in the two template arguments <code>Key</code> and <code>T</code>? How would you redesign this data type to make it so?</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/03/13/function-types/" title="Function Types">Function Types</a>.</p><h2>Acknowledgment</h2><p>As usual, big thanks go to Gershom Bazerman for reviewing this article.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408223272" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Function Types		</h2><p>So far I’ve been glossing over the meaning of function types. A function type is different from other types.</p><p>Take <code>Integer</code>, for instance: It’s just a set of integers. <code>Bool</code> is a two element set. But a function type <code>a-&gt;b</code> is more than that: it’s a set of morphisms between objects <code>a</code> and <code>b</code>. A set of morphisms between two objects in any category is called a hom-set. It just so happens that in the category <b>Set</b> every hom-set is itself an object in the same category —because it is, after all, a <em>set</em>.</p><p>The same is not true of other categories where hom-sets are external to a category. They are even called <em>external</em> hom-sets.</p><p>It’s the self-referential nature of the category <b>Set</b> that makes function types special. But there is a way, at least in some categories, to construct objects that represent hom-sets. Such objects are called <em>internal</em> hom-sets.</p><h2>Universal Construction</h2><p>Let’s forget for a moment that function types are sets and try to construct a function type, or more generally, an internal hom-set, from scratch. As usual, we’ll take our cues from the <b>Set</b> category, but carefully avoid using any properties of sets, so that the construction will automatically work for other categories.</p><p>A function type may be considered a composite type because of its relationship to the argument type and the result type. We’ve already seen the constructions of composite types — those that involved relationships between objects. We used universal constructions to define a <a title="Products and Coproducts" href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" target="_blank">product type and a coproduct types</a>. We can use the same trick to define a function type. We will need a pattern that involves three objects: the function type that we are constructing, the argument type, and the result type.</p><p>The obvious pattern that connects these three types is called <em>function application</em> or <em>evaluation</em>. Given a candidate for a function type, let’s call it <code>z</code> (notice that, if we are not in the category <b>Set</b>, this is just an object like any other object), and the argument type <code>a</code> (an object), the application maps this pair to the result type <code>b</code> (an object). We have three objects, two of them fixed (the ones representing the argument type and the result type).</p><p>We also have the application, which is a mapping. How do we incorporate this mapping into our pattern? If we were allowed to look inside objects, we could pair a function <code>f</code> (an element of <code>z</code>) with an argument <code>x</code> (an element of <code>a</code>) and map it to <code>f x</code> (the application of <code>f</code> to <code>x</code>, which is an element of <code>b</code>).</p><p>But instead of dealing with individual pairs <code>(f, x)</code>, we can as well talk about the whole <em>product</em> of the function type <code>z</code> and the argument type <code>a</code>. The product <code>z×a</code> is an object, and we can pick, as our application morphism, an arrow <code>g</code> from that object to <code>b</code>. In <b>Set</b>, <code>g</code> would be the function that maps every pair <code>(f, x)</code> to <code>f x</code>.</p><p>So that’s the pattern: a product of two objects <code>z</code> and <code>a</code> connected to another object <code>b</code> by a morphism <code>g</code>.</p><p>Is this pattern specific enough to single out the function type using a universal construction? Not in every category. But in the categories of interest to us it is. And another question: Would it be possible to define a function object without first defining a product? There are categories in which there is no product, or there isn’t a product for all pairs of objects. The answer is no: there is no function type, if there is no product type. We’ll come back to this later when we talk about exponentials.</p><p>Let’s review the universal construction. We start with a pattern of objects and morphisms. That’s our imprecise query, and it usually yields lots and lots of hits. In particular, in <b>Set</b>, pretty much everything is connected to everything. We can take any object <code>z</code>, form its product with <code>a</code>, and there’s going to be a function from it to <code>b</code> (except when <code>b</code> is an empty set).</p><p>That’s when we apply our secret weapon: ranking. This is usually done by requiring that there be a unique mapping between candidate objects — a mapping that somehow factorizes our construction. In our case, we’ll decree that <code>z</code> together with the morphism <code>g</code> from <code>z×a</code> to <code>b</code> is <em>better</em> than some other <code>z'</code> with its own application <code>g'</code>, if and only if there is a unique mapping <code>h</code> from <code>z'</code> to <code>z</code> such that the application of <code>g'</code> factors through the application of <code>g</code>. (Hint: Read this sentence while looking at the picture.)</p><p>Now here’s the tricky part, and the main reason I postponed this particular universal construction till now. Given the morphism <code>h :: z'-&gt; z</code>, we want to close the diagram that has both <code>z'</code> and <code>z</code> crossed with <code>a</code>. What we really need, given the mapping <code>h</code> from <code>z'</code> to <code>z</code>, is a mapping from <code>z'×a</code> to <code>z×a</code>. And now, after discussing the <a title="Functoriality" href="https://bartoszmilewski.com/2015/02/03/functoriality/" target="_blank">functoriality of the product</a>, we know how to do it. Because the product itself is a functor (more precisely an endo-bi-functor), it’s possible to lift pairs of morphisms. In other words, we can define not only products of objects but also products of morphisms.</p><p>Since we are not touching the second component of the product <code>z'×a</code>, we will lift the pair of morphisms <code>(h, id)</code>, where <code>id</code> is an identity on <code>a</code>.</p><p>So, here’s how we can factor one application, <code>g</code>, out of another application <code>g'</code>:</p><pre>g' = g ∘ (h × id)</pre><p>The key here is the action of the product on morphisms.</p><p>The third part of the universal construction is selecting the object that is universally the best. Let’s call this object <code>a⇒b</code> (think of this as a symbolic name for one object, not to be confused with a Haskell typeclass constraint — I’ll discuss different ways of naming it later). This object comes with its own application — a morphism from <code>(a⇒b)×a</code> to <code>b</code> — which we will call <code>eval</code>. The object <code>a⇒b</code> is the best if any other candidate for a function object can be uniquely mapped to it in such a way that its application morphism <code>g</code> factorizes through <code>eval</code>. This object is better than any other object according to our ranking.</p><p>Formally:</p><p>Of course, there is no guarantee that such an object <code>a⇒b</code> exists for any pair of objects <code>a</code> and <code>b</code> in a given category. But it always does in <b>Set</b>. Moreover, in <b>Set</b>, this object is isomorphic to the hom-set <em>Set(a, b)</em>.</p><p>This is why, in Haskell, we interpret the function type <code>a-&gt;b</code> as the categorical function object <code>a⇒b</code>.</p><h2>Currying</h2><p>Let’s have a second look at all the candidates for the function object. This time, however, let’s think of the morphism <code>g</code> as a function of two variables, <code>z</code> and <code>a</code>.</p><pre>g :: z × a -&gt; b</pre><p>Being a morphism from a product comes as close as it gets to being a function of two variables. In particular, in <strong>Set</strong>, <code>g</code> is a function from pairs of values, one from the set <code>z</code> and one from the set <code>a</code>.</p><p>On the other hand, the universal property tells us that for each such <code>g</code> there is a unique morphism <code>h</code> that maps <code>z</code> to a function object <code>a⇒b</code>.</p><pre>h :: z -&gt; (a⇒b)</pre><p>In <b>Set</b>, this just means that <code>h</code> is a function that takes one variable of type <code>z</code> and returns a function from <code>a</code> to <code>b</code>. That makes <code>h</code> a higher order function. Therefore the universal construction establishes a one-to-one correspondence between functions of two variables and functions of one variable returning functions. This correspondence is called <em>currying</em>, and <code>h</code> is called the curried version of <code>g</code>.</p><p>This correspondence is one-to-one, because given any <code>g</code> there is a unique <code>h</code>, and given any <code>h</code> you can always recreate the two-argument function <code>g</code> using the formula:</p><pre>g = eval ∘ (h × id)</pre><p>The function <code>g</code> can be called the <em>uncurried</em> version of <code>h</code>.</p><p>Currying is essentially built into the syntax of Haskell. A function returning a function:</p><pre>a -&gt; (b -&gt; c)</pre><p>is often thought of as a function of two variables. That’s how we read the un-parenthesized signature:</p><pre>a -&gt; b -&gt; c</pre><p>This interpretation is apparent in the way we define multi-argument functions. For instance:</p><pre>catstr :: String -&gt; String -&gt; String
 catstr s s’ = s ++ s’</pre><p>The same function can be written as a one-argument function returning a function — a lambda:</p><pre>catstr’ s = \s’ -&gt; s ++ s’</pre><p>These two definitions are equivalent, and either can be partially applied to just one argument, producing a one-argument function, as in:</p><pre>greet :: String -&gt; String
 greet = catstr “Hello “</pre><p>Strictly speaking, a function of two variables is one that takes a pair (a product type):</p><pre>(a, b) -&gt; c</pre><p>It’s trivial to convert between the two representations, and the two (higher-order) functions that do it are called, unsurprisingly, <code>curry</code> and <code>uncurry</code>:</p><pre>curry :: ((a, b)-&gt;c) -&gt; (a-&gt;b-&gt;c)
 curry f a b = f (a, b)</pre><p>and</p><pre>uncurry :: (a-&gt;b-&gt;c) -&gt; ((a, b)-&gt;c)
 uncurry f (a, b) = f a b</pre><p>Notice that <code>curry</code> is the <em>factorizer</em> for the universal construction of the function object. This is especially apparent if it’s rewritten in this form:</p><pre>factorizer :: ((a, b)-&gt;c) -&gt; (a-&gt;(b-&gt;c))
 factorizer g = \a -&gt; (\b -&gt; g (a, b))</pre><p>(As a reminder: A factorizer produces the factorizing function from a candidate.)</p><p>In non-functional languages, like C++, currying is possible but nontrivial. You can think of multi-argument functions in C++ as corresponding to Haskell functions taking tuples (although, to confuse things even more, in C++ you can define functions that take an explicit <code>std::tuple</code>, as well as variadic functions, and functions taking initializer lists).</p><p>You can partially apply a C++ function using the template <code>std::bind</code>. For instance, given a function of two strings:</p><pre>std::string catstr(std::string s1, std::string s2) {
    return s1 + s2;
 }</pre><p>you can define a function of one string:</p><pre>using namespace std::placeholders;

 auto greet = std::bind(catstr, "Hello ", _1);
 std::cout &lt;&lt; greet("Haskell Curry");</pre><p>Scala, which is more functional than C++ or Java, falls somewhere in between. If you anticipate that the function you’re defining will be partially applied, you define it with multiple argument lists:</p><pre>def catstr(s1: String)(s2: String) = s1 + s2</pre><p>Of course that requires some amount of foresight or prescience on the part of a library writer.</p><h2>Exponentials</h2><p>In mathematical literature, the function object, or the internal hom-object between two objects <code>a</code> and <code>b</code>, is often called the <em>exponential</em> and denoted by <code>b<sup>a</sup></code>. Notice that the argument type is in the exponent. This notation might seem strange at first, but it makes perfect sense if you think of the relationship between functions and products. We’ve already seen that we have to use the product in the universal construction of the internal hom-object, but the connection goes deeper than that.</p><p>This is best seen when you consider functions between finite types — types that have a finite number of values, like <code>Bool</code>, <code>Char</code>, or even <code>Int</code> or <code>Double</code>. Such functions, at least in principle, can be fully memoized or turned into data structures to be looked up. And this is the essence of the equivalence between functions, which are morphisms, and function types, which are objects.</p><p>For instance a (pure) function from <code>Bool</code> is completely specified by a pair of values: one corresponding to <code>False</code>, and one corresponding to <code>True</code>. The set of all possible functions from <code>Bool</code> to, say, <code>Int</code> is the set of all pairs of <code>Int</code>s. This is the same as the product <code>Int × Int</code> or, being a little creative with notation, <code>Int<sup>2</sup></code>.</p><p>For another example, let’s look at the C++ type <code>char</code>, which contains 256 values (Haskell <code>Char</code> is larger, because Haskell uses Unicode). There are several functions in the <code></code> part of the C++ Standard Library that are usually implemented using lookups. Functions like <code>isupper</code> or <code>isspace</code> are implemented using tables, which are equivalent to tuples of 256 Boolean values. A tuple is a product type, so we are dealing with products of 256 Booleans: <code>bool × bool × bool × ... × bool</code>. We know from arithmetics that an iterated product defines a power. If you “multiply” <code>bool</code> by itself 256 (or <code>char</code>) times, you get <code>bool</code> to the power of <code>char</code>, or <code>bool<sup>char</sup></code>.</p><p>How many values are there in the type defined as 256-tuples of <code>bool</code>? Exactly 2<sup>256</sup>. This is also the number of different functions from <code>char</code> to <code>bool</code>, each function corresponding to a unique 256-tuple. You can similarly calculate that the number of functions from <code>bool</code> to <code>char</code> is 256<sup>2</sup>, and so on. The exponential notation for function types makes perfect sense in these cases.</p><p>We probably wouldn’t want to fully memoize a function from <code>int</code> or <code>double</code>. But the equivalence between functions and data types, if not always practical, is there. There are also infinite types, for instance lists, strings, or trees. Eager memoization of functions from those types would require infinite storage. But Haskell is a lazy language, so the boundary between lazily evaluated (infinite) data structures and functions is fuzzy. This function vs. data duality explains the identification of Haskell’s function type with the categorical exponential object — which corresponds more to our idea of <em>data</em>.</p><h2>Cartesian Closed Categories</h2><p>Although I will continue using the category of sets as a model for types and functions, it’s worth mentioning that there is a larger family of categories that can be used for that purpose. These categories are called <em>cartesian closed</em>, and <b>Set</b> is just one example of such a category.</p><p>A cartesian closed category must contain:</p><ol>
 <li>The terminal object,</li>
 <li>A product of any pair of objects, and</li>
 <li>An exponential for any pair of objects.</li>
 </ol><p>If you consider an exponential as an iterated product (possibly infinitely many times), then you can think of a cartesian closed category as one supporting products of an arbitrary arity. In particular, the terminal object can be thought of as a product of zero objects — or the zero-th power of an object.</p><p>What’s interesting about cartesian closed categories from the perspective of computer science is that they provide models for the simply typed lambda calculus, which forms the basis of all typed programming languages.</p><p>The terminal object and the product have their duals: the initial object and the coproduct. A cartesian closed category that also supports those two, and in which product can be distributed over coproduct</p><pre>a × (b + c) = a × b + a × c
 (b + c) × a = b × a + c × a</pre><p>is called a <em>bicartesian closed</em> category. We’ll see in the next section that bicartesian closed categories, of which <b>Set</b> is a prime example, have some interesting properties.</p><h2>Exponentials and Algebraic Data Types</h2><p>The interpretation of function types as exponentials fits very well into the scheme of algebraic data types. It turns out that all the basic identities from high-school algebra relating numbers zero and one, sums, products, and exponentials hold pretty much unchanged in any bicartesian closed category theory for, respectively, initial and final objects, coproducts, products, and exponentials. We don’t have the tools yet to prove them (such as adjunctions or the Yoneda lemma), but I’ll list them here nevertheless as a source of valuable intuitions.</p><h3>Zeroth Power</h3><pre>a<sup>0</sup> = 1</pre><p>In the categorical interpretation, we replace 0 with the initial object, 1 with the final object, and equality with isomorphism. The exponential is the internal hom-object. This particular exponential represents the set of morphisms going from the initial object to an arbitrary object <code>a</code>. By the definition of the initial object, there is exactly one such morphism, so the hom-set <em>C(0, a)</em> is a singleton set. A singleton set is the terminal object in <b>Set</b>, so this identity trivially works in <b>Set</b>. What we are saying is that it works in any bicartesian closed category.</p><p>In Haskell, we replace 0 with <code>Void</code>; 1 with the unit type <code>()</code>; and the exponential with function type. The claim is that the set of functions from <code>Void</code> to any type <code>a</code> is equivalent to the unit type — which is a singleton. In other words, there is only one function <code>Void-&gt;a</code>. We’ve seen this function before: it’s called <code>absurd</code>.</p><p>This is a little bit tricky, for two reasons. One is that in Haskell we don’t really have uninhabited types — every type contains the “result of a never ending calculation,” or the bottom. The second reason is that all implementations of <code>absurd</code> are equivalent because, no matter what they do, nobody can ever execute them. There is no value that can be passed to <code>absurd</code>. (And if you manage to pass it a never ending calculation, it will never return!)</p><h3>Powers of One</h3><pre>1<sup>a</sup> = 1</pre><p>This identity, when interpreted in <b>Set</b>, restates the definition of the terminal object: There is a unique morphism from any object to the terminal object. In general, the internal hom-object from <code>a</code> to the terminal object is isomorphic to the terminal object itself.</p><p>In Haskell, there is only one function from any type <code>a</code> to unit. We’ve seen this function before — it’s called <code>unit</code>. You can also think of it as the function <code>const</code> partially applied to <code>()</code>.</p><h3>First Power</h3><pre>a<sup>1</sup> = a</pre><p>This is a restatement of the observation that morphisms from the terminal object can be used to pick “elements” of the object <code>a</code>. The set of such morphisms is isomorphic to the object itself. In <b>Set</b>, and in Haskell, the isomorphism is between elements of the set <code>a</code> and functions that pick those elements, <code>()-&gt;a</code>.</p><h3>Exponentials of Sums</h3><pre>a<sup>b+c</sup> = a<sup>b</sup> × a<sup>c</sup></pre><p>Categorically, this says that the exponential from a coproduct of two objects is isomorphic to a product of two exponentials. In Haskell, this algebraic identity has a very practical, interpretation. It tells us that a function from a sum of two types is equivalent to a pair of functions from individual types. This is just the case analysis that we use when defining functions on sums. Instead of writing one function definition with a <code>case</code> statement, we usually split it into two (or more) functions dealing with each type constructor separately. For instance, take a function from the sum type <code>(Either Int Double)</code>:</p><pre>f :: Either Int Double -&gt; String</pre><p>It may be defined as a pair of functions from, respectively, <code>Int</code> and <code>Double</code>:</p><pre>f (Left n)  = if n &lt; 0 then "Negative int" else "Positive int"
 f (Right x) = if x &lt; 0.0 then "Negative double" else "Positive double"</pre><p>Here, <code>n</code> is an <code>Int</code> and <code>x</code> is a <code>Double</code>.</p><h3>Exponentials of Exponentials</h3><pre>(a<sup>b</sup>)<sup>c</sup> = a<sup>b×c</sup></pre><p>This is just a way of expressing currying purely in terms of exponential objects. A function returning a function is equivalent to a function from a product (a two-argument function).</p><h3>Exponentials over Products</h3><pre>(a × b)<sup>c</sup> = a<sup>c</sup> × b<sup>c</sup></pre><p>In Haskell: A function returning a pair is equivalent to a pair of functions, each producing one element of the pair.</p><p>It’s pretty incredible how those simple high-school algebraic identities can be lifted to category theory and have practical application in functional programming.</p><h2>Curry-Howard Isomorphism</h2><p>I have already mentioned the correspondence between logic and algebraic data types. The <code>Void</code> type and the unit type <code>()</code> correspond to false and true. Product types and sum types correspond to logical conjunction ∧ (AND) and disjunction ⋁ (OR). In this scheme, the function type we have just defined corresponds to logical implication ⇒. In other words, the type <code>a-&gt;b</code> can be read as “if a then b.”</p><p>According to the Curry-Howard isomorphism, every type can be interpreted as a proposition — a statement or a judgment that may be true or false. Such a proposition is considered true if the type is inhabited and false if it isn’t. In particular, a logical implication is true if the function type corresponding to it is inhabited, which means that there exists a function of that type. An implementation of a function is therefore a proof of a theorem. Writing programs is equivalent to proving theorems. Let’s see a few examples.</p><p>Let’s take the function <code>eval</code> we have introduced in the definition of the function object. Its signature is:</p><pre>eval :: ((a -&gt; b), a) -&gt; b</pre><p>It takes a pair consisting of a function and its argument and produces a result of the appropriate type. It’s the Haskell implementation of the morphism:</p><pre>eval :: (a⇒b) × a -&gt; b</pre><p>which defines the function type <code>a⇒b</code> (or the exponential object <code>b<sup>a</sup></code>). Let’s translate this signature to a logical predicate using the Curry-Howard isomorphism:</p><pre>((a ⇒ b) ∧ a) ⇒ b</pre><p>Here’s how you can read this statement: If it’s true that <code>b</code> follows from <code>a</code>, and <code>a</code> is true, then <code>b</code> must be true. This makes perfect intuitive sense and has been known since antiquity as <em>modus ponens</em>. We can prove this theorem by implementing the function:</p><pre>eval :: ((a -&gt; b), a) -&gt; b
 eval (f, x) = f x</pre><p>If you give me a pair consisting of a function <code>f</code> taking <code>a</code> and returning <code>b</code>, and a concrete value <code>x</code> of type <code>a</code>, I can produce a concrete value of type <code>b</code> by simply applying the function <code>f</code> to <code>x</code>. By implementing this function I have just shown that the type <code>((a -&gt; b), a) -&gt; b</code> is inhabited. Therefore <em>modus ponens</em> is true in our logic.</p><p>How about a predicate that is blatantly false? For instance: if <code>a</code> or <code>b</code> is true then <code>a</code> must be true.</p><pre>a ⋁ b ⇒ a</pre><p>This is obviously wrong because you can chose an <code>a</code> that is false and a <code>b</code> that is true, and that’s a counter-example.</p><p>Mapping this predicate into a function signature using the Curry-Howard isomorphism, we get:</p><pre>Either a b -&gt; a</pre><p>Try as you may, you can’t implement this function — you can’t produce a value of type <code>a</code> if you are called with the <code>Right</code> value. (Remember, we are talking about <em>pure</em> functions.)</p><p>Finally, we come to the meaning of the <code>absurd</code> function:</p><pre>absurd :: Void -&gt; a</pre><p>Considering that <code>Void</code> translates into false, we get:</p><pre> false ⇒ a</pre><p>Anything follows from falsehood (<em>ex falso quodlibet</em>). Here’s one possible proof (implementation) of this statement (function) in Haskell:</p><pre>absurd (Void a) = absurd a</pre><p>where <code>Void</code> is defined as:</p><pre>newtype Void = Void Void</pre><p>As always, the type <code>Void</code> is tricky. This definition makes it impossible to construct a value because in order to construct one, you would need to provide one. Therefore, the function <code>absurd</code> can never be called.</p><p>These are all interesting examples, but is there a practical side to Curry-Howard isomorphism? Probably not in everyday programming. But there are programming languages like Agda or Coq, which take advantage of the Curry-Howard isomorphism to prove theorems.</p><p>Computers are not only helping mathematicians do their work — they are revolutionizing the very foundations of mathematics. The latest hot research topic in that area is called Homotopy Type Theory, and is an outgrowth of type theory. It’s full of Booleans, integers, products and coproducts, function types, and so on. And, as if to dispel any doubts, the theory is being formulated in Coq and Agda. Computers are revolutionizing the world in more than one way.</p><h2>Bibliography</h2><ol>
 <li>Ralph Hinze, Daniel W. H. James, <a href="http://www.cs.ox.ac.uk/ralf.hinze/publications/WGP10.pdf" target="_blank">Reason Isomorphically!</a>. This paper contains proofs of all those high-school algebraic identities in category theory that I mentioned in this chapter.</li>
 </ol><p>Next: <a title="Natural Transformations" href="https://bartoszmilewski.com/2015/04/07/natural-transformations/">Natural Transformations</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408234625" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Natural Transformations		</h2><p>We talked about functors as mappings between categories that preserve their structure. A functor “embeds” one category in another. It may collapse multiple things into one, but it never breaks connections. One way of thinking about it is that with a functor we are modeling one category inside another. The source category serves as a model, a blueprint, for some structure that’s part of the target category.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg"><img data-attachment-id="4346" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/1_functors/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg" data-orig-size="640,630" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976343&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="1_Functors" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=510&amp;h=502" class="alignnone size-large wp-image-4346" src="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=510&amp;h=502" alt="1_Functors" width="510" height="502" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=510&amp;h=502 510w, https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=150&amp;h=148 150w, https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg?w=300&amp;h=295 300w, https://bartoszmilewski.files.wordpress.com/2015/04/1_functors.jpg 640w" sizes="(max-width: 510px) 100vw, 510px"></a></p><p>There may be many ways of embedding one category in another. Sometimes they are equivalent, sometimes very different. One may collapse the whole source category into one object, another may map every object to a different object and every morphism to a different morphism. The same blueprint may be realized in many different ways. Natural transformations help us compare these realizations. They are mappings of functors — special mappings that preserve their functorial nature.</p><p>Consider two functors <code>F</code> and <code>G</code> between categories <em>C</em> and <em>D</em>. If you focus on just one object <code>a</code> in <em>C</em>, it is mapped to two objects: <code>F a</code> and <code>G a</code>. A mapping of functors should therefore map <code>F a</code> to <code>G a</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg"><img data-attachment-id="4348" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/2_natcomp/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg" data-orig-size="640,543" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="2_NatComp" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=300&amp;h=255" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=510" class="alignnone wp-image-4348 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=300&amp;h=255" alt="2_NatComp" width="300" height="255" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=300&amp;h=255 300w, https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=600&amp;h=510 600w, https://bartoszmilewski.files.wordpress.com/2015/04/2_natcomp.jpg?w=150&amp;h=127 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that <code>F a</code> and <code>G a</code> are objects in the same category <em>D</em>. Mappings between objects in the same category should not go against the grain of the category. We don’t want to make artificial connections between objects. So it’s <em>natural</em> to use existing connections, namely morphisms. A natural transformation is a selection of morphisms: for every object <code>a</code>, it picks one morphism from <code>F a</code> to <code>G a</code>. If we call the natural transformation <code>α</code>, this morphism is called the <em>component</em> of <code>α</code> at <code>a</code>, or <code>α<sub>a</sub></code>.</p><pre>α<sub>a</sub> :: F a -&gt; G a</pre><p>Keep in mind that <code>a</code> is an object in <em>C</em> while <code>α<sub>a</sub></code> is a morphism in <em>D</em>.</p><p>If, for some <code>a</code>, there is no morphism between <code>F a</code> and <code>G a</code> in <em>D</em>, there can be no natural transformation between <code>F</code> and <code>G</code>.</p><p>Of course that’s only half of the story, because functors not only map objects, they map morphisms as well. So what does a natural transformation do with those mappings? It turns out that the mapping of morphisms is fixed — under any natural transformation between F and G, <code>F f</code> must be transformed into <code>G f</code>. What’s more, the mapping of morphisms by the two functors drastically restricts the choices we have in defining a natural transformation that’s compatible with it. Consider a morphism <code>f</code> between two objects <code>a</code> and <code>b</code> in <em>C</em>. It’s mapped to two morphisms, <code>F f</code> and <code>G f</code> in <em>D</em>:</p><pre>F f :: F a -&gt; F b
 G f :: G a -&gt; G b</pre><p>The natural transformation <code>α</code> provides two additional morphisms that complete the diagram in <em>D</em>:</p><pre>α<sub>a</sub> :: F a -&gt; G a
 α<sub>b</sub> :: F b -&gt; G b</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg"><img data-attachment-id="4349" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/3_naturality/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg" data-orig-size="640,528" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="3_Naturality" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=300&amp;h=248" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=510" class="alignnone wp-image-4349 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=300&amp;h=248" alt="3_Naturality" width="300" height="248" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=300&amp;h=248 300w, https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=600&amp;h=496 600w, https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=150&amp;h=124 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Now we have two ways of getting from <code>F a</code> to <code>G b</code>. To make sure that they are equal, we must impose the <em>naturality condition</em> that holds for any <code>f</code>:</p><pre>G f ∘ α<sub>a</sub> = α<sub>b</sub> ∘ F f</pre><p>The naturality condition is a pretty stringent requirement. For instance, if the morphism <code>F f</code> is invertible, naturality determines <code>α<sub>b</sub></code> in terms of <code>α<sub>a</sub></code>. It <em>transports</em> <code>α<sub>a</sub></code> along <code>f</code>:</p><pre>α<sub>b</sub> = (G f) ∘ α<sub>a</sub> ∘ (F f)<sup>-1</sup></pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg"><img data-attachment-id="4350" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/4_transport/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg" data-orig-size="640,450" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="4_Transport" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=300&amp;h=211" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=510" class="alignnone wp-image-4350 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=300&amp;h=211" alt="4_Transport" width="300" height="211" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=300&amp;h=211 300w, https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=600&amp;h=422 600w, https://bartoszmilewski.files.wordpress.com/2015/04/4_transport.jpg?w=150&amp;h=105 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>If there is more than one invertible morphism between two objects, all these transports have to agree. In general, though, morphisms are not invertible; but you can see that the existence of natural transformations between two functors is far from guaranteed. So the scarcity or the abundance of functors that are related by natural transformations may tell you a lot about the structure of categories between which they operate. We’ll see some examples of that when we talk about limits and the Yoneda lemma.</p><p>Looking at a natural transformation component-wise, one may say that it maps objects to morphisms. Because of the naturality condition, one may also say that it maps morphisms to commuting squares — there is one commuting naturality square in <em>D</em> for every morphism in <em>C</em>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg"><img data-attachment-id="4374" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/naturality-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg" data-orig-size="640,340" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1428058196&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Naturality" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=300&amp;h=159" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=510" class="alignnone size-medium wp-image-4374" src="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=300&amp;h=159" alt="Naturality" width="300" height="159" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=300&amp;h=159 300w, https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=600&amp;h=318 600w, https://bartoszmilewski.files.wordpress.com/2015/04/naturality.jpg?w=150&amp;h=80 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>This property of natural transformations comes in very handy in a lot of categorical constructions, which often include commuting diagrams. With a judicious choice of functors, a lot of these commutativity conditions may be transformed into naturality conditions. We’ll see examples of that when we get to limits, colimits, and adjunctions.</p><p>Finally, natural transformations may be used to define isomorphisms of functors. Saying that two functors are naturally isomorphic is almost like saying they are the same. <em>Natural isomorphism</em> is defined as a natural transformation whose components are all isomorphisms (invertible morphisms).</p><h2>Polymorphic Functions</h2><p>We talked about the role of functors (or, more specifically, endofunctors) in programming. They correspond to type constructors that map types to types. They also map functions to functions, and this mapping is implemented by a higher order function <code>fmap</code> (or <code>transform</code>, <code>then</code>, and the like in C++).</p><p>To construct a natural transformation we start with an object, here a type, <code>a</code>. One functor, <code>F</code>, maps it to the type <code>F a</code>. Another functor, <code>G</code>, maps it to <code>G a</code>. The component of a natural transformation <code>alpha</code> at <code>a</code> is a function from <code>F a</code> to <code>G a</code>. In pseudo-Haskell:</p><pre>alpha<sub>a</sub> :: F a -&gt; G a</pre><p>A natural transformation is a polymorphic function that is defined for all types <code>a</code>:</p><pre>alpha :: forall a . F a -&gt; G a</pre><p>The <code>forall a</code> is optional in Haskell (and in fact requires turning on the language extension <code>ExplicitForAll</code>). Normally, you would write it like this:</p><pre>alpha :: F a -&gt; G a</pre><p>Keep in mind that it’s really a family of functions parameterized by <code>a</code>. This is another example of the terseness of the Haskell syntax. A similar construct in C++ would be slightly more verbose:</p><pre>template&lt;class A&gt; G&lt;A&gt; alpha(F&lt;A&gt;);</pre><p>There is a more profound difference between Haskell’s polymorphic functions and C++ generic functions, and it’s reflected in the way these functions are implemented and type-checked. In Haskell, a polymorphic function must be defined uniformly for all types. One formula must work across all types. This is called <em>parametric polymorphism</em>.</p><p>C++, on the other hand, supports by default&nbsp;<em>ad hoc polymorphism</em>, which means that a template doesn’t have to be well-defined for all types. Whether a template will work for a given type is decided at instantiation time, where a concrete type is substituted for the type parameter. Type checking is deferred, which unfortunately often leads to incomprehensible error messages.</p><p>In C++, there is also a mechanism for function overloading and template specialization, which allows different definitions of the same function for different types. In Haskell this functionality is provided by type classes and type families.</p><p>Haskell’s parametric polymorphism has an unexpected consequence: any polymorphic function of the type:</p><pre>alpha :: F a -&gt; G a</pre><p>where <code>F</code> and <code>G</code> are functors, automatically satisfies the naturality condition. Here it is in categorical notation (<code>f</code> is a function <code>f::a-&gt;b</code>):</p><pre>G f ∘ α<sub>a</sub> = α<sub>b</sub> ∘ F f</pre><p>In Haskell, the action of a functor <code>G</code> on a morphism <code>f</code> is implemented using <code>fmap</code>. I’ll first write it in pseudo-Haskell, with explicit type annotations:</p><pre>fmap<sub>G</sub> f . alpha<sub>a</sub> = alpha<sub>b</sub> . fmap<sub>F</sub> f</pre><p>Because of type inference, these annotations are not necessary, and the following equation holds:</p><pre>fmap f . alpha = alpha . fmap f</pre><p>This is still not real Haskell — function equality is not expressible in code — but it’s an identity that can be used by the programmer in equational reasoning; or by the compiler, to implement optimizations.</p><p>The reason why the naturality condition is automatic in Haskell has to do with “theorems for free.” Parametric polymorphism, which is used to define natural transformations in Haskell, imposes very strong limitations on the implementation — one formula for all types. These limitations translate into equational theorems about such functions. In the case of functions that transform functors, free theorems are the naturality conditions. [You may read more about free theorems in my blog <a title="Parametricity: Money for Nothing and Theorems for Free" href="https://bartoszmilewski.com/2014/09/22/parametricity-money-for-nothing-and-theorems-for-free/" target="_blank">Parametricity: Money for Nothing and Theorems for Free</a>.]</p><p>One way of thinking about functors in Haskell that I mentioned earlier is to consider them generalized containers. We can continue this analogy and consider natural transformations to be recipes for repackaging the contents of one container into another container. We are not touching the items themselves: we don’t modify them, and we don’t create new ones. We are just copying (some of) them, sometimes multiple times, into a new container.</p><p>The naturality condition becomes the statement that it doesn’t matter whether we modify the items first, through the application of <code>fmap</code>, and repackage later; or repackage first, and then modify the items in the new container, with its own implementation of <code>fmap</code>. These two actions, repackaging and <code>fmap</code>ping, are orthogonal. “One moves the eggs, the other boils them.”</p><p>Let’s see a few examples of natural transformations in Haskell. The first is between the list functor, and the <code>Maybe</code> functor. It returns the head of the list, but only if the list is non-empty:</p><pre>safeHead :: [a] -&gt; Maybe a
 safeHead [] = Nothing
 safeHead (x:xs) = Just x</pre><p>It’s a function polymorphic in <code>a</code>. It works for any type <code>a</code>, with no limitations, so it is an example of parametric polymorphism. Therefore it is a natural transformation between the two functors. But just to convince ourselves, let’s verify the naturality condition.</p><pre>fmap f . safeHead = safeHead . fmap f</pre><p>We have two cases to consider; an empty list:</p><pre>fmap f (safeHead []) = fmap f Nothing = Nothing</pre><pre>safeHead (fmap f []) = safeHead [] = Nothing</pre><p>and a non-empty list:</p><pre>fmap f (safeHead (x:xs)) = fmap f (Just x) = Just (f x)</pre><pre>safeHead (fmap f (x:xs)) = safeHead (f x : fmap f xs) = Just (f x)</pre><p>I used the implementation of <code>fmap</code> for lists:</p><pre>fmap f [] = []
 fmap f (x:xs) = f x : fmap f xs</pre><p>and for <code>Maybe</code>:</p><pre>fmap f Nothing = Nothing
 fmap f (Just x) = Just (f x)</pre><p>An interesting case is when one of the functors is the trivial <code>Const</code> functor. A natural transformation from or to a <code>Const</code> functor looks just like a function that’s either polymorphic in its return type or in its argument type.</p><p>For instance, <code>length</code> can be thought of as a natural transformation from the list functor to the <code>Const Int</code> functor:</p><pre>length :: [a] -&gt; Const Int a
 length [] = Const 0
 length (x:xs) = Const (1 + unConst (length xs))</pre><p>Here, <code>unConst</code> is used to peel off the <code>Const</code> constructor:</p><pre>unConst :: Const c a -&gt; c
 unConst (Const x) = x</pre><p>Of course, in practice <code>length</code> is defined as:</p><pre>length :: [a] -&gt; Int</pre><p>which effectively hides the fact that it’s a natural transformation.</p><p>Finding a parametrically polymorphic function <em>from</em> a <code>Const</code> functor is a little harder, since it would require the creation of a value from nothing. The best we can do is:</p><pre>scam :: Const Int a -&gt; Maybe a
 scam (Const x) = Nothing</pre><p>Another common functor that we’ve seen already, and which will play an important role in the Yoneda lemma, is the <code>Reader</code> functor. I will rewrite its definition as a <code>newtype</code>:</p><pre>newtype Reader e a = Reader (e -&gt; a)</pre><p>It is parameterized by two types, but is (covariantly) functorial only in the second one:</p><pre>instance Functor (Reader e) where
    fmap f (Reader g) = Reader (\x -&gt; f (g x))</pre><p>For every type <code>e</code>, you can define a family of natural transformations from <code>Reader e</code> to any other functor <code>f</code>. We’ll see later that the members of this family are always in one to one correspondence with the elements of <code>f e</code> (the <a href="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/" target="_blank">Yoneda lemma</a>).</p><p>For instance, consider the somewhat trivial unit type <code>()</code> with one element <code>()</code>. The functor <code>Reader ()</code> takes any type <code>a</code> and maps it into a function type <code>()-&gt;a</code>. These are just all the functions that pick a single element from the set <code>a</code>. There are as many of these as there are elements in <code>a</code>. Now let’s consider natural transformations from this functor to the <code>Maybe</code> functor:</p><pre>alpha :: Reader () a -&gt; Maybe a</pre><p>There are only two of these, <code>dumb</code> and <code>obvious</code>:</p><pre>dumb (Reader _) = Nothing</pre><p>and</p><pre>obvious (Reader g) = Just (g ())</pre><p>(The only thing you can do with <code>g</code> is to apply it to the unit value <code>()</code>.)</p><p>And, indeed, as predicted by the Yoneda lemma, these correspond to the two elements of the <code>Maybe ()</code> type, which are <code>Nothing</code> and <code>Just ()</code>. We’ll come back to the Yoneda lemma later — this was just a little teaser.</p><h2>Beyond Naturality</h2><p>A parametrically polymorphic function between two functors (including the edge case of the <code>Const</code> functor) is always a natural transformation. Since all standard algebraic data types are functors, any polymorphic function between such types is a natural transformation.</p><p>We also have function types at our disposal, and those are functorial in their return type. We can use them to build functors (like the <code>Reader</code> functor) and define natural transformations that are higher-order functions.</p><p>However, function types are not covariant in the argument type. They are <em>contravariant</em>. Of course contravariant functors are equivalent to covariant functors from the opposite category. Polymorphic functions between two contravariant functors are still natural transformations in the categorical sense, except that they work on functors from the opposite category to Haskell types.</p><p>You might remember the example of a contravariant functor we’ve looked at before:</p><pre>newtype Op r a = Op (a -&gt; r)</pre><p>This functor is contravariant in <code>a</code>:</p><pre>instance Contravariant (Op r) where
    contramap f (Op g) = Op (g . f)</pre><p>We can write a polymorphic function from, say, <code>Op Bool</code> to <code>Op String</code>:</p><pre>predToStr (Op f) = Op (\x -&gt; if f x then "T" else "F")</pre><p>But since the two functors are not covariant, this is not a natural transformation in <b>Hask</b>. However, because they are both contravariant, they satisfy the “opposite” naturality condition:</p><pre>contramap f . predToStr = predToStr . contramap f</pre><p>Notice that the function <code>f</code> must go in the opposite direction than what you’d use with <code>fmap</code>, because of the signature of <code>contramap</code>:</p><pre>contramap :: (b -&gt; a) -&gt; (Op Bool a -&gt; Op Bool b)</pre><p>Are there any type constructors that are not functors, whether covariant or contravariant? Here’s one example:</p><pre>a -&gt; a</pre><p>This is not a functor because the same type <code>a</code> is used both in the negative (contravariant) and positive (covariant) position. You can’t implement <code>fmap</code> or <code>contramap</code> for this type. Therefore a function of the signature:</p><pre>(a -&gt; a) -&gt; f a</pre><p>where <code>f</code> is an arbitrary functor, cannot be a natural transformation. Interestingly, there is a generalization of natural transformations, called dinatural transformations, that deals with such cases. We’ll get to them when we discuss ends.</p><h2>Functor Category</h2><p>Now that we have mappings between functors — natural transformations — it’s only natural to ask the question whether functors form a category. And indeed they do! There is one category of functors for each pair of categories, C and D. Objects in this category are functors from C to D, and morphisms are natural transformations between those functors.</p><p>We have to define composition of two natural transformations, but that’s quite easy. The components of natural transformations are morphisms, and we know how to compose morphisms.</p><p>Indeed, let’s take a natural transformation α from functor F to G. Its component at object <code>a</code> is some morphism:</p><pre>α<sub>a</sub> :: F a -&gt; G a</pre><p>We’d like to compose α with β, which is a natural transformation from functor G to H. The component of β at <code>a</code> is a morphism:</p><pre>β<sub>a</sub> :: G a -&gt; H a</pre><p>These morphisms are composable and their composition is another morphism:</p><pre>β<sub>a</sub> ∘ α<sub>a</sub> :: F a -&gt; H a</pre><p>We will use this morphism as the component of the natural transformation β ⋅ α — the composition of two natural transformations β after α:</p><pre>(β ⋅ α)<sub>a</sub> = β<sub>a</sub> ∘ α<sub>a</sub></pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg"><img data-attachment-id="4351" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/5_vertical/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg" data-orig-size="640,433" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="5_Vertical" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=300&amp;h=203" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=510" class="alignnone wp-image-4351 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=300&amp;h=203" alt="5_Vertical" width="300" height="203" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=300&amp;h=203 300w, https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=600&amp;h=406 600w, https://bartoszmilewski.files.wordpress.com/2015/04/5_vertical.jpg?w=150&amp;h=101 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>One (long) look at a diagram convinces us that the result of this composition is indeed a natural transformation from F to H:</p><pre>H f ∘ (β ⋅ α)<sub>a</sub> = (β ⋅ α)<sub>b</sub> ∘ F f</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg"><img data-attachment-id="4352" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/6_verticalnaturality/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg" data-orig-size="640,620" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="6_VerticalNaturality" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=300&amp;h=291" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=510" class="alignnone wp-image-4352 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=300&amp;h=291" alt="6_VerticalNaturality" width="300" height="291" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=300&amp;h=291 300w, https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=600&amp;h=582 600w, https://bartoszmilewski.files.wordpress.com/2015/04/6_verticalnaturality.jpg?w=150&amp;h=145 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Composition of natural transformations is associative, because their components, which are regular morphisms, are associative with respect to their composition.</p><p>Finally, for each functor F there is an identity natural transformation 1<sub>F</sub> whose components are the identity morphisms:</p><pre>id<sub>F a</sub> :: F a -&gt; F a</pre><p>So, indeed, functors form a category.</p><p>A word about notation. Following Saunders Mac Lane I use the dot for the kind of natural transformation composition I have just described. The problem is that there are two ways of composing natural transformations. This one is called the vertical composition, because the functors are usually stacked up vertically in the diagrams that describe it. Vertical composition is important in defining the functor category. I’ll explain horizontal composition shortly.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg"><img data-attachment-id="4353" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/6a_vertical/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg" data-orig-size="623,412" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976286&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="6a_Vertical" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=220&amp;h=145" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=510" class="alignnone wp-image-4353 " src="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=220&amp;h=145" alt="6a_Vertical" width="220" height="145" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=220&amp;h=145 220w, https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=440&amp;h=290 440w, https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=150&amp;h=99 150w, https://bartoszmilewski.files.wordpress.com/2015/04/6a_vertical.jpg?w=300&amp;h=198 300w" sizes="(max-width: 220px) 100vw, 220px"></a></p><p>The functor category between categories C and D is written as <code>Fun(C, D)</code>, or <code>[C, D]</code>, or sometimes as <code>D<sup>C</sup></code>. This last notation suggests that a functor category itself might be considered a function object (an exponential) in some other category. Is this indeed the case?</p><p>Let’s have a look at the hierarchy of abstractions that we’ve been building so far. We started with a category, which is a collection of objects and morphisms. Categories themselves (or, strictly speaking <em>small</em> categories, whose objects form sets) are themselves objects in a higher-level category <b>Cat</b>. Morphisms in that category are functors. A Hom-set in <b>Cat</b> is a set of functors. For instance Cat(C, D) is a set of functors between two categories C and D.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg"><img data-attachment-id="4354" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/7_cathomset/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg" data-orig-size="640,629" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976286&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="7_CatHomSet" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=215&amp;h=211" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=510" class="alignnone wp-image-4354 " src="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=215&amp;h=211" alt="7_CatHomSet" width="215" height="211" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=215&amp;h=211 215w, https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=430&amp;h=422 430w, https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=150&amp;h=147 150w, https://bartoszmilewski.files.wordpress.com/2015/04/7_cathomset.jpg?w=300&amp;h=295 300w" sizes="(max-width: 215px) 100vw, 215px"></a></p><p>A functor category [C, D] is also a set of functors between two categories (plus natural transformations as morphisms). Its objects are the same as the members of Cat(C, D). Moreover, a functor category, being a category, must itself be an object of <b>Cat</b> (it so happens that the functor category between two small categories is itself small). We have a relationship between a Hom-set in a category and an object in the same category. The situation is exactly like the exponential object that we’ve seen in the last section. Let’s see how we can construct the latter in <b>Cat</b>.</p><p>As you may remember, in order to construct an exponential, we need to first define a product. In <b>Cat</b>, this turns out to be relatively easy, because small categories are <em>sets</em> of objects, and we know how to define cartesian products of sets. So an object in a product category C × D is just a pair of objects, <code>(c, d)</code>, one from C and one from D. Similarly, a morphism between two such pairs, <code>(c, d)</code> and <code>(c', d')</code>, is a pair of morphisms, <code>(f, g)</code>, where <code>f :: c -&gt; c'</code> and <code>g :: d -&gt; d'</code>. These pairs of morphisms compose component-wise, and there is always an identity pair that is just a pair of identity morphisms. To make the long story short, <b>Cat</b> is a full-blown cartesian closed category in which there is an exponential object D<sup>C</sup> for any pair of categories. And by “object” in <b>Cat</b> I mean a category, so D<sup>C</sup> is a category, which we can identify with the functor category between C and D.</p><h2>2-Categories</h2><p>With that out of the way, let’s have a closer look at <b>Cat</b>. By definition, any Hom-set in <b>Cat</b> is a set of functors. But, as we have seen, functors between two objects have a richer structure than just a set. They form a category, with natural transformations acting as morphisms. Since functors are considered morphisms in <b>Cat</b>, natural transformations are morphisms between morphisms.</p><p>This richer structure is an example of a 2-category, a generalization of a category where, besides objects and morphisms (which might be called 1-morphisms in this context), there are also 2-morphisms, which are morphisms between morphisms.</p><p>In the case of <b>Cat</b> seen as a 2-category we have:</p><ul>
 <li>Objects: (Small) categories</li>
 <li>1-morphisms: Functors between categories</li>
 <li>2-morphisms: Natural transformations between functors.</li>
 </ul><p>Instead of a Hom-set between two categories C and D, we have a Hom-category — the functor category D<sup>C</sup>. We have regular functor composition: a functor F from D<sup>C</sup> composes with a functor G from E<sup>D</sup> to give G ∘ F from E<sup>C</sup>. But we also have composition inside each Hom-category — vertical composition of natural transformations, or 2-morphisms, between functors.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg"><img data-attachment-id="4355" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/8_cat-2-cat/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg" data-orig-size="640,510" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976286&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="8_Cat-2-Cat" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=216&amp;h=172" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=510" class="alignnone wp-image-4355 " src="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=216&amp;h=172" alt="8_Cat-2-Cat" width="216" height="172" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=216&amp;h=172 216w, https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=432&amp;h=344 432w, https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=150&amp;h=120 150w, https://bartoszmilewski.files.wordpress.com/2015/04/8_cat-2-cat.jpg?w=300&amp;h=239 300w" sizes="(max-width: 216px) 100vw, 216px"></a></p><p>With two kinds of composition in a 2-category, the question arises: How do they interact with each other?</p><p>Let’s pick two functors, or 1-morphisms, in <b>Cat</b>:</p><pre>F :: C -&gt; D
 G :: D -&gt; E</pre><p>and their composition:</p><pre>G ∘ F :: C -&gt; E</pre><p>Suppose we have two natural transformations, α and β, that act, respectively, on functors F and G:</p><pre>α :: F -&gt; F'
 β :: G -&gt; G'</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg"><img data-attachment-id="4357" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/10_horizontal/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg" data-orig-size="640,354" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976286&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="10_Horizontal" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=300&amp;h=166" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=510" class="alignnone wp-image-4357 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=300&amp;h=166" alt="10_Horizontal" width="300" height="166" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=300&amp;h=166 300w, https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=600&amp;h=332 600w, https://bartoszmilewski.files.wordpress.com/2015/04/10_horizontal.jpg?w=150&amp;h=83 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that we cannot apply vertical composition to this pair, because the target of α is different from the source of β. In fact they are members of two different functor categories: D <sup>C</sup> and E <sup>D</sup>. We can, however, apply composition to the functors F’ and G’, because the target of F’ is the source of G’ — it’s the category D. What’s the relation between the functors G’∘ F’ and G ∘ F?</p><p>Having α and β at our disposal, can we define a natural transformation from G ∘ F to G’∘ F’? Let me sketch the construction.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg"><img data-attachment-id="4356" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/9_horizontal/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg" data-orig-size="640,464" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976286&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="9_Horizontal" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=369&amp;h=268" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=510" class="alignnone wp-image-4356 " src="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=369&amp;h=268" alt="9_Horizontal" width="369" height="268" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=369&amp;h=268 369w, https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=150&amp;h=109 150w, https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg?w=300&amp;h=218 300w, https://bartoszmilewski.files.wordpress.com/2015/04/9_horizontal.jpg 640w" sizes="(max-width: 369px) 100vw, 369px"></a></p><p>As usual, we start with an object <code>a</code> in C. Its image splits into two objects in D: <code>F a</code> and <code>F'a</code>. There is also a morphism, a component of α, connecting these two objects:</p><pre>α<sub>a</sub> :: F a -&gt; F'a</pre><p>When going from D to E, these two objects split further into four objects:</p><pre>G (F a), G'(F a), G (F'a), G'(F'a)</pre><p>We also have four morphisms forming a square. Two of these morphisms are the components of the natural transformation β:</p><pre>β<sub>F a</sub> :: G (F a) -&gt; G'(F a)
 β<sub>F'a</sub> :: G (F'a) -&gt; G'(F'a)</pre><p>The other two are the images of α<sub>a</sub> under the two functors (functors map morphisms):</p><pre>G α<sub>a</sub> :: G (F a) -&gt; G (F'a)
 G'α<sub>a</sub> :: G'(F a) -&gt; G'(F'a)</pre><p>That’s a lot of morphisms. Our goal is to find a morphism that goes from <code>G (F a)</code> to <code>G'(F'a)</code>, a candidate for the component of a natural transformation connecting the two functors G ∘ F and G’∘ F’. In fact there’s not one but two paths we can take from <code>G (F a)</code> to <code>G'(F'a)</code>:</p><pre>G'α<sub>a</sub> ∘ β<sub>F a</sub>
 β<sub>F'a</sub> ∘ G α<sub>a</sub></pre><p>Luckily for us, they are equal, because the square we have formed turns out to be the naturality square for β.</p><p>We have just defined a component of a natural transformation from G ∘ F to G’∘ F’. The proof of naturality for this transformation is pretty straightforward, provided you have enough patience.</p><p>We call this natural transformation the <em>horizontal composition</em> of α and β:</p><pre>β ∘ α :: G ∘ F -&gt; G'∘ F'</pre><p>Again, following Mac Lane I use the small circle for horizontal composition, although you may also encounter star in its place.</p><p>Here’s a categorical rule of thumb: Every time you have composition, you should look for a category. We have vertical composition of natural transformations, and it’s part of the functor category. But what about the horizontal composition? What category does that live in?</p><p>The way to figure this out is to look at <b>Cat</b> sideways. Look at natural transformations not as arrows between functors but as arrows between categories. A natural transformation sits between two categories, the ones that are connected by the functors it transforms. We can think of it as connecting these two categories.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg"><img data-attachment-id="4375" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/sideways/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg" data-orig-size="640,185" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1428058196&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Sideways" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=300&amp;h=87" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=510" class="alignnone size-medium wp-image-4375" src="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=300&amp;h=87" alt="Sideways" width="300" height="87" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=300&amp;h=87 300w, https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=600&amp;h=174 600w, https://bartoszmilewski.files.wordpress.com/2015/04/sideways.jpg?w=150&amp;h=43 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Let’s focus on two objects of <b>Cat</b> — categories C and D. There is a set of natural transformations that go between functors that connect C to D. These natural transformations are our new arrows from C to D. By the same token, there are natural transformations going between functors that connect D to E, which we can treat as new arrows going from D to E. Horizontal composition is the composition of these arrows.</p><p>We also have an identity arrow going from C to C. It’s the identity natural transformation that maps the identity functor on C to itself. Notice that the identity for horizontal composition is also the identity for vertical composition, but not vice versa.</p><p>Finally, the two compositions satisfy the interchange law:</p><pre>(β' ⋅ α') ∘ (β ⋅ α) = (β' ∘ β) ⋅ (α' ∘ α)</pre><p>I will quote Saunders Mac Lane here: The reader may enjoy writing down the evident diagrams needed to prove this fact.</p><p>There is one more piece of notation that might come in handy in the future. In this new sideways interpretation of <b>Cat</b> there are two ways of getting from object to object: using a functor or using a natural transformation. We can, however, re-interpret the functor arrow as a special kind of natural transformation: the identity natural transformation acting on this functor. So you’ll often see this notation:</p><pre>F ∘ α</pre><p>where F is a functor from D to E, and α is a natural transformation between two functors going from C to D. Since you can’t compose a functor with a natural transformation, this is interpreted as a horizontal composition of the identity natural transformation 1<sub>F</sub> after α.</p><p>Similarly:</p><pre>α ∘ F</pre><p>is a horizontal composition of α after 1<sub>F</sub>.</p><h2>Conclusion</h2><p>This concludes the first part of the book. We’ve learned the basic vocabulary of category theory. You may think of objects and categories as nouns; and morphisms, functors, and natural transformations as verbs. Morphisms connect objects, functors connect categories, natural transformations connect functors.</p><p>But we’ve also seen that, what appears as an action at one level of abstraction, becomes an object at the next level. A set of morphisms turns into a function object. As an object, it can be a source or a target of another morphism. That’s the idea behind higher order functions.</p><p>A functor maps objects to objects, so we can use it as a type constructor, or a parametric type. A functor also maps morphisms, so it is a higher order function — <code>fmap</code>. There are some simple functors, like <code>Const</code>, product, and coproduct, that can be used to generate a large variety of algebraic data types. Function types are also functorial, both covariant and contravariant, and can be used to extend algebraic data types.</p><p>Functors may be looked upon as objects in the functor category. As such, they become sources and targets of morphisms: natural transformations. A natural transformation is a special type of polymorphic function.</p><h2>Challenges</h2><ol>
 <li>Define a natural transformation from the <code>Maybe</code> functor to the list functor. Prove the naturality condition for it.</li>
 <li>Define at least two different natural transformations between <code>Reader ()</code> and the list functor. How many different lists of <code>()</code> are there?</li>
 <li>Continue the previous exercise with <code>Reader Bool</code> and <code>Maybe</code>.</li>
 <li>Show that horizontal composition of natural transformation satisfies the naturality condition (hint: use components). It’s a good exercise in diagram chasing.</li>
 <li>Write a short essay about how you may enjoy writing down the evident diagrams needed to prove the interchange law.</li>
 <li>Create a few test cases for the opposite naturality condition of transformations between different <code>Op</code> functors. Here’s one choice:
 <pre>op :: Op Bool Int
 op = Op (\x -&gt; x &gt; 0)</pre>
 <p>and</p>
 <pre>f :: String -&gt; Int
 f x = read x</pre>
 </li>
 </ol><p>Next: <a title="Category Theory and Declarative Programming" href="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/">Declarative Programming</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408247497" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Category Theory and Declarative&nbsp;Programming		</h2><h2>Introduction to Part II</h2><p>In the first part of the book I argued that both category theory and programming are about composability. In programming, you keep decomposing a problem until you reach the level of detail that you can deal with, solve each subproblem in turn, and re-compose the solutions bottom-up. There are, roughly speaking, two ways of doing it: by telling the computer what to do, or by telling it how to do it. One is called declarative and the other imperative.</p><p>You can see this even at the most basic level. Composition itself may be defined declaratively; as in, <code>h</code> is a composite of <code>g</code> after <code>f</code>:</p><pre>h = g . f</pre><p>or imperatively; as in, call <code>f</code> first, remember the result of that call, then call <code>g</code> with the result:</p><pre>h x = let y = f x
      in g y</pre><p>The imperative version of a program is usually described as a sequence of actions ordered in time. In particular, the call to <code>g</code> cannot happen before the execution of <code>f</code> completes. At least, that’s the conceptual picture — in a lazy language, with <em>call-by-need</em> argument passing, the actual execution may proceed differently.</p><p>In fact, depending on the cleverness of the compiler, there may be little or no difference between how declarative and imperative code is executed. But the two methodologies differ, sometimes drastically, in the way we approach problem solving and in the maintainability and testability of the resulting code.</p><p>The main question is: when faced with a problem, do we always have the choice between a declarative and imperative approaches to solving it? And, if there is a declarative solution, can it always be translated into computer code? The answer to this question is far from obvious and, if we could find it, we would probably revolutionize our understanding of the universe.</p><p>Let me elaborate. There is a similar duality in physics, which either points at some deep underlying principle, or tells us something about how our minds work. Richard Feynman mentions this duality as an inspiration in his own work on quantum electrodynamics.</p><p>There are two forms of expressing most laws of physics. One uses local, or infinitesimal, considerations. We look at the state of a system around a small neighborhood, and predict how it will evolve within the next instant of time. This is usually expressed using differential equations that have to be integrated, or summed up, over a period of time.</p><p>Notice how this approach resembles imperative thinking: we reach the final solution by following a sequence of small steps, each depending on the result of the previous one. In fact, computer simulations of physical systems are routinely implemented by turning differential equations into difference equations and iterating them. This is how spaceships are animated in the asteroids game. At each time step, the position of a spaceship is changed by adding a small increment, which is calculated by multiplying its velocity by the time delta. The velocity, in turn, is changed by a small increment proportional to acceleration, which is given by force divided by mass.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png"><img data-attachment-id="4432" data-permalink="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/asteroids/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png" data-orig-size="320,240" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Asteroids" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png?w=300&amp;h=225" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png?w=320" class="alignnone size-medium wp-image-4432" src="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png?w=300&amp;h=225" alt="Asteroids" width="300" height="225" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png?w=300&amp;h=225 300w, https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png?w=150&amp;h=113 150w, https://bartoszmilewski.files.wordpress.com/2015/04/asteroids.png 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>These are the direct encodings of the differential equations corresponding to Newton’s laws of motion:</p><pre>F = m dv/dt
 v = dx/dt</pre><p>Similar methods may be applied to more complex problems, like the propagation of electromagnetic fields using Maxwell’s equations, or even the behavior of quarks and gluons inside a proton using lattice QCD (quantum chromodynamics).</p><p>This local thinking combined with discretization of space and time that is encouraged by the use of digital computers found its extreme expression in the heroic attempt by Stephen Wolfram to reduce the complexity of the whole universe to a system of cellular automata.</p><p>The other approach is global. We look at the initial and the final state of the system, and calculate a trajectory that connects them by minimizing a certain functional. The simplest example is the Fermat’s principle of least time. It states that light rays propagate along paths that minimize their flight time. In particular, in the absence of reflecting or refracting objects, a light ray from point A to point B will take the shortest path, which is a straight line. But light propagates slower in dense (transparent) materials, like water or glass. So if you pick the starting point in the air, and the ending point under water, it’s more advantageous for light to travel longer in the air and then take a shortcut through water. The path of minimum time makes the ray refract at the boundary of air and water, resulting in Snell’s law of refraction:</p><pre>sin θ<sub>1</sub> / sin θ<sub>2</sub> =  v<sub>1</sub> / v<sub>2</sub></pre><p>where <code>v<sub>1</sub></code> is the speed of light in the air and <code>v<sub>2</sub></code> is the speed of light in the water.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg"><img data-attachment-id="4437" data-permalink="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/snell/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg" data-orig-size="477,640" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1429013610&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Snell" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=224&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=477" class="alignnone size-medium wp-image-4437" src="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=224&amp;h=300" alt="Snell" width="224" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=224&amp;h=300 224w, https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=448&amp;h=600 448w, https://bartoszmilewski.files.wordpress.com/2015/04/snell.jpg?w=112&amp;h=150 112w" sizes="(max-width: 224px) 100vw, 224px"></a></p><p>All of classical mechanics can be derived from the principle of least action. The action can be calculated for any trajectory by integrating the Lagrangian, which is the difference between kinetic and potential energy (notice: it’s the difference, not the sum — the sum would be the total energy). When you fire a mortar to hit a given target, the projectile will first go up, where the potential energy due to gravity is higher, and spend some time  there racking up negative contribution to the action. It will also slow down at the top of the parabola, to minimize kinetic energy. Then it will speed up to go quickly through the area of low potential energy.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg"><img data-attachment-id="4438" data-permalink="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/mortar/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg" data-orig-size="640,338" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1429013610&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Mortar" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=300&amp;h=158" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=510" src="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=300&amp;h=158" alt="Mortar" width="300" height="158" class="alignnone size-medium wp-image-4438" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=300&amp;h=158 300w, https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=598&amp;h=316 598w, https://bartoszmilewski.files.wordpress.com/2015/04/mortar.jpg?w=150&amp;h=79 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Feynman’s greatest contribution was to realize that the principle of least action can be generalized to quantum mechanics. There, again, the problem is formulated in terms of initial state and final state. The Feynman path integral between those states is used to calculate the probability of transition.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg"><img data-attachment-id="4439" data-permalink="https://bartoszmilewski.com/2015/04/15/category-theory-and-declarative-programming/feynman/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg" data-orig-size="640,480" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1429013610&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Feynman" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=300&amp;h=225" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=510" src="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=300&amp;h=225" alt="Feynman" width="300" height="225" class="alignnone size-medium wp-image-4439" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=300&amp;h=225 300w, https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=600&amp;h=450 600w, https://bartoszmilewski.files.wordpress.com/2015/04/feynman.jpg?w=150&amp;h=113 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>The point is that there is a curious unexplained duality in the way we can describe the laws of physics. We can use the local picture, in which things happen sequentially and in small increments. Or we can use the global picture, where we declare the initial and final conditions, and everything in between just follows.</p><p>The global approach can be also used in programming, for instance when implementing ray tracing. We declare the position of the eye and the positions of light sources, and figure out the paths that the light rays may take to connect them. We don’t explicitly minimize the time of flight for each ray, but we do use Snell’s law and the geometry of reflection to the same effect.</p><p>The biggest difference between the local and the global approach is in their treatment of space and, more importantly, time. The local approach embraces the immediate gratification of here and now, whereas the global approach takes a long-term static view, as if the future had been preordained, and we were only analyzing the properties of some eternal universe.</p><p>Nowhere is it better illustrated than in the Functional Reactive Programming approach to user interaction. Instead of writing separate handlers for every possible user action, all having access to some shared mutable state, FRP treats external events as an infinite list, and applies a series of transformations to it. Conceptually, the list of all our future actions is there, available as the input data to our program. From a program’s perspective there’s no difference between the list of digits of π, a list of pseudo-random numbers, or a list of mouse positions coming through computer hardware. In each case, if you want to get the nth item, you have to first go through the first n-1 items. When applied to temporal events, we call this property <em>causality</em>.</p><p>So what does it have to do with category theory? I will argue that category theory encourages a global approach and therefore supports declarative programming. First of all, unlike calculus, it has no built-in notion of distance, or neighborhood, or time. All we have is abstract objects and abstract connections between them. If you can get from A to B through a series of steps, you can also get there in one leap. Moreover, the major tool of category theory is the universal construction, which is the epitome of a global approach. We’ve seen it in action, for instance, in the definition of the categorical product. It was done by specifying its properties — a very declarative approach. It’s an object equipped with two projections, and it’s the best such object — it optimizes a certain property: the property of factorizing the projections of other such objects. </p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg"><img data-attachment-id="3772" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg" data-orig-size="541,440" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=510" src="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244" alt="ProductRanking" width="300" height="244" class="alignnone size-medium wp-image-3772" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244 300w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=150&amp;h=122 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg 541w" sizes="(max-width: 300px) 100vw, 300px"></a><br>
 Compare this with Fermat’s principle of minimum time, or the principle of least action.</p><p>Conversely, contrast this with the traditional definition of a cartesian product, which is much more imperative. You describe how to create an element of the product by picking one element from one set and another element from another set. It’s a recipe for creating a pair. And there’s another for disassembling a pair.</p><p>In almost every programming language, including functional languages like Haskell, product types, coproduct types, and function types are built in, rather than being defined by universal constructions; although there have been attempts at creating categorical programming languages (see, e.g., <a href="http://synrc.com/publications/cat/Category%20Theory/Type%20Theory/Hagino%20T.%20A%20Categorical%20Programming%20Language.pdf" target="_blank">Tatsuya Hagino’s thesis</a>). </p><p>Whether used directly or not, categorical definitions justify pre-existing programming constructs, and give rise to new ones. Most importantly, category theory provides a meta-language for reasoning about computer programs at a declarative level. It also encourages reasoning about problem specification before it is cast into code.</p><p>Next <a href="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/">Limits and Colimits</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408259908" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Limits and Colimits		</h2><p>It seems like in category theory everything is related to everything and everything can be viewed from many angles. Take for instance the universal construction of the <a title="Products and Coproducts" href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" target="_blank">product</a>. Now that we know more about <a title="Functors" href="https://bartoszmilewski.com/2015/01/20/functors/" target="_blank">functors</a> and <a title="Natural Transformations" href="https://bartoszmilewski.com/2015/04/07/natural-transformations/" target="_blank">natural transformations</a>, can we simplify and, possibly, generalize it? Let us try.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg"><img data-attachment-id="3767" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productpattern/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg" data-orig-size="417,276" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductPattern" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=417" class="alignnone wp-image-3767 size-thumbnail" src="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=150&amp;h=99" alt="ProductPattern" width="150" height="99" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=150&amp;h=99 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productpattern.jpg?w=300&amp;h=198 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>The construction of a product starts with the selection of two objects <code>a</code> and <code>b</code>, whose product we want to construct. But what does it mean to <em>select objects</em>? Can we rephrase this action in more categorical terms? Two objects form a pattern — a very simple pattern. We can abstract this pattern into a category — a very simple category, but a category nevertheless. It’s a category that we’ll call <strong>2</strong>. It contains just two objects, 1 and 2, and no morphisms other than the two obligatory identities. Now we can rephrase the selection of two objects in <em>C</em> as the act of defining a functor D from the category <strong>2</strong> to <em>C</em>. A functor maps objects to objects, so its image is just two objects (or it could be one, if the functor collapses objects, which is fine too). It also maps morphisms — in this case it simply maps identity morphisms to identity morphisms.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg"><img data-attachment-id="4482" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/two/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg" data-orig-size="320,235" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430233998&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Two" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg?w=300&amp;h=220" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg?w=320" class="alignnone wp-image-4482 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg?w=300&amp;h=220" alt="Two" width="300" height="220" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg?w=300&amp;h=220 300w, https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg?w=150&amp;h=110 150w, https://bartoszmilewski.files.wordpress.com/2015/04/two.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>What’s great about this approach is that it builds on categorical notions, eschewing the imprecise descriptions like “selecting objects,” taken straight from the hunter-gatherer lexicon of our ancestors. And, incidentally, it is also easily generalized, because nothing can stop us from using categories more complex than <strong>2</strong> to define our patterns.</p><p>But let’s continue. The next step in the definition of a product is the selection of the candidate object <code>c</code>. Here again, we could rephrase the selection in terms of a functor from a singleton category. And indeed, if we were using Kan extensions, that would be the right thing to do. But since we are not ready for Kan extensions yet, there is another trick we can use: a constant functor Δ from the same category <strong>2</strong> to <em>C</em>. The selection of <code>c</code> in <em>C</em> can be done with Δ<sub>c</sub>. Remember, Δ<sub>c</sub> maps all objects into <code>c</code> and all morphisms into <code>id<sub>c</sub></code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg"><img data-attachment-id="4483" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/twodelta/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg" data-orig-size="320,226" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430233998&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="TwoDelta" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg?w=300&amp;h=212" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg?w=320" class="alignnone size-medium wp-image-4483" src="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg?w=300&amp;h=212" alt="TwoDelta" width="300" height="212" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg?w=300&amp;h=212 300w, https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg?w=150&amp;h=106 150w, https://bartoszmilewski.files.wordpress.com/2015/04/twodelta.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Now we have two functors, Δ<sub>c</sub> and D going between <strong>2</strong> and <em>C</em> so it’s only natural to ask about natural transformations between them. Since there are only two objects in <strong>2</strong>, a natural transformation will have two components. Object 1 in <strong>2</strong> is mapped to <code>c</code> by Δ<sub>c</sub> and to <code>a</code> by D. So the component of a natural transformation between Δ<sub>c</sub> and D at 1 is a morphism from <code>c</code> to <code>a</code>. We can call it <code>p</code>. Similarly, the second component is a morphism <code>q</code> from <code>c</code> to <code>b</code> — the image of the object 2 in <strong>2</strong> under D. But these are exactly like the two projections we used in our original definition of the product. So instead of talking about selecting objects and projections, we can just talk about picking functors and natural transformations. It so happens that in this simple case the naturality condition for our transformation is trivially satisfied, because there are no morphisms (other than the identities) in <strong>2</strong>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg"><img data-attachment-id="4498" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/productcone/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg" data-orig-size="320,217" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430239027&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductCone" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg?w=300&amp;h=203" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg?w=320" class="alignnone size-medium wp-image-4498" src="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg?w=300&amp;h=203" alt="ProductCone" width="300" height="203" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg?w=300&amp;h=203 300w, https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg?w=150&amp;h=102 150w, https://bartoszmilewski.files.wordpress.com/2015/04/productcone.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>A generalization of this construction to categories other than <strong>2</strong> — ones that, for instance, contain non-trivial morphisms — will impose naturality conditions on the transformation between Δ<sub>c</sub> and D. We call such transformation a <em>cone</em>, because the image of Δ is the apex of a cone/pyramid whose sides are formed by the components of the natural transformation. The image of D forms the base of the cone.</p><p>In general, to build a cone, we start with a category <em>I</em> that defines the pattern. It’s a small, often finite category. We pick a functor D from <em>I</em> to <em>C</em> and call it (or its image) a <em>diagram</em>. We pick some <code>c</code> in <em>C</em> as the apex of our cone. We use it to define the constant functor Δ<sub>c</sub> from <em>I</em> to <em>C</em>. A natural transformation from Δ<sub>c</sub> to D is then our cone. For a finite <em>I</em> it’s just a bunch of morphisms connecting <code>c</code> to the diagram: the image of <em>I</em> under D.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg"><img data-attachment-id="4485" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/cone-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg" data-orig-size="320,230" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430233998&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Cone" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg?w=300&amp;h=216" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg?w=320" class="alignnone size-medium wp-image-4485" src="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg?w=300&amp;h=216" alt="Cone" width="300" height="216" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg?w=300&amp;h=216 300w, https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg?w=150&amp;h=108 150w, https://bartoszmilewski.files.wordpress.com/2015/04/cone.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Naturality requires that all triangles (the walls of the pyramid) in this diagram commute. Indeed, take any morphism <code>f</code> in <em>I</em>. The functor D maps it to a morphism <code>D f</code> in <em>C</em>, a morphism that forms the base of some triangle. The constant functor Δ<sub>c</sub> maps <code>f</code> to the identity morphism on <code>c</code>. Δ squishes the two ends of the morphism into one object, and the naturality square becomes a commuting triangle. The two arms of this triangle are the components of the natural transformation.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg"><img data-attachment-id="4486" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/conenaturality/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg" data-orig-size="320,247" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234085&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ConeNaturality" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg?w=300&amp;h=232" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg?w=320" class="alignnone size-medium wp-image-4486" src="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg?w=300&amp;h=232" alt="ConeNaturality" width="300" height="232" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg?w=300&amp;h=232 300w, https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg?w=150&amp;h=116 150w, https://bartoszmilewski.files.wordpress.com/2015/04/conenaturality.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>So that’s one cone. What we are interested in is the <em>universal cone</em> — just like we picked a universal object for our definition of a product.</p><p>There are many ways to go about it. For instance, we may define a <em>category of cones</em> based on a given functor D. Objects in that category are cones. Not every object <code>c</code> in <em>C</em>&nbsp;can be an apex of a cone, though, because there may be no natural transformation between Δ<sub>c</sub> and D.</p><p>To make it a category, we also have to define morphisms between cones. These would be fully determined by morphisms between their apexes. But not just any morphism will do. Remember that, in our construction of the product, we imposed the condition that the morphisms between candidate objects (the apexes) must be common factors for the projections. For instance:</p><pre>p' = p . m
 q' = q . m</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg"><img data-attachment-id="3772" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg" data-orig-size="541,440" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=510" class="alignnone wp-image-3772 " src="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=205&amp;h=167" alt="ProductRanking" width="205" height="167" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=205&amp;h=167 205w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=410&amp;h=334 410w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=150&amp;h=122 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244 300w" sizes="(max-width: 205px) 100vw, 205px"></a></p><p>This condition translates, in the general case, to the condition that the triangles whose one side is the factorizing morphism all commute.</p><p>We’ll take those factorizing morphisms as the morphisms in our category of cones. It’s easy to check that those morphisms indeed compose, and that the identity morphism is a factorizing morphism as well. Cones therefore form a category.</p><p>Now we can define the universal cone as the <em>terminal object</em> in the category of cones. The definition of the terminal object states that there is a unique morphism from any other object to that object. In our case it means that there is a unique factorizing morphism from the apex of any other cone to the apex of the universal cone. We call this universal cone the <em>limit</em> of the diagram D, <code>Lim D</code> (in the literature, you’ll often see a left arrow pointing towards <em>I</em> under the <code>Lim</code> sign). Often, as a shorthand, we call the apex of this cone the limit (or the limit object).</p><p>The intuition is that the limit embodies the properties of the whole diagram in a single object. For instance, the limit of our two-object diagram is the product of two objects. The product (together with the two projections) contains the information about both objects. And being universal means that it has no extraneous junk.</p><h2>Limit as a Natural Isomorphism</h2><p>There is still something unsatisfying about this definition of a limit. I mean, it’s workable, but we still have this commutativity condition for the triangles that are linking any two cones. It would be so much more elegant if we could replace it with some naturality condition. But how?</p><p>We are no longer dealing with one cone but with a whole collection (in fact, a category) of cones. If the limit exists (and — let’s make it clear — there’s no guarantee of that), one of those cones is the universal cone. For every other cone we have a unique factorizing morphism that maps its apex, let’s call it <code>c</code>, to the apex of the universal cone, which we named <code>Lim D</code>. (In fact, I can skip the word “other,” because the identity morphism maps the universal cone to itself and it trivially factorizes through itself.) Let me repeat the important part: given any cone, there is a unique morphism of a special kind. We have a mapping of cones to special morphisms, and it’s a one-to-one mapping.</p><p>This special morphism is a member of the hom-set <code>C(c, Lim D)</code>. The other members of this hom-set are less fortunate, in the sense that they don’t factorize the mapping of cones. What we want is to be able to pick, for each <code>c</code>, one morphism from the set <code>C(c, Lim D)</code> — a morphism that satisfies the particular commutativity condition. Does that sound like defining a natural transformation? It most certainly does!</p><p>But what are the functors that are related by this transformation?</p><p>One functor is the mapping of <code>c</code> to the set <code>C(c, Lim D)</code>. It’s a functor from <em>C</em> to <b>Set</b> — it maps objects to sets. In fact it’s a contravariant functor. Here’s how we define its action on morphisms: Let’s take a morphism <code>f</code> from <code>c'</code> to <code>c</code>:</p><pre>f :: c' -&gt; c</pre><p>Our functor maps <code>c'</code> to the set <code>C(c', Lim D)</code>. To define the action of this functor on <code>f</code> (in other words, to lift <code>f</code>), we have to define the corresponding mapping between <code>C(c, Lim D)</code> and <code>C(c', Lim D)</code>. So let’s pick one element <code>u</code> of <code>C(c, Lim D)</code> and see if we can map it to some element of <code>C(c', Lim D)</code>. An element of a hom-set is a morphism, so we have:</p><pre>u :: c -&gt; Lim D</pre><p>We can precompose <code>u</code> with <code>f</code> to get:</p><pre>u . f :: c' -&gt; Lim D</pre><p>And that’s an element of <code>C(c', Lim D)</code>— so indeed, we have found a mapping of morphisms:</p><pre>contramap :: (c' -&gt; c) -&gt; (c -&gt; Lim D) -&gt; (c' -&gt; Lim D)
 contramap f u = u . f</pre><p>Notice the inversion in the order of <code>c</code> and <code>c'</code> characteristic of a <em>contravariant</em> functor.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg"><img data-attachment-id="4488" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/homsetmapping/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg" data-orig-size="320,257" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234085&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="HomSetMapping" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=249&amp;h=200" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=320" class="alignnone wp-image-4488" src="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=249&amp;h=200" alt="HomSetMapping" width="249" height="200" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=249&amp;h=200 249w, https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=150&amp;h=120 150w, https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg?w=300&amp;h=241 300w, https://bartoszmilewski.files.wordpress.com/2015/04/homsetmapping.jpg 320w" sizes="(max-width: 249px) 100vw, 249px"></a></p><p>To define a natural transformation, we need another functor that’s also a mapping from <em>C</em> to <b>Set</b>. But this time we’ll consider a set of cones. Cones are just natural transformations, so we are looking at the set of natural transformations <code>Nat(Δ<sub>c</sub>, D)</code>. The mapping from <code>c</code> to this particular set of natural transformations is a (contravariant) functor. How can we show that? Again, let’s define its action on a morphism:</p><pre>f :: c' -&gt; c</pre><p>The lifting of <code>f</code> should be a mapping of natural transformations between two functors that go from <em>I</em> to <em>C</em>:</p><pre>Nat(Δ<sub>c</sub>, D) -&gt; Nat(Δ<sub>c'</sub>, D)</pre><p>How do we map natural transformations? Every natural transformation is a selection of morphisms — its components — one morphism per element of <em>I</em>. A component of some α (a member of <code>Nat(Δ<sub>c</sub>, D)</code>) at <code>a</code> (an object in <em>I</em>) is a morphism:</p><pre>α<sub>a</sub> :: Δ<sub>c</sub>a -&gt; D a</pre><p>or, using the definition of the constant functor Δ,</p><pre>α<sub>a</sub> :: c -&gt; D a</pre><p>Given <code>f</code> and α, we have to construct a β, a member of <code>Nat(Δ<sub>c'</sub>, D)</code>. Its component at <code>a</code> should be a morphism:</p><pre>β<sub>a</sub> :: c' -&gt; D a</pre><p>We can easily get the latter from the former by precomposing it with <code>f</code>:</p><pre>β<sub>a</sub> = α<sub>a</sub> . f</pre><p>It’s relatively easy to show that those components indeed add up to a natural transformation.<br>
 <a href="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg"><img data-attachment-id="4489" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/natmapping/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg" data-orig-size="320,207" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234085&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="NatMapping" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg?w=300&amp;h=194" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg?w=320" class="alignnone size-medium wp-image-4489" src="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg?w=300&amp;h=194" alt="NatMapping" width="300" height="194" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg?w=300&amp;h=194 300w, https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg?w=150&amp;h=97 150w, https://bartoszmilewski.files.wordpress.com/2015/04/natmapping.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Given our morphism <code>f</code>, we have thus built a mapping between two natural transformations, component-wise. This mapping defines <code>contramap</code> for the functor:</p><pre>c -&gt; Nat(Δ<sub>c</sub>, D)</pre><p>What I have just done is to show you that we have two (contravariant) functors from <em>C</em> to <b>Set</b>. I haven’t made any assumptions — these functors always exist.</p><p>Incidentally, the first of these functors plays an important role in category theory, and we’ll see it again when we talk about Yoneda’s lemma. There is a name for contravariant functors from any category <em>C</em> to <b>Set</b>: they are called “presheaves.” This one is called a <em>representable presheaf</em>. The second functor is also a presheaf.</p><p>Now that we have two functors, we can talk about natural transformations between them. So without further ado, here’s the conclusion: A functor <code>D</code> from <em>I</em> to <em>C</em> has a limit <code>Lim D</code> if and only if there is a natural isomorphism between the two functors I have just defined:</p><pre>C(c, Lim D) ≃ Nat(Δ<sub>c</sub>, D)</pre><p>Let me remind you what a natural isomorphism is. It’s a natural transformation whose every component is an isomorphism, that is to say an invertible morphism.</p><p>I’m not going to go through the proof of this statement. The procedure is pretty straightforward if not tedious. When dealing with natural transformations, you usually focus on components, which are morphisms. In this case, since the target of both functors is <b>Set</b>, the components of the natural isomorphism will be functions. These are higher order functions, because they go from the hom-set to the set of natural transformations. Again, you can analyze a function by considering what it does to its argument: here the argument will be a morphism — a member of <code>C(c, Lim D)</code> — and the result will be a natural transformation — a member of <code>Nat(Δ<sub>c</sub>, D)</code>, or what we have called a cone. This natural transformation, in turn, has its own components, which are morphisms. So it’s morphisms all the way down, and if you can keep track of them, you can prove the statement.</p><p>The most important result is that the naturality condition for this isomorphism is exactly the commutativity condition for the mapping of cones.</p><p>As a preview of coming attractions, let me mention that the set <code>Nat(Δ<sub>c</sub>, D)</code> can be thought of as a hom-set in the functor category; so our natural isomorphism relates two hom-sets, which points at an even more general relationship called an adjunction.</p><h2>Examples of Limits</h2><p>We’ve seen that the categorical product is a limit of a diagram generated by a simple category we called <b>2</b>.</p><p>There is an even simpler example of a limit: the terminal object. The first impulse would be to think of a singleton category as leading to a terminal object, but the truth is even starker than that: the terminal object is a limit generated by an empty category. A functor from an empty category selects no object, so a cone shrinks to just the apex. The universal cone is the lone apex that has a unique morphism coming to it from any other apex. You will recognize this as the definition of the terminal object.</p><p>The next interesting limit is called the <em>equalizer</em>. It’s a limit generated by a two-element category with two parallel morphisms going between them (and, as always, the identity morphisms). This category selects a diagram in <em>C</em> consisting of two objects, <code>a</code> and <code>b</code>, and two morphisms:</p><pre>f :: a -&gt; b
 g :: a -&gt; b</pre><p>To build a cone over this diagram, we have to add the apex, <code>c</code> and two projections:</p><pre>p :: c -&gt; a
 q :: c -&gt; b</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg"><img data-attachment-id="4490" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/equalizercone/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg" data-orig-size="320,295" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234085&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="EqualizerCone" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=218&amp;h=201" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=320" class="alignnone wp-image-4490" src="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=218&amp;h=201" alt="EqualizerCone" width="218" height="201" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=218&amp;h=201 218w, https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=150&amp;h=138 150w, https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg?w=300&amp;h=277 300w, https://bartoszmilewski.files.wordpress.com/2015/04/equalizercone.jpg 320w" sizes="(max-width: 218px) 100vw, 218px"></a></p><p>We have two triangles that must commute:</p><pre>q = f . p
 q = g . p</pre><p>This tells us that <code>q</code> is uniquely determined by one of these equations, say, <code>q = f . p</code>, and we can omit it from the picture. So we are left with just one condition:</p><pre>f . p = g . p</pre><p>The way to think about it is that, if we restrict our attention to <b>Set</b>, the image of the function <code>p</code> selects a subset of <code>a</code>. When restricted to this subset, the functions <code>f</code> and <code>g</code> are equal.</p><p>For instance, take <code>a</code> to be the two-dimensional plane parameterized by coordinates <code>x</code> and <code>y</code>. Take <code>b</code> to be the real line, and take:</p><pre>f (x, y) = 2 * y + x
 g (x, y) = y - x</pre><p>The equalizer for these two functions is the set of real numbers (the apex, <code>c</code>) and the function:</p><pre>p t = (t, (-2) * t)</pre><p>Notice that <code>(p t)</code> defines a straight line in the two-dimensional plane. Along this line, the two functions are equal.</p><p>Of course, there are other sets <code>c'</code> and functions <code>p'</code> that may lead to the equality:</p><pre>f . p' = g . p'</pre><p>but they all uniquely factor out through <code>p</code>. For instance, we can take the singleton set <code>()</code> as <code>c'</code> and the function:</p><pre>p'() = (0, 0)</pre><p>It’s a good cone, because <code>f (0, 0) = g (0, 0)</code>. But it’s not universal, because of the unique factorization through <code>h</code>:</p><pre>p' = p . h</pre><p>with</p><pre>h () = 0</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg"><img data-attachment-id="4491" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/equilizerlimit/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg" data-orig-size="303,320" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234085&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="EquilizerLimit" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=211&amp;h=223" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=303" class="alignnone wp-image-4491" src="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=211&amp;h=223" alt="EquilizerLimit" width="211" height="223" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=211&amp;h=223 211w, https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=142&amp;h=150 142w, https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg?w=284&amp;h=300 284w, https://bartoszmilewski.files.wordpress.com/2015/04/equilizerlimit.jpg 303w" sizes="(max-width: 211px) 100vw, 211px"></a><br>
 An equalizer can thus be used to solve equations of the type <code>f x = g x</code>. But it’s much more general, because it’s defined in terms of objects and morphisms rather than algebraically.</p><p>An even more general idea of solving an equation is embodied in another limit — the pullback. Here, we still have two morphisms that we want to equate, but this time their domains are different. We start with a three-object category of the shape: <code>1-&gt;2&lt;-3</code>. The diagram corresponding to this category consists of three objects, <code>a</code>, <code>b</code>, and <code>c</code>, and two morphisms:</p><pre>f :: a -&gt; b
 g :: c -&gt; b</pre><p>This diagram is often called a <em>cospan</em>.</p><p>A cone built on top of this diagram consists of the apex, <code>d</code>, and three morphisms:</p><pre>p :: d -&gt; a
 q :: d -&gt; c
 r :: d -&gt; b</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg"><img data-attachment-id="4492" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/pullbackcone/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg" data-orig-size="320,231" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234148&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="PullbackCone" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=238&amp;h=172" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=320" class="alignnone wp-image-4492" src="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=238&amp;h=172" alt="PullbackCone" width="238" height="172" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=238&amp;h=172 238w, https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=150&amp;h=108 150w, https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg?w=300&amp;h=217 300w, https://bartoszmilewski.files.wordpress.com/2015/04/pullbackcone.jpg 320w" sizes="(max-width: 238px) 100vw, 238px"></a></p><p>Commutativity conditions tell us that <code>r</code> is completely determined by the other morphisms, and can be omitted from the picture. So we are only left with the following condition:</p><pre>g . q = f . p</pre><p>A pullback is a universal cone of this shape.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg"><img data-attachment-id="4493" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/pullbacklimit/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg" data-orig-size="288,320" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234148&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="PullbackLimit" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg?w=204&amp;h=227" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg?w=288" class="alignnone wp-image-4493" src="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg?w=204&amp;h=227" alt="PullbackLimit" width="204" height="227" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg?w=204&amp;h=227 204w, https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg?w=135&amp;h=150 135w, https://bartoszmilewski.files.wordpress.com/2015/04/pullbacklimit.jpg 288w" sizes="(max-width: 204px) 100vw, 204px"></a></p><p>Again, if you narrow your focus down to sets, you can think of the object <code>d</code> as consisting of pairs of elements from <code>a</code> and <code>c</code> for which <code>f</code> acting on the first component is equal to <code>g</code> acting on the second component. If this is still too general, consider the special case in which <code>g</code> is a constant function, say <code>g _ = 1.23</code> (assuming that <code>b</code> is a set of real numbers). Then you are really solving the equation:</p><pre>f x = 1.23</pre><p>In this case, the choice of <code>c</code> is irrelevant (as long as it’s not an empty set), so we can take it to be a singleton set. The set <code>a</code> could, for instance, be the set of three-dimensional vectors, and <code>f</code> the vector length. Then the pullback is the set of pairs <code>(v, ())</code>, where <code>v</code> is a vector of length 1.23 (a solution to the equation <code>sqrt (x<sup>2</sup>+y<sup>2</sup>+z<sup>2</sup>) = 1.23</code>), and <code>()</code> is the dummy element of the singleton set.</p><p>But pullbacks have more general applications, also in programming. For instance, consider C++ classes as a category in which morphism are arrows that connect subclasses to superclasses. We’ll consider inheritance a transitive property, so if C inherits from B and B inherits from A then we’ll say that C inherits from A (after all, you can pass a pointer to C where a pointer to A is expected). Also, we’ll assume that C inherits from C, so we have the identity arrow for every class. This way subclassing is aligned with subtyping. C++ also supports multiple inheritance, so you can construct a diamond inheritance diagram with two classes B and C inheriting from A, and a fourth class D multiply inheriting from B and C. Normally, D would get two copies of A, which is rarely desirable; but you can use virtual inheritance to have just one copy of A in D.</p><p>What would it mean to have D be a pullback in this diagram? It would mean that any class E that multiply inherits from B and C is also a subclass of D. This is not directly expressible in C++, where subtyping is nominal (the C++ compiler wouldn’t infer this kind of class relationship — it would require “duck typing”). But we could go outside of the subtyping relationship and instead ask whether a cast from E to D would be safe or not. This cast would be safe if D were the bare-bone combination of B and C, with no additional data and no overriding of methods. And, of course, there would be no pullback if there is a name conflict between some methods of B and C.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg"><img data-attachment-id="4500" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/classes/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg" data-orig-size="223,320" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430239703&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Classes" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg?w=155&amp;h=222" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg?w=223" class="alignnone wp-image-4500" src="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg?w=155&amp;h=222" alt="Classes" width="155" height="222" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg?w=155&amp;h=222 155w, https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg?w=105&amp;h=150 105w, https://bartoszmilewski.files.wordpress.com/2015/04/classes.jpg 223w" sizes="(max-width: 155px) 100vw, 155px"></a></p><p>There’s also a more advanced use of a pullback in type inference. There is often a need to <em>unify</em> types of two expressions. For instance, suppose that the compiler wants to infer the type of a function:</p><pre>twice f x = f (f x)</pre><p>It will assign preliminary types to all variables and sub-expressions. In particular, it will assign:</p><pre>f       :: t0
 x       :: t1
 f x     :: t2
 f (f x) :: t3</pre><p>from which it will deduce that:</p><pre>twice :: t0 -&gt; t1 -&gt; t3</pre><p>It will also come up with a set of constraints resulting from the rules of function application:</p><pre>t0 = t1 -&gt; t2 -- because f is applied to x
 t0 = t2 -&gt; t3 -- because f is applied to (f x)</pre><p>These constraints have to be unified by finding a set of types (or type variables) that, when substituted for the unknown types in both expressions, produce the same type. One such substitution is:</p><pre>t1 = t2 = t3 = Int
 twice :: (Int -&gt; Int) -&gt; Int -&gt; Int</pre><p>but, obviously, it’s not the most general one. The most general substitution is obtained using a pullback. I won’t go into the details, because they are beyond the scope of this book, but you can convince yourself that the result should be:</p><pre>twice :: (t -&gt; t) -&gt; t -&gt; t</pre><p>with <code>t</code> a free type variable.</p><h2>Colimits</h2><p>Just like all constructions in category theory, limits have their dual image in opposite categories. When you invert the direction of all arrows in a cone, you get a co-cone, and the universal one of those is called a colimit. Notice that the inversion also affects the factorizing morphism, which now flows from the universal co-cone to any other co-cone.</p><p>A typical example of a colimit is a coproduct, which corresponds to the diagram generated by <b>2</b>, the category we’ve used in the definition of the product.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg"><img data-attachment-id="3775" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/coproductranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg" data-orig-size="575,479" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="CoproductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=510" class="alignnone wp-image-3775 size-thumbnail" src="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=150&amp;h=125" alt="CoproductRanking" width="150" height="125" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=150&amp;h=125 150w, https://bartoszmilewski.files.wordpress.com/2014/12/coproductranking.jpg?w=300&amp;h=250 300w" sizes="(max-width: 150px) 100vw, 150px"></a></p><p>Both the product and the coproduct embody the essence of a pair of objects, each in a different way.</p><p>Just like the terminal object was a limit, so the initial object is a colimit corresponding to the diagram based on an empty category.</p><p>The dual of the pullback is called the <em>pushout</em>. It’s based on a diagram called a span, generated by the category <code>1&lt;-2-&gt;3</code>.</p><h2>Continuity</h2><p>I said previously that functors come close to the idea of continuous mappings of categories, in the sense that they never break existing connections (morphisms). The actual definition of a <em>continuous functor</em> <code>F</code> from a category <em>C</em> to <em>C’</em> includes the requirement that the functor preserve limits. Every diagram <code>D</code> in <em>C</em> can be mapped to a diagram <code>F ∘ D</code> in <em>C’</em> by simply composing two functors. The continuity condition for <code>F</code> states that, if the diagram <code>D</code> has a limit <code>Lim D</code>, then the diagram <code>F ∘ D</code> also has a limit, and it is equal to <code>F (Lim D)</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg"><img data-attachment-id="4495" data-permalink="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/continuity/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg" data-orig-size="320,92" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1430234148&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Continuity" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg?w=300&amp;h=86" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg?w=320" class="alignnone wp-image-4495 size-medium" src="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg?w=300&amp;h=86" alt="Continuity" width="300" height="86" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg?w=300&amp;h=86 300w, https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg?w=150&amp;h=43 150w, https://bartoszmilewski.files.wordpress.com/2015/04/continuity.jpg 320w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that, because functors map morphisms to morphisms, and compositions to compositions, an image of a cone is always a cone. A commuting triangle is always mapped to a commuting triangle (functors preserve composition). The same is true for the factorizing morphisms: the image of a factorizing morphism is also a factorizing morphism. So every functor is <em>almost</em> continuous. What may go wrong is the uniqueness condition. The factorizing morphism in <em>C’</em> might not be unique. There may also be other “better cones” in <em>C’</em> that were not available in <em>C</em>.</p><p>A hom-functor is an example of a continuous functor. Recall that the hom-functor, <code>C(a, b)</code>, is contravariant in the first variable and covariant in the second. In other words, it’s a functor:</p><pre>C<sup>op</sup> × C -&gt; Set</pre><p>When its second argument is fixed, the hom-set functor (which becomes the representable presheaf) maps colimits in <em>C</em> to limits in <b>Set</b>; and when its first argument is fixed, it maps limits to limits.</p><p>In Haskell, a hom-functor is the mapping of any two types to a function type, so it’s just a parameterized function type. When we fix the second parameter, let’s say to <code>String</code>, we get the contravariant functor:</p><pre>newtype ToString a = ToString (a -&gt; String)
 instance Contravariant ToString where
    contramap f (ToString g) = ToString (g . f)</pre><p>Continuity means that when <code>ToString</code> is applied to a colimit, for instance a coproduct <code>Either b c</code>, it will produce a limit; in this case a product of two function types:</p><pre>ToString (Either b c) ~ (b -&gt; String, c -&gt; String)</pre><p>Indeed, any function of <code>Either b c</code> is implemented as a case statement with the two cases being serviced by a pair of functions.</p><p>Similarly, when we fix the first argument of the hom-set, we get the familiar reader functor. Its continuity means that, for instance, any function returning a product is equivalent to a product of functions; in particular:</p><pre>r -&gt; (a, b) ~ (r -&gt; a, r -&gt; b)</pre><p>I know what you’re thinking: You don’t need category theory to figure these things out. And you’re right! Still, I find it amazing that such results can be derived from first principles with no recourse to bits and bytes, processor architectures, compiler technologies, or even lambda calculus.</p><p>If you’re curious where the names “limit” and “continuity” come from, they are a generalization of the corresponding notions from calculus. In calculus limits and continuity are defined in terms of open neighborhoods. Open sets, which define topology, form a category (a poset).</p><h2>Challenges</h2><ol>
 <li>How would you describe a pushout in the category of C++ classes?</li>
 <li>Show that the limit of the identity functor <code>Id :: C -&gt; C</code> is the initial object.</li>
 <li>Subsets of a given set form a category. A morphism in that category is defined to be an arrow connecting two sets if the first is the subset of the second. What is a pullback of two sets in such a category? What’s a pushout? What are the initial and terminal objects?</li>
 <li>Can you guess what a coequalizer is?</li>
 <li>Show that, in a category with a terminal object, a pullback towards the terminal object is a product.</li>
 <li>Similarly, show that a pushout from an initial object (if one exists) is the coproduct.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/07/21/free-monoids/">Free Monoids</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408270820" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Free Monoids		</h2><p>Monoids are an important concept in both category theory and in programming. Categories correspond to strongly typed languages, monoids to untyped languages. That’s because in a monoid you can compose any two arrows, just as in an untyped language you can compose any two functions (of course, you may end up with a runtime error when you execute your program).</p><p>We’ve seen that a monoid may be described as a category with a single object, where all logic is encoded in the rules of morphism composition. This categorical model is fully equivalent to the more traditional set-theoretical definition of a monoid, where we “multiply” two elements of a set to get a third element. This process of “multiplication” can be further dissected into first forming a pair of elements and then identifying this pair with an existing element — their “product.”</p><p>What happens when we forgo the second part of multiplication — the identification of pairs with existing elements? We can, for instance, start with an arbitrary set, form all possible pairs of elements, and call them new elements. Then we’ll pair these new elements with all possible elements, and so on. This is a chain reaction — we’ll keep adding new elements forever. The result, an infinite set, will be <em>almost</em> a monoid. But a monoid also needs a unit element and the law of associativity. No problem, we can add a special unit element and identify some of the pairs — just enough to support the unit and associativity laws.</p><p>Let’s see how this works in a simple example. Let’s start with a set of two elements, <code>{a, b}</code>. We’ll call them the generators of the free monoid. First, we’ll add a special element <code>e</code> to serve as the unit. Next we’ll add all the pairs of elements and call them “products”. The product of <code>a</code> and <code>b</code> will be the pair <code>(a, b)</code>. The product of <code>b</code> and <code>a</code> will be the pair <code>(b, a)</code>, the product of <code>a</code> with <code>a</code> will be <code>(a, a)</code>, the product of <code>b</code> with <code>b</code> will be <code>(b, b)</code>. We can also form pairs with <code>e</code>, like <code>(a, e)</code>, <code>(e, b)</code>, etc., but we’ll identify them with <code>a</code>, <code>b</code>, etc. So in this round we’ll only add <code>(a, a)</code>, <code>(a, b)</code> and <code>(b, a)</code> and <code>(b, b)</code>, and end up with the set <code>{e, a, b, (a, a), (a, b), (b, a), (b, b)}</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg"><img data-attachment-id="4840" data-permalink="https://bartoszmilewski.com/2015/07/21/free-monoids/bunnies/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg" data-orig-size="636,293" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1437244957&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Bunnies" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=436&amp;h=201" class="alignnone wp-image-4840 " src="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=436&amp;h=201" alt="Bunnies" width="436" height="201" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=436&amp;h=201 436w, https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=150&amp;h=69 150w, https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg?w=300&amp;h=138 300w, https://bartoszmilewski.files.wordpress.com/2015/07/bunnies.jpg 636w" sizes="(max-width: 436px) 100vw, 436px"></a></p><p>In the next round we’ll keep adding elements like: <code>(a, (a, b))</code>, <code>((a, b), a)</code>, etc. At this point we’ll have to make sure that associativity holds, so we’ll identify <code>(a, (b, a))</code> with <code>((a, b), a)</code>, etc. In other words, we won’t be needing internal parentheses.</p><p>You can guess what the final result of this process will be: we’ll create all possible lists of <code>a</code>s and <code>b</code>s. In fact, if we represent <code>e</code> as an empty list, we can see that our “multiplication” is nothing but list concatenation.</p><p>This kind of construction, in which you keep generating all possible combinations of elements, and perform the minimum number of identifications — just enough to uphold the laws — is called a free construction. What we have just done is to construct a <em>free monoid</em> from the set of generators <code>{a, b}</code>.</p><h2>Free Monoid in Haskell</h2><p>A two-element set in Haskell is equivalent to the type <code>Bool</code>, and the free monoid generated by this set is equivalent to the type <code>[Bool]</code> (list of <code>Bool</code>). (I am deliberately ignoring problems with infinite lists.)</p><p>A monoid in Haskell is defined by the type class:</p><pre>class Monoid m where
    mempty  :: m
    mappend :: m -&gt; m -&gt; m</pre><p>This just says that every <code>Monoid</code> must have a neutral element, which is called <code>mempty</code>, and a binary function (multiplication) called <code>mappend</code>. The unit and associativity laws cannot be expressed in Haskell and must be verified by the programmer every time a monoid is instantiated.</p><p>The fact that a list of any type forms a monoid is described by this instance definition:</p><pre>instance Monoid [a] where
    mempty  = []
    mappend = (++)</pre><p>It states that an empty list <code>[]</code> is the unit element, and list concatenation <code>(++)</code> is the binary operation.</p><p>As we have seen, a list of type <code>a</code> corresponds to a free monoid with the set <code>a</code> serving as generators. The set of natural numbers with multiplication is not a free monoid, because we identify lots of products. Compare for instance:</p><pre>2 * 3 = 6
 [2] ++ [3] = [2, 3] // not the same as [6]</pre><p>That was easy, but the question is, can we perform this free construction in category theory, where we are not allowed to look inside objects? We’ll use our workhorse: the universal construction.</p><p>The second interesting question is, can any monoid be obtained from some free monoid by identifying more than the minimum number of elements required by the laws? I’ll show you that this follows directly from the universal construction.</p><h2>Free Monoid Universal Construction</h2><p>If you recall our previous experiences with universal constructions, you might notice that it’s not so much about constructing something as about selecting an object that best fits a given pattern. So if we want to use the universal construction to “construct” a free monoid, we have to consider a whole bunch of monoids from which to pick one. We need a whole category of monoids to chose from. But do monoids form a category?</p><p>Let’s first look at monoids as sets equipped with additional structure defined by unit and multiplication. We’ll pick as morphisms those functions that preserve the monoidal structure. Such structure-preserving functions are called <em>homomorphisms</em>. A monoid homomorphism must map the product of two elements to the product of the mapping of the two elements:</p><pre>h (a * b) = h a * h b</pre><p>and it must map unit to unit.<br>
 For instance, consider a homomorphism from lists of integers to integers. If we map <code>[2]</code> to 2 and <code>[3]</code> to 3, we have to map <code>[2, 3]</code> to 6, because concatenation</p><pre>[2] ++ [3] = [2, 3]</pre><p>becomes multiplication</p><pre>2 * 3 = 6</pre><p>Now let’s forget about the internal structure of individual monoids, and only look at them as objects with corresponding morphisms. You get a category <b>Mon</b> of monoids.</p><p>Okay, maybe before we forget about internal structure, let us notice an important property. Every object of <b>Mon</b> can be trivially mapped to a set. It’s just the set of its elements. This set is called the <i>underlying</i> set. In fact, not only can we map objects of <b>Mon</b> to sets, but we can also map morphisms of <b>Mon</b> (homomorphisms) to functions. Again, this seems sort of trivial, but it will become useful soon. This mapping of objects and morphisms from <b>Mon</b> to <b>Set</b> is in fact a functor. Since this functor “forgets” the monoidal structure — once we are inside a plain set, we no longer distinguish the unit element or care about multiplication — it’s called a <i>forgetful functor</i>. Forgetful functors come up regularly in category theory.</p><p>We now have two different views of <b>Mon</b>. We can treat it just like any other category with objects and morphisms. In that view, we don’t see the internal structure of monoids. All we can say about a particular object in <b>Mon</b> is that it connects to itself and to other objects through morphisms. The “multiplication” table of morphisms — the composition rules — are derived from the other view: monoids-as-sets. By going to category theory we haven’t lost this view completely — we can still access it through our forgetful functor.</p><p>To apply the universal construction, we need to define a special property that would let us search through the category of monoids and pick the best candidate for a free monoid. But a free monoid is defined by its generators. Different choices of generators produce different free monoids (a list of <code>Bool</code> is not the same as a list of <code>Int</code>). Our construction must start with a set of generators. So we’re back to sets!</p><p>That’s where the forgetful functor comes into play. We can use it to X-ray our monoids. We can identify the generators in the X-ray images of those blobs. Here’s how it works:</p><p>We start with a set of generators, <code>x</code>. That’s a set in <b>Set</b>.</p><p>The pattern we are going to match consists of a monoid <code>m</code> — an object of <b>Mon</b> — and a function <code>p</code> in <b>Set</b>:</p><pre>p :: x -&gt; U m</pre><p>where <code>U</code> is our forgetful functor from <b>Mon</b> to <b>Set</b>. This is a weird heterogeneous pattern — half in <b>Mon</b> and half in <b>Set</b>.</p><p>The idea is that the function <code>p</code> will identify the set of generators inside the X-ray image of <code>m</code>. It doesn’t matter that functions may be lousy at identifying points inside sets (they may collapse them). It will all be sorted out by the universal construction, which will pick the best representative of this pattern.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg"><img data-attachment-id="4841" data-permalink="https://bartoszmilewski.com/2015/07/21/free-monoids/monoid-pattern/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg" data-orig-size="595,367" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1437244957&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Monoid Pattern" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg?w=300&amp;h=185" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg?w=510" class="alignnone size-medium wp-image-4841" src="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg?w=300&amp;h=185" alt="Monoid Pattern" width="300" height="185" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg?w=300&amp;h=185 300w, https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg?w=150&amp;h=93 150w, https://bartoszmilewski.files.wordpress.com/2015/07/monoid-pattern.jpg 595w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>We also have to define the ranking among candidates. Suppose we have another candidate: a monoid <code>n</code> and a function that identifies the generators in its X-ray image:</p><pre>q :: x -&gt; U n</pre><p>We’ll say that <code>m</code> is better than <code>n</code> if there is a morphism of monoids (that’s a structure-preserving homomorphism):</p><pre>h :: m -&gt; n</pre><p>whose image under <code>U</code> (remember, <code>U</code> is a functor, so it maps morphisms to functions) factorizes through <code>p</code>:</p><pre>q = U h . p</pre><p>If you think of <code>p</code> as selecting the generators in <code>m</code>; and <code>q</code> as selecting “the same” generators in <code>n</code>; then you can think of <code>h</code> as mapping these generators between the two monoids. Remember that <code>h</code>, by definition, preserves the monoidal structure. It means that a product of two generators in one monoid will be mapped to a product of the corresponding two generators in the second monoid, and so on.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg"><img data-attachment-id="4842" data-permalink="https://bartoszmilewski.com/2015/07/21/free-monoids/monoid-ranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg" data-orig-size="607,448" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1437244957&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Monoid Ranking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=300&amp;h=221" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=510" class="alignnone size-medium wp-image-4842" src="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=300&amp;h=221" alt="Monoid Ranking" width="300" height="221" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=300&amp;h=221 300w, https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=600&amp;h=442 600w, https://bartoszmilewski.files.wordpress.com/2015/07/monoid-ranking.jpg?w=150&amp;h=111 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>This ranking may be used to find the best candidate — the free monoid. Here’s the definition:</p><p class="box2">We’ll say that <code>m</code> (together with the function <code>p</code>) is the <strong>free monoid</strong> with the generators <code>x</code> if and only if there is a <em>unique</em> morphism <code>h</code> from <code>m</code> to any other monoid <code>n</code> (together with the function <code>q</code>) that satisfies the above factorization property.</p><p>Incidentally, this answers our second question. The function <code>U h</code> is the one that has the power to collapse multiple elements of <code>U m</code> to a single element of <code>U n</code>. This collapse corresponds to identifying some elements of the free monoid. Therefore any monoid with generators <code>x</code> can be obtained from the free monoid based on <code>x</code> by identifying some of the elements. The free monoid is the one where only the bare minimum of identifications have been made.</p><p>We’ll come back to free monoids when we talk about adjunctions.</p><h2>Challenges</h2><ol>
 <li>You might think (as I did, originally) that the requirement that a homomorphism of monoids preserve the unit is redundant. After all, we know that for all <code>a</code>
 <pre>h a * h e = h (a * e) = h a</pre>
 <p>So <code>h e</code> acts like a right unit (and, by analogy, as a left unit). The problem is that <code>h a</code>, for all <code>a</code> might only cover a sub-monoid of the target monoid. There may be a “true” unit outside of the image of <code>h</code>. Show that an isomorphism between monoids that preserves multiplication must automatically preserve unit.</p></li>
 <li>Consider a monoid homomorphism from lists of integers with concatenation to integers with multiplication. What is the image of the empty list <code>[]</code>? Assume that all singleton lists are mapped to the integers they contain, that is <code>[3]</code> is mapped to 3, etc. What’s the image of <code>[1, 2, 3, 4]</code>? How many different lists map to the integer 12? Is there any other homomorphism between the two monoids?</li>
 <li>What is the free monoid generated by a one-element set? Can you see what it’s isomorphic to?</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/07/29/representable-functors/">Representable Functors</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408294060" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Representable Functors		</h2><p>It’s about time we had a little talk about sets. Mathematicians have a love/hate relationship with set theory. It’s the assembly language of mathematics — at least it used to be. Category theory tries to step away from set theory, to some extent. For instance, it’s a known fact that the set of all sets doesn’t exist, but the category of all sets, <b>Set</b>, does. So that’s good. On the other hand, we assume that morphisms between any two objects in a category form a set. We even called it a hom-set. To be fair, there is a branch of category theory where morphisms don’t form sets. Instead they are objects in another category. Those categories that use hom-objects rather than hom-sets, are called <i>enriched</i> categories. In what follows, though, we’ll stick to categories with good old-fashioned hom-sets.</p><p>A set is the closest thing to a featureless blob you can get outside of categorical objects. A set has elements, but you can’t say much about these elements. If you have a finite set, you can count the elements. You can kind of count the elements of an inifinite set using cardinal numbers. The set of natural numbers, for instance, is smaller than the set of real numbers, even though both are infinite. But, maybe surprisingly, a set of rational numbers is the same size as the set of natural numbers. </p><p>Other than that, all the information about sets can be encoded in functions between them — especially the invertible ones called isomorphisms. For all intents and purposes isomorphic sets are identical. Before I summon the wrath of foundational mathematicians, let me explain that the distinction between equality and isomorphism is of fundamental importance. In fact it is one of the main concerns of the latest branch of mathematics, the Homotopy Type Theory (HoTT). I’m mentioning HoTT because it’s a pure mathematical theory that takes inspiration from computation, and one of its main proponents, Vladimir Voevodsky, had a major epiphany while studying the Coq theorem prover. The interaction between mathematics and programming goes both ways.</p><p>The important lesson about sets is that it’s okay to compare sets of unlike elements. For instance, we can say that a given set of natural transformations is isomorphic to some set of morphisms, because a set is just a set. Isomorphism in this case just means that for every natural transformation from one set there is a unique morphism from the other set and vice versa. They can be paired against each other. You can’t compare apples with oranges, if they are objects from different categories, but you can compare sets of apples against sets of oranges. Often transforming a categorical problem into a set-theoretical problem gives us the necessary insight or even lets us prove valuable theorems. </p><h2>The Hom Functor</h2><p>Every category comes equipped with a canonical family of mappings to <b>Set</b>. Those mappings are in fact functors, so they preserve the structure of the category. Let’s build one such mapping. </p><p>Let’s fix one object <code>a</code> in <i>C</i> and pick another object <code>x</code> also in <i>C</i>. The hom-set <code>C(a, x)</code> is a set, an object in <b>Set</b>. When we vary <code>x</code>, keeping <code>a</code> fixed, <code>C(a, x)</code> will also vary in <b>Set</b>. Thus we have a mapping from <code>x</code> to <b>Set</b>.<br>
 <a href="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg"><img data-attachment-id="4780" data-permalink="https://bartoszmilewski.com/2015/07/13/from-lenses-to-yoneda-embedding/hom-set-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg" data-orig-size="484,292" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1436192503&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Hom-Set" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg?w=300&amp;h=181" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg?w=484" src="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg?w=300&amp;h=181" alt="Hom-Set" width="300" height="181" class="alignnone size-medium wp-image-4780" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg?w=300&amp;h=181 300w, https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg?w=150&amp;h=90 150w, https://bartoszmilewski.files.wordpress.com/2015/07/hom-set.jpg 484w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>If we want to stress the fact that we are considering the hom-set as a mapping in its second argument, we use the notation:</p><pre>C(a, -)</pre><p>with the dash serving as the placeholder for the argument. </p><p>This mapping of objects is easily extended to the mapping of morphisms. Let’s take a morphism <code>f</code> in <i>C</i> between two arbitrary objects <code>x</code> and <code>y</code>. The object <code>x</code> is mapped to the set <code>C(a, x)</code>, and the object <code>y</code> is mapped to <code>C(a, y)</code>, under the mapping we have just defined. If this mapping is to be a functor, <code>f</code> must be mapped to a function between the two sets:</p><pre>C(a, x) -&gt; C(a, y)</pre><p>Let’s define this function point-wise, that is for each argument separately. For the argument we should pick an arbitrary element of <code>C(a, x)</code> — let’s call it <code>h</code>. Morphisms are composable, if they match end to end. It so happens that the target of <code>h</code> matches the source of <code>f</code>, so their composition:</p><pre>f ∘ h :: a -&gt; y</pre><p>is a morphism going from <code>a</code> to <code>y</code>. It is therefore a member of <code>C(a, y)</code>. </p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg"><img data-attachment-id="4781" data-permalink="https://bartoszmilewski.com/2015/07/13/from-lenses-to-yoneda-embedding/hom-functor/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg" data-orig-size="592,372" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1436192503&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Hom Functor" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg?w=300&amp;h=189" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg?w=510" src="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg?w=300&amp;h=189" alt="Hom Functor" width="300" height="189" class="alignnone size-medium wp-image-4781" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg?w=300&amp;h=189 300w, https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg?w=150&amp;h=94 150w, https://bartoszmilewski.files.wordpress.com/2015/07/hom-functor.jpg 592w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>We have just found our function from <code>C(a, x)</code> to <code>C(a, y)</code>, which can serve as the image of <code>f</code>. If there is no danger of confusion, we’ll write this lifted function as:</p><pre>C(a, f)</pre><p>and its action on a morphism <code>h</code> as:</p><pre>C(a, f) h = f ∘ h</pre><p>Since this construction works in any category, it must also work in the category of Haskell types. In Haskell, the hom-functor is better known as the <code>Reader</code> functor:</p><pre>type Reader a x = a -&gt; x</pre><pre>instance Functor (Reader a) where
    fmap f h = f . h</pre><p>Now let’s consider what happens if, instead of fixing the source of the hom-set, we fix the target. In other words, we’re asking the question if the mapping </p><pre>C(-, a)</pre><p> is also a functor. It is, but instead of being covariant, it’s contravariant. That’s because the same kind of matching of morphisms end to end results in postcomposition by <code>f</code>; rather than precomposition, as was the case with <code>C(a, -)</code>.</p><p>We have already seen this contravariant functor in Haskell. We called it <code>Op</code>:</p><pre>type Op a x = x -&gt; a</pre><pre>instance Contravariant (Op a) where
    contramap f h = h . f</pre><p>Finally, if we let both objects vary, we get a profunctor <code>C(-, =)</code>, which is contravariant in the first argument and covariant in the second (to underline the fact that the two arguments may vary independently, we use a double dash as the second placeholder). We have seen this profunctor before, when we talked about functoriality:</p><pre>instance Profunctor (-&gt;) where
  dimap ab cd bc = cd . bc . ab
  lmap = flip (.)
  rmap = (.)</pre><p>The important lesson is that this observation holds in any category: the mapping of objects to hom-sets is functorial. Since contravariance is equivalent to a mapping from the opposite category, we can state this fact succintly as:</p><pre>C(-, =) :: C<sup>op</sup> × C -&gt; Set</pre><h2>Representable Functors</h2><p>We’ve seen that, for every choice of an object <code>a</code> in <i>C</i>, we get a functor from <i>C</i> to <b>Set</b>. This kind of structure-preserving mapping to <b>Set</b> is often called a <em>representation</em>. We are representing objects and morphisms of <i>C</i> as sets and functions in <b>Set</b>. </p><p>The functor <code>C(a, -)</code> itself is sometimes called representable. More generally, any functor <code>F</code> that is naturally isomorphic to the hom-functor, for some choice of <code>a</code>, is called <em>representable</em>. Such functor must necessarily be <b>Set</b>-valued, since <code>C(a, -)</code> is.</p><p>I said before that we often think of isomorphic sets as identical. More generally, we think of isomorphic <em>objects</em> in a category as identical. That’s because objects have no structure other than their relation to other objects (and themselves) through morphisms. </p><p>For instance, we’ve previously talked about the category of monoids, <b>Mon</b>, that was initially modeled with sets. But we were careful to pick as morphisms only those functions that preserved the monoidal structure of those sets. So if two objects in <b>Mon</b> are isomorphic, meaning there is an invertible morphism between them, they have exactly the same structure. If we peeked at the sets and functions that they were based upon, we’d see that the unit element of one monoid was mapped to the unit element of another, and that a product of two elements was mapped to the product of their mappings. </p><p>The same reasoning can be applied to functors. Functors between two categories form a category in which natural transformations play the role of morphisms. So two functors are isomorphic, and can be thought of as identical, if there is an invertible natural transformation between them. </p><p>Let’s analyze the definition of the representable functor from this perspective. For <code>F</code> to be representable we require that: There be an object <code>a</code> in <i>C</i>; one natural transformation α from <code>C(a, -)</code> to <code>F</code>; another natural transformation, β, in the opposite direction; and that their composition be the identity natural transformation. </p><p>Let’s look at the component of α at some object <code>x</code>. It’s a function in <b>Set</b>:</p><pre>α<sub>x</sub> :: C(a, x) -&gt; F x</pre><p>The naturality condition for this transformation tells us that, for any morphism <code>f</code> from <code>x</code> to <code>y</code>, the following diagram commutes:</p><pre>F f ∘ α<sub>x</sub> = α<sub>y</sub> ∘ C(a, f)</pre><p>In Haskell, we would replace natural transformations with polymorphic functions:</p><pre>alpha :: forall x. (a -&gt; x) -&gt; F x</pre><p>with the optional <code>forall</code> quantifier. The naturality condition </p><pre>fmap f . alpha = alpha . fmap f</pre><p>is automatically satisfied due to parametricity (it’s one of those theorems for free I mentioned earlier), with the understanding that <code>fmap</code> on the left is defined by the functor <code>F</code>, whereas the one on the right is defined by the reader functor. Since <code>fmap</code> for reader is just function precomposition, we can be even more explicit. Acting on <code>h</code>, an element of <code>C(a, x)</code>, the naturality condition simplifies to:</p><pre>fmap f (alpha h) = alpha (f . h)</pre><p>The other transformation, <code>beta</code>, goes the opposite way:</p><pre>beta :: forall x. F x -&gt; (a -&gt; x)</pre><p>It must respect naturality conditions, and it must be the inverse of α:</p><pre>α ∘ β = id = β ∘ α</pre><p>We will see later that a natural transformation from <code>C(a, -)</code> to any <b>Set</b>-valued functor always exists (Yoneda’s lemma) but it is not necessarily invertible. </p><p>Let me give you an example in Haskell with the list functor and <code>Int</code> as <code>a</code>. Here’s a natural transformation that does the job:</p><pre>alpha :: forall x. (Int -&gt; x) -&gt; [x]
 alpha h = map h [12]</pre><p>I have arbitrarily picked the number 12 and created a singleton list with it. I can then <code>fmap</code> the function <code>h</code> over this list and get a list of the type returned by <code>h</code>. (There are actually as many such transformations as there are list of integers.) </p><p>The naturality condition is equivalent to the composability of <code>map</code> (the list version of <code>fmap</code>):</p><pre>map f (map h [12]) = map (f . h) [12]</pre><p>But if we tried to find the inverse transformation, we would have to go from a list of arbitrary type <code>x</code> to a function returning <code>x</code>:</p><pre>beta :: forall x. [x] -&gt; (Int -&gt; x)</pre><p>You might think of retrieving an <code>x</code> from the list, e.g., using <code>head</code>, but that won’t work for an empty list. Notice that there is no choice for the type <code>a</code> (in place of <code>Int</code>) that would work here. So the list functor is not representable.</p><p>Remember when we talked about Haskell (endo-) functors being a little like containers? In the same vein we can think of representable functors as containers for storing memoized results of function calls (the members of hom-sets in Haskell are just functions). The representing object, the type <code>a</code> in <code>C(a, -)</code>, is thought of as the key type, with which we can access the tabulated values of a function. The transformation we called α is called <code>tabulate</code>, and its inverse, β, is called <code>index</code>. Here’s a (slightly simplified) <code>Representable</code> class definition:</p><pre>class Representable f where
   type Rep f :: *
   tabulate :: (Rep f -&gt; x) -&gt; f x
   index    :: f x -&gt; Rep f -&gt; x</pre><p>Notice that the representing type, our <code>a</code>, which is called <code>Rep f</code> here, is part of the definition of <code>Representable</code>. The star just means that <code>Rep f</code> is a type (as opposed to a type constructor, or other more exotic kinds).</p><p>Infinite lists, or streams, which cannot be empty, are representable. </p><pre>data Stream x = Cons x (Stream x)</pre><p>You can think of them as memoized values of a function taking an <code>Integer</code> as an argument. (Strictly speaking, I should be using non-negative natural numbers, but I didn’t want to complicate the code.) </p><p>To <code>tabulate</code> such a function, you create an infinite stream of values. Of course, this is only possible because Haskell is lazy. The values are evaluated on demand. You access the memoized values using <code>index</code>:</p><pre>instance Representable Stream where
    type Rep Stream = Integer
    tabulate f = Cons (f 0) (tabulate (f . (+1)))
    index (Cons b bs) n = if n == 0 then b else index bs (n - 1)</pre><p>It’s interesting that you can implement a single memoization scheme to cover a whole family of functions with arbitrary return types.</p><p>Representability for contravariant functors is similarly defined, except that we keep the second argument of <code>C(-, a)</code> fixed. Or, equivalently, we may consider functors from <i>C</i><sup>op</sup> to <b>Set</b>, because <code>C<sup>op</sup>(a, -)</code> is the same as <code>C(-, a)</code>.</p><p>There is an interesting twist to representability. Remember that hom-sets can internally be treated as exponential objects, in cartesian closed categories. The hom-set <code>C(a, x)</code> is equivalent to <code>x<sup>a</sup></code>, and for a representable functor <code>F</code> we can write:</p><pre>-<sup>a</sup> = F</pre><p>Let’s take the logarithm of both sides, just for kicks:</p><pre>a = log F</pre><p>Of course, this is a purely formal transformation, but if you know some of the properties of logarithms, it is quite helpful. In particular, it turns out that functors that are based on product types can be represented with sum types, and that sum-type functors are not in general representable (example: the list functor).</p><p>Finally, notice that a representable functor gives us two different implementations of the same thing — one a function, one a data structure. They have exactly the same content — the same values are retrieved using the same keys. That’s the sense of “sameness” I was talking about. Two naturally isomorphic functors are identical as far as their contents are involved. On the other hand, the two representations are often implemented differently and may have different performance characteristics. Memoization is used as a performance enhancement and may lead to substantially reduced run times. Being able to generate different representations of the same underlying computation is very valuable in practice. So, surprisingly, even though it’s not concerned with performance at all, category theory provides ample opportunities to explore alternative implementations that have practical value.</p><h2>Challenges</h2><ol>
 <li>Show that the hom-functors map identity morphisms in <i>C</i> to corresponding identity functions in <b>Set</b>.</li>
 <li>Show that <code>Maybe</code> is not representable.</li>
 <li>Is the <code>Reader</code> functor representable?</li>
 <li>Using <code>Stream</code> representation, memoize a function that squares its argument.</li>
 <li>Show that <code>tabulate</code> and <code>index</code> for <code>Stream</code> are indeed the inverse of each other. (Hint: use induction.)</li>
 <li>The functor:
 <pre>Pair a = Pair a a</pre>
 <p>is representable. Can you guess the type that represents it? Implement <code>tabulate</code> and <code>index</code>.</p></li>
 </ol><h2>Bibliography</h2><ol>
 <li>The Catsters video about <a href="https://www.youtube.com/watch?v=4QgjKUzyrhM" target="_blank">representable functors</a>.	</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/">The Yoneda Lemma</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408312784" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			The Yoneda Lemma		</h2><p>Most constructions in category theory are generalizations of results from other more specific areas of mathematics. Things like products, coproducts, monoids, exponentials, etc., have been known long before category theory. They might have been known under different names in different branches of mathematics. A cartesian product in set theory, a meet in order theory, a conjunction in logic — they are all specific examples of the abstract idea of a categorical product.</p><p>The Yoneda lemma stands out in this respect as a sweeping statement about categories in general with little or no precedent in other branches of mathematics. Some say that its closest analog is Cayley’s theorem in group theory (every group is isomorphic to a permutation group of some set).</p><p>The setting for the Yoneda lemma is an arbitrary category <i>C</i> together with a functor <code>F</code> from <i>C</i> to <b>Set</b>. We’ve seen in the previous section that some <b>Set</b>-valued functors are representable, that is isomorphic to a hom-functor. The Yoneda lemma tells us that all <b>Set</b>-valued functors can be obtained from hom-functors through natural transformations, and it explicitly enumerates all such transformations.</p><p>When I talked about natural transformations, I mentioned that the naturality condition can be quite restrictive. When you define a component of a natural transformation at one object, naturality may be strong enough to “transport” this component to another object that is connected to it through a morphism. The more arrows between objects in the source and the target categories there are, the more constraints you have for transporting the components of natural transformations. <b>Set</b> happens to be a very arrow-rich category.</p><p>The Yoneda lemma tells us that a natural transformation between a hom-functor and any other functor <code>F</code> is completely determined by specifying the value of its single component at just one point! The rest of the natural transformation just follows from naturality conditions.</p><p>So let’s review the naturality condition between the two functors involved in the Yoneda lemma. The first functor is the hom-functor. It maps any object <code>x</code> in <i>C</i> to the set of morphisms <code>C(a, x)</code> — for <code>a</code> a fixed object in <i>C</i>. We’ve also seen that it maps any morphism <code>f</code> from <code>x</code> to <code>y</code> to <code>C(a, f)</code>.</p><p>The second functor is an arbitrary <b>Set</b>-valued functor <code>F</code>.</p><p>Let’s call the natural transformation between these two functors <code>α</code>. Because we are operating in <b>Set</b>, the components of the natural transformation, like <code>α<sub>x</sub></code> or <code>α<sub>y</sub></code>, are just regular functions between sets:</p><pre>α<sub>x</sub> :: C(a, x) -&gt; F x
 α<sub>y</sub> :: C(a, y) -&gt; F y</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1.png"><img data-attachment-id="4983" data-permalink="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/yoneda1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png" data-orig-size="295,291" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png?w=295" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png?w=295" class="alignnone wp-image-4983 " src="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png?w=263&amp;h=259" alt="Yoneda1" width="263" height="259" srcset="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png?w=263&amp;h=259 263w, https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png?w=150&amp;h=148 150w, https://bartoszmilewski.files.wordpress.com/2015/08/yoneda1-e1440290035365.png 295w" sizes="(max-width: 263px) 100vw, 263px"></a></p><p>And because these are just functions, we can look at their values at specific points. But what’s a point in the set <code>C(a, x)</code>? Here’s the key observation: Every point in the set <code>C(a, x)</code> is also a morphism <code>h</code> from <code>a</code> to <code>x</code>.</p><p>So the naturality square for <code>α</code>:</p><pre>α<sub>y</sub> ∘ C(a, f) = F f ∘ α<sub>x</sub></pre><p>becomes, point-wise, when acting on <code>h</code>:</p><pre>α<sub>y</sub> (C(a, f) h) = (F f) (α<sub>x</sub> h)</pre><p>You might recall from the previous section that the action of the hom-functor <code>C(a,-)</code> on a morphism <code>f</code> was defined as precomposition:</p><pre>C(a, f) h = f ∘ h</pre><p>which leads to:</p><pre>α<sub>y</sub> (f ∘ h) = (F f) (α<sub>x</sub> h)</pre><p>Just how strong this condition is can be seen by specializing it to the case of <code>x</code> equal to <code>a</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png"><img data-attachment-id="4987" data-permalink="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/yoneda2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png" data-orig-size="346,317" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png?w=300&amp;h=275" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png?w=346" class="alignnone size-medium wp-image-4987" src="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png?w=300&amp;h=275" alt="Yoneda2" width="300" height="275" srcset="https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png?w=300&amp;h=275 300w, https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png?w=150&amp;h=137 150w, https://bartoszmilewski.files.wordpress.com/2015/08/yoneda2.png 346w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>In that case <code>h</code> becomes a morphism from <code>a</code> to <code>a</code>. We know that there is at least one such morphism, <code>h = id<sub>a</sub></code>. Let’s plug it in:</p><pre>α<sub>y</sub> f = (F f) (α<sub>a</sub> id<sub>a</sub>)</pre><p>Notice what has just happened: The left hand side is the action of <code>α<sub>y</sub></code> on an arbitrary element <code>f</code> of <code>C(a, y)</code>. And it is totally determined by the single value of <code>α<sub>a</sub></code> at <code>id<sub>a</sub></code>. We can pick any such value and it will generate a natural transformation. Since the values of <code>α<sub>a</sub></code> are in the set <code>F a</code>, any point in <code>F a</code> will define some <code>α</code>.</p><p>Conversely, given any natural transformation <code>α</code> from <code>C(a, -)</code> to <code>F</code>, you can evaluate it at <code>id<sub>a</sub></code> to get a point in <code>F a</code>.</p><p>We have just proven the Yoneda lemma:</p><p class="box2">There is a one-to-one correspondence between natural transformations from <code>C(a, -)</code> to <code>F</code> and elements of <code>F a</code>.</p><p>in other words,</p><pre>Nat(C(a, -), F) ≅ F a</pre><p>Or, if we use the notation <code>[C, Set]</code> for the functor category between <i>C</i> and <b>Set</b>, the set of natural transformation is just a hom-set in that category, and we can write:</p><pre>[C, Set](C(a, -), F) ≅ F a</pre><p>I’ll explain later how this correspondence is in fact a natural isomorphism.</p><p>Now let’s try to get some intuition about this result. The most amazing thing is that the whole natural transformation crystallizes from just one nucleation site: the value we assign to it at <code>id<sub>a</sub></code>. It spreads from that point following the naturality condition. It floods the image of <i>C</i> in <b>Set</b>. So let’s first consider what the image of <i>C</i> is under <code>C(a, -)</code>.</p><p>Let’s start with the image of <code>a</code> itself. Under the hom-functor <code>C(a, -)</code>, <code>a</code> is mapped to the set <code>C(a, a)</code>. Under the functor <code>F</code>, on the other hand, it is mapped to the set <code>F a</code>. The component of the natural transformation <code>α<sub>a</sub></code> is some function from <code>C(a, a)</code> to <code>F a</code>. Let’s focus on just one point in the set <code>C(a, a)</code>, the point corresponding to the morphism <code>id<sub>a</sub></code>. To emphasize the fact that it’s just a point in a set, let’s call it <code>p</code>. The component <code>α<sub>a</sub></code> should map <code>p</code> to some point <code>q</code> in <code>F a</code>. I’ll show you that any choice of <code>q</code> leads to a unique natural transformation.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png"><img data-attachment-id="5217" data-permalink="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/yoneda3-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png?w=510" data-orig-size="252,283" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda3" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png?w=510?w=252" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png?w=510?w=252" class="alignnone wp-image-5217 size-full" src="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png?w=510" alt="Yoneda3" srcset="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png 252w, https://bartoszmilewski.files.wordpress.com/2015/09/yoneda3.png?w=134 134w" sizes="(max-width: 252px) 100vw, 252px"></a></p><p>The first claim is that the choice of one point <code>q</code> uniquely determines the rest of the function <code>α<sub>a</sub></code>. Indeed, let’s pick any other point, <code>p'</code> in <code>C(a, a)</code>, corresponding to some morphism <code>g</code> from <code>a</code> to <code>a</code>. And here’s where the magic of the Yoneda lemma happens: <code>g</code> can be viewed as a point <code>p'</code> in the set <code>C(a, a)</code>. At the same time, it selects two <em>functions</em> between sets. Indeed, under the hom-functor, the morphism <code>g</code> is mapped to a function <code>C(a, g)</code>; and under <code>F</code> it’s mapped to <code>F g</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png"><img data-attachment-id="5218" data-permalink="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/yoneda4-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=510" data-orig-size="433,343" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda4" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=510?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=510?w=433" class="alignnone wp-image-5218 size-full" src="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=510" alt="Yoneda4" srcset="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png 433w, https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=150 150w, https://bartoszmilewski.files.wordpress.com/2015/09/yoneda4.png?w=300 300w" sizes="(max-width: 433px) 100vw, 433px"></a></p><p>Now let’s consider the action of <code>C(a, g)</code> on our original <code>p</code> which, as you remember, corresponds to <code>id<sub>a</sub></code>. It is defined as precomposition, <code>g∘id<sub>a</sub></code>, which is equal to <code>g</code>, which corresponds to our point <code>p'</code>. So the morphism <code>g</code> is mapped to a function that, when acting on <code>p</code> produces <code>p'</code>, which is <code>g</code>. We have come full circle!</p><p>Now consider the action of <code>F g</code> on <code>q</code>. It is some <code>q'</code>, a point in <code>F a</code>. To complete the naturality square, <code>p'</code> must be mapped to <code>q'</code> under <code>α<sub>a</sub></code>. We picked an arbitrary <code>p'</code> (an arbitrary <code>g</code>) and derived its mapping under <code>α<sub>a</sub></code>. The function <code>α<sub>a</sub></code> is thus completely determined.</p><p>The second claim is that <code>α<sub>x</sub></code> is uniquely determined for any object <code>x</code> in <i>C</i> that is connected to <code>a</code>. The reasoning is analogous, except that now we have two more sets, <code>C(a, x)</code> and <code>F x</code>, and the morphism <code>g</code> from <code>a</code> to <code>x</code> is mapped, under the hom-functor, to:</p><pre>C(a, g) :: C(a, a) -&gt; C(a, x)</pre><p>and under <code>F</code> to:</p><pre>F g :: F a -&gt; F x</pre><p>Again, <code>C(a, g)</code> acting on our <code>p</code> is given by the precomposition: <code>g ∘ id<sub>a</sub></code>, which corresponds to a point <code>p'</code> in <code>C(a, x)</code>. Naturality determines the value of <code>α<sub>x</sub></code> acting on <code>p'</code> to be:</p><pre>q' = (F g) q</pre><p>Since <code>p'</code> was arbitrary, the whole function <code>α<sub>x</sub></code> is thus determined.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png"><img data-attachment-id="5219" data-permalink="https://bartoszmilewski.com/2015/09/01/the-yoneda-lemma/yoneda5-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=510" data-orig-size="449,354" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda5" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=510?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=510?w=449" class="alignnone wp-image-5219 size-full" src="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=510" alt="Yoneda5" srcset="https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png 449w, https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=150 150w, https://bartoszmilewski.files.wordpress.com/2015/09/yoneda5.png?w=300 300w" sizes="(max-width: 449px) 100vw, 449px"></a></p><p>What if there are objects in <i>C</i> that have no connection to <code>a</code>? They are all mapped under <code>C(a, -)</code> to a single set — the empty set. Recall that the empty set is the initial object in the category of sets. It means that there is a unique function from this set to any other set. We called this function <code>absurd</code>. So here, again, we have no choice for the component of the natural transformation: it can only be <code>absurd</code>.</p><p>One way of understanding the Yoneda lemma is to realize that natural transformations between <b>Set</b>-valued functors are just families of functions, and functions are in general lossy. A function may collapse information and it may cover only parts of its codomain. The only functions that are not lossy are the ones that are invertible — the isomorphisms. It follows then that the best structure-preserving <b>Set</b>-valued functors are the representable ones. They are either the hom-functors or&nbsp;the functors that are naturally isomorphic to hom-functors. Any other functor <code>F</code> is obtained from a hom-functor through a lossy transformation. Such a transformation may not only lose information, but it may also cover only a small part of the image of the functor <code>F</code> in <b>Set</b>.</p><h2>Yoneda in Haskell</h2><p>We have already encountered the hom-functor in Haskell under the guise of the reader functor:</p><pre>type Reader a x = a -&gt; x</pre><p>The reader maps morphisms (here, functions) by precomposition:</p><pre>instance Functor (Reader a) where
    fmap f h = f . h</pre><p>The Yoneda lemma tells us that the reader functor can be naturally mapped to any other functor.</p><p>A natural transformation is a polymorphic function. So given a functor <code>F</code>, we have a mapping to it from the reader functor:</p><pre>alpha :: forall x . (a -&gt; x) -&gt; F x</pre><p>As usual, <code>forall</code> is optional, but I like to write it explicitly to emphasize parametric polymorphism of natural transformations.</p><p>The Yoneda lemma tells us that these natural transformations are in one-to-one correspondence with the elements of <code>F a</code>:</p><pre>forall x . (a -&gt; x) -&gt; F x ≅ F a</pre><p>The right hand side of this identity is what we would normally consider a data structure. Remember the interpretation of functors as generalized containers? <code>F a</code> is a container of <code>a</code>. But the left hand side is a polymorphic function that takes a function as an argument. The Yoneda lemma tells us that the two representations are equivalent — they contain the same information.</p><p>Another way of saying this is: Give me a polymorphic function of the type:</p><pre>alpha :: forall x . (a -&gt; x) -&gt; F x</pre><p>and I’ll produce a container of <code>a</code>. The trick is the one we used in the proof of the Yoneda lemma: we call this function with <code>id</code> to get an element of <code>F a</code>:</p><pre>alpha id :: F a</pre><p>The converse is also true: Given a value of the type <code>F a</code>:</p><pre>fa :: F a</pre><p>one can define a polymorphic function:</p><pre>alpha h = fmap h fa</pre><p>of the correct type. You can easily go back and forth between the two representations.</p><p>The advantage of having multiple representations is that one might be easier to compose than the other, or that one might be more efficient in some applications than the other.</p><p>The simplest illustration of this principle is the code transformation that is often used in compiler construction: the continuation passing style or CPS. It’s the simplest application of the Yoneda lemma to the identity functor. Replacing <code>F</code> with identity produces:</p><pre>forall r . (a -&gt; r) -&gt; r ≅ a</pre><p>The interpretation of this formula is that any type <code>a</code> can be replaced by a function that takes a “handler” for <code>a</code>. A handler is a function accepting <code>a</code> and performing the rest of the computation — the continuation. (The type <code>r</code> usually encapsulates some kind of status code.)</p><p>This style of programming is very common in UIs, in asynchronous systems, and in concurrent programming. The drawback of CPS is that it involves inversion of control. The code is split between producers and consumers (handlers), and is not easily composable. Anybody who’s done any amount of nontrivial web programming is familiar with the nightmare of spaghetti code from interacting stateful handlers. As we’ll see later, judicious use of functors and monads can restore some compositional properties of CPS.</p><h2>Co-Yoneda</h2><p>As usual, we get a bonus construction by inverting the direction of arrows. The Yoneda lemma can be applied to the opposite category <i>C</i><sup>op</sup> to give us a mapping between contravariant functors.</p><p>Equivalently, we can derive the co-Yoneda lemma by fixing the target object of our hom-functors instead of the source. We get the contravariant hom-functor from <i>C</i> to <b>Set</b>: <code>C(-, a)</code>. The contravariant version of the Yoneda lemma establishes one-to-one correspondence between natural transformations from this functor to any other contravariant functor <code>F</code> and the elements of the set <code>F a</code>:</p><pre>Nat(C(-, a), F) ≅ F a</pre><p>Here’s the Haskell version of the co-Yoneda lemma:</p><pre>forall x . (x -&gt; a) -&gt; F x ≅ F a</pre><p>Notice that in some literature it’s the contravariant version that’s called the Yoneda lemma.</p><h2>Challenges</h2><ol>
 <li>Show that the two functions <code>phi</code> and <code>psi</code> that form the Yoneda isomorphism in Haskell are inverses of each other.
 <pre>phi :: (forall x . (a -&gt; x) -&gt; F x) -&gt; F a
 phi alpha = alpha id</pre>
 <pre>psi :: F a -&gt; (forall x . (a -&gt; x) -&gt; F x)
 psi fa h = fmap h fa</pre>
 </li>
 <li>A discrete category is one that has objects but no morphisms other than identity morphisms. How does the Yoneda lemma work for functors from such a category?</li>
 <li>A list of units <code>[()]</code> contains no other information but its length. So, as a data type, it can be considered an encoding of integers. An empty list encodes zero, a singleton <code>[()]</code> (a value, not a type) encodes one, and so on. Construct another representation of this data type using the Yoneda lemma for the list functor.</li>
 </ol><h2>Bibliography</h2><ol>
 <li><a href="https://www.youtube.com/watch?v=TLMxHB19khE" target="_blank">Catsters</a> video</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/10/28/yoneda-embedding/">Yoneda Embedding</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408324407" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Yoneda Embedding		</h2><p>We’ve seen previously that, when we fix an object <code>a</code> in the category <i>C</i>, the mapping <code>C(a, -)</code> is a (covariant) functor from <i>C</i> to <b>Set</b>.</p><pre>x -&gt; C(a, x)</pre><p>(The codomain is <b>Set</b> because the hom-set C(a, x) is a <em>set</em>.) We call this mapping a hom-functor — we have previously defined its action on morphisms as well.</p><p>Now let’s vary <code>a</code> in this mapping. We get a new mapping that assigns the hom-<em>functor</em> <code>C(a, -)</code> to any <code>a</code>.</p><pre>a -&gt; C(a, -)</pre><p>It’s a mapping of objects from category <i>C</i> to functors, which are <em>objects</em> in the functor category (see the section about functor categories in <a href="https://bartoszmilewski.com/2015/04/07/natural-transformations/" target="_blank">Natural Transformations</a>). Let’s use the notation <code>[C, Set]</code> for the functor category from <i>C</i> to <b>Set</b>. You may also recall that hom-functors are the prototypical <a href="https://bartoszmilewski.com/2015/07/29/representable-functors/" target="_blank">representable functors</a>.</p><p>Every time we have a mapping of objects between two categories, it’s natural to ask if such a mapping is also a functor. In other words whether we can lift a morphism from one category to a morphism in the other category. A morphism in <i>C</i> is just an element of <code>C(a, b)</code>, but a morphism in the functor category <code>[C, Set]</code> is a natural transformation. So we are looking for a mapping of morphisms to natural transformations.</p><p>Let’s see if we can find a natural transformation corresponding to a morphism <code>f :: a-&gt;b</code>. First, lets see what <code>a</code> and <code>b</code> are mapped to. They are mapped to two functors: <code>C(a, -)</code> and <code>C(b, -)</code>. We need a natural transformation between those two functors.</p><p>And here’s the trick: we use the Yoneda lemma:</p><pre>[C, Set](C(a, -), F) ≅ F a</pre><p>and replace the generic <code>F</code> with the hom-functor <code>C(b, -)</code>. We get:</p><pre>[C, Set](C(a, -), C(b, -)) ≅ C(b, a)</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg"><img data-attachment-id="4782" data-permalink="https://bartoszmilewski.com/2015/07/13/from-lenses-to-yoneda-embedding/yoneda-embedding/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg" data-orig-size="721,348" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1436191781&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda Embedding" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=372&amp;h=180" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=510" class="alignnone  wp-image-4782" src="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=372&amp;h=180" alt="Yoneda Embedding" width="372" height="180" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=372&amp;h=180 372w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=150&amp;h=72 150w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg?w=300&amp;h=145 300w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding.jpg 721w" sizes="(max-width: 372px) 100vw, 372px"></a></p><p>This is exactly the natural transformation between the two hom-functors we were looking for, but with a little twist: We have a mapping between a natural transformation and a morphism — an element of <code>C(b, a)</code> — that goes in the “wrong” direction. But that’s okay; it only means that the functor we are looking at is contravariant.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg"><img data-attachment-id="4783" data-permalink="https://bartoszmilewski.com/2015/07/13/from-lenses-to-yoneda-embedding/yoneda-embedding-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg" data-orig-size="785,286" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1436191781&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Yoneda Embedding 2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=433&amp;h=157" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=510" class="alignnone  wp-image-4783" src="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=433&amp;h=157" alt="Yoneda Embedding 2" width="433" height="157" srcset="https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=431&amp;h=157 431w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=150&amp;h=55 150w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=300&amp;h=109 300w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg?w=768&amp;h=280 768w, https://bartoszmilewski.files.wordpress.com/2015/07/yoneda-embedding-2.jpg 785w" sizes="(max-width: 433px) 100vw, 433px"></a></p><p>Actually, we’ve got even more than we bargained for. The mapping from <i>C</i> to <code>[C, Set]</code> is not only a contravariant functor — it is a <em>fully faithful</em> functor. Fullness and faithfulness are properties of functors that describe how they map hom-sets. </p><p>A <em>faithful</em> functor is <em>injective</em> on hom-sets, meaning that it maps distinct morphisms to distinct morphisms. In other words, it doesn’t coalesce them. </p><p>A <em>full</em> functor is <em>surjective</em> on hom-sets, meaning that it maps one hom-set <em>onto</em> the other hom-set, fully covering the latter. </p><p>A fully faithful functor <code>F</code> is a <em>bijection</em> on hom-sets — a one to one matching of all elements of both sets. For every pair of objects <code>a</code> and <code>b</code> in the source category <i>C</i> there is a bijection between <code>C(a, b)</code> and <code>D(F a, F b)</code>, where <i>D</i> is the target category of <code>F</code> (in our case, the functor category, <code>[C, Set]</code>). Notice that this doesn’t mean that <code>F</code> is a bijection on <i>objects</i>. There may be objects in <i>D</i> that are not in the image of <code>F</code>, and we can’t say anything about hom-sets for those objects.</p><h2>The Embedding</h2><p>The (contravariant) functor we have just described, the functor that maps objects in <i>C</i> to functors in <code>[C, Set]</code>:</p><pre>a -&gt; C(a, -)</pre><p>defines the <em>Yoneda embedding</em>. It <em>embeds</em> a category <i>C</i> (strictly speaking, the category <i>C<sup>op</sup></i>, because of contravariance) inside the functor category <code>[C, Set]</code>. It not only maps objects in <i>C</i> to functors, but also faithfully preserves all connections between them. </p><p>This is a very useful result because mathematicians know a lot about the category of functors, especially functors whose codomain is <b>Set</b>. We can get a lot of insight about an arbitrary category <i>C</i> by embedding it in the functor category.</p><p>Of course there is a dual version of the Yoneda embedding, sometimes called the co-Yoneda embedding. Observe that we could have started by fixing the target object (rather than the source object) of each hom-set, <code>C(-, a)</code>. That would give us a contravariant hom-functor. Contravariant functors from <i>C</i> to <b>Set</b> are our familiar presheaves (see, for instance, <a href="https://bartoszmilewski.com/2015/04/15/limits-and-colimits/" target="_blank">Limits and Colimits</a>). The co-Yoneda embedding defines the embedding of a category <i>C</i> in the category of presheaves. Its action on morphisms is given by:</p><pre>[C, Set](C(-, a), C(-, b)) ≅ C(a, b)</pre><p>Again, mathematicians know a lot about the category of presheaves, so being able to embed an arbitrary category in it is a big win.</p><h2>Application to Haskell</h2><p>In Haskell, the Yoneda embedding can be represented as the isomorphism between natural transformations amongst reader functors on the one hand, and functions (going in the opposite direction) on the other hand:</p><pre>forall x. (a -&gt; x) -&gt; (b -&gt; x) ≅ b -&gt; a</pre><p>(Remember, the reader functor is equivalent to <code>((-&gt;) a)</code>.)</p><p>The left hand side of this identity is a polymorphic function that, given a function from <code>a</code> to <code>x</code> and a value of type <code>b</code>, can produce a value of type <code>x</code> (I’m uncurrying — dropping the parentheses around — the function <code>b -&gt; x</code>). The only way this can be done for all <code>x</code> is if our function knows how to convert a <code>b</code> to an <code>a</code>. It has to secretly have access to a function <code>b-&gt;a</code>. </p><p>Given such a converter, <code>btoa</code>, one can define the left hand side, call it<code>fromY</code>, as:</p><pre>fromY :: (a -&gt; x) -&gt; b -&gt; x
 fromY f b = f (btoa b)</pre><p>Conversely, given a function <code>fromY</code> we can recover the converter by calling <code>fromY</code> with the identity:</p><pre>fromY id :: b -&gt; a</pre><p>This establishes the bijection between functions of the type <code>fromY</code> and <code>btoa</code>.</p><p>An alternative way of looking at this isomorphism is that it’s a CPS encoding of a function from <code>b</code> to <code>a</code>. The argument <code>a-&gt;x</code> is a continuation (the handler). The result is a function from <code>b</code> to <code>x</code> which, when called with a value of type <code>b</code>, will execute the continuation precomposed with the function being encoded. </p><p>The Yoneda embedding also explains some of the alternative representations of data structures in Haskell. In particular, it provides a very useful <a href="https://bartoszmilewski.com/2015/07/13/from-lenses-to-yoneda-embedding/" target="_blank">representation of lenses</a> from the <code>Control.Lens</code> library. </p><h2>Preorder Example</h2><p>This example was suggested by Robert Harper. It’s the application of the Yoneda embedding to a category defined by a preorder. A preorder is a set with an ordering relation between its elements that’s traditionally written as <code>&lt;=</code> (less than or equal). The “pre” in preorder is there because we’re only requiring the relation to be transitive and reflexive but not necessarily antisymmetric (so it’s possible to have cycles). </p><p>A set with the preorder relation gives rise to a category. The objects are the elements of this set. A morphism from object <code>a</code> to <code>b</code> either doesn’t exist, if the objects cannot be compared or if it’s not true that <code>a &lt;= b</code>; or it exists if <code>a &lt;= b</code>, and it points from <code>a</code> to <code>b</code>. There is never more than one morphism from one object to another. Therefore any hom-set in such a category is either an empty set or a one-element set. Such a category is called <em>thin</em>.</p><p>It’s easy to convince yourself that this construction is indeed a category: The arrows are composable because, if <code>a &lt;= b</code> and <code>b &lt;= c</code> then <code>a &lt;= c</code>; and the composition is associative. We also have the identity arrows because every element is (less than or) equal to itself (reflexivity of the underlying relation). </p><p>We can now apply the co-Yoneda embedding to a preorder category. In particular, we’re interested in its action on morphisms:</p><pre>[C, Set](C(-, a), C(-, b)) ≅ C(a, b)</pre><p>The hom-set on the right hand side is non-empty if and only if <code>a &lt;= b</code> — in which case it’s a one-element set. Consequently, if <code>a &lt;= b</code>, there exists a single natural transformation on the left. Otherwise there is no natural transformation.</p><p>So what’s a natural transformation between hom-functors in a preorder? It should be a family of functions between sets <code>C(-, a)</code> and <code>C(-, b)</code>. In a preorder, each of these sets can either be empty or a singleton. Let’s see what kind of functions are there at our disposal.</p><p>There is a function from an empty set to itself (the identity acting on an empty set), a function <code>absurd</code> from an empty set to a singleton set (it does nothing, since it only needs to be defined for elements of an empty set, of which there are none), and a function from a singleton to itself (the identity acting on a one-element set). The only combination that is forbidden is the mapping from a singleton to an empty set (what would the value of such a function be when acting on the single element?). </p><p>So our natural transformation will never connect a singleton hom-set to an empty hom-set. In other words, if <code>x &lt;= a</code> (singleton hom-set <code>C(x, a)</code>) then <code>C(x, b)</code> cannot be empty. A non-empty <code>C(x, b)</code> means that <code>x</code> is less or equal to <code>b</code>. So the existence of the natural transformation in question requires that, for every <code>x</code>, if <code>x &lt;= a</code> then <code>x &lt;= b</code>. </p><pre>for all x, x ≤ a ⇒ x ≤ b</pre><p>On the other hand, co-Yoneda tells us that the existence of this natural transformation is equivalent to <code>C(a, b)</code> being non-empty, or to <code>a &lt;= b</code>. Together, we get:</p><pre>a ≤ b if and only if for all x, x ≤ a ⇒ x ≤ b</pre><p>We could have arrived at this result directly. The intuition is that, if <code>a &lt;= b</code> then all elements that are below <code>a</code> must also be below <code>b</code>. Conversely, when you substitute <code>a</code> for <code>x</code> on the right hand side, it follows that <code>a &lt;= b</code>. But you must admit that arriving at this result through the Yoneda embedding is much more exciting.</p><h2>Naturality</h2><p>The Yoneda lemma establishes the isomorphism between the set of natural transformations and an object in <b>Set</b>. Natural transformations are morphisms in the functor category <code>[C, Set]</code>. The set of natural transformation between any two functors is a hom-set in that category. The Yoneda lemma is the isomorphism:</p><pre>[C, Set](C(a, -), F) ≅ F a</pre><p>This isomorphism turns out to be natural in both <code>F</code> and <code>a</code>. In other words, it’s natural in <code>(F, a)</code>, a pair taken from the product category <code>[C, Set] × C</code>. Notice that we are now treating <code>F</code> as an <em>object</em> in the functor category.</p><p>Let’s think for a moment what this means. A natural isomorphism is an invertible <em>natural transformation</em> between two functors. And indeed, the right hand side of our isomorphism is a functor. It’s a functor from <code>[C, Set] × C</code> to <b>Set</b>. Its action on a pair <code>(F, a)</code> is a set — the result of evaluating the functor <code>F</code> at the object <code>a</code>. This is called the evaluation functor.</p><p>The left hand side is also a functor that takes <code>(F, a)</code> to a set of natural transformations <code>[C, Set](C(a, -), F)</code>. </p><p>To show that these are really functors, we should also define their action on morphisms. But what’s a morphism between a pair <code>(F, a)</code> and <code>(G, b)</code>? It’s a pair of morphisms, <code>(Φ, f)</code>; the first being a morphism between functors — a natural transformation — the second being a regular morphism in <i>C</i>. </p><p>The evaluation functor takes this pair <code>(Φ, f)</code> and maps it to a function between two sets, <code>F a</code> and <code>G b</code>. We can easily construct such a function from the component of <code>Φ</code> at <code>a</code> (which maps <code>F a</code> to <code>G a</code>) and the morphism <code>f</code> lifted by <code>G</code>:</p><pre>(G f) ∘ Φ<sub>a</sub></pre><p>Notice that, because of naturality of <code>Φ</code>, this is the same as:</p><pre>Φ<sub>b</sub> ∘ (F f)</pre><p>I’m not going to prove the naturality of the whole isomorphism — after you’ve established what the functors are, the proof is pretty mechanical. It follows from the fact that our isomorphism is built up from functors and natural transformations. There is simply no way for it to go wrong. </p><h2>Challenges</h2><ol>
 <li>Express the co-Yoneda embedding in Haskell.</li>
 <li>Show that the bijection we established between <code>fromY</code> and <code>btoa</code> is an isomorphism (the two mappings are the inverse of each other).</li>
 <li>Work out the Yoneda embedding for a monoid. What functor corresponds to the monoid’s single object? What natural transformations correspond to monoid morphisms?</li>
 <li>What is the application of the <i>covariant</i> Yoneda embedding to preorders? (Question suggested by Gershom Bazerman.)</li>
 <li>Yoneda embedding can be used to embed an arbitrary functor category <code>[C, D]</code> in the functor category <code>[[C, D], Set]</code>. Figure out how it works on morphisms (which in this case are natural transformations).</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2015/11/17/its-all-about-morphisms/">It’s All About Morphisms</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408338659" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			It’s All About&nbsp;Morphisms		</h2><p>If I haven’t convinced you yet that category theory is all about morphisms then I haven’t done my job properly. Since the next topic is adjunctions, which are defined in terms of isomorphisms of hom-sets, it makes sense to review our intuitions about the building blocks of hom-sets. Also, you’ll see that adjunctions provide a more general language to describe a lot of constructions we’ve studied before, so it might help to review them too.</p><h2>Functors</h2><p>To begin with, you should really think of functors as mappings of morphisms — the view that’s emphasized in the Haskell definition of the <code>Functor</code> typeclass, which revolves around <code>fmap</code>. Of course, functors also map objects — the endpoints of morphisms — otherwise we wouldn’t be able to talk about preserving composition. Objects tell us which pairs of morphisms are composable. The target of one morphism must be equal to the source of the other — if they are to be composed. So if we want the composition of morphisms to be mapped to the composition of <em>lifted</em> morphisms, the mapping of their endpoints is pretty much determined.</p><h2>Commuting Diagrams</h2><p>A lot of properties of morphisms are expressed in terms of commuting diagrams. If a particular morphism can be described as a composition of other morphisms in more than one way, then we have a commuting diagram.</p><p>In particular, commuting diagrams form the basis of almost all universal constructions (with the notable exceptions of the initial and terminal objects). We’ve seen this in the definitions of products, coproducts, various other (co-)limits, exponential objects, free monoids, etc.</p><p>The product is a simple example of a universal construction. We pick two objects <code>a</code> and <code>b</code> and see if there exists an object <code>c</code>, together with a pair of morphisms <code>p</code> and <code>q</code>, that has the universal property of being their product.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg"><img data-attachment-id="3772" data-permalink="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/productranking/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg" data-orig-size="541,440" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.8&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 4&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1419437767&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.85&quot;,&quot;iso&quot;:&quot;80&quot;,&quot;shutter_speed&quot;:&quot;0.0043668122270742&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ProductRanking" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=171&amp;h=139" data-large-file="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=510" class="alignnone wp-image-3772" src="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=171&amp;h=139" alt="ProductRanking" width="171" height="139" srcset="https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=171&amp;h=139 171w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=342&amp;h=278 342w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=150&amp;h=122 150w, https://bartoszmilewski.files.wordpress.com/2014/12/productranking.jpg?w=300&amp;h=244 300w" sizes="(max-width: 171px) 100vw, 171px"></a></p><p>A product is a special case of a limit. A limit is defined in terms of cones. A general cone is built from commuting diagrams. Commutativity of those diagrams may be replaced with a suitable naturality condition for the mapping of functors. This way commutativity is reduced to the role of the assembly language for the higher level language of natural transformations.</p><h2>Natural Transformations</h2><p>In general, natural transformations are very convenient whenever we need a mapping from morphisms to commuting squares. Two opposing sides of a naturality square are the mappings of some morphism <code>f</code> under two functors <code>F</code> and <code>G</code>. The other sides are the components of the natural transformation (which are also morphisms).</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg"><img data-attachment-id="4349" data-permalink="https://bartoszmilewski.com/2015/04/07/natural-transformations/3_naturality/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg" data-orig-size="640,528" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;XP-520\/620 Series&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1427976202&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="3_Naturality" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=216&amp;h=179" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=510" class="alignnone wp-image-4349" src="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=216&amp;h=179" alt="3_Naturality" width="216" height="179" srcset="https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=216&amp;h=179 216w, https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=432&amp;h=356 432w, https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=150&amp;h=124 150w, https://bartoszmilewski.files.wordpress.com/2015/04/3_naturality.jpg?w=300&amp;h=248 300w" sizes="(max-width: 216px) 100vw, 216px"></a></p><p>Naturality means that when you move to the “neighboring” component (by neighboring I mean connected by a morphism), you’re not going against the structure of either the category or the functors. It doesn’t matter whether you first use a component of the natural transformation to bridge the gap between objects, and then jump to its neighbor using the functor; or the other way around. The two directions are orthogonal. A natural transformation moves you left and right, and the functors move you up and down or back and forth — so to speak. You can visualize the <em>image</em> of a functor as a sheet in the target category. A natural transformation maps one such sheet corresponding to F, to another, corresponding to G.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png"><img data-attachment-id="5221" data-permalink="https://bartoszmilewski.com/2015/11/17/its-all-about-morphisms/sheets/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=510" data-orig-size="325,272" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Sheets" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=510?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=510?w=325" class="alignnone size-full wp-image-5221" src="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=510" alt="Sheets" srcset="https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png 325w, https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=150 150w, https://bartoszmilewski.files.wordpress.com/2015/11/sheets.png?w=300 300w" sizes="(max-width: 325px) 100vw, 325px"></a></p><p>We’ve seen examples of this orthogonality in Haskell. There the action of a functor modifies the content of a container without changing its shape, while a natural transformation repackages the untouched contents into a different container. The order of these operations doesn’t matter.</p><p>We’ve seen the cones in the definition of a limit replaced by natural transformations. Naturality ensures that the sides of every cone commute. Still, a limit is defined in terms of mappings <em>between</em> cones. These mappings must also satisfy commutativity conditions. (For instance, the triangles in the definition of the product must commute.)</p><p>These conditions, too, may be replaced by naturality. You may recall that the <em>universal</em> cone, or the limit, is defined as a natural transformation between the (contravariant) hom-functor:</p><pre>F :: c -&gt; C(c, Lim D)</pre><p>and the (also contravariant) functor that maps objects in <i>C</i> to cones, which themselves are natural transformations:</p><pre>G :: c -&gt; Nat(Δ<sub>c</sub>, D)</pre><p>Here, <code>Δ<sub>c</sub></code> is the constant functor, and <code>D</code> is the functor that defines the diagram in <i>C</i>. Both functors <code>F</code> and <code>G</code> have well defined actions on morphisms in <i>C</i>. It so happens that this particular natural transformation between <code>F</code> and <code>G</code> is an <em>isomorphism</em>.</p><h2>Natural Isomorphisms</h2><p>A natural isomorphism — which is a natural transformation whose every component is reversible — is category theory’s way of saying that “two things are the same.” A component of such a transformation must be an isomorphism between objects — a morphism that has the inverse. If you visualize functor images as sheets, a natural isomorphism is a one-to-one invertible mapping between those sheets.</p><h2>Hom-Sets</h2><p>But what are morphisms? They do have more structure than objects: unlike objects, morphisms have two ends. But if you fix the source and the target objects, the morphisms between the two form a boring set (at least for locally small categories). We can give elements of this set names like <code>f</code> or <code>g</code>, to distinguish one from another — but what is it, really, that makes them different?</p><p>The essential difference between morphisms in a given hom-set lies in the way they compose with other morphisms (from abutting hom-sets). If there is a morphism <code>h</code> whose composition (either pre- or post-) with <code>f</code> is different than that with <code>g</code>, for instance:</p><pre>h ∘ f ≠ h ∘ g</pre><p>then we can directly “observe” the difference between <code>f</code> and <code>g</code>. But even if the difference is not directly observable, we might use functors to zoom in on the hom-set. A functor <code>F</code> may map the two morphisms to distinct morphisms:</p><pre>F f ≠ F g</pre><p>in a richer category, where the abutting hom-sets provide more resolution, e.g.,</p><pre>h' ∘ F f ≠ h' ∘ F g</pre><p>where <code>h'</code> is not in the image of <code>F</code>.</p><h2>Hom-Set Isomorphisms</h2><p>A lot of categorical constructions rely on isomorphisms between hom-sets. But since hom-sets are just sets, a plain isomorphism between them doesn’t tell you much. For finite sets, an isomorphism just says that they have the same number of elements. If the sets are infinite, their cardinality must be the same. But any meaningful isomorphism of hom-sets must take into account composition. And composition involves more than one hom-set. We need to define isomorphisms that span whole collections of hom-sets, and we need to impose some compatibility conditions that interoperate with composition. And a <em>natural</em> isomorphism fits the bill exactly.</p><p>But what’s a natural isomorphism of hom-sets? Naturality is a property of mappings between functors, not sets. So we are really talking about a natural isomorphism between hom-set-valued functors. These functors are more than just set-valued functors. Their action on morphisms is induced by the appropriate hom-functors. Morphisms are canonically mapped by hom-functors using either pre- or post-composition (depending on the covariance of the functor).</p><p>The Yoneda embedding is one example of such an isomorphism. It maps hom-sets in <i>C</i> to hom-sets in the functor category; and it’s natural. One functor in the Yoneda embedding is the hom-functor in <i>C</i> and the other maps objects to sets of natural transformations between hom-sets.</p><p>The definition of a limit is also a natural isomorphism between hom-sets (the second one, again, in the functor category):</p><pre>C(c, Lim D) ≃ Nat(Δ<sub>c</sub>, D)</pre><p>It turns out that our construction of an exponential object, or that of a free monoid, can also be rewritten as a natural isomorphism between hom-sets.</p><p>This is no coincidence — we’ll see next that these are just different examples of adjunctions, which are defined as natural isomorphisms of hom-sets.</p><h2>Asymmetry of Hom-Sets</h2><p>There is one more observation that will help us understand adjunctions. Hom-sets are, in general, not symmetric. A hom-set <code>C(a, b)</code> is often very different from the hom-set <code>C(b, a)</code>. The ultimate demonstration of this asymmetry is a partial order viewed as a category. In a partial order, a morphism from <code>a</code> to <code>b</code> exists if and only if <code>a</code> is less than or equal to <code>b</code>. If <code>a</code> and <code>b</code> are different, then there can be no morphism going the other way, from <code>b</code> to <code>a</code>. So if the hom-set <code>C(a, b)</code> is non-empty, which in this case means it’s a singleton set, then <code>C(b, a)</code> must be empty, unless <code>a = b</code>. The arrows in this category have a definite flow in one direction.</p><p>A preorder, which is based on a relation that’s not necessarily antisymmetric, is also “mostly” directional, except for occasional cycles. It’s convenient to think of an arbitrary category as a generalization of a preoder.</p><p>A preorder is a thin category — all hom-sets are either singletons or empty. We can visualize a general category as a “thick” preorder.</p><h2>Challenges</h2><ol>
 <li>Consider some degenerate cases of a naturality condition and draw the appropriate diagrams. For instance, what happens if either functor <code>F</code> or <code>G</code> map both objects <code>a</code> and <code>b</code> (the ends of <code>f :: a -&gt; b</code>) to the same object, e.g., <code>F a = F b</code> or <code>G a = G b</code>? (Notice that you get a cone or a co-cone this way.) Then consider cases where either <code>F a = G a</code> or <code>F b = G b</code>. Finally, what if you start with a morphism that loops on itself — <code>f :: a -&gt; a</code>?</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2016/04/18/adjunctions/" target="_blank">Adjunctions</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408353382" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Adjunctions		</h2><p>In mathematics we have various ways of saying that one thing is like another. The strictest is equality. Two things are equal if there is no way to distinguish one from another. One can be substituted for the other in every imaginable context. For instance, did you notice that we used <em>equality</em> of morphisms every time we talked about commuting diagrams? That’s because morphisms form a set (hom-set) and set elements can be compared for equality.</p><p>But equality is often too strong. There are many examples of things being the same for all intents and purposes, without actually being equal. For instance, the pair type <code>(Bool, Char)</code> is not strictly equal to <code>(Char, Bool)</code>, but we understand that they contain the same information. This concept is best captured by an <em>isomorphism</em> between two types — a morphism that’s invertible. Since it’s a morphism, it preserves the structure; and being “iso” means that it’s part of a round trip that lands you in the same spot, no matter on which side you start. In the case of pairs, this isomorphism is called <code>swap</code>:</p><pre>swap       :: (a,b) -&gt; (b,a)
 swap (a,b) = (b,a)</pre><p><code>swap</code> happens to be its own inverse.</p><h2>Adjunction and Unit/Counit Pair</h2><p>When we talk about categories being isomorphic, we express this in terms of mappings between categories, a.k.a. functors. We would like to be able to say that two categories <i>C</i> and <i>D</i> are isomorphic if there exists a functor <code>R</code> (“right”) from <i>C</i> to <i>D</i>, which is invertible. In other words, there exists another functor <code>L</code> (“left”) from <i>D</i> back to <i>C</i> which, when composed with <code>R</code>, is equal to the identity functor <code>I</code>. There are two possible compositions, <code>R ∘ L</code> and <code>L ∘ R</code>; and two possible identity functors: one in <i>C</i> and another in <i>D</i>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg" rel="attachment wp-att-5487"><img data-attachment-id="5487" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg" data-orig-size="1016,541" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj – 1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=300&amp;h=160" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=510" class="alignnone size-medium wp-image-5487" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=300&amp;h=160" alt="Adj - 1" width="300" height="160" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=300&amp;h=160 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=600&amp;h=320 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-1.jpg?w=150&amp;h=80 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>But here’s the tricky part: What does it mean for two functors to be <em>equal</em>? What do we mean by this equality:</p><pre>R ∘ L = I<sub>D</sub></pre><p>or this one:</p><pre>L ∘ R = I<sub>C</sub></pre><p>It would be reasonable to define functor equality in terms of equality of objects. Two functors, when acting on equal objects, should produce equal objects. But we don’t, in general, have the notion of object equality in an arbitrary category. It’s just not part of the definition. (Going deeper into this rabbit hole of “what equality really is,” we would end up in Homotopy Type Theory.)</p><p>You might argue that functors <em>are</em> morphisms in the category of categories, so they should be equality-comparable. And indeed, as long as we are talking about small categories, where objects form a set, we can indeed use the equality of elements of a set to equality-compare objects.</p><p>But, remember, <b>Cat</b> is really a 2-category. Hom-sets in a 2-category have additional structure — there are 2-morphisms acting between 1-morphisms. In <b>Cat</b>, 1-morphisms are functors, and 2-morphisms are natural transformations. So it’s more natural (can’t avoid this pun!) to consider natural isomorphisms as substitutes for equality when talking about functors.</p><p>So, instead of isomorphism of categories, it makes sense to consider a more general notion of <em>equivalence</em>. Two categories <i>C</i> and <i>D</i> are <em>equivalent</em> if we can find two functors going back and forth between them, whose composition (either way) is <em>naturally isomorphic</em> to the identity functor. In other words, there is a two-way natural transformation between the composition <code>R ∘ L</code> and the identity functor <code>I<sub>D</sub></code>, and another between <code>L ∘ R</code> and the identity functor <code>I<sub>C</sub></code>.</p><p>Adjunction is even weaker than equivalence, because it doesn’t require that the composition of the two functors be <em>isomorphic</em> to the identity functor. Instead it stipulates the existence of a <em>one way</em> natural transformation from <code>I<sub>D</sub></code> to <code>R∘L</code>, and another from <code>L∘R</code> to <code>I<sub>C</sub></code>. Here are the signatures of these two natural transformations:</p><pre>η :: I<sub>D</sub> -&gt; R ∘ L
 ε :: L ∘ R -&gt; I<sub>C</sub></pre><p>η is called the unit, and ε the counit of the adjunction.</p><p>Notice the asymmetry between these two definitions. In general, we don’t have the two remaining mappings:</p><pre>R ∘ L -&gt; I<sub>D</sub> -- not necessarily
 I<sub>C</sub> -&gt; L ∘ R -- not necessarily</pre><p>Because of this asymmetry, the functor <code>L</code> is called the <em>left adjoint</em> to the functor <code>R</code>, while the functor <code>R</code> is the right adjoint to <code>L</code>. (Of course, left and right make sense only if you draw your diagrams one particular way.)</p><p>The compact notation for the adjunction is:</p><pre>L ⊣ R</pre><p>To better understand the adjunction, let’s analyze the unit and the counit in more detail.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg" rel="attachment wp-att-5489"><img data-attachment-id="5489" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-unit/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg" data-orig-size="757,462" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-Unit" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=300&amp;h=183" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=510" class="alignnone size-medium wp-image-5489" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=300&amp;h=183" alt="Adj-Unit" width="300" height="183" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=300&amp;h=183 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=600&amp;h=366 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-unit.jpg?w=150&amp;h=92 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Let’s start with the unit. It’s a natural transformation, so it’s a family of morphisms. Given an object <code>d</code> in <i>D</i>, the component of η is a morphism between <code>I d</code>, which is equal to <code>d</code>, and <code>(R ∘ L) d</code>; which, in the picture, is called <code>d'</code>:</p><pre>η<sub>d</sub> :: d -&gt; (R ∘ L) d</pre><p>Notice that the composition <code>R∘L</code> is an endofunctor in <i>D</i>.</p><p>This equation tells us that we can pick any object <code>d</code> in <i>D</i> as our starting point, and use the round trip functor <code>R ∘ L</code> to pick our target object <code>d'</code>. Then we shoot an arrow — the morphism <code>η<sub>d</sub></code> — to our target.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg" rel="attachment wp-att-5490"><img data-attachment-id="5490" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-counit/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg" data-orig-size="786,474" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-Counit" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=300&amp;h=181" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=510" class="alignnone size-medium wp-image-5490" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=300&amp;h=181" alt="Adj-Counit" width="300" height="181" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=300&amp;h=181 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=600&amp;h=362 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-counit.jpg?w=150&amp;h=90 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>By the same token, the component of of the counit ε can be described as:</p><pre>ε<sub>c'</sub> :: (L ∘ R) c -&gt; c</pre><p>where <code>c'</code> is <code>(L ∘ R) c</code>. It tells us that we can pick any object <code>c</code> in <i>C</i> as our target, and use the round trip functor <code>L ∘ R</code> to pick the source <code>c'</code>. Then we shoot the arrow — the morphism <code>ε<sub>c'</sub></code> — from the source to the target.</p><p>Another way of looking at unit and counit is that unit lets us <i>introduce</i> the composition <code>R ∘ L</code> anywhere we could insert an identity functor on <i>D</i>; and counit lets us <i>eliminate</i> the composition <code>L ∘ R</code>, replacing it with the identity on <i>C</i>. That leads to some “obvious” consistency conditions, which make sure that introduction followed by elimination doesn’t change anything:</p><pre>L = L ∘ I<sub>D</sub> -&gt; L ∘ R ∘ L -&gt; I<sub>C</sub> ∘ L  = L</pre><pre>R = I<sub>D</sub> ∘ R -&gt; R ∘ L ∘ R -&gt; R ∘ I<sub>C</sub> = R</pre><p>These are called triangular identities because they make the following diagrams commute: </p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png"><img data-attachment-id="8382" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/triangles/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png" data-orig-size="424,307" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="triangles" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=209&amp;h=151" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=424" class="alignnone wp-image-8382" src="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=209&amp;h=151" alt="triangles" width="209" height="151" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=209&amp;h=151 209w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=418&amp;h=302 418w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=150&amp;h=109 150w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles.png?w=300&amp;h=217 300w" sizes="(max-width: 209px) 100vw, 209px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png"><img data-attachment-id="8381" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/triangles-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png" data-orig-size="458,299" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="triangles-2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=211&amp;h=138" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=458" class=" alignnone wp-image-8381" src="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=211&amp;h=138" alt="triangles-2" width="211" height="138" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=211&amp;h=138 211w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=422&amp;h=276 422w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=150&amp;h=98 150w, https://bartoszmilewski.files.wordpress.com/2017/02/triangles-2.png?w=300&amp;h=196 300w" sizes="(max-width: 211px) 100vw, 211px"></a><br>
 These are diagrams in the functor category: the arrows are natural transformations, and their composition is the horizontal composition of natural transformations. In components, these identities become:</p><pre>ε<sub> L d</sub> ∘ L η<sub> d</sub> = id<sub> L d</sub>
 R ε<sub> c</sub> ∘ η<sub> R c</sub> = id<sub> R c</sub></pre><p>We often see unit and counit in Haskell under different names. Unit is known as <code>return</code> (or <code>pure</code>, in the definition of <code>Applicative</code>):</p><pre>return :: d -&gt; m d</pre><p>and counint as <code>extract</code>:</p><pre>extract :: w c -&gt; c</pre><p>Here, <code>m</code> is the (endo-) functor corresponding to <code>R∘L</code>, and <code>w</code> is the (endo-) functor corresponding to <code>L∘R</code>. As we’ll see later, they are part of the definition of a monad and a comonad, respectively.</p><p>If you think of an endofunctor as a container, the unit (or <code>return</code>) is a polymorphic function that creates a default box around a value of arbitrary type. The counit (or <code>extract</code>) does the reverse: it retrieves or produces a single value from a container.</p><p>We’ll see later that every pair of adjoint functors defines a monad and a comonad. Conversely, every monad or comonad may be factorized into a pair of adjoint functors — this factorization is not unique, though.</p><p>In Haskell, we use monads a lot, but only rarely factorize them into pairs of adjoint functors, primarily because those functors would normally take us out of <b>Hask</b>.</p><p>We can however define adjunctions of <em>endofunctors</em> in Haskell. Here’s part of the definition taken from <code>Data.Functor.Adjunction</code>:</p><pre>class (Functor f, Representable u) =&gt;
      Adjunction f u | f -&gt; u, u -&gt; f where
  unit         :: a -&gt; u (f a)
  counit       :: f (u a) -&gt; a
 </pre><p>This definition requires some explanation. First of all, it describes a multi-parameter type class — the two parameters being <code>f</code> and <code>u</code>. It establishes a relation called <code>Adjunction</code> between these two type constructors.</p><p>Additional conditions, after the vertical bar, specify functional dependencies. For instance, <code>f -&gt; u</code> means that <code>u</code> is determined by <code>f</code> (the relation between <code>f</code> and <code>u</code> is a function, here on type constructors). Conversely, <code>u -&gt; f</code> means that, if we know <code>u</code>, then <code>f</code> is uniquely determined.</p><p>I’ll explain in a moment why, in Haskell, we can impose the condition that the right adjoint <code>u</code> be a <em>representable</em> functor.</p><h2>Adjunctions and Hom-Sets</h2><p>There is an equivalent definition of the adjunction in terms of natural isomorphisms of hom-sets. This definition ties nicely with universal constructions we’ve been studying so far. Every time you hear the statement that there is some unique morphism, which factorizes some construction, you should think of it as a mapping of some set to a hom-set. That’s the meaning of “picking a unique morphism.”</p><p>Furthermore, factorization can be often described in terms of natural transformations. Factorization involves commuting diagrams — some morphism being equal to a composition of two morphisms (factors). A natural transformation maps morphisms to commuting diagrams. So, in a universal construction, we go from a morphism to a commuting diagram, and then to a unique morphism. We end up with a mapping from morphism to morphism, or from one hom-set to another (usually in different categories). If this mapping is invertible, and if it can be naturally extended across all hom-sets, we have an adjunction.</p><p>The main difference between universal constructions and adjunctions it that the latter are defined globally — for all hom-sets. For instance, using a universal construction you can define a product of two select objects, even if it doesn’t exist for any other pair of objects in that category. As we’ll see soon, if the product of <em>any pair</em> of objects exists in a category, it can be also defined through an adjunction.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg" rel="attachment wp-att-5491"><img data-attachment-id="5491" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-homsets/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg" data-orig-size="992,680" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-HomSets" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=300&amp;h=206" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=510" class="alignnone size-medium wp-image-5491" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=300&amp;h=206" alt="Adj-HomSets" width="300" height="206" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=300&amp;h=206 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=600&amp;h=412 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-homsets.jpg?w=150&amp;h=103 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Here’s the alternative definition of the adjunction using hom-sets. As before, we have two functors <code>L :: D-&gt;C</code> and <code>R :: C-&gt;D</code>. We pick two arbitrary objects: the source object <code>d</code> in <i>D</i>, and the target object <code>c</code> in <i>C</i>. We can map the source object <code>d</code> to <i>C</i> using <code>L</code>. Now we have two objects in <i>C</i>, <code>L d</code> and <code>c</code>. They define a hom-set:</p><pre>C(L d, c)</pre><p>Similarly, we can map the target object <code>c</code> using <code>R</code>. Now we have two objects in <i>D</i>, <code>d</code> and <code>R c</code>. They, too, define a hom set:</p><pre>D(d, R c)</pre><p>We say that <code>L</code> is left adjoint to <code>R</code> iff there is an isomorphism of hom sets:</p><pre>C(L d, c) ≅ D(d, R c)</pre><p>that is natural both in <code>d</code> and <code>c</code>.</p><p>Naturality means that the source <code>d</code> can be varied smoothly across <i>D</i>; and the target <code>c</code>, across <i>C</i>. More precisely, we have a natural transformation <code>φ</code> between the following two (covariant) functors from <i>C</i> to <b>Set</b>. Here’s the action of these functors on objects:</p><pre>c -&gt; C(L d, c)
 c -&gt; D(d, R c)</pre><p>The other natural transformation, <code>ψ</code>, acts between the following (contravariant) functors:</p><pre>d -&gt; C(L d, c)
 d -&gt; D(d, R c)</pre><p>Both natural transformations must be invertible.</p><p>It’s easy to show that the two definitions of the adjunction are equivalent. For instance, let’s derive the unit transformation starting from the isomorphism of hom-sets:</p><pre>C(L d, c) ≅ D(d, R c)</pre><p>Since this isomorphism works for any object <code>c</code>, it must also work for <code>c = L d</code>:</p><pre>C(L d, L d) ≅ D(d, (R ∘ L) d)</pre><p>We know that the left hand side must contain at least one morphism, the identity. The natural transformation will map this morphism to an element of <code>D(d, (R ∘ L) d)</code> or, inserting the identity functor <code>I</code>, a morphism in:</p><pre>D(I d, (R ∘ L) d)</pre><p>We get a family of morphisms parameterized by <code>d</code>. They form a natural transformation between the functor <code>I</code> and the functor <code>R ∘ L</code> (the naturality condition is easy to verify). This is exactly our unit, <code>η</code>.</p><p>Conversely, starting from the existence of the unit and co-unit, we can define the transformations between hom-sets. For instance, let’s pick an arbitrary morphism <code>f</code> in the hom-set <code>C(L d, c)</code>. We want to define a <code>φ</code> that, acting on <code>f</code>, produces a morphism in <code>D(d, R c)</code>.</p><p>There isn’t really much choice. One thing we can try is to lift <code>f</code> using <code>R</code>. That will produce a morphism <code>R f</code> from <code>R (L d)</code> to <code>R c</code> — a morphism that’s an element of <code>D((R ∘ L) d, R c)</code>.</p><p>What we need for a component of <code>φ</code>, is a morphism from <code>d</code> to <code>R c</code>. That’s not a problem, since we can use a component of <code>η<sub>d</sub></code> to get from <code>d</code> to <code>(R ∘ L) d</code>. We get:</p><pre>φ<sub>f</sub> = R f ∘ η<sub>d</sub></pre><p>The other direction is analogous, and so is the derivation of <code>ψ</code>.</p><p>Going back to the Haskell definition of <code>Adjunction</code>, the natural transformations <code>φ</code> and <code>ψ</code> are replaced by polymorphic (in <code>a</code> and <code>b</code>) functions <code>leftAdjunct</code> and <code>rightAdjunct</code>, respectively. The functors <code>L</code> and <code>R</code> are called <code>f</code> and <code>u</code>:</p><pre>class (Functor f, Representable u) =&gt;
      Adjunction f u | f -&gt; u, u -&gt; f where
  leftAdjunct  :: (f a -&gt; b) -&gt; (a -&gt; u b)
  rightAdjunct :: (a -&gt; u b) -&gt; (f a -&gt; b)
 </pre><p>The equivalence between the <code>unit</code>/<code>counit</code> formulation and the <code>leftAdjunct</code>/<code>rightAdjunct</code> formulation is witnessed by these mappings:</p><pre>  unit           = leftAdjunct id
  counit         = rightAdjunct id
  leftAdjunct f  = fmap f . unit
  rightAdjunct f = counit . fmap f
 </pre><p>It’s very instructive to follow the translation from the categorical description of the adjunction to Haskell code. I highly encourage this as an exercise.</p><p>We are now ready to explain why, in Haskell, the right adjoint is automatically a <a href="https://bartoszmilewski.com/2015/07/29/representable-functors/" target="_blank">representable functor</a>. The reason for this is that, to the first approximation, we can treat the category of Haskell types as the category of sets.</p><p>When the right category <i>D</i> is <b>Set</b>, the right adjoint <code>R</code> is a functor from <i>C</i> to <b>Set</b>. Such a functor is representable if we can find an object <code>rep</code> in <i>C</i> such that the hom-functor <code>C(rep, _)</code> is naturally isomorphic to <code>R</code>. It turns out that, if <code>R</code> is the right adjoint of some functor <code>L</code> from <b>Set</b> to <i>C</i>, such an object always exists — it’s the image of the singleton set <code>()</code> under <code>L</code>:</p><pre>rep = L ()</pre><p>Indeed, the adjunction tells us that the following two hom-sets are naturally isomorphic:</p><pre>C(L (), c) ≅ Set((), R c)</pre><p>For a given <code>c</code>, the right hand side is the set of functions from the singleton set <code>()</code> to <code>R c</code>. We’ve seen earlier that each such function picks one element from the set <code>R c</code>. The set of such functions is isomorphic to the set <code>R c</code>. So we have:</p><pre>C(L (), -) ≅ R</pre><p>which shows that <code>R</code> is indeed representable.</p><h2>Product from Adjunction</h2><p>We have previously introduced several concepts using universal constructions. Many of those concepts, when defined globally, are easier to express using adjunctions. The simplest non-trivial example is that of the product. The gist of the <a href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" target="_blank">universal construction of the product</a> is the ability to factorize any product-like candidate through the universal product.</p><p>More precisely, the product of two objects <code>a</code> and <code>b</code> is the object <code>(a × b)</code> (or <code>(a, b)</code> in the Haskell notation) equipped with two morphisms <code>fst</code> and <code>snd</code> such that, for any other candidate <code>c</code> equipped with two morphisms <code>p::c-&gt;a</code> and <code>q::c-&gt;b</code>, there exists a unique morphism <code>m::c-&gt;(a, b)</code> that factorizes <code>p</code> and <code>q</code> through <code>fst</code> and <code>snd</code>.</p><p>As we’ve seen <a href="https://bartoszmilewski.com/2015/01/07/products-and-coproducts/" target="_blank">earlier</a>, in Haskell, we can implement a <code>factorizer</code> that generates this morphism from the two projections:</p><pre>factorizer :: (c -&gt; a) -&gt; (c -&gt; b) -&gt; (c -&gt; (a, b))
 factorizer p q = \x -&gt; (p x, q x)</pre><p>It’s easy to verify that the factorization conditions hold:</p><pre>fst . factorizer p q = p
 snd . factorizer p q = q</pre><p>We have a mapping that takes a pair of morphisms <code>p</code> and <code>q</code> and produces another morphism <code>m = factorizer p q</code>.</p><p>How can we translate this into a mapping between two hom-sets that we need to define an adjunction? The trick is to go outside of <b>Hask</b> and treat the pair of morphisms as a single morphism in the product category.</p><p>Let me remind you what a product category is. Take two arbitrary categories <i>C</i> and <i>D</i>. The objects in the product category <i>C×D</i> are pairs of objects, one from <i>C</i> and one from <i>D</i>. The morphisms are pairs of morphisms, one from <i>C</i> and one from <i>D</i>.</p><p>To define a product in some category <i>C</i>, we should start with the product category <i>C×C</i>. Pairs of morphism from <i>C</i> are single morphisms in the product category <i>C×C</i>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg" rel="attachment wp-att-5492"><img data-attachment-id="5492" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-productcat/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg" data-orig-size="1120,832" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-ProductCat" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=300&amp;h=223" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=510" class="alignnone size-medium wp-image-5492" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=300&amp;h=223" alt="Adj-ProductCat" width="300" height="223" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=300&amp;h=223 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=600&amp;h=446 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-productcat.jpg?w=150&amp;h=111 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>It might be a little confusing at first that we are using a product category to define a product. These are, however, very different products. We don’t need a universal construction to define a product category. All we need is the notion of a pair of objects and a pair of morphisms.</p><p>However, a pair of objects from <i>C</i> is <em>not</em> an object in <i>C</i>. It’s an object in a different category, <i>C×C</i>. We can write the pair formally as <code>&lt;a, b&gt;</code>, where <code>a</code> and <code>b</code> are objects of <i>C</i>. The universal construction, on the other hand, is necessary in order to define the object <code>a×b</code> (or <code>(a, b)</code> in Haskell), which is an object in <em>the same</em> category <i>C</i>. This object is supposed to represent the pair <code>&lt;a, b&gt;</code> in a way specified by the universal construction. It doesn’t always exist and, even if it exists for some, might not exist for other pairs of objects in <i>C</i>.</p><p>Let’s now look at the <code>factorizer</code> as a mapping of hom-sets. The first hom-set is in the product category <i>C×C</i>, and the second is in <i>C</i>. A general morphism in <i>C×C</i> would be a pair of morphisms <code>&lt;f, g&gt;</code>:</p><pre>f :: c' -&gt; a
 g :: c'' -&gt; b</pre><p>with <code>c''</code> potentially different from <code>c'</code>. But to define a product, we are interested in a special morphism in <i>C×C</i>, the pair <code>p</code> and <code>q</code> that share the same source object <code>c</code>. That’s okay: In the definition of an adjuncion, the source of the left hom-set is not an arbitrary object — it’s the result of the left functor <code>L</code> acting on some object from the right category. The functor that fits the bill is easy to guess — it’s the diagonal functor from <i>C</i> to <i>C×C</i>, whose action on objects is:</p><pre>Δ c = &lt;c, c&gt;</pre><p>The left-hand side hom-set in our adjunction should thus be:</p><pre>(C×C)(Δ c, &lt;a, b&gt;)</pre><p>It’s a hom-set in the product category. Its elements are pairs of morphisms that we recognize as the arguments to our <code>factorizer</code>:</p><pre>(c -&gt; a) -&gt; (c -&gt; b) ...</pre><p>The right-hand side hom-set lives in <i>C</i>, and it goes between the source object <code>c</code> and the result of some functor <code>R</code> acting on the target object in <i>C×C</i>. That’s the functor that maps the pair <code>&lt;a, b&gt;</code> to our product object, <code>a×b</code>. We recognize this element of the hom-set as the <em>result</em> of the <code>factorizer</code>:</p><pre>... -&gt; (c -&gt; (a, b))</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg" rel="attachment wp-att-5493"><img data-attachment-id="5493" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-product/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg" data-orig-size="1341,867" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-Product" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=300&amp;h=194" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=510" class="alignnone size-medium wp-image-5493" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=300&amp;h=194" alt="Adj-Product" width="300" height="194" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=300&amp;h=194 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=600&amp;h=388 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-product.jpg?w=150&amp;h=97 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>We still don’t have a full adjunction. For that we first need our <code>factorizer</code> to be invertible — we are building an <em>isomorphism</em> between hom-sets. The inverse of the <code>factorizer</code> should start from a morphism <code>m</code> — a morphism from some object <code>c</code> to the product object <code>a×b</code>. In other words, <code>m</code> should be an element of:</p><pre>C(c, a×b)</pre><p>The inverse factorizer should map <code>m</code> to a morphism <code>&lt;p, q&gt;</code> in <i>C×C</i> that goes from <code>&lt;c, c&gt;</code> to <code>&lt;a, b&gt;</code>; in other words, a morphism that’s an element of:</p><pre>(C×C)(Δ c, &lt;a, b&gt;)</pre><p>If that mapping exists, we conclude that there exists the right adjoint to the diagonal functor. That functor defines a product.</p><p>In Haskell, we can always construct the inverse of the <code>factorizer</code> by composing <code>m</code> with, respectively, <code>fst</code> and <code>snd</code>.</p><pre>p = fst ∘ m
 q = snd ∘ m</pre><p>To complete the proof of the equivalence of the two ways of defining a product we also need to show that the mapping between hom-sets is natural in <code>a</code>, <code>b</code>, and <code>c</code>. I will leave this as an exercise for the dedicated reader.</p><p>To summarize what we have done: A categorical product may be defined globally as the <em>right adjoint</em> of the diagonal functor:</p><pre>(C × C)(Δ c, &lt;a, b&gt;) ≅ C(c, a×b)</pre><p>Here, <code>a×b</code> is the result of the action of our right adjoint functor <code>Product</code> on the pair <code>&lt;a, b&gt;</code>. Notice that any functor from <i>C×C</i> is a bifunctor, so <code>Product</code> is a bifunctor. In Haskell, the <code>Product</code> bifunctor is written simply as <code>(,)</code>. You can apply it to two types and get their product type, for instance:</p><pre>(,) Int Bool ~ (Int, Bool)</pre><h2>Exponential from Adjunction</h2><p>The exponential <code>b<sup>a</sup></code>, or the function object <code>a⇒b</code>, can be defined using a <a href="https://bartoszmilewski.com/2015/03/13/function-types/" target="_blank">universal construction</a>. This construction, if it exists for all pairs of objects, can be seen as an adjunction. Again, the trick is to concentrate on the statement:</p><p>This statement establishes a mapping between hom-sets.</p><p>In this case, we are dealing with objects in the same category, so the two adjoint functors are endofunctors. The left (endo-)functor <code>L</code>, when acting on object <code>z</code>, produces <code>z × a</code>. It’s a functor that corresponds to taking a product with some fixed <code>a</code>.</p><p>The right (endo-)functor <code>R</code>, when acting on <code>b</code> produces the function object <code>a⇒b</code> (or <code>b<sup>a</sup></code>). Again, <code>a</code> is fixed. The adjunction between these two functors is often written as:</p><pre>- × a ⊣ (-)<sup>a</sup></pre><p>The mapping of hom-sets that underlies this adjunction is best seen by redrawing the diagram that we used in the universal construction.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg" rel="attachment wp-att-5494"><img data-attachment-id="5494" data-permalink="https://bartoszmilewski.com/2016/04/18/adjunctions/adj-expo/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg" data-orig-size="903,543" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1459589918&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0020703933747412&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Adj-Expo" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=300&amp;h=180" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=510" class="alignnone size-medium wp-image-5494" src="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=300&amp;h=180" alt="Adj-Expo" width="300" height="180" srcset="https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=300&amp;h=180 300w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=600&amp;h=360 600w, https://bartoszmilewski.files.wordpress.com/2016/04/adj-expo.jpg?w=150&amp;h=90 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that the <code>eval</code> morphism is nothing else but the counit of this adjunction:</p><pre>(a⇒b) × a -&gt; b</pre><p>where:</p><pre>(a⇒b) × a = (L ∘ R) b</pre><p>I have previously mentioned that a universal construction defines a unique object, up to isomorphism. That’s why we have “the” product and “the” exponential. This property translates to adjunctions as well: if a functor has an adjoint, this adjoint is unique up to isomorphism.</p><h2>Challenges</h2><ol>
 <li>Derive the naturality square for <code>ψ</code>, the transformation between the two (contravariant) functors:
 <pre>a -&gt; C(L a, b)
 a -&gt; D(a, R b)</pre>
 </li>
 <li>Derive the counit <code>ε</code> starting from the hom-sets isomorphism in the second definition of the adjunction.</li>
 <li>Complete the proof of equivalence of the two definitions of the adjunction.</li>
 <li>Show that the coproduct can be defined by an adjunction. Start with the definition of the factorizer for a coproduct.</li>
 <li>Show that the coproduct is the left adjoint of the diagonal functor.</li>
 <li>Define the adjunction between a product and a function object in Haskell.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2016/06/15/freeforgetful-adjunctions/">Free/Forgetful Adjunctions</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Edward Kmett and Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408370234" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Free/Forgetful Adjunctions		</h2><h2>Free Monoid from Adjunction</h2><p>Free constructions are a powerful application of adjunctions. A <em>free functor</em> is defined as the left adjoint to a <em>forgetful functor</em>. A forgetful functor is usually a pretty simple functor that forgets some structure. For instance, lots of interesting categories are built on top of sets. But categorical objects, which abstract those sets, have no internal structure — they have no elements. Still, those objects often carry the memory of sets, in the sense that there is a mapping — a functor — from a given category <i>C</i> to <b>Set</b>. A set corresponding to some object in <i>C</i> is called its <em>underlying set</em>.</p><p>Monoids are such objects that have underlying sets — sets of elements. There is a forgetful functor <code>U</code> from the category of monoids <b>Mon</b> to the category of sets, which maps monoids to their underlying sets. It also maps monoid morphisms (homomorphisms) to functions between sets.</p><p>I like to think of <b>Mon</b> as having split personality. On the one hand, it’s a bunch of sets with multiplication and unit elements. On the other hand, it’s a category with featureless objects whose only structure is encoded in morphisms that go between them. Every set-function that preserves multiplication and unit gives rise to a morphism in <b>Mon</b>.</p><p>Things to keep in mind:</p><ul>
 <li>There may be many monoids that map to the same set, and</li>
 <li>There are fewer (or at most as many as) monoid morphisms than there are functions between their underlying sets.</li>
 </ul><p>The functor <code>F</code> that’s the left adjoint to the forgetful functor <code>U</code> is the free functor that builds free monoids from their generator sets. The adjunction follows from the <a href="https://bartoszmilewski.com/2015/07/21/free-monoids/" target="_blank">free monoid universal construction</a> we’ve discussed before.</p><p>In terms of hom-sets, we can write this adjunction as:</p><pre>Mon(F x, m) ≅ Set(x, U m)</pre><p>This (natural in <code>x</code> and <code>m</code>) isomorphism tells us that:</p><ul>
 <li>For every monoid homomorphism between the free monoid <code>F x</code> generated by <code>x</code> and an arbitrary monoid <code>m</code> there is a unique function that embeds the set of generators <code>x</code> in the underlying set of <code>m</code>. It’s a function in <code>Set(x, U m)</code>.</li>
 <li>For every function that embeds <code>x</code> in the underlying set of some <code>m</code> there is a unique monoid morphism between the free monoid generated by <code>x</code> and the monoid <code>m</code>. (This is the morphism we called <code>h</code> in our universal construction.)</li>
 </ul><p><a href="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg"><img data-attachment-id="5534" data-permalink="https://bartoszmilewski.com/2016/06/15/freeforgetful-adjunctions/freemonadjunction/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg" data-orig-size="1644,653" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1463508588&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0017064846416382&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FreeMonAdjunction" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=512&amp;h=203" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=510" class="alignnone wp-image-5534" src="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=512&amp;h=203" alt="FreeMonAdjunction" width="512" height="203" srcset="https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=512&amp;h=203 512w, https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=1022&amp;h=406 1022w, https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=150&amp;h=60 150w, https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=300&amp;h=119 300w, https://bartoszmilewski.files.wordpress.com/2016/05/freemonadjunction.jpg?w=768&amp;h=305 768w" sizes="(max-width: 512px) 100vw, 512px"></a></p><p>The intuition is that <code>F x</code> is the “maximum” monoid that can be built on the basis of <code>x</code>. If we could look inside monoids, we would see that any morphism that belongs to <code>Mon(F x, m)</code> <em>embeds</em> this free monoid in some other monoid <code>m</code>. It does it by possibly identifying some elements. In particular, it embeds the generators of <code>F x</code> (i.e., the elements of <code>x</code>) in <code>m</code>. The adjunction shows that the embedding of <code>x</code>, which is given by a function from <code>Set(x, U m)</code> on the right, uniquely determines the embedding of monoids on the left, and vice versa.</p><p>In Haskell, the list data structure is a free monoid (with some caveats: see <a href="http://comonad.com/reader/2015/free-monoids-in-haskell/" target="_blank">Dan Doel’s blog post</a>). A list type <code>[a]</code> is a free monoid with the type <code>a</code> representing the set of generators. For instance, the type <code>[Char]</code> contains the unit element — the empty list <code>[]</code> — and the singletons like <code>['a']</code>, <code>['b']</code> — the generators of the free monoid. The rest is generated by applying the “product.” Here, the product of two lists simply appends one to another. Appending is associative and unital (that is, there is a neutral element — here, the empty list). A free monoid generated by <code>Char</code> is nothing but the set of all strings of characters from <code>Char</code>. It’s called <code>String</code> in Haskell:</p><pre>type String = [Char]</pre><p>(<code>type</code> defines a type synonym — a different name for an existing type).</p><p>Another interesting example is a free monoid built from just one generator. It’s the type of the list of units, <code>[()]</code>. Its elements are <code>[]</code>, <code>[()]</code>, <code>[(), ()]</code>, etc. Every such list can be described by one natural number — its length. There is no more information encoded in the list of units. Appending two such lists produces a new list whose length is the sum of the lengths of its constituents. It’s easy to see that the type <code>[()]</code> is isomorphic to the additive monoid of natural numbers (with zero). Here are the two functions that are the inverse of each other, witnessing this isomorphism:</p><pre>toNat :: [()] -&gt; Int
 toNat = length

 toLst :: Int -&gt; [()]
 toLst n = replicate n ()</pre><p>For simplicity I used the type <code>Int</code> rather than <code>Natural</code>, but the idea is the same. The function <code>replicate</code> creates a list of length <code>n</code> pre-filled with a given value — here, the unit.</p><h2>Some Intuitions</h2><p>What follows are some hand-waving arguments. Those kind of arguments are far from rigorous, but they help in forming intuitions.</p><p>To get some intuition about the free/forgetful adjunctions it helps to keep in mind that functors and functions are lossy in nature. Functors may collapse multiple objects and morphisms, functions may bunch together multiple elements of a set. Also, their image may cover only part of their codomain.</p><p>An “average” hom-set in <b>Set</b> will contain a whole spectrum of functions starting with the ones that are least lossy (e.g., injections or, possibly, isomorphisms) and ending with constant functions that collapse the whole domain to a single element (if there is one).</p><p>I tend to think of morphisms in an arbitrary category as being lossy too. It’s just a mental model, but it’s a useful one, especially when thinking of adjunctions — in particular those in which one of the categories is <b>Set</b>.</p><p>Formally, we can only speak of morphisms that are invertible (isomorphisms) or non-invertible. It’s that latter kind that may be though of as lossy. There is also a notion of mono- and epi- morphisms that generalize the idea of injective (non-collapsing) and surjective (covering the whole codomain) functions, but it’s possible to have a morphism that is both mono and epi, and which is still non-invertible.</p><p>In the Free ⊣ Forgetful adjunction, we have the more constrained category <i>C</i> on the left, and a less constrained category <i>D</i> on the right. Morphisms in <i>C</i> are “fewer” because they have to preserve some additional structure. In the case of <b>Mon</b>, they have to preserve multiplication and unit. Morphisms in <i>D</i> don’t have to preserve as much structure, so there are “more” of them.</p><p>When we apply a forgetful functor <code>U</code> to an object <code>c</code> in <i>C</i>, we think of it as revealing the “internal structure” of <code>c</code>. In fact, if <i>D</i> is <b>Set</b> we think of <code>U</code> as <em>defining</em> the internal structure of <code>c</code> — its underlying set. (In an arbitrary category, we can’t talk about the internals of an object other than through its connections to other objects, but here we are just hand-waving.)</p><p>If we map two objects <code>c'</code> and <code>c</code> using <code>U</code>, we expect that, in general, the mapping of the hom-set <code>C(c', c)</code> will cover only a subset of <code>D(U c', U c)</code>. That’s because morphisms in <code>C(c', c)</code> have to preserve the additional structure, whereas the ones in <code>D(U c', U c)</code> don’t.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg"><img data-attachment-id="5536" data-permalink="https://bartoszmilewski.com/2016/06/15/freeforgetful-adjunctions/forgettingmorphisms/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg" data-orig-size="1289,684" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1463508588&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0017064846416382&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="ForgettingMorphisms" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=413&amp;h=219" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=510" class="alignnone wp-image-5536" src="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=413&amp;h=219" alt="ForgettingMorphisms" width="413" height="219" srcset="https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=413&amp;h=219 413w, https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=826&amp;h=438 826w, https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=150&amp;h=80 150w, https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=300&amp;h=159 300w, https://bartoszmilewski.files.wordpress.com/2016/05/forgettingmorphisms.jpg?w=768&amp;h=408 768w" sizes="(max-width: 413px) 100vw, 413px"></a></p><p>But since an adjunction is defined as an <em>isomporphism</em> of particular hom-sets, we have to be very picky with our selection of <code>c'</code>. In the adjunction, <code>c'</code> is picked not from just anywhere in <i>C</i>, but from the (presumably smaller) image of the free functor <code>F</code>:</p><pre>C(F d, c) ≅ D(d, U c)</pre><p>The image of <code>F</code> must therefore consist of objects that have lots of morphisms going to an arbitrary <code>c</code>. In fact, there has to be as many structure-preserving morphisms from <code>F d</code> to <code>c</code> as there are non-structure preserving morphisms from <code>d</code> to <code>U c</code>. It means that the image of <code>F</code> must consist of essentially structure-free objects (so that there is no structure to preserve by morphisms). Such “structure-free” objects are called free objects.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg"><img data-attachment-id="5537" data-permalink="https://bartoszmilewski.com/2016/06/15/freeforgetful-adjunctions/freeimage/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg" data-orig-size="1100,650" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1463508588&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;32&quot;,&quot;shutter_speed&quot;:&quot;0.0017064846416382&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FreeImage" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=422&amp;h=249" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=510" class="alignnone wp-image-5537" src="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=422&amp;h=249" alt="FreeImage" width="422" height="249" srcset="https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=422&amp;h=249 422w, https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=844&amp;h=498 844w, https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=150&amp;h=89 150w, https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=300&amp;h=177 300w, https://bartoszmilewski.files.wordpress.com/2016/05/freeimage.jpg?w=768&amp;h=454 768w" sizes="(max-width: 422px) 100vw, 422px"></a></p><p>In the monoid example, a free monoid has no structure other than what’s generated by unit and associativity laws. Other than that, all multiplications produce brand new elements.</p><p>In a free monoid, 2*3 is not 6 — it’s a new element [2, 3]. Since there is no identification of [2, 3] and 6, a morphism from this free monoid to any other monoid <code>m</code> is allowed to map them separately. But it’s also okay for it to map both [2, 3] and 6 (their product) to the same element of <code>m</code>. Or to identify [2, 3] and 5 (their sum) in an additive monoid, and so on. Different identifications give you different monoids.</p><p>This leads to another interesting intuition: Free monoids, instead of performing the monoidal operation, accumulate the arguments that were passed to it. Instead of multiplying 2 and 3 they remember 2 and 3 in a list. The advantage of this scheme is that we don’t have to specify what monoidal operation we will use. We can keep accumulating arguments, and only at the end apply an operator to the result. And it’s then that we can chose what operator to apply. We can add the numbers, or multiply them, or perform addition modulo 2, and so on. A free monoid separates the creation of an expression from its evaluation. We’ll see this idea again when we talk about algebras.</p><p>This intuition generalizes to other, more elaborate free constructions. For instance, we can accumulate whole expression trees before evaluating them. The advantage of this approach is that we can transform such trees to make the evaluation faster or less memory consuming. This is, for instance, done in implementing matrix calculus, where eager evaluation would lead to lots of allocations of temporary arrays to store intermediate results.</p><h2>Challenges</h2><ol>
 <li>Consider a free monoid built from a singleton set as its generator. Show that there is a one-to-one correspondence between morphisms from this free monoid to any monoid <code>m</code>, and functions from the singleton set to the underlying set of <code>m</code>.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2016/11/21/monads-programmers-definition/">Monads: Programmer’s Definition</a>.</p><h2>Acknowledgments</h2><p>I’d like to thank Gershom Bazerman for checking my math and logic, and André van Meulebrouck, who has been volunteering his editing help throughout this series of posts.<br>
 <iframe id="twitter-widget-0" scrolling="no" frameborder="0" allowtransparency="true" class="twitter-follow-button twitter-follow-button-rendered" title="Twitter Follow Button" src="https://platform.twitter.com/widgets/follow_button.c2fee4cea2b1b8626df3db7d9a85b72d.en.html#dnt=false&amp;id=twitter-widget-0&amp;lang=en&amp;screen_name=BartoszMilewski&amp;show_count=false&amp;show_screen_name=true&amp;size=m&amp;time=1503408396188" style="position: static; visibility: visible; width: 156px; height: 20px;" data-screen-name="BartoszMilewski"></iframe></p>

 <h2 class="post-title">
 			Monads: Programmer’s Definition		</h2><p>Programmers have developed a whole mythology around monads. It’s supposed to be one of the most abstract and difficult concepts in programming. There are people who “get it” and those who don’t. For many, the moment when they understand the concept of the monad is like a mystical experience. The monad abstracts the essence of so many diverse constructions that we simply don’t have a good analogy for it in everyday life. We are reduced to groping in the dark, like those blind men touching different parts of the elephant end exclaiming triumphantly: “It’s a rope,” “It’s a tree trunk,” or “It’s a burrito!”</p><p>Let me set the record straight: The whole mysticism around the monad is the result of a misunderstanding. The monad is a very simple concept. It’s the diversity of applications of the monad that causes the confusion.</p><p>As part of research for this post I looked up duct tape (a.k.a., duck tape) and its applications. Here’s a little sample of things that you can do with it:</p><ul>
 <li>sealing ducts</li>
 <li>fixing CO<sub>2</sub> scrubbers on board Apollo 13</li>
 <li>wart treatment</li>
 <li>fixing Apple’s iPhone 4 dropped call issue</li>
 <li>making a prom dress</li>
 <li>building a suspension bridge</li>
 </ul><p>Now imagine that you didn’t know what duct tape was and you were trying to figure it out based on this list. Good luck!</p><p>So I’d like to add one more item to the collection of “the monad is like…” clichés: The monad is like duct tape. Its applications are widely diverse, but its principle is very simple: it glues things together. More precisely, it composes things.</p><p>This partially explains the difficulties a lot of programmers, especially those coming from the imperative background, have with understanding the monad. The problem is that we are not used to thinking of programing in terms of function composition. This is understandable. We often give names to intermediate values rather than pass them directly from function to function. We also inline short segments of glue code rather than abstract them into helper functions. Here’s an imperative-style implementation of the vector-length function in C:</p><pre>double vlen(double * v) {
  double d = 0.0;
  int n;
  for (n = 0; n &lt; 3; ++n)
    d += v[n] * v[n];
  return sqrt(d);
 }</pre><p>Compare this with the (stylized) Haskell version that makes function composition explicit:</p><pre>vlen = sqrt . sum . fmap  (flip (^) 2)</pre><p>(Here, to make things even more cryptic, I partially applied the exponentiation operator <code>(^)</code> by setting its second argument to <code>2</code>.)</p><p>I’m not arguing that Haskell’s point-free style is always better, just that function composition is at the bottom of everything we do in programming. And even though we are effectively composing functions, Haskell does go to great lengths to provide imperative-style syntax called the <code>do</code> notation for monadic composition. We’ll see its use later. But first, let me explain why we need monadic composition in the first place.</p><h2>The Kleisli Category</h2><p>We have previously arrived at the <a href="https://bartoszmilewski.com/2014/12/23/kleisli-categories/">writer monad</a> by embellishing regular functions. The particular embellishment was done by pairing their return values with strings or, more generally, with elements of a monoid. We can now recognize that such embellishment is a functor:</p><pre>newtype Writer w a = Writer (a, w)

 instance Functor (Writer w) where
  fmap f (Writer (a, w)) = Writer (f a, w)</pre><p>We have subsequently found a way of composing embellished functions, or Kleisli arrows, which are functions of the form:</p><pre>a -&gt; Writer w b</pre><p>It was inside the composition that we implemented the accumulation of the log.</p><p>We are now ready for a more general definition of the Kleisli category. We start with a category <i>C</i> and an endofunctor <code>m</code>. The corresponding Kleisli category <i>K</i> has the same objects as <i>C</i>, but its morphisms are different. A morphism between two objects <code>a</code> and <code>b</code> in <i>K</i> is implemented as a morphism:</p><pre>a -&gt; m b</pre><p>in the original category <i>C</i>. It’s important to keep in mind that we treat a Kleisli arrow in <i>K</i> as a morphism between <code>a</code> and <code>b</code>, and not between <code>a</code> and <code>m b</code>.</p><p>In our example, <code>m</code> was specialized to <code>Writer w</code>, for some fixed monoid <code>w</code>.</p><p>Kleisli arrows form a category only if we can define proper composition for them. If there is a composition, which is associative and has an identity arrow for every object, then the functor <code>m</code> is called a <i>monad</i>, and the resulting category is called the Kleisli category.</p><p>In Haskell, Kleisli composition is defined using the fish operator <code>&gt;=&gt;</code>, and the identity arrrow is a polymorphic function called <code>return</code>. Here’s the definition of a monad using Kleisli composition:</p><pre>class Monad m where
  (&gt;=&gt;) :: (a -&gt; m b) -&gt; (b -&gt; m c) -&gt; (a -&gt; m c)
  return :: a -&gt; m a</pre><p>Keep in mind that there are many equivalent ways of defining a monad, and that this is not the primary one in the Haskell ecosystem. I like it for its conceptual simplicity and the intuition it provides, but there are other definitions that are more convenient when programming. We’ll talk about them momentarily.</p><p>In this formulation, monad laws are very easy to express. They cannot be enforced in Haskell, but they can be used for equational reasoning. They are simply the standard composition laws for the Kleisli category:</p><pre>(f &gt;=&gt; g) &gt;=&gt; h = f &gt;=&gt; (g &gt;=&gt; h) -- associativity
 return &gt;=&gt; f = f                  -- left unit
 f &gt;=&gt; return = f                  -- right unit</pre><p>This kind of a definition also expresses what a monad really is: it’s a way of composing embellished functions. It’s not about side effects or state. It’s about composition. As we’ll see later, embellished functions may be used to express a variety of effects or state, but that’s not what the monad is for. The monad is the sticky duct tape that ties one end of an embellished function to the other end of an embellished function.</p><p>Going back to our <code>Writer</code> example: The logging functions (the Kleisli arrows for the <code>Writer</code> functor) form a category because <code>Writer</code> is a monad:</p><pre>instance Monoid w =&gt; Monad (Writer w) where
    f &gt;=&gt; g = \a -&gt;
        let Writer (b, s)  = f a
            Writer (c, s') = g b
        in Writer (c, s `mappend` s')
    return a = Writer (a, mempty)</pre><p>Monad laws for <code>Writer w</code> are satisfied as long as monoid laws for <code>w</code> are satisfied (they can’t be enforced in Haskell either).</p><p>There’s a useful Kleisli arrow defined for the <code>Writer</code> monad called <code>tell</code>. It’s sole purpose is to add its argument to the log:</p><pre>tell :: w -&gt; Writer w ()
 tell s = Writer ((), s)</pre><p>We’ll use it later as a building block for other monadic functions.</p><h2>Fish Anatomy</h2><p>When implementing the fish operator for different monads you quickly realize that a lot of code is repeated and can be easily factored out. To begin with, the Kleisli composition of two functions must return a function, so its implementation may as well start with a lambda taking an argument of type <code>a</code>:</p><pre>(&gt;=&gt;) :: (a -&gt; m b) -&gt; (b -&gt; m c) -&gt; (a -&gt; m c)
 f &gt;=&gt; g = \a -&gt; ...</pre><p>The only thing we can do with this argument is to pass it to <code>f</code>:</p><pre>f &gt;=&gt; g = \a -&gt; let mb = f a
                in ...</pre><p>At this point we have to produce the result of type <code>m c</code>, having at our disposal an object of type <code>m b</code> and a function <code>g :: b -&gt; m c</code>. Let’s define a function that does that for us. This function is called bind and is usually written in the form of an infix operator:</p><pre>(&gt;&gt;=) :: m a -&gt; (a -&gt; m b) -&gt; m b</pre><p>For every monad, instead of defining the fish operator, we may instead define bind. In fact the standard Haskell definition of a monad uses bind:</p><pre>class Monad m where
    (&gt;&gt;=) :: m a -&gt; (a -&gt; m b) -&gt; m b
    return :: a -&gt; m a</pre><p>Here’s the definition of bind for the <code>Writer</code> monad:</p><pre>(Writer (a, w)) &gt;&gt;= f = let Writer (b, w') = f a
                        in  Writer (b, w `mappend` w')</pre><p>It is indeed shorter than the definition of the fish operator.</p><p>It’s possible to further dissect bind, taking advantage of the fact that <code>m</code> is a functor. We can use <code>fmap</code> to apply the function <code>a -&gt; m b</code> to the contents of <code>m a</code>. This will turn <code>a</code> into <code>m b</code>. The result of the application is therefore of type <code>m (m b)</code>. This is not exactly what we want — we need the result of type <code>m b</code> — but we’re close. All we need is a function that collapses or flattens the double application of <code>m</code>. Such function is called <code>join</code>:</p><pre>join :: m (m a) -&gt; m a</pre><p>Using <code>join</code>, we can rewrite bind as:</p><pre>ma &gt;&gt;= f = join (fmap f ma)</pre><p>That leads us to the third option for defining a monad:</p><pre>class Functor m =&gt; Monad m where
    join :: m (m a) -&gt; m a
    return :: a -&gt; m a</pre><p>Here we have explicitly requested that <code>m</code> be a <code>Functor</code>. We didn’t have to do that in the previous two definitions of the monad. That’s because any type constructor <code>m</code> that either supports the fish or bind operator is automatically a functor. For instance, it’s possible to define <code>fmap</code> in terms of bind and <code>return</code>:</p><pre>fmap f ma = ma &gt;&gt;= \a -&gt; return (f a)</pre><p>For completeness, here’s <code>join</code> for the <code>Writer</code> monad:</p><pre>join :: Monoid w =&gt; Writer w (Writer w a) -&gt; Writer w a
 join (Writer ((Writer (a, w')), w)) = Writer (a, w `mappend` w')</pre><h2>The <code>do</code> Notation</h2><p>One way of writing code using monads is to work with Kleisli arrows — composing them using the fish operator. This mode of programming is the generalization of the point-free style. Point-free code is compact and often quite elegant. In general, though, it can be hard to understand, bordering on cryptic. That’s why most programmers prefer to give names to function arguments and intermediate values.</p><p>When dealing with monads it means favoring the bind operator over the fish operator. Bind takes a monadic value and returns a monadic value. The programmer may chose to give names to those values. But that’s hardly an improvement. What we really want is to pretend that we are dealing with regular values, not the monadic containers that encapsulate them. That’s how imperative code works — side effects, such as updating a global log, are mostly hidden from view. And that’s what the <code>do</code> notation emulates in Haskell.</p><p>You might be wondering then, why use monads at all? If we want to make side effects invisible, why not stick to an imperative language? The answer is that the monad gives us much better control over side effects. For instance, the log in the <code>Writer</code> monad is passed from function to function and is never exposed globally. There is no possibility of garbling the log or creating a data race. Also, monadic code is clearly demarcated and cordoned off from the rest of the program.</p><p>The <code>do</code> notation is just syntactic sugar for monadic composition. On the surface, it looks a lot like imperative code, but it translates directly to a sequence of binds and lambda expressions.</p><p>For instance, take the example we used previously to illustrate the composition of Kleisli arrows in the <code>Writer</code> monad. Using our current definitions, it could be rewritten as:</p><pre>process :: String -&gt; Writer String [String]
 process = upCase &gt;=&gt; toWords</pre><p>This function turns all characters in the input string to upper case and splits it into words, all the while producing a log of its actions.</p><p>In the <code>do</code> notation it would look like this:</p><pre>process s = do
    upStr &lt;- upCase s
    toWords upStr</pre><p>Here, <code>upStr</code> is just a <code>String</code>, even though <code>upCase</code> produces a <code>Writer</code>:</p><pre>upCase :: String -&gt; Writer String String
 upCase s = Writer (map toUpper s, "upCase ")</pre><p>This is because the <code>do</code> block is desugared by the compiler to:</p><pre>process s =
   upCase s <span class="red"><strong>&gt;&gt;= \</strong></span> upStr <span class="red"><strong>-&gt;</strong></span>
       toWords upStr</pre><p>The monadic result of <code>upCase</code> is bound to a lambda that takes a <code>String</code>. It’s the name of this string that shows up in the <code>do</code> block. When reading the line:</p><pre>upStr &lt;- upCase s</pre><p>we say that <code>upStr</code> <i>gets</i> the result of <code>upCase s</code>.</p><p>The pseudo-imperative style is even more pronounced when we inline <code>toWords</code>. We replace it with the call to <code>tell</code>, which logs the string <code>"toWords "</code>, followed by the call to <code>return</code> with the result of splitting the string <code>upStr</code> using <code>words</code>. Notice that <code>words</code> is a regular function working on strings.</p><pre>process s = do
    upStr &lt;- upStr s
    tell "toWords "
    return (words upStr)</pre><p>Here, each line in the do block introduces a new nested bind in the desugared code:</p><pre>process s =
    upCase s &gt;&gt;= \upStr -&gt;
      tell "toWords " &gt;&gt;= \() -&gt;
        return (words upStr)</pre><p>Notice that <code>tell</code> produces a unit value, so it doesn’t have to be passed to the following lambda. Ignoring the contents of a monadic result (but not its effect — here, the contribution to the log) is quite common, so there is a special operator to replace bind in that case:</p><pre>(&gt;&gt;) :: m a -&gt; m b -&gt; m b
 m &gt;&gt; k = m &gt;&gt;= (\_ -&gt; k)</pre><p>The actual desugaring of our code looks like this:</p><pre>process s =
    upCase s &gt;&gt;= \upStr -&gt;
      tell "toWords " &gt;&gt;
        return (words upStr)</pre><p>In general, <code>do</code> blocks consist of lines (or sub-blocks) that either use the left arrow to introduce new names that are then available in the rest of the code, or are executed purely for side-effects. Bind operators are implicit between the lines of code. Incidentally, it is possible, in Haskell, to replace the formatting in the <code>do</code> blocks with braces and semicolons. This provides the justification for describing the monad as a way of overloading the semicolon.</p><p>Notice that the nesting of lambdas and bind operators when desugaring the <code>do</code> notation has the effect of influencing the execution of the rest of the <code>do</code> block based on the result of each line. This property can be used to introduce complex control structures, for instance to simulate exceptions.</p><p>Interestingly, the equivalent of the <code>do</code> notation has found its application in imperative languages, C++ in particular. I’m talking about resumable functions or coroutines. It’s not a secret that C++ <a href="https://bartoszmilewski.com/2014/02/26/c17-i-see-a-monad-in-your-future/" target="_blank">futures form a monad</a>. It’s an example of the continuation monad, which we’ll discuss shortly. The problem with continuations is that they are very hard to compose. In Haskell, we use the <code>do</code> notation to turn the spaghetti of “my handler will call your handler” into something that looks very much like sequential code. Resumable functions make the same transformation possible in C++. And the same mechanism can be applied to turn the <a href="https://bartoszmilewski.com/2014/04/21/getting-lazy-with-c/" target="_blank">spaghetti of nested loops</a> into list comprehensions or “generators,” which are essentially the <code>do</code> notation for the list monad. Without the unifying abstraction of the monad, each of these problems is typically addressed by providing custom extensions to the language. In Haskell, this is all dealt with through libraries.</p><p>Next: <a href="https://bartoszmilewski.com/2016/11/30/monads-and-effects/">Monads and Effects</a>.</p>

        <h2 class="post-title">
        			Monads and Effects		</h2><p>Now that we know what the monad is for — it lets us compose embellished functions — the really interesting question is why embellished functions are so important in functional programming. We’ve already seen one example, the <code>Writer</code> monad, where embellishment let us create and accumulate a log across multiple function calls. A problem that would otherwise be solved using impure functions (e.g., by accessing and modifying some global state) was solved with pure functions.</p><h2>The Problem</h2><p>Here is a short list of similar problems, copied from <a href="https://core.ac.uk/download/pdf/21173011.pdf" target="_blank">Eugenio Moggi’s seminal paper</a>, all of which are traditionally solved by abandoning the purity of functions.</p><ul>
        <li>Partiality: Computations that may not terminate</li>
        <li>Nondeterminism: Computations that may return many results</li>
        <li>Side effects: Computations that access/modify state
        <ul>
        <li>Read-only state, or the environment</li>
        <li>Write-only state, or a log</li>
        <li>Read/write state</li>
        </ul>
        </li>
        <li>Exceptions: Partial functions that may fail</li>
        <li>Continuations: Ability to save state of the program and then restore it on demand</li>
        <li>Interactive Input</li>
        <li>Interactive Output</li>
        </ul><p>What really is mind blowing is that all these problems may be solved using the same clever trick: turning to embellished functions. Of course, the embellishment will be totally different in each case.</p><p>You have to realize that, at this stage, there is no requirement that the embellishment be monadic. It’s only when we insist on composition — being able to decompose a single embellished function into smaller embellished functions — that we need a monad. Again, since each of the embellishments is different, monadic composition will be implemented differently, but the overall pattern is the same. It’s a very simple pattern: composition that is associative and equipped with identity.</p><p>The next section is heavy on Haskell examples. Feel free to skim or even skip it if you’re eager to get back to category theory or if you’re already familiar with Haskell’s implementation of monads.</p><h2>The Solution</h2><p>First, let’s analyze the way we used the <code>Writer</code> monad. We started with a pure function that performed a certain task — given arguments, it produced a certain output. We replaced this function with another function that embellished the original output by pairing it with a string. That was our solution to the logging problem.</p><p>We couldn’t stop there because, in general, we don’t want to deal with monolithic solutions. We needed to be able to decompose one log-producing function into smaller log-producing functions. It’s the composition of those smaller functions that led us to the concept of a monad.</p><p>What’s really amazing is that the same pattern of embellishing the function return types works for a large variety of problems that normally would require abandoning purity. Let’s go through our list and identify the embellishment that applies to each problem in turn.</p><h3>Partiality</h3><p>We modify the return type of every function that may not terminate by turning it into a “lifted” type — a type that contains all values of the original type plus the special “bottom” value <code>⊥</code>. For instance, the <code>Bool</code> type, as a set, would contain two elements: <code>True</code> and <code>False</code>. The lifted <code>Bool</code> contains three elements. Functions that return the lifted <code>Bool</code> may produce <code>True</code> or <code>False</code>, or execute forever.</p><p>The funny thing is that, in a lazy language like Haskell, a never-ending function may actually return a value, and this value may be passed to the next function. We call this special value the bottom. As long as this value is not explicitly needed (for instance, to be pattern matched, or produced as output), it may be passed around without stalling the execution of the program. Because every Haskell function may be potentially non-terminating, all types in Haskell are assumed to be lifted. This is why we often talk about the category <b>Hask</b> of Haskell (lifted) types and functions rather than the simpler <b>Set</b>. It is not clear, though, that <b>Hask</b> is a real category (see this <a href="http://math.andrej.com/2016/08/06/hask-is-not-a-category/" target="_blank">Andrej Bauer post</a>).</p><h3>Nondeterminism</h3><p>If a function can return many different results, it may as well return them all at once. Semantically, a non-deterministic function is equivalent to a function that returns a list of results. This makes a lot of sense in a lazy garbage-collected language. For instance, if all you need is one value, you can just take the head of the list, and the tail will never be evaluated. If you need a random value, use a random number generator to pick the n-th element of the list. Laziness even allows you to return an infinite list of results.</p><p>In the list monad — Haskell’s implementation of nondeterministic computations — <code>join</code> is implemented as <code>concat</code>. Remember that <code>join</code> is supposed to flatten a container of containers — <code>concat</code> concatenates a list of lists into a single list. <code>return</code> creates a singleton list:</p><pre>instance Monad [] where
            join = concat
            return x = [x]</pre><p>The bind operator for the list monad is given by the general formula: <code>fmap</code> followed by <code>join</code> which, in this case gives:</p><pre>as &gt;&gt;= k = concat (fmap k as)</pre><p>Here, the function <code>k</code>, which itself produces a list, is applied to every element of the list <code>as</code>. The result is a list of lists, which is flattened using <code>concat</code>.</p><p>From the programmer’s point of view, working with a list is easier than, for instance, calling a non-deterministic function in a loop, or implementing a function that returns an iterator (although, <a href="http://ericniebler.com/2014/04/27/range-comprehensions/" target="_blank">in modern C++</a>, returning a lazy range would be almost equivalent to returning a list in Haskell).</p><p>A good example of using non-determinism creatively is in game programming. For instance, when a computer plays chess against a human, it can’t predict the opponent’s next move. It can, however, generate a list of all possible moves and analyze them one by one. Similarly, a non-deterministic parser may generate a list of all possible parses for a given expression.</p><p>Even though we may interpret functions returning lists as non-deterministic, the applications of the list monad are much wider. That’s because stitching together computations that produce lists is a perfect functional substitute for iterative constructs — loops — that are used in imperative programming. A single loop can be often rewritten using <code>fmap</code> that applies the body of the loop to each element of the list. The <code>do</code> notation in the list monad can be used to replace complex nested loops.</p><p>My favorite example is the program that generates Pythagorean triples — triples of positive integers that can form sides of right triangles.</p><pre>triples = do
            z &lt;- [1..]
            x &lt;- [1..z]
            y &lt;- [x..z]
            guard (x^2 + y^2 == z^2)
            return (x, y, z)</pre><p>The first line tells us that <code>z</code> gets an element from an infinite list of positive numbers <code>[1..]</code>. Then <code>x</code> gets an element from the (finite) list <code>[1..z]</code> of numbers between 1 and <code>z</code>. Finally <code>y</code> gets an element from the list of numbers between <code>x</code> and <code>z</code>. We have three numbers <code>1 &lt;= x &lt;= y &lt;= z</code> at our disposal. The function <code>guard</code> takes a <code>Bool</code> expression and returns a list of units:</p><pre>guard :: Bool -&gt; [()]
        guard True  = [()]
        guard False = []</pre><p>This function (which is a member of a larger class called <code>MonadPlus</code>) is used here to filter out non-Pythagorean triples. Indeed, if you look at the implementation of bind (or the related operator <code>&gt;&gt;</code>), you’ll notice that, when given an empty list, it produces an empty list. On the other hand, when given a non-empty list (here, the singleton list containing unit <code>[()]</code>), bind will call the continuation, here <code>return (x, y, z)</code>, which produces a singleton list with a verified Pythagorean triple. All those singleton lists will be concatenated by the enclosing binds to produce the final (infinite) result. Of course, the caller of <code>triples</code> will never be able to consume the whole list, but that doesn’t matter, because Haskell is lazy.</p><p>The problem that normally would require a set of three nested loops has been dramatically simplified with the help of the list monad and the <code>do</code> notation. As if that weren’t enough, Haskell let’s you simplify this code even further using list comprehension:</p><pre>triples = [(x, y, z) | z &lt;- [1..]
                             , x &lt;- [1..z]
                             , y &lt;- [x..z]
                             , x^2 + y^2 == z^2]</pre><p>This is just further syntactic sugar for the list monad (strictly speaking, <code>MonadPlus</code>).</p><p>You might see similar constructs in other functional or imperative languages under the guise of generators and coroutines.</p><h3>Read-Only State</h3><p>A function that has read-only access to some external state, or environment, can be always replaced by a function that takes that environment as an additional argument. A pure function <code>(a, e) -&gt; b</code> (where <code>e</code> is the type of the environment) doesn’t look, at first sight, like a Kleisli arrow. But as soon as we curry it to <code>a -&gt; (e -&gt; b)</code> we recognize the embellishment as our old friend the reader functor:</p><pre>newtype Reader e a = Reader (e -&gt; a)</pre><p>You may interpret a function returning a <code>Reader</code> as producing a mini-executable: an action that given an environment produces the desired result. There is a helper function <code>runReader</code> to execute such an action:</p><pre>runReader :: Reader e a -&gt; e -&gt; a
        runReader (Reader f) e = f e</pre><p>It may produce different results for different values of the environment.</p><p>Notice that both the function returning a <code>Reader</code>, and the <code>Reader</code> action itself are pure.</p><p>To implement bind for the <code>Reader</code> monad, first notice that you have to produce a function that takes the environment <code>e</code> and produces a <code>b</code>:</p><pre>ra &gt;&gt;= k = Reader (\e -&gt; ...)</pre><p>Inside the lambda, we can execute the action <code>ra</code> to produce an <code>a</code>:</p><pre>ra &gt;&gt;= k = Reader (\e -&gt; let a = runReader ra e
                                 in ...)</pre><p>We can then pass the <code>a</code> to the continuation <code>k</code> to get a new action <code>rb</code>:</p><pre>ra &gt;&gt;= k = Reader (\e -&gt; let a  = runReader ra e
                                     rb = k a
                                 in ...)</pre><p>Finally, we can run the action <code>rb</code> with the environment <code>e</code>:</p><pre>ra &gt;&gt;= k = Reader (\e -&gt; let a  = runReader ra e
                                     rb = k a
                                 in runReader rb e)</pre><p>To implement <code>return</code> we create an action that ignores the environment and returns the unchanged value.</p><p>Putting it all together, after a few simplifications, we get the following definition:</p><pre>instance Monad (Reader e) where
            ra &gt;&gt;= k = Reader (\e -&gt; runReader (k (runReader ra e)) e)
            return x = Reader (\e -&gt; x)</pre><h3>Write-Only State</h3><p>This is just our initial logging example. The embellishment is given by the <code>Writer</code> functor:</p><pre>newtype Writer w a = Writer (a, w)</pre><p>For completeness, there’s also a trivial helper <code>runWriter</code> that unpacks the data constructor:</p><pre>runWriter :: Writer w a -&gt; (a, w)
        runWriter (Writer (a, w)) = (a, w)</pre><p>As we’ve seen before, in order to make <code>Writer</code> composable, <code>w</code> has to be a monoid. Here’s the monad instance for <code>Writer</code> written in terms of the bind operator:</p><pre>instance (Monoid w) =&gt; Monad (Writer w) where
            (Writer (a, w)) &gt;&gt;= k = let (a', w') = runWriter (k a)
                                    in Writer (a', w `mappend` w')
            return a = Writer (a, mempty)</pre><h3>State</h3><p>Functions that have read/write access to state combine the embellishments of the <code>Reader</code> and the <code>Writer</code>. You may think of them as pure functions that take the state as an extra argument and produce a pair value/state as a result: <code>(a, s) -&gt; (b, s)</code>. After currying, we get them into the form of Kleisli arrows <code>a -&gt; (s -&gt; (b, s))</code>, with the embellishment abstracted in the <code>State</code> functor:</p><pre>newtype State s a = State (s -&gt; (a, s))</pre><p>Again, we can look at a Kleisli arrow as returning an action, which can be executed using the helper function:</p><pre>runState :: State s a -&gt; s -&gt; (a, s)
        runState (State f) s = f s</pre><p>Different initial states may not only produce different results, but also different final states.</p><p>The implementation of bind for the <code>State</code> monad is very similar to that of the <code>Reader</code> monad, except that care has to be taken to pass the correct state at each step:</p><pre>sa &gt;&gt;= k = State (\s -&gt; let (a, s') = runState sa s
                                    sb = k a
                                in runState sb s')</pre><p>Here’s the full instance:</p><pre>instance Monad (State s) where
            sa &gt;&gt;= k = State (\s -&gt; let (a, s') = runState sa s
                                    in runState (k a) s')
            return a = State (\s -&gt; (a, s))</pre><p>There are also two helper Kleisli arrows that may be used to manipulate the state. One of them retrieves the state for inspection:</p><pre>get :: State s s
        get = State (\s -&gt; (s, s))</pre><p>and the other replaces it with a completely new state:</p><pre>put :: s -&gt; State s ()
        put s' = State (\s -&gt; ((), s'))</pre><h3>Exceptions</h3><p>An imperative function that throws an exception is really a partial function — it’s a function that’s not defined for some values of its arguments. The simplest implementation of exceptions in terms of pure total functions uses the <code>Maybe</code> functor. A partial function is extended to a total function that returns <code>Just a</code> whenever it makes sense, and <code>Nothing</code> when it doesn’t. If we want to also return some information about the cause of the failure, we can use the <code>Either</code> functor instead (with the first type fixed, for instance, to <code>String</code>).</p><p>Here’s the <code>Monad</code> instance for <code>Maybe</code>:</p><pre>instance Monad Maybe where
            Nothing &gt;&gt;= k = Nothing
            Just a  &gt;&gt;= k = k a
            return a = Just a</pre><p>Notice that monadic composition for <code>Maybe</code> correctly short-circuits the computation (the continuation <code>k</code> is never called) when an error is detected. That’s the behavior we expect from exceptions.</p><h3>Continuations</h3><p>It’s the “Don’t call us, we’ll call you!” situation you may experience after a job interview. Instead of getting a direct answer, you are supposed to provide a handler, a function to be called with the result. This style of programming is especially useful when the result is not known at the time of the call because, for instance, it’s being evaluated by another thread or delivered from a remote web site. A Kleisli arrow in this case returns a function that accepts a handler, which represents “the rest of the computation”:</p><pre>data Cont r a = Cont ((a -&gt; r) -&gt; r)</pre><p>The handler <code>a -&gt; r</code>, when it’s eventually called, produces the result of type <code>r</code>, and this result is returned at the end. A continuation is parameterized by the result type. (In practice, this is often some kind of status indicator.)</p><p>There is also a helper function for executing the action returned by the Kleisli arrow. It takes the handler and passes it to the continuation:</p><pre>runCont :: Cont r a -&gt; (a -&gt; r) -&gt; r
        runCont (Cont k) h = k h</pre><p>The composition of continuations is notoriously difficult, so its handling through a monad and, in particular, the <code>do</code> notation, is of extreme advantage.</p><p>Let’s figure out the implementation of bind. First let’s look at the stripped down signature:</p><pre>(&gt;&gt;=) :: ((a -&gt; r) -&gt; r) -&gt;
                 (a -&gt; (b -&gt; r) -&gt; r) -&gt;
                 (<span class="red">(b -&gt; r) -&gt; r</span>)</pre><p>Our goal is to create a function that takes the handler <code>(b -&gt; r)</code> and produces the result <code>r</code>. So that’s our starting point:</p><pre>ka &gt;&gt;= kab = Cont (\hb -&gt; ...)</pre><p>Inside the lambda, we want to call the function <code>ka</code> with the appropriate handler that represents the rest of the computation. We’ll implement this handler as a lambda:</p><pre>runCont ka (\a -&gt; ...)</pre><p>In this case, the rest of the computation involves first calling <code>kab</code> with <code>a</code>, and then passing <code>hb</code> to the resulting action <code>kb</code>:</p><pre>runCont ka (\a -&gt; let kb = <span class="red">kab</span> a
                          in runCont kb <span class="red">hb</span>)</pre><p>As you can see, continuations are composed inside out. The final handler <code>hb</code> is called from the innermost layer of the computation. Here’s the full instance:</p><pre>instance Monad (Cont r) where
            ka &gt;&gt;= kab = Cont (\hb -&gt; runCont ka (\a -&gt; runCont (kab a) hb))
            return a = Cont (\ha -&gt; ha a)</pre><h3>Interactive Input</h3><p>This is the trickiest problem and a source of a lot of confusion. Clearly, a function like <code>getChar</code>, if it were to return a character typed at the keyboard, couldn’t be pure. But what if it returned the character inside a container? As long as there was no way of extracting the character from this container, we could claim that the function is pure. Every time you call <code>getChar</code> it would return exactly the same container. Conceptually, this container would contain the superposition of all possible characters.</p><p>If you’re familiar with quantum mechanics, you should have no problem understanding this analogy. It’s just like the box with the Schrödinger’s cat inside — except that there is no way to open or peek inside the box. The box is defined using the special built-in <code>IO</code> functor. In our example, <code>getChar</code> could be declared as a Kleisli arrow:</p><pre>getChar :: () -&gt; IO Char</pre><p>(Actually, since a function from the unit type is equivalent to picking a value of the return type, the declaration of <code>getChar</code> is simplified to <code>getChar :: IO Char</code>.)</p><p>Being a functor, <code>IO</code> lets you manipulate its contents using <code>fmap</code>. And, as a functor, it can store the contents of any type, not just a character. The real utility of this approach comes to light when you consider that, in Haskell, <code>IO</code> is a monad. It means that you are able to compose Kleisli arrows that produce <code>IO</code> objects.</p><p>You might think that Kleisli composition would allow you to peek at the contents of the <code>IO</code> object (thus “collapsing the wave function,” if we were to continue the quantum analogy). Indeed, you could compose <code>getChar</code> with another Kleisli arrow that takes a character and, say, converts it to an integer. The catch is that this second Kleisli arrow could only return this integer as an <code>(IO Int)</code>. Again, you’ll end up with a superposition of all possible integers. And so on. The Schrödinger’s cat is never out of the bag. Once you are inside the <code>IO</code> monad, there is no way out of it. There is no equivalent of <code>runState</code> or <code>runReader</code> for the <code>IO</code> monad. There is no <code>runIO</code>!</p><p>So what can you do with the result of a Kleisli arrow, the <code>IO</code> object, other than compose it with another Kleisli arrow? Well, you can return it from <code>main</code>. In Haskell, <code>main</code> has the signature:</p><pre>main :: IO ()</pre><p>and you are free to think of it as a Kleisli arrow:</p><pre>main :: () -&gt; IO ()</pre><p>From that perspective, a Haskell program is just one big Kleisli arrow in the <code>IO</code> monad. You can compose it from smaller Kleisli arrows using monadic composition. It’s up to the runtime system to do something with the resulting <code>IO</code> object (also called <code>IO</code> action).</p><p>Notice that the arrow itself is a pure function — it’s pure functions all the way down. The dirty work is relegated to the system. When it finally executes the <code>IO</code> action returned from <code>main</code>, it does all kinds of nasty things like reading user input, modifying files, printing obnoxious messages, formatting a disk, and so on. The Haskell program never dirties its hands (well, except when it calls <code>unsafePerformIO</code>, but that’s a different story).</p><p>Of course, because Haskell is lazy, <code>main</code> returns almost immediately, and the dirty work begins right away. It’s during the execution of the <code>IO</code> action that the results of pure computations are requested and evaluated on demand. So, in reality, the execution of a program is an interleaving of pure (Haskell) and dirty (system) code.</p><p>There is an alternative interpretation of the <code>IO</code> monad that is even more bizarre but makes perfect sense as a mathematical model. It treats the whole Universe as an object in a program. Notice that, conceptually, the imperative model treats the Universe as an external global object, so procedures that perform I/O have side effects by virtue of interacting with that object. They can both read and modify the state of the Universe.</p><p>We already know how to deal with state in functional programming — we use the state monad. Unlike simple state, however, the state of the Universe cannot be easily described using standard data structures. But we don’t have to, as long as we never directly interact with it. It’s enough that we assume that there exists a type <code>RealWorld</code> and, by some miracle of cosmic engineering, the runtime is able to provide an object of this type. An <code>IO</code> action is just a function:</p><pre>type IO a  =  RealWorld -&gt; (a, RealWorld)</pre><p>Or, in terms of the <code>State</code> monad:</p><pre>type IO = State RealWorld</pre><p>However, <code>&gt;=&gt;</code> and <code>return</code> for the <code>IO</code> monad have to be built into the language.</p><h3>Interactive Output</h3><p>The same <code>IO</code> monad is used to encapsulate interactive output. <code>RealWorld</code> is supposed to contain all output devices. You might wonder why we can’t just call output functions from Haskell and pretend that they do nothing. For instance, why do we have:</p><pre>putStr :: String -&gt; IO ()</pre><p>rather than the simpler:</p><pre>putStr :: String -&gt; ()</pre><p>Two reasons: Haskell is lazy, so it would never call a function whose output — here, the unit object — is not used for anything. And, even if it weren’t lazy, it could still freely change the order of such calls and thus garble the output. The only way to force sequential execution of two functions in Haskell is through data dependency. The input of one function must depend on the output of another. Having <code>RealWorld</code> passed between <code>IO</code> actions enforces sequencing.</p><p>Conceptually, in this program:</p><pre>main :: IO ()
        main = do
            putStr "Hello "
            putStr "World!"</pre><p>the action that prints “World!” receives, as input, the Universe in which “Hello ” is already on the screen. It outputs a new Universe, with “Hello World!” on the screen.</p><h2>Conclusion</h2><p>Of course I have just scratched the surface of monadic programming. Monads not only accomplish, with pure functions, what normally is done with side effects in imperative programming, but they also do it with a high degree of control and type safety. They are not without drawbacks, though. The major complaint about monads is that they don’t easily compose with each other. Granted, you can combine most of the basic monads using the monad transformer library. It’s relatively easy to create a monad stack that combines, say, state with exceptions, but there is no formula for stacking arbitrary monads together.</p><p>Next: <a href="https://bartoszmilewski.com/2016/12/27/monads-categorically/">Monads Categorically</a>.</p>

            <h2 class="post-title">
            			Monads Categorically		</h2><p>If you mention monads to a programmer, you’ll probably end up talking about effects. To a mathematician, monads are about algebras. We’ll talk about algebras later — they play an important role in programming — but first I’d like to give you a little intuition about their relation to monads. For now, it’s a bit of a hand-waving argument, but bear with me.</p><p>Algebra is about creating, manipulating, and evaluating expressions. Expressions are built using operators. Consider this simple expression:</p><pre>x<sup>2</sup> + 2 x + 1</pre><p>This expression is formed using variables like <code>x</code>, and constants like 1 or 2, bound together with operators like plus or times. As programmers, we often think of expressions as trees.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png"><img data-attachment-id="8000" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/exptree/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png" data-orig-size="436,447" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="exptree" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=175&amp;h=180" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=436" class="alignnone wp-image-8000" src="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=175&amp;h=180" alt="exptree" width="175" height="180" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=175&amp;h=180 175w, https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=350&amp;h=360 350w, https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=146&amp;h=150 146w, https://bartoszmilewski.files.wordpress.com/2016/12/exptree.png?w=293&amp;h=300 293w" sizes="(max-width: 175px) 100vw, 175px"></a></p><p>Trees are containers so, more generally, an expression is a container for storing variables. In category theory, we represent containers as endofunctors. If we assign the type <code>a</code> to the variable <code>x</code>, our expression will have the type <code>m a</code>, where <code>m</code> is an endofunctor that builds expression trees. (Nontrivial branching expressions are usually created using recursively defined endofunctors.)</p><p>What’s the most common operation that can be performed on an expression? It’s substitution: replacing variables with expressions. For instance, in our example, we could replace <code>x</code> with <code>y - 1</code> to get:</p><pre>(y - 1)<sup>2</sup> + 2 (y - 1) + 1</pre><p>Here’s what happened: We took an expression of type <code>m a</code> and applied a transformation of type <code>a -&gt; m b</code> (<code>b</code> represents the type of <code>y</code>). The result is an expression of type <code>m b</code>. Let me spell it out:</p><pre>m a -&gt; (a -&gt; m b) -&gt; m b</pre><p>Yes, that’s the signature of monadic bind.</p><p>That was a bit of motivation. Now let’s get to the math of the monad. Mathematicians use different notation than programmers. They prefer to use the letter <code>T</code> for the endofunctor, and Greek letters: μ for <code>join</code> and η for <code>return</code>. Both <code>join</code> and <code>return</code> are polymorphic functions, so we can guess that they correspond to natural transformations.</p><p>Therefore, in category theory, a monad is defined as an endofunctor <code>T</code> equipped with a pair of natural transformations μ and η.</p><p>μ is a natural transformation from the square of the functor <code>T<sup>2</sup></code> back to <code>T</code>. The square is simply the functor composed with itself, <code>T ∘ T</code> (we can only do this kind of squaring for endofunctors).</p><pre>μ :: T<sup>2</sup> -&gt; T</pre><p>The component of this natural transformation at an object <code>a</code> is the morphism:</p><pre>μ<sub>a</sub> :: T (T a) -&gt; T a</pre><p>which, in <i>Hask</i>, translates directly to our definition of <code>join</code>.</p><p>η is a natural transformation between the identity functor <code>I</code> and <code>T</code>:</p><pre>η :: I -&gt; T</pre><p>Considering that the action of <code>I</code> on the object <code>a</code> is just <code>a</code>, the component of η is given by the morphism:</p><pre>η<sub>a</sub> :: a -&gt; T a</pre><p>which translates directly to our definition of <code>return</code>.</p><p>These natural transformations must satisfy some additional laws. One way of looking at it is that these laws let us define a Kleisli category for the endofunctor <code>T</code>. Remember that a Kleisli arrow between <code>a</code> and <code>b</code> is defined as a morphism <code>a -&gt; T b</code>. The composition of two such arrows (I’ll write it as a circle with the subscript <code>T</code>) can be implemented using μ:</p><pre>g ∘<sub>T</sub> f = μ<sub>c</sub> ∘ (T g) ∘ f</pre><p>where</p><pre>f :: a -&gt; T b
            g :: b -&gt; T c</pre><p>Here <code>T</code>, being a functor, can be applied to the morphism <code>g</code>. It might be easier to recognize this formula in Haskell notation:</p><pre>f &gt;=&gt; g = join . fmap g . f</pre><p>or, in components:</p><pre>(f &gt;=&gt; g) a = join (fmap g (f a))</pre><p>In terms of the algebraic interpretation, we are just composing two successive substitutions.</p><p>For Kleisli arrows to form a category we want their composition to be associative, and η<sub>a</sub> to be the identity Kleisli arrow at <code>a</code>. This requirement can be translated to monadic laws for μ and η. But there is another way of deriving these laws that makes them look more like monoid laws. In fact <code>μ</code> is often called multiplication, and <code>η</code> unit.</p><p>Roughly speaking, the associativity law states that the two ways of reducing the cube of <code>T</code>, <code>T<sup>3</sup></code>, down to <code>T</code> must give the same result. Two unit laws (left and right) state that when <code>η</code> is applied to <code>T</code> and then reduced by <code>μ</code>, we get back <code>T</code>.</p><p>Things are a little tricky because we are composing natural transformations and functors. So a little refresher on horizontal composition is in order. For instance, <code>T<sup>3</sup></code> can be seen as a composition of <code>T</code> after <code>T<sup>2</sup></code>. We can apply to it the horizontal composition of two natural transformations:</p><pre>I<sub>T</sub> ∘ μ</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png"><img data-attachment-id="7996" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/assoc1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png" data-orig-size="563,342" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="assoc1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=248&amp;h=151" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=510" class="alignnone wp-image-7996" src="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=248&amp;h=151" alt="assoc1" width="248" height="151" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=248&amp;h=151 248w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=496&amp;h=302 496w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=150&amp;h=91 150w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc1.png?w=300&amp;h=182 300w" sizes="(max-width: 248px) 100vw, 248px"></a></p><p>and get <code>T∘T</code>; which can be further reduced to <code>T</code> by applying <code>μ</code>. <code>I<sub>T</sub></code> is the identity natural transformation from <code>T</code> to <code>T</code>. You will often see the notation for this type of horizontal composition <code>I<sub>T</sub> ∘ μ</code> shortened to <code>T∘μ</code>. This notation is unambiguous because it makes no sense to compose a functor with a natural transformation, therefore <code>T</code> must mean <code>I<sub>T</sub></code> in this context.</p><p>We can also draw the diagram in the (endo-) functor category <code>[C, C]</code>:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png"><img data-attachment-id="7997" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/assoc2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png" data-orig-size="381,340" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="assoc2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=167&amp;h=149" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=381" class="alignnone wp-image-7997" src="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=167&amp;h=149" alt="assoc2" width="167" height="149" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=167&amp;h=149 167w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=334&amp;h=298 334w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=150&amp;h=134 150w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc2.png?w=300&amp;h=268 300w" sizes="(max-width: 167px) 100vw, 167px"></a></p><p>Alternatively, we can treat <code>T<sup>3</sup></code> as the composition of <code>T<sup>2</sup>∘T</code> and apply <code>μ∘T</code> to it. The result is also <code>T∘T</code> which, again, can be reduced to <code>T</code> using μ. We require that the two paths produce the same result.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png"><img class="alignnone wp-image-7995" src="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=208&amp;h=165" alt="assoc" width="208" height="165" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=208&amp;h=165 208w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=416&amp;h=330 416w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=150&amp;h=119 150w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=300&amp;h=238 300w" sizes="(max-width: 208px) 100vw, 208px"></a></p><p>Similarly, we can apply the horizontal composition <code>η∘T</code> to the composition of the identity functor <code>I</code> after <code>T</code> to obtain <code>T<sup>2</sup></code>, which can then be reduced using <code>μ</code>. The result should be the same as if we applied the identity natural transformation directly to <code>T</code>. And, by analogy, the same should be true for <code>T∘η</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png"><img data-attachment-id="8002" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/unitlawcomp-1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png" data-orig-size="794,329" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="unitlawcomp-1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=300&amp;h=124" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=510" class="alignnone size-medium wp-image-8002" src="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=300&amp;h=124" alt="unitlawcomp-1" width="300" height="124" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=300&amp;h=124 300w, https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=600&amp;h=248 600w, https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp-1.png?w=150&amp;h=62 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>You can convince yourself that these laws guarantee that the composition of Kleisli arrows indeed satisfies the laws of a category.</p><p>The similarities between a monad and a monoid are striking. We have multiplication μ, unit η, associativity, and unit laws. But our definition of a monoid is too narrow to describe a monad as a monoid. So let’s generalize the notion of a monoid.</p><h2>Monoidal Categories</h2><p>Let’s go back to the conventional definition of a monoid. It’s a set with a binary operation and a special element called unit. In Haskell, this can be expressed as a typeclass:</p><pre>class Monoid m where
                mappend :: m -&gt; m -&gt; m
                mempty  :: m</pre><p>The binary operation <code>mappend</code> must be associative and unital (i.e., multiplication by the unit <code>mempty</code> is a no-op).</p><p>Notice that, in Haskell, the definition of <code>mappend</code> is curried. It can be interpreted as mapping every element of <code>m</code> to a function:</p><pre>mappend :: m -&gt; (m -&gt; m)</pre><p>It’s this interpretation that gives rise to the definition of a monoid as a single-object category where endomorphisms <code>(m -&gt; m)</code> represent the elements of the monoid. But because currying is built into Haskell, we could as well have started with a different definition of multiplication:</p><pre>mu :: (m, m) -&gt; m</pre><p>Here, the cartesian product <code>(m, m)</code> becomes the source of pairs to be multiplied.</p><p>This definition suggests a different path to generalization: replacing the cartesian product with categorical product. We could start with a category where products are globally defined, pick an object <code>m</code> there, and define multiplication as a morphism:</p><pre>μ :: m × m -&gt; m</pre><p>We have one problem though: In an arbitrary category we can’t peek inside an object, so how do we pick the unit element? There is a trick to it. Remember how element selection is equivalent to a function from the singleton set? In Haskell, we could replace the definition of <code>mempty</code> with a function:</p><pre>eta :: () -&gt; m</pre><p>The singleton is the terminal object in <b>Set</b>, so it’s natural to generalize this definition to any category that has a terminal object <code>t</code>:</p><pre>η :: t -&gt; m</pre><p>This lets us pick the unit “element” without having to talk about elements.</p><p>Unlike in our previous definition of a monoid as a single-object category, monoidal laws here are not automatically satisfied — we have to impose them. But in order to formulate them we have to establish the monoidal structure of the underlying categorical product itself. Let’s recall how monoidal structure works in Haskell first.</p><p>We start with associativity. In Haskell, the corresponding equational law is:</p><pre>mu x (mu y z) = mu (mu x y) z</pre><p>Before we can generalize it to other categories, we have to rewrite it as an equality of functions (morphisms). We have to abstract it away from its action on individual variables — in other words, we have to use point-free notation. Knowning that the cartesian product is a bifunctor, we can write the left hand side as:</p><pre>(mu . bimap id mu)(x, (y, z))</pre><p>and the right hand side as:</p><pre>(mu . bimap mu id)((x, y), z)</pre><p>This is almost what we want. Unfortunately, the cartesian product is not strictly associative — <code>(x, (y, z))</code> is not the same as <code>((x, y), z)</code> — so we can’t just write point-free:</p><pre>mu . bimap id mu = mu . bimap mu id</pre><p>On the other hand, the two nestings of pairs are isomorphic. There is an invertible function called the associator that converts between them:</p><pre>alpha :: ((a, b), c) -&gt; (a, (b, c))
            alpha ((x, y), z) = (x, (y, z))</pre><p>With the help of the associator, we can write the point-free associativity law for <code>mu</code>:</p><pre>mu . bimap id mu . <span class="red">alpha</span> = mu . bimap mu id</pre><p>We can apply a similar trick to unit laws which, in the new notation, take the form:</p><pre>mu (eta (), x) = x
            mu (x, eta ()) = x</pre><p>They can be rewritten as:</p><pre>(mu . bimap eta id) ((), x) = lambda ((), x)
            (mu . bimap id eta) (x, ()) = rho (x, ())</pre><p>The isomorphisms <code>lambda</code> and <code>rho</code> are called the left and right unitor, respectively. They witness the fact that the unit <code>()</code> is the identity of the cartesian product up to isomorphism:</p><pre>lambda :: ((), a) -&gt; a
            lambda ((), x) = x</pre><pre>rho :: (a, ()) -&gt; a
            rho (x, ()) = x</pre><p>The point-free versions of the unit laws are therefore:</p><pre>mu . bimap id eta = lambda
            mu . bimap eta id = rho</pre><p>We have formulated point-free monoidal laws for <code>mu</code> and <code>eta</code> using the fact that the underlying cartesian product itself acts like a monoidal multiplication in the category of types. Keep in mind though that the associativity and unit laws for the cartesian product are valid only up to isomorphism.</p><p>It turns out that these laws can be generalized to any category with products and a terminal object. Categorical products are indeed associative up to isomorphism and the terminal object is the unit, also up to isomorphism. The associator and the two unitors are natural isomorphisms. The laws can be represented by commuting diagrams.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png"><img data-attachment-id="7998" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/assocmon/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png" data-orig-size="740,368" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="assocmon" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=300&amp;h=149" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=510" class="alignnone size-medium wp-image-7998" src="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=300&amp;h=149" alt="assocmon" width="300" height="149" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=300&amp;h=149 300w, https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=600&amp;h=298 600w, https://bartoszmilewski.files.wordpress.com/2016/12/assocmon.png?w=150&amp;h=75 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that, because the product is a bifunctor, it can lift a pair of morphisms — in Haskell this was done using <code>bimap</code>.</p><p>We could stop here and say that we can define a monoid on top of any category with categorical products and a terminal object. As long as we can pick an object <code>m</code> and two morphisms μ and η that satisfy monoidal laws, we have a monoid. But we can do better than that. We don’t need a full-blown categorical product to formulate the laws for μ and η. Recall that a product is defined through a universal construction that uses projections. We haven’t used any projections in our formulation of monoidal laws.</p><p>A bifunctor that behaves like a product without being a product is called a tensor product, often denoted by the infix operator ⊗. A definition of a tensor product in general is a bit tricky, but we won’t worry about it. We’ll just list its properties — the most important being associativity up to isomorphism.</p><p>Similarly, we don’t need the object <code>t</code> to be terminal. We never used its terminal property — namely, the existence of a unique morphism from any object to it. What we require is that it works well in concert with the tensor product. Which means that we want it to be the unit of the tensor product, again, up to isomorphism. Let’s put it all together:</p><p>A monoidal category is a category <i>C</i> equipped with a bifunctor called the tensor product:</p><pre>⊗ :: C × C -&gt; C</pre><p>and a distinct object <code>i</code> called the unit object, together with three natural isomorphisms called, respectively, the associator and the left and right unitors:</p><pre>α<sub>a b c</sub> :: (a ⊗ b) ⊗ c -&gt; a ⊗ (b ⊗ c)
            λ<sub>a</sub> :: i ⊗ a -&gt; a
            ρ<sub>a</sub> :: a ⊗ i -&gt; a</pre><p>(There is also a coherence condition for simplifying a quadruple tensor product.)</p><p>What’s important is that a tensor product describes many familiar bifunctors. In particular, it works for a product, a coproduct and, as we’ll see shortly, for the composition of endofunctors (and also for some more esoteric products like Day convolution). Monoidal categories will play an essential role in the formulation of enriched categories.</p><h2>Monoid in a Monoidal Category</h2><p>We are now ready to define a monoid in a more general setting of a monoidal category. We start by picking an object <code>m</code>. Using the tensor product we can form powers of <code>m</code>. The square of <code>m</code> is <code>m ⊗ m</code>. There are two ways of forming the cube of <code>m</code>, but they are isomorphic through the associator. Similarly for higher powers of <code>m</code> (that’s where we need the coherence conditions). To form a monoid we need to pick two morphisms:</p><pre>μ :: m ⊗ m -&gt; m
            η :: i -&gt; m</pre><p>where <code>i</code> is the unit object for our tensor product.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg"><img data-attachment-id="7982" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/monoid-1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg" data-orig-size="1950,1740" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1482229990&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="monoid-1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=300&amp;h=268" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=510" class="alignnone size-medium wp-image-7982" src="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=300&amp;h=268" alt="monoid-1" width="300" height="268" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=300&amp;h=268 300w, https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=600&amp;h=536 600w, https://bartoszmilewski.files.wordpress.com/2016/12/monoid-1.jpg?w=150&amp;h=134 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>These morphisms have to satisfy associativity and unit laws, which can be expressed in terms of the following commuting diagrams:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg"><img data-attachment-id="8065" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/assoctensor-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg" data-orig-size="640,309" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1482581750&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="assoctensor" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=300&amp;h=145" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=510" class="alignnone size-medium wp-image-8065" src="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=300&amp;h=145" alt="assoctensor" width="300" height="145" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=300&amp;h=145 300w, https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=600&amp;h=290 600w, https://bartoszmilewski.files.wordpress.com/2016/12/assoctensor.jpg?w=150&amp;h=72 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg"><img data-attachment-id="8038" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/unitmon-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg" data-orig-size="640,258" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1482581750&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="unitmon" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=300&amp;h=121" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=510" class="alignnone size-medium wp-image-8038" src="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=300&amp;h=121" alt="unitmon" width="300" height="121" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=300&amp;h=121 300w, https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=600&amp;h=242 600w, https://bartoszmilewski.files.wordpress.com/2016/12/unitmon.jpg?w=150&amp;h=60 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Notice that it’s essential that the tensor product be a bifunctor because we need to lift pairs of morphisms to form products such as <code>μ ⊗ id</code> or <code>η ⊗ id</code>. These diagrams are just a straightforward generalization of our previous results for categorical products.</p><h2>Monads as Monoids</h2><p>Monoidal structures pop up in unexpected places. One such place is the functor category. If you squint a little, you might be able to see functor composition as a form of multiplication. The problem is that not any two functors can be composed — the target category of one has to be the source category of the other. That’s just the usual rule of composition of morphisms — and, as we know, functors are indeed morphisms in the category <b>Cat</b>. But just like endomorphisms (morphisms that loop back to the same object) are always composable, so are endofunctors. For any given category <i>C</i>, endofunctors from <i>C</i> to <i>C</i> form the functor category <code>[C, C]</code>. Its objects are endofunctors, and morphisms are natural transformations between them. We can take any two objects from this category, say endofunctors <code>F</code> and <code>G</code>, and produce a third object <code>F ∘ G</code> — an endofunctor that’s their composition.</p><p>Is endofunctor composition a good candidate for a tensor product? First, we have to establish that it’s a bifunctor. Can it be used to lift a pair of morphisms — here, natural transformations? The signature of the analog of <code>bimap</code> for the tensor product would look something like this:</p><pre>bimap :: (a -&gt; b) -&gt; (c -&gt; d) -&gt; (a ⊗ c -&gt; b ⊗ d)</pre><p>If you replace objects by endofunctors, arrows by natural transformations, and tensor products by composition, you get:</p><pre>(F -&gt; F') -&gt; (G -&gt; G') -&gt; (F ∘ G -&gt; F' ∘ G')</pre><p>which you may recognize as the special case of horizontal composition.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png"><img data-attachment-id="8001" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/horizcomp/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png" data-orig-size="668,325" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="horizcomp" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=255&amp;h=124" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=510" class="alignnone wp-image-8001" src="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=255&amp;h=124" alt="horizcomp" width="255" height="124" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=255&amp;h=124 255w, https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=510&amp;h=248 510w, https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=150&amp;h=73 150w, https://bartoszmilewski.files.wordpress.com/2016/12/horizcomp.png?w=300&amp;h=146 300w" sizes="(max-width: 255px) 100vw, 255px"></a></p><p>We also have at our disposal the identity endofunctor <code>I</code>, which can serve as the identity for endofunctor composition — our new tensor product. Moreover, functor composition is associative. In fact associativity and unit laws are strict — there’s no need for the associator or the two unitors. So endofunctors form a strict monoidal category with functor composition as tensor product.</p><p>What’s a monoid in this category? It’s an object — that is an endofunctor <code>T</code>; and two morphisms — that is natural transformations:</p><pre>μ :: T ∘ T -&gt; T
            η :: I -&gt; T</pre><p>Not only that, here are the monoid laws:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png"><img data-attachment-id="7995" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/assoc/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png" data-orig-size="465,369" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="assoc" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=183&amp;h=145" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=465" class="alignnone wp-image-7995" src="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=183&amp;h=145" alt="assoc" width="183" height="145" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=183&amp;h=145 183w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=366&amp;h=290 366w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=150&amp;h=119 150w, https://bartoszmilewski.files.wordpress.com/2016/12/assoc.png?w=300&amp;h=238 300w" sizes="(max-width: 183px) 100vw, 183px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png"><img data-attachment-id="8003" data-permalink="https://bartoszmilewski.com/2016/12/27/monads-categorically/unitlawcomp/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png" data-orig-size="785,345" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="unitlawcomp" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=275&amp;h=121" data-large-file="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=510" class=" wp-image-8003 alignnone" src="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=275&amp;h=121" alt="unitlawcomp" width="275" height="121" srcset="https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=275&amp;h=121 275w, https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=550&amp;h=242 550w, https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=150&amp;h=66 150w, https://bartoszmilewski.files.wordpress.com/2016/12/unitlawcomp.png?w=300&amp;h=132 300w" sizes="(max-width: 275px) 100vw, 275px"></a></p><p>They are exactly the monad laws we’ve seen before. Now you understand the famous quote from Saunders Mac Lane:</p><p class="box">All told, monad is just a monoid in the category of endofunctors.</p><p>You might have seen it emblazoned on some t-shirts at functional programming conferences.</p><h2>Monads from Adjunctions</h2><p>An <a href="https://bartoszmilewski.com/2016/04/18/adjunctions/">adjunction</a>, <code>L ⊣ R</code>, is a pair of functors going back and forth between two categories <i>C</i> and <i>D</i>. There are two ways of composing them giving rise to two endofunctors, <code>R ∘ L</code> and <code>L ∘ R</code>. As per an adjunction, these endofunctors are related to identity functors through two natural transformations called unit and counit:</p><pre>η :: I<sub>D</sub> -&gt; R ∘ L
            ε :: L ∘ R -&gt; I<sub>C</sub></pre><p>Immediately we see that the unit of an adjunction looks just like the unit of a monad. It turns out that the endofunctor <code>R ∘ L</code> is indeed a monad. All we need is to define the appropriate μ to go with the η. That’s a natural transformation between the square of our endofunctor and the endofunctor itself or, in terms of the adjoint functors:</p><pre>R ∘ L ∘ R ∘ L -&gt; R ∘ L</pre><p>And, indeed, we can use the counit to collapse the <code>L ∘ R</code> in the middle. The exact formula for μ is given by the horizontal composition:</p><pre>μ = R ∘ ε ∘ L</pre><p>Monadic laws follow from the identities satisfied by the unit and counit of the adjunction and the interchange law.</p><p>We don’t see a lot of monads derived from adjunctions in Haskell, because an adjunction usually involves two categories. However, the definitions of an exponential, or a function object, is an exception. Here are the two endofunctors that form this adjunction:</p><pre>L z = z × s
            R b = s ⇒ b</pre><p>You may recognize their composition as the familiar state monad:</p><pre>R (L z) = s ⇒ (z × s)</pre><p>We’ve seen this monad before in Haskell:</p><pre>newtype State s a = State (s -&gt; (a, s))</pre><p>Let’s also translate the adjunction to Haskell. The left functor is the product functor:</p><pre>newtype Prod s a = Prod (a, s)</pre><p>and the right functor is the reader functor:</p><pre>newtype Reader s a = Reader (s -&gt; a)</pre><p>They form the adjunction:</p><pre>instance Adjunction (Prod s) (Reader s) where
              counit (Prod (Reader f, s)) = f s
              unit a = Reader (\s -&gt; Prod (a, s))</pre><p>You can easily convince yourself that the composition of the reader functor after the product functor is indeed equivalent to the state functor:</p><pre>newtype State s a = State (s -&gt; (a, s))</pre><p>As expected, the <code>unit</code> of the adjunction is equivalent to the <code>return</code> function of the state monad. The <code>counit</code> acts by evaluating a function acting on its argument. This is recognizable as the uncurried version of the function <code>runState</code>:</p><pre>runState :: State s a -&gt; s -&gt; (a, s)
            runState (State f) s = f s</pre><p>(uncurried, because in <code>counit</code> it acts on a pair).</p><p>We can now define <code>join</code> for the state monad as a component of the natural transformation μ. For that we need a horizontal composition of three natural transformations:</p><pre>μ = R ∘ ε ∘ L</pre><p>In other words, we need to sneak the counit ε across one level of the reader functor. We can’t just call <code>fmap</code> directly, because the compiler would pick the one for the <code>State</code> functor, rather than the <code>Reader</code> functor. But recall that <code>fmap</code> for the reader functor is just left function composition. So we’ll use function composition directly.</p><p>We have to first peel off the data constructor <code>State</code> to expose the function inside the <code>State</code> functor. This is done using <code>runState</code>:</p><pre>ssa :: State s (State s a)
            runState ssa :: s -&gt; (State s a, s)</pre><p>Then we left-compose it with the counit, which is defined by <code>uncurry runState</code>. Finally, we clothe it back in the <code>State</code> data constructor:</p><pre>join :: State s (State s a) -&gt; State s a
            join ssa = State (uncurry runState . runState ssa)</pre><p>This is indeed the implementation of <code>join</code> for the <code>State</code> monad.</p><p>It turns out that not only every adjunction gives rise to a monad, but the converse is also true: every monad can be factorized into a composition of two adjoint functors. Such factorization is not unique though.</p><p>We’ll talk about the other endofunctor <code>L ∘ R</code> in the next section.</p><p>Next: <a href="https://bartoszmilewski.com/2017/01/02/comonads/">Comonads</a>.</p>

            <h2 class="post-title">
 			F-Algebras		</h2><p>We’ve seen several formulations of a monoid: as a set, as a single-object category, as an object in a monoidal category. How much more juice can we squeeze out of this simple concept?</p><p>Let’s try. Take this definition of a monoid as a set <code>m</code> with a pair of functions:</p><pre>μ :: m × m -&gt; m
 η :: 1 -&gt; m</pre><p>Here, 1 is the terminal object in <b>Set</b> — the singleton set. The first function defines multiplication (it takes a pair of elements and returns their product), the second selects the unit element from <code>m</code>. Not every choice of two functions with these signatures results in a monoid. For that we need to impose additional conditions: associativity and unit laws. But let’s forget about that for a moment and just consider “potential monoids.” A pair of functions is an element of a cartesian product of two sets of functions. We know that these sets may be represented as exponential objects:</p><pre>μ ∈ m<sup> m×m</sup>
 η ∈ m<sup>1</sup></pre><p>The cartesian product of these two sets is:</p><pre>m<sup> m×m</sup> × m<sup>1</sup></pre><p>Using some high-school algebra (which works in every cartesian closed category), we can rewrite it as:</p><pre>m<sup> m×m + 1</sup></pre><p>The plus sign stands for the coproduct in <b>Set</b>. We have just replaced a pair of functions with a single function — an element of the set:</p><pre>m × m + 1 -&gt; m</pre><p>Any element of this set of functions is a potential monoid.</p><p>The beauty of this formulation is that it leads to interesting generalizations. For instance, how would we describe a group using this language? A group is a monoid with one additional function that assigns the inverse to every element. The latter is a function of the type <code>m-&gt;m</code>. As an example, integers form a group with addition as a binary operation, zero as the unit, and negation as the inverse. To define a group we would start with a triple of functions:</p><pre>m × m -&gt; m
 m -&gt; m
 1 -&gt; m</pre><p>As before, we can combine all these triples into one set of functions:</p><pre>m × m + m + 1 -&gt; m</pre><p>We started with one binary operator (addition), one unary operator (negation), and one nullary operator (identity — here zero). We combined them into one function. All functions with this signature define potential groups.</p><p>We can go on like this. For instance, to define a ring, we would add one more binary operator and one nullary operator, and so on. Each time we end up with a function type whose left-hand side is a sum of powers (possibly including the zeroth power — the terminal object), and the right-hand side being the set itself.</p><p>Now we can go crazy with generalizations. First of all, we can replace sets with objects and functions with morphisms. We can define n-ary operators as morphisms from n-ary products. It means that we need a category that supports finite products. For nullary operators we require the existence of the terminal object. So we need a cartesian category. In order to combine these operators we need exponentials, so that’s a cartesian closed category. Finally, we need coproducts to complete our algebraic shenanigans.</p><p>Alternatively, we can just forget about the way we derived our formulas and concentrate on the final product. The sum of products on the left hand side of our morphism defines an endofunctor. What if we pick an arbitrary endofunctor <code>F</code> instead? In that case we don’t have to impose any constraints on our category. What we obtain is called an F-algebra.</p><p>An F-algebra is a triple consisting of an endofunctor <code>F</code>, an object <code>a</code>, and a morphism</p><pre>F a -&gt; a</pre><p>The object is often called the carrier, an underlying object or, in the context of programming, the carrier <em>type</em>. The morphism is often called the evaluation function or the structure map. Think of the functor <code>F</code> as forming expressions and the morphism as evaluating them.</p><p>Here’s the Haskell definition of an F-algebra:</p><pre>type Algebra f a = f a -&gt; a</pre><p>It identifies the algebra with its evaluation function.</p><p>In the monoid example, the functor in question is:</p><pre>data MonF a = MEmpty | MAppend a a</pre><p>This is Haskell for <code>1 + a × a</code> (remember <a href="https://bartoszmilewski.com/2015/01/13/simple-algebraic-data-types/" target="_blank">algebraic data structures</a>).</p><p>A ring would be defined using the following functor:</p><pre>data RingF a = RZero
             | ROne
             | RAdd a a
             | RMul a a
             | RNeg a</pre><p>which is Haskell for <code>1 + 1 + a × a + a × a + a</code>.</p><p>An example of a ring is the set of integers. We can choose <code>Integer</code> as the carrier type and define the evaluation function as:</p><pre>evalZ :: <b>Algebra</b> RingF Integer
 evalZ RZero      = 0
 evalZ ROne       = 1
 evalZ (RAdd m n) = m + n
 evalZ (RMul m n) = m * n
 evalZ (RNeg n)   = -n</pre><p>There are more F-algebras based on the same functor <code>RingF</code>. For instance, polynomials form a ring and so do square matrices.</p><p>As you can see, the role of the functor is to generate expressions that can be evaluated using the evaluator of the algebra. So far we’ve only seen very simple expressions. We are often interested in more elaborate expressions that can be defined using recursion.</p><h2>Recursion</h2><p>One way to generate arbitrary expression trees is to replace the variable <code>a</code> inside the functor definition with recursion. For instance, an arbitrary expression in a ring is generated by this tree-like data structure:</p><pre>data Expr = RZero
          | ROne
          | RAdd Expr Expr
          | RMul Expr Expr
          | RNeg Expr</pre><p>We can replace the original ring evaluator with its recursive version:</p><pre>evalZ :: Expr -&gt; Integer
 evalZ RZero        = 0
 evalZ ROne         = 1
 evalZ (RAdd e1 e2) = evalZ e1 + evalZ e2
 evalZ (RMul e1 e2) = evalZ e1 * evalZ e2
 evalZ (RNeg e)     = -(evalZ e)</pre><p>This is still not very practical, since we are forced to represent all integers as sums of ones, but it will do in a pinch.</p><p>But how can we describe expression trees using the language of F-algebras? We have to somehow formalize the process of replacing the free type variable in the definition of our functor, recursively, with the result of the replacement. Imagine doing this in steps. First, define a depth-one tree as:</p><pre>type RingF1 a = RingF (RingF a)</pre><p>We are filling the holes in the definition of <code>RingF</code> with depth-zero trees generated by <code>RingF a</code>. Depth-2 trees are similarly obtained as:</p><pre>type RingF2 a = RingF (RingF (RingF a))</pre><p>which we can also write as:</p><pre>type RingF2 a = RingF (RingF1 a)</pre><p>Continuing this process, we can write a symbolic equation:</p><pre>type RingF<sub>n+1</sub> a = RingF (RingF<sub>n</sub> a)</pre><p>Conceptually, after repeating this process infinitely many times, we end up with our <code>Expr</code>. Notice that <code>Expr</code> does not depend on <code>a</code>. The starting point of our journey doesn’t matter, we always end up in the same place. This is not always true for an arbitrary endofunctor in an arbitrary category, but in the category <b>Set</b> things are nice.</p><p>Of course, this is a hand-waving argument, and I’ll make it more rigorous later.</p><p>Applying an endofunctor infinitely many times produces a <i>fixed point</i>, an object defined as:</p><pre>Fix f = f (Fix f)</pre><p>The intuition behind this definition is that, since we applied <code>f</code> infinitely many times to get <code>Fix f</code>, applying it one more time doesn’t change anything. In Haskell, the definition of a fixed point is:</p><pre>newtype Fix f = Fix (f (Fix f))</pre><p>Arguably, this would be more readable if the constructor’s name were different than the name of the type being defined, as in:</p><pre>newtype Fix f = In (f (Fix f))</pre><p>but I’ll stick with the accepted notation. The constructor <code>Fix</code> (or <code>In</code>, if you prefer) can be seen as a function:</p><pre>Fix :: f (Fix f) -&gt; Fix f</pre><p>There is also a function that peels off one level of functor application:</p><pre>unFix :: Fix f -&gt; f (Fix f)
 unFix (Fix x) = x</pre><p>The two functions are the inverse of each other. We’ll use these functions later.</p><h2>Category of F-Algebras</h2><p>Here’s the oldest trick in the book: Whenever you come up with a way of constructing some new objects, see if they form a category. Not surprisingly, algebras over a given endofunctor <code>F</code> form a category. Objects in that category are algebras — pairs consisting of a carrier object <code>a</code> and a morphism <code>F a -&gt; a</code>, both from the original category <i>C</i>.</p><p>To complete the picture, we have to define morphisms in the category of F-algebras. A morphism must map one algebra <code>(a, f)</code> to another algebra <code>(b, g)</code>. We’ll define it as a morphism <code>m</code> that maps the carriers — it goes from <code>a</code> to <code>b</code> in the original category. Not any morphism will do: we want it to be compatible with the two evaluators. (We call such a structure-preserving morphism a <i>homomorphism</i>.) Here’s how you define a homomorphism of F-algebras. First, notice that we can lift <code>m</code> to the mapping:</p><pre>F m :: F a -&gt; F b</pre><p>we can then follow it with <code>g</code> to get to <code>b</code>. Equivalently, we can use <code>f</code> to go from <code>F a</code> to <code>a</code> and then follow it with <code>m</code>. We want the two paths to be equal:</p><pre>g ∘ F m = m ∘ f</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png"><img data-attachment-id="8351" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png" data-orig-size="452,314" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=201&amp;h=139" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=452" class="alignnone wp-image-8351" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=201&amp;h=139" alt="alg" width="201" height="139" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=201&amp;h=139 201w, https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=400&amp;h=278 400w, https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=150&amp;h=104 150w, https://bartoszmilewski.files.wordpress.com/2017/02/alg.png?w=300&amp;h=208 300w" sizes="(max-width: 201px) 100vw, 201px"></a></p><p>It’s easy to convince yourself that this is indeed a category (hint: identity morphisms from <i>C</i> work just fine, and a composition of homomorphisms is a homomorphism).</p><p>An initial object in the category of F-algebras, if it exists, is called the <em>initial algebra</em>. Let’s call the carrier of this initial algebra <code>i</code> and its evaluator <code>j :: F i -&gt; i</code>. It turns out that <code>j</code>, the evaluator of the initial algebra, is an isomorphism. This result is known as Lambek’s theorem. The proof relies on the definition of the initial object, which requires that there be a unique homomorphism <code>m</code> from it to any other F-algebra. Since <code>m</code> is a homomorphism, the following diagram must commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png"><img data-attachment-id="8343" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png?w=510" data-orig-size="204,132" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png?w=510?w=204" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png?w=510?w=204" class="alignnone size-full wp-image-8343" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png?w=510" alt="alg2" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png 204w, https://bartoszmilewski.files.wordpress.com/2017/02/alg2.png?w=150 150w" sizes="(max-width: 204px) 100vw, 204px"></a></p><p>Now let’s construct an algebra whose carrier is <code>F i</code>. The evaluator of such an algebra must be a morphism from <code>F (F i)</code> to <code>F i</code>. We can easily construct such an evaluator simply by lifting <code>j</code>:</p><pre>F j :: F (F i) -&gt; F i</pre><p>Because <code>(i, j)</code> is the initial algebra, there must be a unique homomorphism <code>m</code> from it to <code>(F i, F j)</code>. The following diagram must commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png"><img data-attachment-id="8356" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg3a/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png?w=510" data-orig-size="199,145" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg3a" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png?w=510?w=199" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png?w=510?w=199" class="alignnone size-full wp-image-8356" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png?w=510" alt="alg3a" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png 199w, https://bartoszmilewski.files.wordpress.com/2017/02/alg3a.png?w=150 150w" sizes="(max-width: 199px) 100vw, 199px"></a></p><p>But we also have this trivially commuting diagram (both paths are the same!):</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png"><img data-attachment-id="8344" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg3/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png?w=510" data-orig-size="222,144" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg3" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png?w=510?w=222" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png?w=510?w=222" class="alignnone size-full wp-image-8344" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png?w=510" alt="alg3" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png 222w, https://bartoszmilewski.files.wordpress.com/2017/02/alg3.png?w=150 150w" sizes="(max-width: 222px) 100vw, 222px"></a></p><p>which can be interpreted as showing that <code>j</code> is a homomorphism of algebras, mapping <code>(F i, F j)</code> to <code>(i, j)</code>. We can glue these two diagrams together to get:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png"><img data-attachment-id="8345" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg4/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png" data-orig-size="329,145" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg4" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png?w=300&amp;h=132" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png?w=329" class="alignnone size-medium wp-image-8345" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png?w=300&amp;h=132" alt="alg4" width="300" height="132" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png?w=300&amp;h=132 300w, https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png?w=150&amp;h=66 150w, https://bartoszmilewski.files.wordpress.com/2017/02/alg4.png 329w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>This diagram may, in turn, be interpreted as showing that <code>j ∘ m</code> is a homomorphism of algebras. Only in this case the two algebras are the same. Moreover, because <code>(i, j)</code> is initial, there can only be one homomorphism from it to itself, and that’s the identity morphism <code>id<sub>i</sub></code> — which we know is a homomorphism of algebras. Therefore <code>j ∘ m = id<sub>i</sub></code>. Similarly, we can prove that <code>m ∘ j = id<sub>F i</sub></code> by stacking the two diagrams in the reverse order. This shows that <code>m</code> is the inverse of <code>j</code> and therefore <code>j</code> is an isomorphism between <code>F i</code> and <code>i</code>:</p><pre>F i ≅ i</pre><p>But that is just saying that <code>i</code> is a fixed point of <code>F</code>. That’s the formal proof behind the original hand-waving argument.</p><p>Back to Haskell: We recognize <code>i</code> as our <code>Fix f</code>, <code>j</code> as our constructor <code>Fix</code>, and its inverse as <code>unFix</code>. The isomorphism in Lambek’s theorem tells us that, in order to get the initial algebra, we take the functor <code>f</code> and replace its argument <code>a</code> with <code>Fix f</code>. We also see why the fixed point does not depend on <code>a</code>.</p><h3>Natural Numbers</h3><p>Natural numbers can also be defined as an F-algebra. The starting point is the pair of morphisms:</p><pre>zero :: 1 -&gt; N
 succ :: N -&gt; N</pre><p>The first one picks the zero, and the second one maps all numbers to their successors. As before, we can combine the two into one:</p><pre>1 + N -&gt; N</pre><p>The left hand side defines a functor which, in Haskell, can be written like this:</p><pre>data NatF a = ZeroF | SuccF a</pre><p>The fixed point of this functor (the initial algebra that it generates) can be encoded in Haskell as:</p><pre>data Nat = Zero | Succ Nat</pre><p>A natural number is either zero or a successor of another number. This is known as the Peano representation for natural numbers.</p><h2>Catamorphisms</h2><p>Let’s rewrite the initiality condition using Haskell notation. We call the initial algebra <code>Fix f</code>. Its evaluator is the contructor <code>Fix</code>. There is a unique morphism <code>m</code> from the initial algebra to any other algebra over the same functor. Let’s pick an algebra whose carrier is <code>a</code> and the evaluator is <code>alg</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png"><img data-attachment-id="8346" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg5/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png?w=510" data-orig-size="265,142" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg5" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png?w=510?w=265" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png?w=510?w=265" class="alignnone size-full wp-image-8346" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png?w=510" alt="alg5" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png 265w, https://bartoszmilewski.files.wordpress.com/2017/02/alg5.png?w=150 150w" sizes="(max-width: 265px) 100vw, 265px"></a><br>
 By the way, notice what <code>m</code> is: It’s an evaluator for the fixed point, an evaluator for the whole recursive expression tree. Let’s find a general way of implementing it.</p><p>Lambek’s theorem tells us that the constructor <code>Fix</code> is an isomorphism. We called its inverse <code>unFix</code>. We can therefore flip one arrow in this diagram to get:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png"><img data-attachment-id="8347" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg6/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png?w=510" data-orig-size="267,143" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg6" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png?w=510?w=267" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png?w=510?w=267" class="alignnone size-full wp-image-8347" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png?w=510" alt="alg6" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png 267w, https://bartoszmilewski.files.wordpress.com/2017/02/alg6.png?w=150 150w" sizes="(max-width: 267px) 100vw, 267px"></a></p><p>Let’s write down the commutation condition for this diagram:</p><pre>m = alg . fmap m . unFix</pre><p>We can interpret this equation as a recursive definition of <code>m</code>. The recursion is bound to terminate for any finite tree created using the functor <code>f</code>. We can see that by noticing that <code>fmap m</code> operates underneath the top layer of the functor <code>f</code>. In other words, it works on the children of the original tree. The children are always one level shallower than the original tree.</p><p>Here’s what happens when we apply <code>m</code> to a tree constructed using <code>Fix f</code>. The action of <code>unFix</code> peels off the constructor, exposing the top level of the tree. We then apply <code>m</code> to all the children of the top node. This produces results of type <code>a</code>. Finally, we combine those results by applying the non-recursive evaluator <code>alg</code>. The key point is that our evaluator <code>alg</code> is a simple non-recursive function.</p><p>Since we can do this for any algebra <code>alg</code>, it makes sense to define a higher order function that takes the algebra as a parameter and gives us the function we called <code>m</code>. This higher order function is called a catamorphism:</p><pre>cata :: Functor f =&gt; (f a -&gt; a) -&gt; Fix f -&gt; a
 cata alg = alg . fmap (cata alg) . unFix</pre><p>Let’s see an example of that. Take the functor that defines natural numbers:</p><pre>data NatF a = ZeroF | SuccF a</pre><p>Let’s pick <code>(Int, Int)</code> as the carrier type and define our algebra as:</p><pre>fib :: NatF (Int, Int) -&gt; (Int, Int)
 fib ZeroF = (1, 1)
 fib (SuccF (m, n)) = (n, m + n)</pre><p>You can easily convince yourself that the catamorphism for this algebra, <code>cata fib</code>, calculates Fibonacci numbers.</p><p>In general, an algebra for <code>NatF</code> defines a recurrence relation: the value of the current element in terms of the previous element. A catamorphism then evaluates the n-th element of that sequence.</p><h2>Folds</h2><p>A list of <code>e</code> is the initial algebra of the following functor:</p><pre>data ListF e a = NilF | ConsF e a</pre><p>Indeed, replacing the variable <code>a</code> with the result of recursion, which we’ll call <code>List e</code>, we get:</p><pre>data List e = Nil | Cons e (List e)</pre><p>An algebra for a list functor picks a particular carrier type and defines a function that does pattern matching on the two constructors. Its value for <code>NilF</code> tells us how to evaluate an empty list, and its value for <code>ConsF</code> tells us how to combine the current element with the previously accumulated value.</p><p>For instance, here’s an algebra that can be used to calculate the length of a list (the carrier type is <code>Int</code>):</p><pre>lenAlg :: ListF e Int -&gt; Int
 lenAlg (ConsF e n) = n + 1
 lenAlg NilF = 0</pre><p>Indeed, the resulting catamorphism <code>cata lenAlg</code> calculates the length of a list. Notice that the evaluator is a combination of (1) a function that takes a list element and an accumulator and returns a new accumulator, and (2) a starting value, here zero. The type of the value and the type of the accumulator are given by the carrier type.</p><p>Compare this to the traditional Haskell definition:</p><pre>length = foldr (\e n -&gt; n + 1) 0</pre><p>The two arguments to <code>foldr</code> are exactly the two components of the algebra.</p><p>Let’s try another example:</p><pre>sumAlg :: ListF Double Double -&gt; Double
 sumAlg (ConsF e s) = e + s
 sumAlg NilF = 0.0</pre><p>Again, compare this with:</p><pre>sum = foldr (\e s -&gt; e + s) 0.0</pre><p>As you can see, <code>foldr</code> is just a convenient specialization of a catamorphism to lists.</p><h2>Coalgebras</h2><p>As usual, we have a dual construction of an F-coagebra, where the direction of the morphism is reversed:</p><pre>a -&gt; F a</pre><p>Coalgebras for a given functor also form a category, with homomorphisms preserving the coalgebraic structure. The terminal object <code>(t, u)</code> in that category is called the terminal (or final) coalgebra. For every other algebra <code>(a, f)</code> there is a unique homomorphism <code>m</code> that makes the following diagram commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png"><img data-attachment-id="8348" data-permalink="https://bartoszmilewski.com/2017/02/28/f-algebras/alg7/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png?w=510" data-orig-size="204,134" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="alg7" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png?w=510?w=204" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png?w=510?w=204" class="alignnone size-full wp-image-8348" src="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png?w=510" alt="alg7" srcset="https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png 204w, https://bartoszmilewski.files.wordpress.com/2017/02/alg7.png?w=150 150w" sizes="(max-width: 204px) 100vw, 204px"></a></p><p>A terminal colagebra is a fixed point of the functor, in the sense that the morphism <code>u :: t -&gt; F t</code> is an isomorphism (Lambek’s theorem for coalgebras):</p><pre>F t ≅ t</pre><p>A terminal coalgebra is usually interpreted in programming as a recipe for generating (possibly infinite) data structures or transition systems.</p><p>Just like a catamorphism can be used to evaluate an initial algebra, an anamorphism can be used to coevaluate a terminal coalgebra:</p><pre>ana :: Functor f =&gt; (a -&gt; f a) -&gt; a -&gt; Fix f
 ana coalg = Fix . fmap (ana coalg) . coalg</pre><p>A canonical example of a coalgebra is based on a functor whose fixed point is an infinite stream of elements of type <code>e</code>. This is the functor:</p><pre>data StreamF e a = StreamF e a
  deriving Functor</pre><p>and this is its fixed point:</p><pre>data Stream e = Stream e (Stream e)</pre><p>A coalgebra for <code>StreamF e</code> is a function that takes the seed of type <code>a</code> and produces a pair (<code>StreamF</code> is a fancy name for a pair) consisting of an element and the next seed.</p><p>You can easily generate simple examples of coalgebras that produce infinite sequences, like the list of squares, or reciprocals. </p><p>A more interesting example is a coalgebra that produces a list of primes. The trick is to use an infinite list as a carrier. Our starting seed will be the list <code>[2..]</code>. The next seed will be the tail of this list with all multiples of 2 removed. It’s a list of odd numbers starting with 3. In the next step, we’ll take the tail of this list and remove all multiples of 3, and so on. You might recognize the makings of the sieve of Eratosthenes. This coalgebra is implemented by the following function:</p><pre>era :: [Int] -&gt; StreamF Int [Int]
 era (p : ns) = StreamF p (filter (notdiv p) ns)
    where notdiv p n = n `mod` p /= 0</pre><p>The anamorphism for this coalgebra generates the list of primes:</p><pre>primes = ana era [2..]</pre><p>A stream is an infinite list, so it should be possible to convert it to a Haskell list. To do that, we can use the same functor <code>StreamF</code> to form an algebra, and we can run a catamorphism over it. For instance, this is a catamorphism that converts a stream to a list:</p><pre>toListC :: Fix (StreamF e) -&gt; [e]
 toListC = cata al
   where al :: StreamF e [e] -&gt; [e]
         al (StreamF e a) = e : a</pre><p>Here, the same fixed point is simultaneously an initial algebra and a terminal coalgebra for the same endofunctor. It’s not always like this, in an arbitrary category. In general, an endofunctor may have many (or no) fixed points. The initial algebra is the so called least fixed point, and the terminal coalgebra is the greatest fixed point. In Haskell, though, both are defined by the same formula, and they coincide.</p><p>The anamorphism for lists is called unfold. To create finite lists, the functor is modified to produce a <code>Maybe</code> pair:</p><pre>unfoldr :: (b -&gt; Maybe (a, b)) -&gt; b -&gt; [a]</pre><p>The value of <code>Nothing</code> will terminate the generation of the list.</p><p>An interesting case of a coalgebra is related to lenses. A lens can be represented as a pair of a getter and a setter:</p><pre>set :: a -&gt; s -&gt; a
 get :: a -&gt; s</pre><p>Here, <code>a</code> is usually some product data type with a field of type <code>s</code>. The getter retrieves the value of that field and the setter replaces this field with a new value. These two functions can be combined into one:</p><pre>a -&gt; (s, s -&gt; a)</pre><p>We can rewrite this function further as:</p><pre>a -&gt; Store s a</pre><p>where we have defined a functor:</p><pre>data Store s a = Store (s -&gt; a) s</pre><p>Notice that this is not a simple algebraic functor constructed from sums of products. It involves an exponential <code>a<sup>s</sup></code>.</p><p>A lens is a coalgebra for this functor with the carrier type <code>a</code>. We’ve seen before that <code>Store s</code> is also a comonad. It turns out that a well-behaved lens corresponds to a coalgebra that is compatible with the comonad structure. We’ll talk about this in the next section.</p><h2>Challenges</h2><ol>
 <li>Implement the evaluation function for a ring of polynomials of one variable. You can represent a polynomial as a list of coefficients in front of powers of <code>x</code>. For instance, <code>4x<sup>2</sup>-1</code> would be represented as (starting with the zero’th power) <code>[-1, 0, 4]</code>.</li>
 <li>Generalize the previous construction to polynomials of many independent variables, like <code>x<sup>2</sup>y-3y<sup>3</sup>z</code>.</li>
 <li>Implement the algebra for the ring of 2×2 matrices.</li>
 <li>Define a coalgebra whose anamorphism produces a list of squares of natural numbers.</li>
 <li>Use <code>unfoldr</code> to generate a list of the first <code>n</code> primes.</li>
 </ol><p>Next: <a href="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/">Algebras for Monads</a>.</p>

 <h2 class="post-title">
 			Algebras for Monads		</h2><p>If we interpret endofunctors as ways of defining expressions, algebras let us evaluate them and monads let us form and manipulate them. By combining algebras with monads we not only gain a lot of functionality but we can also answer a few interesting questions. One such question concerns the relation between monads and adjunctions. As we’ve seen, every adjunction <a href="https://bartoszmilewski.com/2016/12/27/monads-categorically/" target="_blank">defines a monad</a> (and a comonad). The question is: Can every monad (comonad) be derived from an adjunction? The answer is positive. There is a whole family of adjunctions that generate a given monad. I’ll show you two such adjunction.<br>
 <a href="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png"><img data-attachment-id="8438" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/pigalg/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png" data-orig-size="342,373" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="PigAlg" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=122&amp;h=133" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=342" class="alignnone wp-image-8438" src="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=122&amp;h=133" alt="" width="122" height="133" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=122&amp;h=133 122w, https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=244&amp;h=266 244w, https://bartoszmilewski.files.wordpress.com/2017/03/pigalg.png?w=138&amp;h=150 138w" sizes="(max-width: 122px) 100vw, 122px"></a><br>
 Let’s review the definitions. A monad is an endofunctor <code>m</code> equipped with two natural transformations that satisfy some coherence conditions. The components of these transformations at <code>a</code> are:</p><pre>η<sub>a</sub> :: a -&gt; m a
 μ<sub>a</sub> :: m (m a) -&gt; m a</pre><p>An algebra for the same endofunctor is a selection of a particular object — the carrier <code>a</code> — together with the morphism:</p><pre>alg :: m a -&gt; a</pre><p>The first thing to notice is that the algebra goes in the opposite direction to <code>η<sub>a</sub></code>. The intuition is that <code>η<sub>a</sub></code> creates a trivial expression from a value of type <code>a</code>. The first coherence condition that makes the algebra compatible with the monad ensures that evaluating this expression using the algebra whose carrier is <code>a</code> gives us back the original value:</p><pre>alg ∘ η<sub>a</sub> = id<sub>a</sub></pre><p>The second condition arises from the fact that there are two ways of evaluating the doubly nested expression <code>m (m a)</code>. We can first apply <code>μ<sub>a</sub></code> to flatten the expression, and then use the evaluator of the algebra; or we can apply the lifted evaluator to evaluate the inner expressions, and then apply the evaluator to the result. We’d like the two strategies to be equivalent:</p><pre>alg ∘ μ<sub>a</sub> = alg ∘ m alg</pre><p>Here, <code>m alg</code> is the morphism resulting from lifting <code>alg</code> using the functor <code>m</code>. The following commuting diagrams describe the two conditions (I replaced <code>m</code> with <code>T</code> in anticipation of what follows):</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png"><img data-attachment-id="8430" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/talg1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png" data-orig-size="456,336" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Talg1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=174&amp;h=128" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=456" class="alignnone wp-image-8430" src="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=174&amp;h=128" alt="" width="174" height="128" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=174&amp;h=128 174w, https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=348&amp;h=256 348w, https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=150&amp;h=111 150w, https://bartoszmilewski.files.wordpress.com/2017/03/talg1.png?w=300&amp;h=221 300w" sizes="(max-width: 174px) 100vw, 174px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png"><img data-attachment-id="8431" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/talg2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png" data-orig-size="620,342" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Talg2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=231&amp;h=127" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=510" class="alignnone wp-image-8431" src="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=231&amp;h=127" alt="" width="231" height="127" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=231&amp;h=127 231w, https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=460&amp;h=254 460w, https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=150&amp;h=83 150w, https://bartoszmilewski.files.wordpress.com/2017/03/talg2.png?w=300&amp;h=165 300w" sizes="(max-width: 231px) 100vw, 231px"></a></p><p>We can also express these condition in Haskell:</p><pre>alg . return = id
 alg . join = alg . fmap alg</pre><p>Let’s look at a small example. An algebra for a list endofunctor consists of some type <code>a</code> and a function that produces an <code>a</code> from a list of <code>a</code>. We can express this function using <code>foldr</code> by choosing both the element type and the accumulator type to be equal to <code>a</code>:</p><pre>foldr :: (a -&gt; a -&gt; a) -&gt; a -&gt; [a] -&gt; a</pre><p>This particular algebra is specified by a two-argument function, let’s call it <code>f</code>, and a value <code>z</code>. The list functor happens to also be a monad, with <code>return</code> turning a value into a singleton list. The composition of the algebra, here <code>foldr f z</code>, after <code>return</code> takes <code>x</code> to:</p><pre>foldr f z [x] = x `f` z</pre><p>where the action of <code>f</code> is written in the infix notation. The algebra is compatible with the monad if the following coherence condition is satisfied for every <code>x</code>:</p><pre>x `f` z = x</pre><p>If we look at <code>f</code> as a binary operator, this condition tells us that <code>z</code> is the right unit.</p><p>The second coherence condition operates on a list of lists. The action of <code>join</code> concatenates the individual lists. We can then fold the resulting list. On the other hand, we can first fold the individual lists, and then fold the resulting list. Again, if we interpret <code>f</code> as a binary operator, this condition tells us that this binary operation is associative. These conditions are certainly fulfilled when <code>(a, f, z)</code> is a monoid.</p><h2>T-algebras</h2><p>Since mathematicians prefer to call their monads <code>T</code>, they call algebras compatible with them T-algebras. T-algebras for a given monad T in a category <i>C</i> form a category called the Eilenberg-Moore category, often denoted by C<sup>T</sup>. Morphisms in that category are homomorphisms of algebras. These are the same homomorphisms we’ve seen defined for F-algebras.</p><p>A T-algebra is a pair consisting of a carrier object and an evaluator, <code>(a, f)</code>. There is an obvious forgetful functor <code>U<sup>T</sup></code> from C<sup>T</sup> to C, which maps <code>(a, f)</code> to <code>a</code>. It also maps a homomorphism of T-algebras to a corresponding morphism between carrier objects in C. You may remember from our discussion of adjunctions that the left adjoint to a forgetful functor is called a free functor.</p><p>The left adjoint to <code>U<sup>T</sup></code> is called <code>F<sup>T</sup></code>. It maps an object <code>a</code> in C to a free algebra in C<sup>T</sup>. The carrier of this free algebra is <code>T a</code>. Its evaluator is a morphism from <code>T (T a)</code> back to <code>T a</code>. Since <code>T</code> is a monad, we can use the monadic <code>μ<sub>a</sub></code> (Haskell <code>join</code>) as the evaluator.</p><p>We still have to show that this is a T-algebra. For that, two coherence conditions must be satisified:</p><pre>alg ∘ η<sub>Ta</sub> = id<sub>Ta</sub></pre><pre>alg ∘ μ<sub>a</sub> = alg ∘ T alg</pre><p>But these are just monadic laws, if you plug in <code>μ</code> for the algebra.</p><p>As you may recall, every adjunction defines a monad. It turns out that the adjunction between F<sup>T</sup> and U<sup>T</sup> defines the very monad <code>T</code> that was used in the construction of the Eilenberg-Moore category. Since we can perform this construction for every monad, we conclude that every monad can be generated from an adjunction. Later I’ll show you that there is another adjunction that generates the same monad.</p><p>Here’s the plan: First I’ll show you that <code>F<sup>T</sup></code> is indeed the left adjoint of <code>U<sup>T</sup></code>. I’ll do it by defining the unit and the counit of this adjunction and proving that the corresponding triangular identities are satisfied. Then I’ll show you that the monad generated by this adjunction is indeed our original monad.</p><p>The unit of the adjunction is the natural transformation:</p><pre>η :: I -&gt; U<sup>T</sup> ∘ F<sup>T</sup></pre><p>Let’s calculate the <code>a</code> component of this transformation. The identity functor gives us <code>a</code>. The free functor produces the free algebra <code>(T a, μ<sub>a</sub>)</code>, and the forgetful functor reduces it to <code>T a</code>. Altogether we get a mapping from <code>a</code> to <code>T a</code>. We’ll simply use the unit of the monad <code>T</code> as the unit of this adjunction.</p><p>Let’s look at the counit:</p><pre>ε :: F<sup>T</sup> ∘ U<sup>T</sup> -&gt; I</pre><p>Let’s calculate its component at some T-algebra <code>(a, f)</code>. The forgetful functor forgets the <code>f</code>, and the free functor produces the pair <code>(T a, μ<sub>a</sub>)</code>. So in order to define the component of the counit <code>ε</code> at <code>(a, f)</code>, we need the right morphism in the Eilenberg-Moore category, or a homomorphism of T-algebras:</p><pre>(T a, μ<sub>a</sub>) -&gt; (a, f)</pre><p>Such homomorphism should map the carrier <code>T a</code> to <code>a</code>. Let’s just resurrect the forgotten evaluator <code>f</code>. This time we’ll use it as a homomorphism of T-algebras. Indeed, the same commuting diagram that makes <code>f</code> a T-algebra may be re-interpreted to show that it’s a homomorphism of T-algebras:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png"><img data-attachment-id="8441" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/talg3-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png" data-orig-size="594,369" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Talg3" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=247&amp;h=153" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=510" class="alignnone  wp-image-8441" src="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=247&amp;h=153" alt="" width="247" height="153" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=247&amp;h=153 247w, https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=494&amp;h=306 494w, https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=150&amp;h=93 150w, https://bartoszmilewski.files.wordpress.com/2017/03/talg31.png?w=300&amp;h=186 300w" sizes="(max-width: 247px) 100vw, 247px"></a><br>
 We have thus defined the component of the counit natural transformation <code>ε</code> at <code>(a, f)</code> (an object in the category of T-algebras) to be <code>f</code>.</p><p>To complete the adjunction we also need to show that the unit and the counit satisfy triangular identites. These are:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png"><img data-attachment-id="8433" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/talg4/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png" data-orig-size="1066,374" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Talg4" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=446&amp;h=156" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=510" class="alignnone wp-image-8433" src="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=446&amp;h=156" alt="" width="446" height="156" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=446&amp;h=156 446w, https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=889&amp;h=312 889w, https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=150&amp;h=53 150w, https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=300&amp;h=105 300w, https://bartoszmilewski.files.wordpress.com/2017/03/talg4.png?w=768&amp;h=269 768w" sizes="(max-width: 446px) 100vw, 446px"></a></p><p>The first one holds because of the unit law for the monad <code>T</code>. The second is just the law of the T-algebra <code>(a, f)</code>.</p><p>We have established that the two functors form an adjunction:</p><pre>F<sup>T</sup> ⊣ U<sup>T</sup></pre><p>Every adjunction gives rise to a monad. The round trip</p><pre>U<sup>T</sup> ∘ F<sup>T</sup></pre><p>is the endofunctor in C that gives rise to the corresponding monad. Let’s see what its action on an object <code>a</code> is. The free algebra created by <code>F<sup>T</sup></code> is <code>(T a, μ<sub>a</sub>)</code>. The forgetful functor <code>F<sup>T</sup></code> drops the evaluator. So, indeed, we have:</p><pre>U<sup>T</sup> ∘ F<sup>T</sup> = T</pre><p>As expected, the unit of the adjunction is the unit of the monad <code>T</code>.</p><p>You may remember that the counint of the adjunction produces monadic muliplication through the following formula:</p><pre>μ = R ∘ ε ∘ L</pre><p>This is a horizontal composition of three natural transformations, two of them being identity natural transformations mapping, respectively, <code>L</code> to <code>L</code> and <code>R</code> to <code>R</code>. The one in the middle, the counit, is a natural transformation whose component at an algebra <code>(a, f)</code> is <code>f</code>.</p><p>Let’s calculate the component <code>μ<sub>a</sub></code>. We first horizontally compose <code>ε</code> after <code>F<sup>T</sup></code>, which results in the component of <code>ε</code> at <code>F<sup>T</sup>a</code>. Since <code>F<sup>T</sup></code> takes <code>a</code> to the algebra <code>(T a, μ<sub>a</sub>)</code>, and <code>ε</code> picks the evaluator, we end up with <code>μ<sub>a</sub></code>. Horizontal composition on the left with <code>U<sup>T</sup></code> doesn’t change anything, since the action of <code>U<sup>T</sup></code> on morphisms is trivial. So, indeed, the <code>μ</code> obtained from the adjunction is the same as the <code>μ</code> of the original monad <code>T</code>.</p><h2>The Kleisli Category</h2><p>We’ve seen the Kleisli category before. It’s a category constructed from another category <i>C</i> and a monad <code>T</code>. We’ll call this category <i>C<sub>T</sub></i>. The objects in the Kleisli category <i>C<sub>T</sub></i> are the objects of <i>C</i>, but the morphisms are different. A morphism <code>f<sub>K</sub></code> from <code>a</code> to <code>b</code> in the Kleisli category corresponds to a morphism <code>f</code> from <code>a</code> to <code>T b</code> in the original category. We call this morphism a Kleisli arrow from <code>a</code> to <code>b</code>.</p><p>Composition of morphisms in the Kleisli category is defined in terms of monadic composition of Kleisli arrows. For instance, let’s compose <code>g<sub>K</sub></code> after <code>f<sub>K</sub></code>. In the Kleisli category we have:</p><pre>f<sub>K</sub> :: a -&gt; b
 g<sub>K</sub> :: b -&gt; c</pre><p>which, in the category <i>C</i>, corresponds to:</p><pre>f :: a -&gt; T b
 g :: b -&gt; T c</pre><p>We define the composition:</p><pre>h<sub>K</sub> = g<sub>K</sub> ∘ f<sub>K</sub></pre><p>as a Kleisli arrow in <i>C</i></p><pre>h :: a -&gt; T c
 h = μ ∘ (T g) ∘ f</pre><p>In Haskell we would write it as:</p><pre>h = join . fmap g . f</pre><p>There is a functor <code>F</code> from <i>C</i> to <i>C<sub>T</sub></i> which acts trivially on objects. On morphims, it maps <code>f</code> in <i>C</i> to a morphism in <i>C<sub>T</sub></i> by creating a Kleisli arrow that embellishes the return value of <code>f</code>. Given a morphism:</p><pre>f :: a -&gt; b</pre><p>it creates a morphism in <i>C<sub>T</sub></i> with the corresponding Kleisli arrow:</p><pre>η ∘ f</pre><p>In Haskell we’d write it as:</p><pre>return . f</pre><p>We can also define a functor <code>G</code> from <i>C<sub>T</sub></i> back to <i>C</i>. It takes an object <code>a</code> from the Kleisli category and maps it to an object <code>T a</code> in <i>C</i>. Its action on a morphism <code>f<sub>K</sub></code> corresponding to a Kleisli arrow:</p><pre>f :: a -&gt; T b</pre><p>is a morphism in <i>C</i>:</p><pre>T a -&gt; T b</pre><p>given by first lifting <code>f</code> and then applying <code>μ</code>:</p><pre>μ<sub>T b</sub> ∘ T f</pre><p>In Haskell notation this would read:</p><pre>G f<sub>T</sub> = join . fmap f</pre><p>You may recognize this as the definition of monadic bind in terms of <code>join</code>.</p><p>It’s easy to see that the two functors form an adjunction:</p><pre>F ⊣ G</pre><p>and their composition <code>G ∘ F</code> reproduces the original monad <code>T</code>.</p><p>So this is the second adjunction that produces the same monad. In fact there is a whole category of adjunctions <code>Adj(C, T)</code> that result in the same monad <code>T</code> on <i>C</i>. The Kleisli adjunction we’ve just seen is the initial object in this category, and the Eilenberg-Moore adjunction is the terminal object.</p><h2>Coalgebras for Comonads</h2><p>Analogous constructions can be done for any <a href="https://bartoszmilewski.com/2017/01/02/comonads/" target="_blank">comonad</a> <code>W</code>. We can define a category of coalgebras that are compatible with a comonad. They make the following diagrams commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png"><img data-attachment-id="8434" data-permalink="https://bartoszmilewski.com/2017/03/14/algebras-for-monads/talg5/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png" data-orig-size="1225,357" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;0&quot;}" data-image-title="Talg5" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=449&amp;h=130" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=510" class="alignnone wp-image-8434" src="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=449&amp;h=130" alt="" width="449" height="130" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=446&amp;h=130 446w, https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=892&amp;h=260 892w, https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=150&amp;h=44 150w, https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=300&amp;h=87 300w, https://bartoszmilewski.files.wordpress.com/2017/03/talg5.png?w=768&amp;h=224 768w" sizes="(max-width: 449px) 100vw, 449px"></a></p><p>where <code>coa</code> is the coevaluation morphism of the coalgebra whose carrier is <code>a</code>:</p><pre>coa :: a -&gt; W a</pre><p>and <code>ε</code> and <code>δ</code> are the two natural transformations defining the comonad (in Haskell, their components are called <code>extract</code> and <code>duplicate</code>).</p><p>There is an obvious forgetful functor <code>U<sup>W</sup></code> from the category of these coalgebras to <i>C</i>. It just forgets the coevaluation. We’ll consider its right adjoint <code>F<sup>W</sup></code>.</p><pre>U<sup>W</sup> ⊣ F<sup>W</sup></pre><p>The right adjoint to a forgetful functor is called a cofree functor. <code>F<sup>W</sup></code> generates cofree coalgebras. It assigns, to an object <code>a</code> in <i>C</i>, the coalgebra <code>(W a, δ<sub>a</sub>)</code>. The adjunction reproduces the original comonad as the composite <code>F<sup>W</sup> ∘ U<sup>W</sup></code>.</p><p>Similarly, we can construct a co-Kleisli category with co-Kleisli arrows and regenerate the comonad from the corresponding adjunction.</p><h2>Lenses</h2><p>Let’s go back to our discussion of lenses. A lens can be written as a coalgebra:</p><pre>coalg<sub>s</sub> :: a -&gt; Store s a</pre><p>for the functor <code>Store s</code>:</p><pre>data Store s a = Store (s -&gt; a) s</pre><p>This coalgebra can be also expressed as a pair of functions:</p><pre>set :: a -&gt; s -&gt; a
 get :: a -&gt; s</pre><p>(Think of <code>a</code> as standing for “all,” and <code>s</code> as a “small” part of it.) In terms of this pair, we have:</p><pre>coalg<sub>s</sub> a = Store (set a) (get a)</pre><p>Here, <code>a</code> is a value of type <code>a</code>. Notice that partially applied <code>set</code> is a function <code>s-&gt;a</code>.</p><p>We also know that <code>Store s</code> is a comonad:</p><pre>instance Comonad (Store s) where
  extract (Store f s) = f s
  duplicate (Store f s) = Store (Store f) s</pre><p>The question is: Under what conditions is a lens a coalgebra for this comonad? The first coherence condition:</p><pre>ε<sub>a</sub> ∘ coalg = id<sub>a</sub></pre><p>translates to:</p><pre>set a (get a) = a</pre><p>This is the lens law that expresses the fact that if you set a field of the structure <code>a</code> to its previous value, nothing changes.</p><p>The second condition:</p><pre>fmap coalg ∘ coalg = δ<sub>a</sub> ∘ coalg</pre><p>requires a little more work. First, recall the definition of <code>fmap</code> for the <code>Store</code> functor:</p><pre>fmap g (Store f s) = Store (g . f) s</pre><p>Applying <code>fmap coalg</code> to the result of <code>coalg</code> gives us:</p><pre>Store (coalg . set a) (get a)</pre><p>On the other hand, applying <code>duplicate</code> to the result of <code>coalg</code> produces:</p><pre>Store (Store (set a)) (get a)</pre><p>For these two expressions to be equal, the two functions under <code>Store</code> must be equal when acting on an arbitrary <code>s</code>:</p><pre>coalg (set a s) = Store (set a) s</pre><p>Expanding <code>coalg</code>, we get:</p><pre>Store (set (set a s)) (get (set a s)) = Store (set a) s</pre><p>This is equivalent to two remaining lens laws. The first one:</p><pre>set (set a s) = set a</pre><p>tells us that setting the value of a field twice is the same as setting it once. The second law:</p><pre>get (set a s) = s</pre><p>tells us that getting a value of a field that was set to <code>s</code> gives <code>s</code> back.</p><p>In other words, a well-behaved lens is indeed a comonad coalgebra for the <code>Store</code> functor.</p><h2>Challenges</h2><ol>
 <li>What is the action of the free functor <code>F :: C -&gt; C<sup>T</sup></code> on morphisms. Hint: use the naturality condition for monadic <code>μ</code>.</li>
 <li>Define the adjunction:
 <pre>U<sup>W</sup> ⊣ F<sup>W</sup></pre>
 </li>
 <li>Prove that the above adjunction reproduces the original comonad.</li>
 </ol><h2>Acknowledgment</h2><p>I’d like to thank Gershom Bazerman for helpful comments.</p><p>Next: <a href="https://bartoszmilewski.com/2017/03/29/ends-and-coends/">Ends and Coends</a>.</p>

 <h2 class="post-title">
 			Ends and Coends		</h2><p>There are many intuitions that we may attach to morphisms in a category, but we can all agree that if there is a morphism from the object <code>a</code> to the object <code>b</code> than the two objects are in some way “related.” A morphism is, in a sense, the proof of this relation. This is clearly visible in any poset category, where a morphism <em>is</em> a relation. In general, there may be many “proofs” of the same relation between two objects. These proofs form a set that we call the hom-set. When we vary the objects, we get a mapping from pairs of objects to sets of “proofs.” This mapping is functorial — contravariant in the first argument and covariant in the second. We can look at it as establishing a global relationship between objects in the category. This relationship is described by the hom-functor:</p><pre>C(-, =) :: C<sup>op</sup> × C -&gt; Set</pre><p>In general, any functor like this may be interpreted as establishing a relation between objects in a category. A relation may also involve two different categories <i>C</i> and <i>D</i>. A functor, which describes such a relation, has the following signature and is called a profunctor:</p><pre>p :: D<sup>op</sup> × C -&gt; Set</pre><p>Mathematicians say that it’s a profunctor from <code>C</code> to <code>D</code> (notice the inversion), and use a slashed arrow as a symbol for it:</p><pre>C ↛ D</pre><p>You may think of a profunctor as a <em>proof-relevant relation</em> between objects of <i>C</i> and objects of <i>D</i>, where the elements of the set symbolize proofs of the relation. Whenever <code>p a b</code> is empty, there is no relation between <code>a</code> and <code>b</code>. Keep in mind that relations don’t have to be symmetric.</p><p>Another useful intuition is the generalization of the idea that an endofunctor is a container. A profunctor value of the type <code>p a b</code> could then be considered a container of <code>b</code>s that are keyed by elements of type <code>a</code>. In particular, an element of the hom-profunctor is a function from <code>a</code> to <code>b</code>.</p><p>In Haskell, a profunctor is defined as a two-argument type constructor <code>p</code> equipped with the method called <code>dimap</code>, which lifts a pair of functions, the first going in the “wrong” direction:</p><pre>class Profunctor p where
    dimap :: (c -&gt; a) -&gt; (b -&gt; d) -&gt; p a b -&gt; p c d</pre><p>The functoriality of the profunctor tells us that if we have a proof that <code>a</code> is related to <code>b</code>, then we get the proof that <code>c</code> is related to <code>d</code>, as long as there is a morphism from <code>c</code> to <code>a</code> and another from <code>b</code> to <code>d</code>. Or, we can think of the first function as translating new keys to the old keys, and the second function as modifying the contents of the container.</p><p>For profunctors acting within one category, we can extract quite a lot of information from diagonal elements of the type <code>p a a</code>. We can prove that <code>b</code> is related to <code>c</code> as long as we have a pair of morphisms <code>b-&gt;a</code> and <code>a-&gt;c</code>. Even better, we can use a single morphism to reach off-diagonal values. For instance, if we have a morphism <code>f::a-&gt;b</code>, we can lift the pair <code>&lt;f, id<sub>b</sub>&gt;</code> to go from <code>p b b</code> to <code>p a b</code>:</p><pre>dimap f id pbb :: p a b</pre><p>Or we can lift the pair <code>&lt;id<sub>a</sub>, f&gt;</code> to go from <code>p a a</code> to <code>p a b</code>:</p><pre>dimap id f paa :: p a b</pre><h2>Dinatural Transformations</h2><p>Since profunctors are functors, we can define natural transformations between them in the standard way. In many cases, though, it’s enough to define the mapping between diagonal elements of two profunctors. Such a transformation is called a dinatural transformation, provided it satisfies the commuting conditions that reflect the two ways we can connect diagonal elements to non-diagonal ones. A dinatural transformation between two profunctors <code>p</code> and <code>q</code>, which are members of the functor category <code>[C<sup>op</sup> × C, Set]</code>, is a family of morphisms:</p><pre>α<sub>a</sub> :: p a a -&gt; q a a</pre><p>for which the following diagram commutes, for any <code>f::a-&gt;b</code>:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg"><img data-attachment-id="8521" data-permalink="https://bartoszmilewski.com/2017/03/29/ends-and-coends/end-4/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg" data-orig-size="634,715" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="End" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=266&amp;h=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=510" class="alignnone size-medium wp-image-8521" src="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=266&amp;h=300" alt="" width="266" height="300" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=266&amp;h=300 266w, https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=532&amp;h=600 532w, https://bartoszmilewski.files.wordpress.com/2017/03/end.jpg?w=133&amp;h=150 133w" sizes="(max-width: 266px) 100vw, 266px"></a></p><p>Notice that this is strictly weaker than the naturality condition. If <code>α</code> were a natural transformation in <code>[C<sup>op</sup> × C, Set]</code>, the above diagram could be constructed from two naturality squares and one functoriality condition (profunctor <code>q</code> preserving composition):</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg"><img data-attachment-id="8518" data-permalink="https://bartoszmilewski.com/2017/03/29/ends-and-coends/end-1/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg" data-orig-size="758,814" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="End 1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=323&amp;h=347" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=510" class="alignnone wp-image-8518" src="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=323&amp;h=347" alt="" width="323" height="347" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=323&amp;h=347 323w, https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=646&amp;h=694 646w, https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=140&amp;h=150 140w, https://bartoszmilewski.files.wordpress.com/2017/03/end-1.jpg?w=279&amp;h=300 279w" sizes="(max-width: 323px) 100vw, 323px"></a></p><p>Notice that a component of a natural transformation <code>α</code> in <code>[C<sup>op</sup> × C, Set]</code> is indexed by a pair of objects <code>α<sub> a b</sub></code>. A dinatural transformation, on the other hand, is indexed by one object, since it only maps diagonal elements of the respective profunctors.</p><h2>Ends</h2><p>We are now ready to advance from “algebra” to what could be considered the “calculus” of category theory. The calculus of ends (and coends) borrows ideas and even some notation from traditional calculus. In particular, the coend may be understood as an infinite sum or an integral, whereas the end is similar to an infinite product. There is even something that resembles the Dirac delta function.</p><p>An end is a genaralization of a limit, with the functor replaced by a profunctor. Instead of a cone, we have a wedge. The base of a wedge is formed by diagonal elements of a profunctor <code>p</code>. The apex of the wedge is an object (here, a set, since we are considering <b>Set</b>-valued profunctors), and the sides are a family of functions mapping the apex to the sets in the base. You may think of this family as one polymorphic function — a function that’s polymorphic in its return type:</p><pre>α :: forall a . apex -&gt; p a a</pre><p>Unlike in cones, within a wedge we don’t have any functions that would connect vertices of the base. However, as we’ve seen earlier, given any morphism <code>f::a-&gt;b</code> in <i>C</i>, we can connect both <code>p a a</code> and <code>p b b</code> to the common set <code>p a b</code>. We therefore insist that the following diagram commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg"><img data-attachment-id="8519" data-permalink="https://bartoszmilewski.com/2017/03/29/ends-and-coends/end-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg" data-orig-size="507,412" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="End 2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=259&amp;h=211" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=507" class="alignnone wp-image-8519" src="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=259&amp;h=211" alt="" width="259" height="211" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=259&amp;h=211 259w, https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=150&amp;h=122 150w, https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg?w=300&amp;h=244 300w, https://bartoszmilewski.files.wordpress.com/2017/03/end-2.jpg 507w" sizes="(max-width: 259px) 100vw, 259px"></a></p><p>This is called the wedge condition. It can be written as:</p><pre>p id<sub>a</sub> f ∘ α<sub>a</sub> = p f id<sub>b</sub> ∘ α<sub>b</sub></pre><p>Or, using Haskell notation:</p><pre>dimap id f . alpha = dimap f id . alpha</pre><p>We can now proceed with the universal construction and define the end of <code>p</code> as the uinversal wedge — a set <code>e</code> together with a family of functions <code>π</code> such that for any other wedge with the apex <code>a</code> and a family <code>α</code> there is a unique function <code>h::a-&gt;e</code> that makes all triangles commute:</p><pre>π<sub>a</sub> ∘ h = α<sub>a</sub></pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg"><img data-attachment-id="8532" data-permalink="https://bartoszmilewski.com/2017/03/29/ends-and-coends/end-2-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg" data-orig-size="579,507" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="End 2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=263&amp;h=231" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=510" class="alignnone wp-image-8532" src="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=263&amp;h=231" alt="" width="263" height="231" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=263&amp;h=231 263w, https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=526&amp;h=462 526w, https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=150&amp;h=131 150w, https://bartoszmilewski.files.wordpress.com/2017/03/end-21.jpg?w=300&amp;h=263 300w" sizes="(max-width: 263px) 100vw, 263px"></a></p><p>The symbol for the end is the integral sign, with the “integration variable” in the subscript position:</p><pre>∫<sub>c</sub> p c c</pre><p>Components of <code>π</code> are called projection maps for the end:</p><pre>π<sub>a</sub> :: ∫<sub>c</sub> p c c -&gt; p a a</pre><p>Note that if <i>C</i> is a discrete category (no morphisms other than the identities) the end is just a global product of all diagonal entries of <code>p</code> across the whole category <i>C</i>. Later I’ll show you that, in the more general case, there is a relationship between the end and this product through an equalizer.</p><p>In Haskell, the end formula translates directly to the universal quantifier:</p><pre>forall a. p a a</pre><p>Strictly speaking, this is just a product of all diagonal elements of <code>p</code>, but the wedge condition is satisfied automatically due to parametricity (I’ll explain it in a <a href="https://bartoszmilewski.com/2017/04/11/profunctor-parametricity/" target="_blank">separate blog post</a>). For any function <code>f :: a -&gt; b</code>, the wedge condition reads:</p><pre>dimap f id . pi = dimap id f . pi</pre><p>or, with type annotations:</p><pre>dimap f id<sub>b</sub> . pi<sub>b</sub> = dimap id<sub>a</sub> f . pi<sub>a</sub></pre><p>where both sides of the equation have the type:</p><pre>Profunctor p =&gt; (forall c. p c c) -&gt; p a b</pre><p>and <code>pi</code> is the polymorphic projection:</p><pre>pi :: Profunctor p =&gt; forall c. (forall a. p a a) -&gt; p c c
 pi e = e</pre><p>Here, type inference automatically picks the right component of <code>e</code>.</p><p>Just as we were able to express the whole set of commutation conditions for a cone as one natural transformation, likewise we can group all the wedge conditions into one dinatural transformation. For that we need the generalization of the constant functor <code>Δ<sub>c</sub></code> to a constant profunctor that maps all pairs of objects to a single object <code>c</code>, and all pairs of morphisms to the identity morphism for this object. A wedge is a dinatural transformation from that functor to the profunctor <code>p</code>. Indeed, the dinaturality hexagon shrinks down to the wedge diamond when we realize that <code>Δ<sub>c</sub></code> lifts all morphisms to one identity function.</p><p>Ends can also be defined for target categories other than <b>Set</b>, but here we’ll only consider <b>Set</b>-valued profunctors and their ends.</p><h2>Ends as Equalizers</h2><p>The commutation condition in the definition of the end can be written using an equalizer. First, let’s define two functions (I’m using Haskell notation, because mathematical notation seems to be less user-friendly in this case). These functions correspond to the two converging branches of the wedge condition:</p><pre>lambda :: Profunctor p =&gt; p a a -&gt; (a -&gt; b) -&gt; p a b
 lambda paa f = dimap id f paa

 rho :: Profunctor p =&gt; p b b -&gt; (a -&gt; b) -&gt; p a b
 rho pbb f = dimap f id pbb</pre><p>Both functions map diagonal elements of the profunctor <code>p</code> to polymorphic functions of the type:</p><pre>type ProdP p = forall a b. (a -&gt; b) -&gt; p a b</pre><p>These functions have different types. However, we can unify their types, if we form one big product type, gathering together all diagonal elements of <code>p</code>:</p><pre>newtype DiaProd p = DiaProd (forall a. p a a)</pre><p>The functions <code>lambda</code> and <code>rho</code> induce two mappings from this product type:</p><pre>lambdaP :: Profunctor p =&gt; DiaProd p -&gt; ProdP p
 lambdaP (DiaProd paa) = lambda paa

 rhoP :: Profunctor p =&gt; DiaProd p -&gt; ProdP p
 rhoP (DiaProd paa) = rho paa</pre><p>The end of <code>p</code> is the equalizer of these two functions. Remember that the equalizer picks the largest subset on which two functions are equal. In this case it picks the subset of the product of all diagonal elements for which the wedge diagrams commute.</p><h2>Natural Transformations as Ends</h2><p>The most important example of an end is the set of natural transformations. A natural transformation between two functors <code>F</code> and <code>G</code> is a family of morphisms picked from hom-sets of the form <code>C(F a, G a)</code>. If it weren’t for the naturality condition, the set of natural transformations would be just the product of all these hom-sets. In fact, in Haskell, it is:</p><pre>forall a. f a -&gt; g a</pre><p>The reason it works in Haskell is because naturality follows from parametricity. Outside of Haskell, though, not all diagonal sections across such hom-sets will yield natural transformations. But notice that the mapping:</p><pre>&lt;a, b&gt; -&gt; C(F a, G b)</pre><p>is a profunctor, so it makes sense to study its end. This is the wedge condition:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg"><img data-attachment-id="8534" data-permalink="https://bartoszmilewski.com/2017/03/29/ends-and-coends/end-5/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg" data-orig-size="707,623" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;0&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="End" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=300&amp;h=264" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=510" class="alignnone size-medium wp-image-8534" src="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=300&amp;h=264" alt="" width="300" height="264" srcset="https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=300&amp;h=264 300w, https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=600&amp;h=528 600w, https://bartoszmilewski.files.wordpress.com/2017/03/end1.jpg?w=150&amp;h=132 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Let’s just pick one element from the set <code>∫<sub>c </sub>C(F c, G c)</code>. The two projections will map this element to two components of a particular transformation, let’s call them:</p><pre>τ<sub>a</sub> :: F a -&gt; G a
 τ<sub>b</sub> :: F b -&gt; G b</pre><p>In the left branch, we lift a pair of morphisms <code>&lt;id<sub>a</sub>, G f&gt;</code> using the hom-functor. You may recall that such lifting is implemented as simultaneous pre- and post-composition. When acting on <code>τ<sub>a</sub></code> the lifted pair gives us:</p><pre>G f ∘ τ<sub>a</sub> ∘ id<sub>a</sub></pre><p>The other branch of the diagram gives us:</p><pre>id<sub>b</sub> ∘ τ<sub>b</sub> ∘ F f</pre><p>Their equality, demanded by the wedge condition, is nothing but the naturality condition for <code>τ</code>.</p><h2>Coends</h2><p>As expected, the dual to an end is called a coend. It is constructed from a dual to a wedge called a cowedge (pronounced co-wedge, not cow-edge).</p><p>The symbol for a coend is the integral sign with the “integration variable” in the superscript position:</p><pre>∫<sup> c </sup>p c c</pre><p>Just like the end is related to a product, the coend is related to a coproduct, or a sum (in this respect, it resembles an integral, which is a limit of a sum). Rather than having projections, we have injections going from the diagonal elements of the profunctor down to the coend. If it weren’t for the cowedge conditions, we could say that the coend of the profunctor <code>p</code> is either <code>p a a</code>, or <code>p b b</code>, or <code>p c c</code>, and so on. Or we could say that there exists such an <code>a</code> for which the coend is just the set <code>p a a</code>. The universal quantifier that we used in the definition of the end turns into an existential quantifier for the coend.</p><p>This is why, in pseudo-Haskell, we would define the coend as:</p><pre>exists a. p a a</pre><p>The standard way of encoding existential quantifiers in Haskell is to use universally quantified data constructors. We can thus define:</p><pre>data Coend p = forall a. Coend (p a a)</pre><p>The logic behind this is that it should be possible to construct a coend using a value of any of the family of types <code>p a a</code>, no matter what <code>a</code> we chose.</p><p>Just like an end can be defined using an equalizer, a coend can be described using a <em>coequalizer</em>. All the cowedge conditions can be summarized by taking one gigantic coproduct of <code>p a b</code> for all possible functions <code>b-&gt;a</code>. In Haskell, that would be expressed as an existential type:</p><pre>data SumP p = forall a b. SumP (b -&gt; a) (p a b)</pre><p>There are two ways of evaluating this sum type, by lifting the function using <code>dimap</code> and applying it to the profunctor <code>p</code>:</p><pre>lambda, rho :: Profunctor p =&gt; SumP p -&gt; DiagSum p
 lambda (SumP f pab) = DiagSum (dimap f id pab)
 rho    (SumP f pab) = DiagSum (dimap id f pab)</pre><p>where <code>DiagSum</code> is the sum of diagonal elements of <code>p</code>:</p><pre>data DiagSum p = forall a. DiagSum (p a a)</pre><p>The coequalizer of these two functions is the coend. A coequilizer is obtained from <code>DiagSum p</code> by identifying values that are obtained by applying <code>lambda</code> or <code>rho</code> to the same argument. Here, the argument is a pair consisting of a function <code>b-&gt;a</code> and an element of <code>p a b</code>. The application of <code>lambda</code> and <code>rho</code> produces two potentially different values of the type <code>DiagSum p</code>. In the coend, these two values are identified, making the cowedge condition automatically satisfied. </p><p>The process of identification of related elements in a set is formally known as taking a quotient. To define a quotient we need an <em>equivalence relation</em> <code>~</code>, a relation that is reflexive, symmetric, and transitive:</p><pre>a ~ a
 if a ~ b then b ~ a
 if a ~ b and b ~ c then a ~ c</pre><p>Such a relation splits the set into equivalence classes. Each class consists of elements that are related to each other. We form a quotient set by picking one representative from each class. A classic example is the definition of rational numbers as pairs of whole numbers with the following equivalence relation:</p><pre>(a, b) ~ (c, d) iff a * d = b * c</pre><p>It’s easy to check that this is an equivalence relation. A pair <code>(a, b)</code> is interpreted as a fraction <code>a/b</code>, and fractions that have a common divisor are identified. A rational number is an equivalence class of such fractions.</p><p>You might recall from our earlier discussion of limits and colimits that the hom-functor is continuous, that is, it preserves limits. Dually, the contravariant hom-functor turns colimits into limits. These properties can be generalized to ends and coends, which are a generalization of limits and colimits, respectively. In particular, we get a very useful identity for converting coends to ends:</p><pre>Set(∫<sup> x </sup>p x x, c) ≅ ∫<sub>x </sub>Set(p x x, c)</pre><p>Let’s have a look at it in pseudo-Haskell:</p><pre>(exists x. p x x) -&gt; c ≅ forall x. p x x -&gt; c</pre><p>It tells us that a function that takes an existential type is equivalent to a polymorphic function. This makes perfect sense, because such a function must be prepared to handle any one of the types that may be encoded in the existential type. It’s the same principle that tells us that a function that accepts a sum type must be implemented as a case statement, with a tuple of handlers, one for every type present in the sum. Here, the sum type is replaced by a coend, and a family of handlers becomes an end, or a polymorphic function.</p><h2>Ninja Yoneda Lemma</h2><p>The set of natural transformations that appears in the Yoneda lemma may be encoded using an end, resulting in the following formulation:</p><pre>∫<sub>z </sub>Set(C(a, z), F z) ≅ F a</pre><p>There is also a dual formula:</p><pre>∫<sup> z </sup>C(a, z) × F z ≅ F a</pre><p>This identity is strongly reminiscent of the formula for the Dirac delta function (a function <code>δ(a - z)</code>, or rather a distribution, that has an infinite peak at <code>a = z</code>). Here, the hom-functor plays the role of the delta function.</p><p>Together these two identities are sometimes called the Ninja Yoneda lemma.</p><p>To prove the second formula, we will use the consequence of the Yoneda embedding, which states that two objects are isomorphic if and only if their hom-functors are isomorphic. In other words <code>a ≅ b</code> if and only if there is a natural transformation of the type:</p><pre>[C, Set](C(a, -), C(b, =))</pre><p>that is an isomorphism.</p><p>We start by inserting the left-hand side of the identity we want to prove inside a hom-functor that’s going to some arbitrary object <code>c</code>:</p><pre>Set(∫<sup> z </sup>C(a, z) × F z, c)</pre><p>Using the continuity argument, we can replace the coend with the end:</p><pre>∫<sub>z </sub>Set(C(a, z) × F z, c)</pre><p>We can now take advantage of the adjunction between the product and the exponential:</p><pre>∫<sub>z </sub>Set(C(a, z), c<sup>(F z)</sup>)</pre><p>We can “perform the integration” by using the Yoneda lemma to get:</p><pre>c<sup>(F a)</sup></pre><p>This exponential object is isomorphic to the hom-set:</p><pre>Set(F a, c)</pre><p>Finally, we take advantage of the Yoneda embedding to arrive at the isomorphism:</p><pre>∫<sup> z </sup>C(a, z) × F z ≅ F a</pre><h2>Profunctor Composition</h2><p>Let’s explore further the idea that a profunctor describes a relation — more precisely, a proof-relevant relation, meaning that the set <code>p a b</code> represents the set of proofs that <code>a</code> is related to <code>b</code>. If we have two relations <code>p</code> and <code>q</code> we can try to compose them. We’ll say that <code>a</code> is related to <code>b</code> through the composition of <code>q</code> after <code>p</code> if there exist an intermediary object <code>c</code> such that both <code>q b c</code> and <code>p c a</code> are non-empty. The proofs of this new relation are all pairs of proofs of individual relations. Therefore, with the understanding that the existential quantifier corresponds to a coend, and the cartesian product of two sets corresponds to “pairs of proofs,” we can define composition of profunctors using the following formula:</p><pre>(q ∘ p) a b = ∫<sup> c </sup>p c a × q b c</pre><p>Here’s the equivalent Haskell definition from <code>Data.Profunctor.Composition</code>, after some renaming:</p><pre>data Procompose q p a b where
  Procompose :: q a c -&gt; p c b -&gt; Procompose q p a b
 </pre><p>This is using generalized algebraic data type, or GADT syntax, in which a free type variable (here <code>c</code>) is automatically existentially quanitified. The (uncurried) data constructor <code>Procompose</code> is thus equivalent to:</p><pre>exists c. (q a c, p c b)</pre><p>The unit of so defined composition is the hom-functor — this immediately follows from the Ninja Yoneda lemma. It makes sense, therefore, to ask the question if there is a category in which profunctors serve as morphisms. The answer is positive, with the caveat that both associativity and identity laws for profunctor composition hold only up to natural isomorphism. Such a category, where laws are valid up to isomorphism, is called a bicategory (which is more general than a 2-category). So we have a bicategory <b>Prof</b>, in which objects are categories, morphisms are profunctors, and morphisms between morphisms (a.k.a., two-cells) are natural transformations. In fact, one can go even further, because beside profunctors, we also have regular functors as morphisms between categories. A category which has two types of morphisms is called a double category.</p><p>Profunctors play an important role in the Haskell lens library and in the arrow library.</p><p>Next: <a href="https://bartoszmilewski.com/2017/04/17/kan-extensions/">Kan extensions</a>.</p>

 <h2 class="post-title">
 			Kan Extensions		</h2><p>So far we’ve been mostly working with a single category or a pair of categories. In some cases that was a little too constraining. For instance, when defining a limit in a category <i>C</i>, we introduced an index category <code>I</code> as the template for the pattern that would form the basis for our cones. It would have made sense to introduce another category, a trivial one, to serve as a template for the apex of the cone. Instead we used the constant functor <code>Δ<sub>c</sub></code> from <code>I</code> to <code>C</code>.</p><p>It’s time to fix this awkwardness. Let’s define a limit using three categories. Let’s start with the functor <code>D</code> from the index category <i>I</i> to <i>C</i>. This is the functor that selects the base of the cone — the diagram functor.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg"><img data-attachment-id="8641" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg" data-orig-size="390,336" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan2" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=164&amp;h=141" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=390" class="alignnone wp-image-8641" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=164&amp;h=141" alt="" width="164" height="141" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=164&amp;h=141 164w, https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=328&amp;h=282 328w, https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=150&amp;h=129 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan2.jpg?w=300&amp;h=258 300w" sizes="(max-width: 164px) 100vw, 164px"></a></p><p>The new addition is the category <b>1</b> that contains a single object (and a single identity morphism). There is only one possible functor <code>K</code> from <i>I</i> to this category. It maps all objects to the only object in <b>1</b>, and all morphisms to the identity morphism. Any functor <code>F</code> from <b>1</b> to <i>C</i> picks a potential apex for our cone.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg"><img data-attachment-id="8689" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan1-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg" data-orig-size="537,379" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan1" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg?w=300&amp;h=212" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg?w=510" class="alignnone size-medium wp-image-8689" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg?w=300&amp;h=212" alt="" width="300" height="212" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg?w=300&amp;h=212 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg?w=150&amp;h=106 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan15.jpg 537w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>A cone is a natural transformation <code>ε</code> from <code>F ∘ K</code> to <code>D</code>. Notice that <code>F ∘ K</code> does exactly the same thing as our original <code>Δ<sub>c</sub></code>. The following diagram shows this transformation.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg"><img data-attachment-id="8642" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan3/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg" data-orig-size="441,297" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan3" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=222&amp;h=150" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=441" class="alignnone wp-image-8642" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=222&amp;h=150" alt="" width="222" height="150" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=222&amp;h=150 222w, https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=150&amp;h=101 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg?w=300&amp;h=202 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan3-e1492120491591.jpg 441w" sizes="(max-width: 222px) 100vw, 222px"></a></p><p>We can now define a universal property that picks the “best” such functor <code>F</code>. This <code>F</code> will map <b>1</b> to the object that is the limit of <code>D</code> in <i>C</i>, and the natural transformation <code>ε</code> from <code>F ∘ K</code> to <code>D</code> will provide the corresponding projections. This universal functor is called the right Kan extension of <code>D</code> along <code>K</code> and is denoted by <code>Ran<sub>K</sub>D</code>.</p><p>Let’s formulate the universal property. Suppose we have another cone — that is another functor <code>F'</code> together with a natural transformation <code>ε'</code> from <code>F' ∘ K</code> to <code>D</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg"><img data-attachment-id="8663" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan3-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg" data-orig-size="420,305" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan3" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=227&amp;h=165" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=420" class="alignnone wp-image-8663" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=227&amp;h=165" alt="" width="227" height="165" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=227&amp;h=165 227w, https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=150&amp;h=109 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg?w=300&amp;h=218 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan31-e1492120512209.jpg 420w" sizes="(max-width: 227px) 100vw, 227px"></a></p><p>If the Kan extension <code>F = Ran<sub>K</sub>D</code> exists, there must be a unique natural transformation <code>σ</code> from <code>F'</code> to it, such that <code>ε'</code> factorizes through <code>ε</code>, that is:</p><pre>ε' = ε . (σ ∘ K)</pre><p>Here, <code>σ ∘ K</code> is the horizontal composition of two natural transformations (one of them being the identity natural transformation on <code>K</code>). This transformation is then vertically composed with <code>ε</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg"><img data-attachment-id="8644" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan5/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg" data-orig-size="523,392" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan5" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=237&amp;h=178" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=510" class="alignnone wp-image-8644" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=237&amp;h=178" alt="" width="237" height="178" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=237&amp;h=178 237w, https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=474&amp;h=356 474w, https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=150&amp;h=112 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan5.jpg?w=300&amp;h=225 300w" sizes="(max-width: 237px) 100vw, 237px"></a></p><p>In components, when acting on an object <code>i</code> in <i>I</i>, we get:</p><pre>ε'<sub>i</sub> = ε<sub>i</sub> ∘ σ<sub> K i</sub></pre><p>In our case, <code>σ</code> has only one component corresponding to the single object of <b>1</b>. So, indeed, this is the unique morphism from the apex of the cone defined by <code>F'</code> to the apex of the universal cone defined by <code>Ran<sub>K</sub>D</code>. The commuting conditions are exactly the ones required by the definition of a limit.</p><p>But, importantly, we are free to replace the trivial category <b>1</b> with an arbitrary category <i>A</i>, and the definition of the right Kan extension remains valid.</p><h2>Right Kan Extension</h2><p>The right Kan extension of the functor <code>D::I-&gt;C</code> along the functor <code>K::I-&gt;A</code> is a functor <code>F::A-&gt;C</code> (denoted <code>Ran<sub>K</sub>D</code>) together with a natural transformation</p><pre>ε :: F ∘ K -&gt; D</pre><p>such that for any other functor <code>F'::A-&gt;C</code> and a natural transformation</p><pre>ε' :: F' ∘ K -&gt; D</pre><p>there is a unique natural transformation</p><pre>σ :: F' -&gt; F</pre><p>that factorizes <code>ε'</code>:</p><pre>ε' = ε . (σ ∘ K)</pre><p>This is quite a mouthful, but it can be visualized in this nice diagram:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg"><img data-attachment-id="8646" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan7/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg" data-orig-size="407,389" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan7" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=188&amp;h=180" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=407" class="alignnone wp-image-8646" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=188&amp;h=180" alt="" width="188" height="180" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=188&amp;h=180 188w, https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=376&amp;h=360 376w, https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=150&amp;h=143 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan7.jpg?w=300&amp;h=287 300w" sizes="(max-width: 188px) 100vw, 188px"></a></p><p>An interesting way of looking at this is to notice that, in a sense, the Kan extension acts like the inverse of “functor multiplication.” Some authors go as far as use the notation <code>D/K</code> for <code>Ran<sub>K</sub>D</code>. Indeed, in this notation, the definition of <code>ε</code>, which is also called the counit of the right Kan extension, looks like simple cancellation:</p><pre>ε :: D/K ∘ K -&gt; D</pre><p>There is another interpretation of Kan extensions. Consider that the functor <code>K</code> embeds the category <i>I</i> inside <i>A</i>. In the simplest case <i>I</i> could just be a subcategory of <i>A</i>. We have a functor <code>D</code> that maps <i>I</i> to <i>C</i>. Can we extend <code>D</code> to a functor <code>F</code> that is defined on the whole of <i>A</i>? Ideally, such an extension would make the composition <code>F ∘ K</code> be isomorphic to <code>D</code>. In other words, <code>F</code> would be extending the domain of <code>D</code> to <code>A</code>. But a full-blown isomorphism is usually too much to ask, and we can do with just half of it, namely a one-way natural transformation <code>ε</code> from <code>F ∘ K</code> to <code>D</code>. (The left Kan extension picks the other direction.)</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg"><img data-attachment-id="8645" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan6/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg" data-orig-size="530,296" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan6" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg?w=300&amp;h=168" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg?w=510" class="alignnone size-medium wp-image-8645" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg?w=300&amp;h=168" alt="" width="300" height="168" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg?w=300&amp;h=168 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg?w=150&amp;h=84 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan6.jpg 530w" sizes="(max-width: 300px) 100vw, 300px"></a><br>
 Of course, the embedding picture breaks down when the functor <code>K</code> is not injective on objects or not faithful on hom-sets, as in the example of the limit. In that case, the Kan extension tries its best to extrapolate the lost information.</p><h2>Kan Extension as Adjunction</h2><p>Now suppose that the right Kan extension exists for any <code>D</code> (and a fixed <code>K</code>). In that case <code>Ran<sub>K </sub>-</code> (with the dash replacing <code>D</code>) is a functor from the functor category <code>[I, C]</code> to the functor category <code>[A, C]</code>. It turns out that this functor is the right adjoint to the precomposition functor <code>-∘K</code>. The latter maps functors in <code>[A, C]</code> to functors in <code>[I, C]</code>. The adjunction is:</p><pre>[I, C](F' ∘ K, D) ≅ [A, C](F', Ran<sub>K</sub>D)</pre><p>It is just a restatement of the fact that to every natural transformation we called <code>ε'</code> corresponds a unique natural transformation we called <code>σ</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg"><img data-attachment-id="8700" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan9-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg" data-orig-size="610,484" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan9" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=300&amp;h=238" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=510" class="alignnone size-medium wp-image-8700" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=300&amp;h=238" alt="" width="300" height="238" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=300&amp;h=238 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=600&amp;h=476 600w, https://bartoszmilewski.files.wordpress.com/2017/04/kan92.jpg?w=150&amp;h=119 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>Furthermore, if we chose the category <i>I</i> to be the same as <i>C</i>, we can substitute the identity functor <code>I<sub>C</sub></code> for <code>D</code>. We get the following identity:</p><pre>[C, C](F' ∘ K, I<sub>C</sub>) ≅ [A, C](F', Ran<sub>K</sub>I<sub>C</sub>)</pre><p>We can now chose <code>F'</code> to be the same as <code>Ran<sub>K</sub>I<sub>C</sub></code>. In that case the right hand side contains the identity natural transformation and, corresponding to it, the left hand side gives us the following natural transformation:</p><pre>ε :: Ran<sub>K</sub>I<sub>C</sub> ∘ K -&gt; I<sub>C</sub></pre><p>This looks very much like the counit of an adjunction:</p><pre>Ran<sub>K</sub>I<sub>C</sub> ⊣ K</pre><p>Indeed, the right Kan extension of the identity functor along a functor <code>K</code> can be used to calculate the left adjoint of <code>K</code>. For that, one more condition is necessary: the right Kan extension must be preserved by the functor <code>K</code>. The preservation of the extension means that, if we calculate the Kan extension of the functor precomposed with <code>K</code>, we should get the same result as precomposing the original Kan extesion with <code>K</code>. In our case, this condition simplifies to:</p><pre>K ∘ Ran<sub>K</sub>I<sub>C</sub> ≅ Ran<sub>K</sub>K</pre><p>Notice that, using the division-by-K notation, the adjunction can be written as:</p><pre>I/K ⊣ K</pre><p>which confirms our intuition that an adjunction describes some kind of an inverse. The preservation condition becomes:</p><pre>K ∘ I/K ≅ K/K</pre><p>The right Kan extension of a functor along itself, <code>K/K</code>, is called a codensity monad.</p><p>The adjunction formula is an important result because, as we’ll see soon, we can calculate Kan extensions using ends (coends), thus giving us practical means of finding right (and left) adjoints.</p><h2>Left Kan Extension</h2><p>There is a dual construction that gives us the left Kan extension. To build some intuition, we’ll can start with the definition of a colimit and restructure it to use the singleton category <b>1</b>. We build a cocone by using the functor <code>D::I-&gt;C</code> to form its base, and the functor <code>F::1-&gt;C</code> to select its apex.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg"><img data-attachment-id="8654" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan8-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg" data-orig-size="368,279" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan8" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=183&amp;h=138" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=368" class="alignnone wp-image-8654" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=183&amp;h=138" alt="" width="183" height="138" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=183&amp;h=138 183w, https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=364&amp;h=276 364w, https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=150&amp;h=114 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan81.jpg?w=300&amp;h=227 300w" sizes="(max-width: 183px) 100vw, 183px"></a></p><p>The sides of the cocone, the injections, are components of a natural transformation <code>η</code> from <code>D</code> to <code>F ∘ K</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg"><img data-attachment-id="8679" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan10a/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg" data-orig-size="411,215" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan10a" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=224&amp;h=117" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=411" class="alignnone wp-image-8679" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=224&amp;h=117" alt="" width="224" height="117" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=224&amp;h=117 224w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=150&amp;h=78 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg?w=300&amp;h=157 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10a.jpg 411w" sizes="(max-width: 224px) 100vw, 224px"></a></p><p>The colimit is the universal cocone. So for any other functor <code>F'</code> and a natural transformation</p><pre>η' :: D -&gt; F'∘ K</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg"><img data-attachment-id="8680" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan10b/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg" data-orig-size="418,217" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan10b" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=231&amp;h=120" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=418" class="alignnone wp-image-8680" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=231&amp;h=120" alt="" width="231" height="120" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=231&amp;h=120 231w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=150&amp;h=78 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg?w=300&amp;h=156 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan10b.jpg 418w" sizes="(max-width: 231px) 100vw, 231px"></a></p><p>there is a unique natural transformation <code>σ</code> from <code>F</code> to <code>F'</code></p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg"><img data-attachment-id="8656" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan14/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg" data-orig-size="436,350" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan14" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=200&amp;h=161" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=436" class="alignnone wp-image-8656" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=200&amp;h=161" alt="" width="200" height="161" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=200&amp;h=161 200w, https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=400&amp;h=322 400w, https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=150&amp;h=120 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan14.jpg?w=300&amp;h=241 300w" sizes="(max-width: 200px) 100vw, 200px"></a></p><p>such that:</p><pre>η' = (σ ∘ K) . η</pre><p>This is illustrated in the following diagram:<br>
 <a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg"><img data-attachment-id="8681" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan11-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg" data-orig-size="448,348" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan11" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=211&amp;h=164" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=448" class="alignnone wp-image-8681" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=211&amp;h=164" alt="" width="211" height="164" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=211&amp;h=164 211w, https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=422&amp;h=328 422w, https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=150&amp;h=117 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan112.jpg?w=300&amp;h=233 300w" sizes="(max-width: 211px) 100vw, 211px"></a></p><p>Replacing the singleton category <b>1</b> with <i>A</i>, this definition naturally generalized to the definition of the left Kan extension, denoted by <code>Lan<sub>K</sub>D</code>.<br>
 <a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg"><img data-attachment-id="8651" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan12/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg" data-orig-size="436,350" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan12" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=198&amp;h=159" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=436" class="alignnone wp-image-8651" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=198&amp;h=159" alt="" width="198" height="159" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=198&amp;h=159 198w, https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=396&amp;h=318 396w, https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=150&amp;h=120 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan12.jpg?w=300&amp;h=241 300w" sizes="(max-width: 198px) 100vw, 198px"></a><br>
 The natural transformation:</p><pre>η :: D -&gt; Lan<sub>K</sub>D ∘ K</pre><p>is called the unit of the left Kan extension.</p><p>As before, we can recast the one-to-one correspondence between natural transformations:</p><pre>η' = (σ ∘ K) . η</pre><p>in terms of the adjunction:</p><pre>[A, C](Lan<sub>K</sub>D, F') ≅ [I, C](D, F' ∘ K)</pre><p>In other words, the left Kan extension is the left adjoint, and the right Kan extension is the right adjoint of the postcomposition with <code>K</code>.</p><p>Just like the right Kan extension of the identity functor could be used to calculate the left adjoint of <code>K</code>, the left Kan extension of the identity functor turns out to be the right adjoint of <code>K</code> (with <code>η</code> being the unit of&nbsp; the adjunction):</p><pre>K ⊣ Lan<sub>K</sub>I<sub>C</sub></pre><p>Combining the two results, we get:</p><pre>Ran<sub>K</sub>I<sub>C</sub> ⊣ K ⊣ Lan<sub>K</sub>I<sub>C</sub></pre><h2>Kan Extensions as Ends</h2><p>The real power of Kan extensions comes from the fact that they can be calculated using ends (and coends). For simplicity, we’ll restrict our attention to the case where the target category <i>C</i> is <b>Set</b>, but the formulas can be extended to any category.</p><p>Let’s revisit the idea that a Kan extension can be used to extend the action of a functor outside of its original domain. Suppose that <code>K</code> embeds <i>I</i> inside <i>A</i>. Functor <code>D</code> maps <i>I</i> to <b>Set</b>. We could just say that for any object <code>a</code> in the image of <code>K</code>, that is <code>a = K i</code>, the extended functor maps <code>a</code> to <code>D i</code>. The problem is, what to do with those objects in <i>A</i> that are outside of the image of <code>K</code>? The idea is that every such object is potentially connected through lots of morphisms to every object in the image of <code>K</code>. A functor must preserve these morphisms. The totality of morphisms from an object <code>a</code> to the image of <code>K</code> is characterized by the hom-functor:</p><pre>A(a, K -)</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg"><img data-attachment-id="8652" data-permalink="https://bartoszmilewski.com/2017/04/17/kan-extensions/kan13/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg" data-orig-size="597,365" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;0&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1492088786&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;0&quot;,&quot;iso&quot;:&quot;0&quot;,&quot;shutter_speed&quot;:&quot;0&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Kan13" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg?w=300&amp;h=183" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg?w=510" class="alignnone size-medium wp-image-8652" src="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg?w=300&amp;h=183" alt="" width="300" height="183" srcset="https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg?w=300&amp;h=183 300w, https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg?w=150&amp;h=92 150w, https://bartoszmilewski.files.wordpress.com/2017/04/kan13.jpg 597w" sizes="(max-width: 300px) 100vw, 300px"></a><br>
 Notice that this hom-functor is a composition of two functors:</p><pre>A(a, K -) = A(a, -) ∘ K</pre><p>The right Kan extension is the right adjoint of functor composition:</p><pre>[I, Set](F' ∘ K, D) ≅ [A, Set](F', Ran<sub>K</sub>D)</pre><p>Let’s see what happens when we replace <code>F'</code> with the hom functor:</p><pre>[I, Set](A(a, -) ∘ K, D) ≅ [A, Set](A(a, -), Ran<sub>K</sub>D)</pre><p>and then inline the composition:</p><pre>[I, Set](A(a, K -), D) ≅ [A, Set](A(a, -), Ran<sub>K</sub>D)</pre><p>The right hand side can be reduced using the Yoneda lemma:</p><pre>[I, Set](A(a, K -), D) ≅ Ran<sub>K</sub>D a</pre><p>We can now rewrite the set of natural transformations as the end to get this very convenient formula for the right Kan extension:</p><pre>Ran<sub>K</sub>D a ≅ ∫<sub>i</sub> Set(A(a, K i), D i)</pre><p>There is an analogous formula for the left Kan extension in terms of a coend:</p><pre>Lan<sub>K</sub>D a = ∫<sup>i</sup> A(K i, a) × D i</pre><p>To see that this is the case, we’ll show that this is indeed the left adjoint to functor composition:</p><pre>[A, Set](Lan<sub>K</sub>D, F') ≅ [I, Set](D, F'∘ K)</pre><p>Let’s substitute our formula in the left hand side:</p><pre>[A, Set](∫<sup>i</sup> A(K i, -) × D i, F')</pre><p>This is a set of natural transformations, so it can be rewritten as an end:</p><pre>∫<sub>a</sub> Set(∫<sup>i</sup> A(K i, a) × D i, F'a)</pre><p>Using the continuity of the hom-functor, we can replace the coend with the end:</p><pre>∫<sub>a</sub> ∫<sub>i</sub> Set(A(K i, a) × D i, F'a)</pre><p>We can use the product-exponential adjunction:</p><pre>∫<sub>a</sub> ∫<sub>i</sub> Set(A(K i, a), (F'a)<sup>D i</sup>)</pre><p>The exponential is isomorphic to the corresponding hom-set:</p><pre>∫<sub>a</sub> ∫<sub>i</sub> Set(A(K i, a), A(D i, F'a))</pre><p>There is a theorem called the Fubini theorem that allows us to swap the two ends:</p><pre>∫<sub>i</sub> ∫<sub>a</sub> Set(A(K i, a), A(D i, F'a))</pre><p>The inner end represents the set of natural transformations between two functors, so we can use the Yoneda lemma:</p><pre>∫<sub>i</sub> A(D i, F'(K i))</pre><p>This is indeed the set of natural transformations that forms the right hand side of the adjunction we set out to prove:</p><pre>[I, Set](D, F'∘ K)</pre><p>These kinds of calculations using ends, coends, and the Yoneda lemma are pretty typical for the “calculus” of ends.</p><h2>Kan Extensions in Haskell</h2><p>The end/coend formulas for Kan extensions can be easily translated to Haskell. Let’s start with the right extension:</p><pre>Ran<sub>K</sub>D a ≅ ∫<sub>i</sub> Set(A(a, K i), D i)</pre><p>We replace the end with the universal quantifier, and hom-sets with function types:</p><pre>newtype Ran k d a = Ran (forall i. (a -&gt; k i) -&gt; d i)</pre><p>Looking at this definition, it’s clear that <code>Ran</code> must contain a value of type <code>a</code> to which the function can be applied, and a natural transformation between the two functors <code>k</code> and <code>d</code>. For instance, suppose that <code>k</code> is the tree functor, and <code>d</code> is the list functor, and you were given a <code>Ran Tree [] String</code>. If you pass it a function:</p><pre>f :: String -&gt; Tree Int</pre><p>you’ll get back a list of <code>Int</code>, and so on. The right Kan extension will use your function to produce a tree and then repackage it into a list. For instance, you may pass it a parser that generates a parsing tree from a string, and you’ll get a list that corresponds to the depth-first traversal of this tree.</p><p>The right Kan extension can be used to calculate the left adjoint of a given functor by replacing the functor <code>d</code> with the identity functor. This leads to the left adjoint of a functor <code>k</code> being represented by the set of polymorphic functions of the type:</p><pre>forall i. (a -&gt; k i) -&gt; i</pre><p>Suppose that <code>k</code> is the forgetful functor from the category of monoids. The universal quantifier then goes over all monoids. Of course, in Haskell we cannot express monoidal laws, but the following is a decent approximation of the resulting free functor (the forgetful functor <code>k</code> is an identity on objects):</p><pre>type Lst a = forall i. Monoid i =&gt; (a -&gt; i) -&gt; i</pre><p>As expected, it generates free monoids, or Haskell lists:</p><pre>toLst :: [a] -&gt; Lst a
 toLst as = \f -&gt; foldMap f as

 fromLst :: Lst a -&gt; [a]
 fromLst f = f (\a -&gt; [a])</pre><p>The left Kan extension is a coend:</p><pre>Lan<sub>K</sub>D a = ∫<sup>i</sup> A(K i, a) × D i</pre><p>so it translates to an existential quantifier. Symbolically:</p><pre>Lan k d a = exists i. (k i -&gt; a, d i)</pre><p>This can be encoded in Haskell using GADTs, or using a universally quantified data constructor:</p><pre>data Lan k d a = forall i. Lan (k i -&gt; a) (d i)</pre><p>The interpretation of this data structure is that it contains a function that takes a container of some unspecified <code>i</code>s and produces an <code>a</code>. It also has a container of those <code>i</code>s. Since you have no idea what <code>i</code>s are, the only thing you can do with this data structure is to retrieve the container of <code>i</code>s, repack it into the container defined by the functor <code>k</code> using a natural transformation, and call the function to obtain the <code>a</code>. For instance, if <code>d</code> is a tree, and <code>k</code> is a list, you can serialize the tree, call the function with the resulting list, and obtain an <code>a</code>.</p><p>The left Kan extension can be used to calculate the right adjoint of a functor. We know that the right adjoint of the product functor is the exponential, so let’s try to implement it using the Kan extension:</p><pre>type Exp a b = Lan ((,) a) I b</pre><p>This is indeed isomorphic to the function type, as witnessed by the following pair of functions:</p><pre>toExp :: (a -&gt; b) -&gt; Exp a b
 toExp f = Lan (f . fst) (I ())

 fromExp :: Exp a b -&gt; (a -&gt; b)
 fromExp (Lan f (I x)) = \a -&gt; f (a, x)</pre><p>Notice that, as described earlier in the general case, we performed the following steps: (1) retrieved the container of <code>x</code> (here, it’s just a trivial identity container), and the function <code>f</code>, (2) repackaged the container using the natural transformation between the identity functor and the pair functor, and (3) called the function <code>f</code>.</p><h2>Free Functor</h2><p>An interesting application of Kan extensions is the construction of a free functor. It’s the solution to the following practical problem: suppose you have a type constructor — that is a mapping of objects. Is it possible to define a functor based on this type constructor? In other words, can we define a mapping of morphisms that would extend this type constructor to a full-blown endofunctor? </p><p>The key observation is that a type constructor can be described as a functor whose domain is a discrete category. A discrete category has no morphisms other than the identity morphisms. Given a category <i>C</i>, we can always construct a discrete category <i>|C|</i> by simply discarding all non-identity morphisms. A functor <code>F</code> from <i>|C|</i> to <i>C</i> is then a simple mapping of objects, or what we call a type constructor in Haskell. There is also a canonical functor <code>J</code> that injects <i>|C|</i> into <i>C</i>: it’s an identity on objects (and on identity morphisms). The left Kan extension of <code>F</code> along <code>J</code>, if it exists, is then a functor for <i>C</i> to <i>C</i>:</p><pre>Lan<sub>J</sub> F a = ∫<sup>i</sup> C(J i, a) × F i</pre><p>It’s called a free functor based on <code>F</code>. </p><p>In Haskell, we would write it as:</p><pre>data FreeF f a = forall i. FMap (i -&gt; a) (f i)</pre><p>Indeed, for any type constructor <code>f</code>, <code>FreeF f</code> is a functor:</p><pre>instance Functor (FreeF f) where
  fmap g (FMap h fi) = FMap (g . h) fi</pre><p>As you can see, the free functor fakes the lifting of a function by recording both the function and its argument. It accumulates the lifted functions by recording their composition. Functor rules are automatically satisfied. This construction was used in a paper <a href="http://okmij.org/ftp/Haskell/extensible/more.pdf" target="_blank">Freer Monads, More Extensible Effects</a>.</p><p>Alternatively, we can use the right Kan extension for the same purpose:</p><pre>newtype FreeF f a = FreeF (forall i. (a -&gt; i) -&gt; f i)</pre><p>It’s easy to check that this is indeed a functor:</p><pre>instance Functor (FreeF f) where
  fmap g (FreeF r) = FreeF (\bi -&gt; r (bi . g))</pre><p>Next: <a href="https://bartoszmilewski.com/2017/05/13/enriched-categories/">Enriched Categories</a>.</p>

  <h2 class="post-title">
 			Enriched Categories		</h2><p>A category is <em>small</em> if its objects form a set. But we know that there are things larger than sets. Famously, a set of all sets cannot be formed within the standard set theory (the Zermelo-Fraenkel theory, optionally augmented with the Axiom of Choice). So a category of all sets must be large. There are mathematical tricks like Grothendieck universes that can be used to define collections that go beyond sets. These tricks let us talk about large categories.</p><p>A category is <em>locally small</em> if morphisms between any two objects form a set. If they don’t form a set, we have to rethink a few definitions. In particular, what does it mean to compose morphisms if we can’t even pick them from a set? The solution is to bootstrap ourselves by replacing hom-sets, which are objects in <b>Set</b>, with <em>objects</em> from some other category <i>V</i>. The difference is that, in general, objects don’t have elements, so we are no longer allowed to talk about individual morphisms. We have to define all properties of an <em>enriched</em> category in terms of operations that can be performed on hom-objects as a whole. In order to do that, the category that provides hom-objects must have additional structure — it must be a monoidal category. If we call this monoidal category <i>V</i>, we can talk about a category <i>C</i> enriched over <i>V</i>.</p><p>Beside size reasons, we might be interested in generalizing hom-sets to something that has more structure than mere sets. For instance, a traditional category doesn’t have the notion of a distance between objects. Two objects are either connected by morphisms or not. All objects that are connected to a given object are its neighbors. Unlike in real life; in a category, a friend of a friend of a friend is as close to me as my bosom buddy. In a suitably enriched category, we can define distances between objects.</p><p>There is one more very practical reason to get some experience with enriched categories, and that’s because a very useful online source of categorical knowledge, the <a href="https://ncatlab.org" target="_blank" rel="noopener noreferrer">nLab</a>, is written mostly in terms of enriched categories.</p><h2>Why Monoidal Category?</h2><p>When constructing an enriched category we have to keep in mind that we should be able to recover the usual definitions when we replace the monoidal category with <b>Set</b> and hom-objects with hom-sets. The best way to accomplish this is to start with the usual definitions and keep reformulating them in a point-free manner — that is, without naming elements of sets.</p><p>Let’s start with the definition of composition. Normally, it takes a pair of morphisms, one from <code>C(b, c)</code> and one from <code>C(a, b)</code> and maps it to a morphism from <code>C(a, c)</code>. In other words it’s a mapping:</p><pre>C(b, c) × C(a, b) -&gt; C(a, c)</pre><p>This is a function between sets — one of them being the cartesian product of two hom-sets. This formula can be easily generalized by replacing cartesian product with something more general. A categorical product would work, but we can go even further and use a completely general tensor product.</p><p>Next come the identity morphisms. Instead of picking individual elements from hom-sets, we can define them using functions from the singleton set <b>1</b>:</p><pre>j<sub>a</sub> :: <b>1</b> -&gt; C(a, a)</pre><p>Again, we could replace the singleton set with the terminal object, but we can go even further by replacing it with the unit <code>i</code> of the tensor product.</p><p>As you can see, objects taken from some monoidal category <i>V</i> are good candidates for hom-set replacement. </p><h2>Monoidal Category</h2><p>We’ve talked about monoidal categories before, but it’s worth restating the definition. A monoidal category defines a tensor product that is a bifunctor:</p><pre>⊗ :: V × V -&gt; V</pre><p>We want the tensor product to be associative, but it’s enough to satisfy associativity up to natural isomorphism. This isomorphism is called the associator. Its components are:</p><pre>α<sub>a b c</sub> :: (a ⊗ b) ⊗ c -&gt; a ⊗ (b ⊗ c)</pre><p>It must be natural in all three arguments.</p><p>A monoidal category must also define a special unit object <code>i</code> that serves as the unit of the tensor product; again, up to natural isomorphism. The two isomorphisms are called, respectively, the left and the right unitor, and their components are:</p><pre>λ<sub>a</sub> :: i ⊗ a -&gt; a
 ρ<sub>a</sub> :: a ⊗ i -&gt; a</pre><p>The associator and the unitors must satisfy coherence conditions:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg"><img data-attachment-id="8745" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/assoc-3/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg" data-orig-size="1280,602" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494598993&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Assoc" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=510&amp;h=240" class="alignnone wp-image-8745 size-large" src="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=510&amp;h=240" alt="" width="510" height="240" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=510&amp;h=240 510w, https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=1020&amp;h=480 1020w, https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=150&amp;h=71 150w, https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=300&amp;h=141 300w, https://bartoszmilewski.files.wordpress.com/2017/05/assoc.jpg?w=768&amp;h=361 768w" sizes="(max-width: 510px) 100vw, 510px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg"><img data-attachment-id="8751" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/idcoherence/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg" data-orig-size="1280,496" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494598993&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="IdCoherence" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=407&amp;h=158" class="alignnone wp-image-8751" src="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=407&amp;h=158" alt="" width="407" height="158" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=407&amp;h=158 407w, https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=814&amp;h=316 814w, https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=150&amp;h=58 150w, https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=300&amp;h=116 300w, https://bartoszmilewski.files.wordpress.com/2017/05/idcoherence.jpg?w=768&amp;h=298 768w" sizes="(max-width: 407px) 100vw, 407px"></a></p><p>A monoidal category is called <i>symmetric</i> if there is a natural isomorphism with components:</p><pre>γ<sub>a b</sub> :: a ⊗ b -&gt; b ⊗ a</pre><p>whose “square is one”:</p><pre>γ<sub>b a</sub> ∘ γ<sub>a b</sub> = id<sub>a⊗b</sub></pre><p>and which is consistent with the monoidal structure.</p><p>An interesting thing about monoidal categories is that you may be able to define the internal hom (the function object) as the right adjoint to the tensor product. You may recall that the standard definition of the function object, or the exponential, was through the right adjoint to the categorical product. A category in which such an object existed for any pair of objects was called cartesian closed. Here is the adjunction that defines the internal hom in a monoidal category:</p><pre>V(a ⊗ b, c) ~ V(a, [b, c])</pre><p>Following <a href="http://www.tac.mta.ca/tac/reprints/articles/10/tr10.pdf" target="_blank">G. M. Kelly</a>, I’m using the notation <code>[b, c]</code> for the internal hom. The counit of this adjunction is the natural transformation whose components are called evaluation morphisms:</p><pre>ε<sub>a b</sub> :: ([a, b] ⊗ a) -&gt; b</pre><p>Notice that, if the tensor product is not symmetric, we may define another internal hom, denoted by <code>[[a, c]]</code>, using the following adjunction:</p><pre>V(a ⊗ b, c) ~ V(b, [[a, c]])</pre><p>A monoidal category in which both are defined is called biclosed. An example of a category that is not biclosed is the category of endofunctors in <b>Set</b>, with functor composition serving as tensor product. That’s the category we used to define monads.</p><h2>Enriched Category</h2><p>A category <i>C</i> enriched over a monoidal category <i>V</i> replaces hom-sets with hom-objects. To every pair of objects <code>a</code> and <code>b</code> in <i>C</i> we associate an object <code>C(a, b)</code> in <i>V</i>. We use the same notation for hom-objects as we used for hom-sets, with the understanding that they don’t contain morphisms. On the other hand, <i>V</i> is a regular (non-enriched) category with hom-sets and morphisms. So we are not entirely rid of sets — we just swept them under the rug.</p><p>Since we cannot talk about individual morphisms in <i>C</i>, composition of morphisms is replaced by a family of morphisms in <i>V</i>:</p><pre>∘ :: C(b, c) ⊗ C(a, b) -&gt; C(a, c)</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg"><img data-attachment-id="8747" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/composition-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg" data-orig-size="1040,743" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494599016&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;50&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Composition" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=395&amp;h=282" class="alignnone wp-image-8747" src="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=395&amp;h=282" alt="" width="395" height="282" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=395&amp;h=282 395w, https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=790&amp;h=564 790w, https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=150&amp;h=107 150w, https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=300&amp;h=214 300w, https://bartoszmilewski.files.wordpress.com/2017/05/composition.jpg?w=768&amp;h=549 768w" sizes="(max-width: 395px) 100vw, 395px"></a><br>
 Similarly, identity morphisms are replaced by a family of morphisms in <i>V</i>:</p><pre>j<sub>a</sub> :: i -&gt; C(a, a)</pre><p>where <code>i</code> is the tensor unit in <i>V</i>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg"><img data-attachment-id="8750" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/id/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg" data-orig-size="649,557" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494599016&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;50&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Id" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=254&amp;h=218" class="alignnone wp-image-8750" src="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=254&amp;h=218" alt="" width="254" height="218" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=254&amp;h=218 254w, https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=508&amp;h=436 508w, https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=150&amp;h=129 150w, https://bartoszmilewski.files.wordpress.com/2017/05/id.jpg?w=300&amp;h=257 300w" sizes="(max-width: 254px) 100vw, 254px"></a></p><p>Associativity of composition is defined in terms of the associator in <i>V</i>:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg"><img data-attachment-id="8746" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/compcoherence/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg" data-orig-size="1280,304" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494598993&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="CompCoherence" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=514&amp;h=122" class="alignnone wp-image-8746" src="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=514&amp;h=122" alt="" width="514" height="122" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=514&amp;h=122 514w, https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=1028&amp;h=244 1028w, https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=150&amp;h=36 150w, https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=300&amp;h=71 300w, https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=768&amp;h=182 768w, https://bartoszmilewski.files.wordpress.com/2017/05/compcoherence.jpg?w=1024&amp;h=243 1024w" sizes="(max-width: 514px) 100vw, 514px"></a></p><p>Unit laws are likewise expressed in terms of unitors:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg"><img data-attachment-id="8753" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/rightid/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg" data-orig-size="1280,381" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494598993&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="RightId" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=446&amp;h=133" class="alignnone wp-image-8753" src="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=446&amp;h=133" alt="" width="446" height="133" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=446&amp;h=133 446w, https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=892&amp;h=266 892w, https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=150&amp;h=45 150w, https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=300&amp;h=89 300w, https://bartoszmilewski.files.wordpress.com/2017/05/rightid.jpg?w=768&amp;h=229 768w" sizes="(max-width: 446px) 100vw, 446px"></a></p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg"><img data-attachment-id="8752" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/leftid/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg" data-orig-size="1280,389" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494598993&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="LeftId" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=447&amp;h=136" class="alignnone wp-image-8752" src="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=447&amp;h=136" alt="" width="447" height="136" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=447&amp;h=136 447w, https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=894&amp;h=272 894w, https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=150&amp;h=46 150w, https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=300&amp;h=91 300w, https://bartoszmilewski.files.wordpress.com/2017/05/leftid.jpg?w=768&amp;h=233 768w" sizes="(max-width: 447px) 100vw, 447px"></a></p><h2>Preorders</h2><p>A preorder is defined as a thin category, one in which every hom-set is either empty or a singleton. We interpret a non-empty set <code>C(a, b)</code> as the proof that <code>a</code> is less than or equal to <code>b</code>. Such a category can be interpreted as enriched over a very simple monoidal category that contains just two objects, 0 and 1 (sometimes called False and True). Besides the mandatory identity morphisms, this category has a single morphism going from 0 to 1, let’s call it <code>0-&gt;1</code>. A simple monoidal structure can be established in it, with the tensor product modeling the simple arithmetic of 0 and 1 (i.e., the only non-zero product is <code>1⊗1</code>). The identity object in this category is 1. This is a strict monoidal category, that is, the associator and the unitors are identity morphisms.</p><p>Since in a preorder the-hom set is either empty or a singleton, we can easily replace it with a hom-object from our tiny category. The enriched preorder <i>C</i> has a hom-object <code>C(a, b)</code> for any pair of objects <code>a</code> and <code>b</code>. If <code>a</code> is less than or equal to <code>b</code>, this object is 1; otherwise it’s 0.</p><p>Let’s have a look at composition. The tensor product of any two objects is 0, unless both of them are 1, in which case it’s 1. If it’s 0, then we have two options for the composition morphism: it could be either <code>id<sub>0</sub></code> or <code>0-&gt;1</code>. But if it’s 1, then the only option is <code>id<sub>1</sub></code>. Translating this back to relations, this says that if <code>a &lt;= b</code> and <code>b &lt;= c</code> then <code>a &lt;= c</code>, which is exactly the transitivity law we need.</p><p>What about the identity? It’s a morphism from 1 to <code>C(a, a)</code>. There is only one morphism going from 1, and that’s the identity <code>id<sub>1</sub></code>, so <code>C(a, a)</code> must be 1. It means that <code>a &lt;= a</code>, which is the reflexivity law for a preorder. So both transitivity and reflexivity are automatically enforced, if we implement a preorder as an enriched category.</p><h2>Metric Spaces</h2><p>An interesting example is due to <a href="http://www.tac.mta.ca/tac/reprints/articles/1/tr1.pdf" target="_blank">William Lawvere</a>. He noticed that metric spaces can be defined using enriched categories. A metric space defines a distance between any two objects. This distance is a non-negative real number. It’s convenient to include inifinity as a possible value. If the distance is infinite, there is no way of getting from the starting object to the target object.</p><p>There are some obvious properties that have to be satisfied by distances. One of them is that the distance from an object to itself must be zero. The other is the triangle inequality: the direct distance is no larger than the sum of distances with intermediate stops. We don’t require the distance to be symmetric, which might seem weird at first but, as Lawvere explained, you can imagine that in one direction you’re walking uphill, while in the other you’re going downhill. In any case, symmetry may be imposed later as an additional constraint.</p><p>So how can a metric space be cast into a categorical language? We have to construct a category in which hom-objects are distances. Mind you, distances are not morphisms but hom-objects. How can a hom-object be a number? Only if we can construct a monoidal category <i>V</i> in which these numbers are objects. Non-negative real numbers (plus infinity) form a total order, so they can be treated as a thin category. A morphism between two such numbers <code>x</code> and <code>y</code> exists if and only if <code>x &gt;= y</code> (note: this is the opposite direction to the one traditionally used in the definition of a preorder). The monoidal structure is given by addition, with zero serving as the unit object. In other words, the tensor product of two numbers is their sum.</p><p>A metric space is a category enriched over such monoidal category. A hom-object <code>C(a, b)</code> from object <code>a</code> to <code>b</code> is a non-negative (possibly infinite) number that we will call the distance from <code>a</code> to <code>b</code>. Let’s see what we get for identity and composition in such a category.</p><p>By our definitions, a morphism from the tensorial unit, which is the number zero, to a hom-object <code>C(a, a)</code> is the relation:</p><pre>0 &gt;= C(a, a)</pre><p>Since <code>C(a, a)</code> is a non-negative number, this condition tells us that the distance from <code>a</code> to <code>a</code> is always zero. Check!</p><p>Now let’s talk about composition. We start with the tensor product of two abutting hom-objects, <code>C(b, c)⊗C(a, b)</code>. We have defined the tensor product as the sum of the two distances. Composition is a morphism in <i>V</i> from this product to <code>C(a, c)</code>. A morphism in <i>V</i> is defined as the greater-or-equal relation. In other words, the sum of distances from <code>a</code> to <code>b</code> and from <code>b</code> to <code>c</code> is greater than or equal to the distance from <code>a</code> to <code>c</code>. But that’s just the standard triangle inequality. Check!</p><p>By re-casting the metric space in terms of an enriched category, we get the triangle inequality and the zero self-distance “for free.”</p><h2>Enriched Functors</h2><p>The definition of a functor involves the mapping of morphisms. In the enriched setting, we don’t have the notion of individual morphisms, so we have to deal with hom-objects in bulk. Hom-objects are objects in a monoidal category <i>V</i>, and we have morphisms between them at our disposal. It therefore makes sense to define enriched functors between categories when they are enriched over the same monoidal category <i>V</i>. We can then use morphisms in <i>V</i> to map the hom-objects between two enriched categories.</p><p>An <em>enriched functor</em> <code>F</code> between two categories <i>C</i> and <i>D</i>, besides mapping objects to objects, also assigns, to every pair of objects in <i>C</i>, a morphism in <i>V</i>:</p><pre>F<sub>a b</sub> :: C(a, b) -&gt; D(F a, F b)</pre><p>A functor is a structure-preserving mapping. For regular functors it meant preserving composition and identity. In the enriched setting, the preservation of composition means that the following diagram commute:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg"><img data-attachment-id="8748" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/functorcomp/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg" data-orig-size="1280,522" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494599016&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;50&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FunctorComp" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=510&amp;h=208" class="alignnone size-large wp-image-8748" src="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=510&amp;h=208" alt="" width="510" height="208" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=510&amp;h=208 510w, https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=1020&amp;h=416 1020w, https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=150&amp;h=61 150w, https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=300&amp;h=122 300w, https://bartoszmilewski.files.wordpress.com/2017/05/functorcomp.jpg?w=768&amp;h=313 768w" sizes="(max-width: 510px) 100vw, 510px"></a></p><p>The preservation of identity is replaced by the preservation of the morphisms in <i>V</i> that “select” the identity:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg"><img data-attachment-id="8749" data-permalink="https://bartoszmilewski.com/2017/05/13/enriched-categories/functorid-2/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg" data-orig-size="1169,527" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;2.2&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;iPhone 5s&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1494599016&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;4.15&quot;,&quot;iso&quot;:&quot;50&quot;,&quot;shutter_speed&quot;:&quot;0.01&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="FunctorId" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=388&amp;h=175" class="alignnone wp-image-8749" src="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=388&amp;h=175" alt="" width="388" height="175" srcset="https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=388&amp;h=175 388w, https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=776&amp;h=350 776w, https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=150&amp;h=68 150w, https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=300&amp;h=135 300w, https://bartoszmilewski.files.wordpress.com/2017/05/functorid.jpg?w=768&amp;h=346 768w" sizes="(max-width: 388px) 100vw, 388px"></a></p><h2>Self Enrichment</h2><p>A closed symmetric monoidal category may be self-enriched by replacing hom-sets with internal homs (see the definition above). To make this work, we have to define the composition law for internal homs. In other words, we have to implement a morphism with the following signature:</p><pre>[b, c] ⊗ [a, b] -&gt; [a, c]</pre><p>This is not much different from any other programming task, except that, in category theory, we usually use point free implementations. We start by specifying the set whose element it’s supposed to be. In this case, it’s a member of the hom-set:</p><pre>V([b, c] ⊗ [a, b], [a, c])</pre><p>This hom-set is isomorphic to:</p><pre>V(([b, c] ⊗ [a, b]) ⊗ a, c)</pre><p>I just used the adjunction that defined the internal hom <code>[a, c]</code>. If we can build a morphism in this new set, the adjunction will point us at the morphism in the original set, which we can then use as composition. We construct this morphism by composing several morphisms that are at our disposal. To begin with, we can use the associator <code>α<sub>[b, c] [a, b] a</sub></code> to reassociate the expression on the left:</p><pre>([b, c] ⊗ [a, b]) ⊗ a -&gt; [b, c] ⊗ ([a, b] ⊗ a)</pre><p>We can follow it with the co-unit of the adjunction <code>ε<sub>a b</sub></code>:</p><pre>[b, c] ⊗ ([a, b] ⊗ a) -&gt; [b, c] ⊗ b</pre><p>And use the counit <code>ε<sub>b c</sub></code> again to get to <code>c</code>. We have thus constructed a morphism:</p><pre>ε<sub>b c</sub> . (id<sub>[b, c]</sub> ⊗ ε<sub>a b</sub>) . α<sub>[b, c] [a, b] a</sub></pre><p>that is an element of the hom-set:</p><pre>V(([b, c] ⊗ [a, b]) ⊗ a, c)</pre><p>The adjunction will give us the composition law we were looking for.</p><p>Similarly, the identity:</p><pre>j<sub>a</sub> :: i -&gt; [a, a]</pre><p>is a member of the following hom-set:</p><pre>V(i, [a, a])</pre><p>which is isomorphic, through adjunction, to:</p><pre> V(i ⊗ a, a)</pre><p>We know that this hom-set contains the left identity <code>λ<sub>a</sub></code>. We can define <code>j<sub>a</sub></code> as its image under the adjunction.</p><p>A practical example of self-enrichment is the category <b>Set</b> that serves as the prototype for types in programming languages. We’ve seen before that it’s a closed monoidal category with respect to cartesian product. In <b>Set</b>, the hom-set between any two sets is itself a set, so it’s an object in <b>Set</b>. We know that it’s isomorphic to the exponential set, so the external and the internal homs are equivalent. Now we also know that, through self-enrichment, we can use the exponential set as the hom-object and express composition in terms of cartesian products of exponential objects.</p><h2>Relation to 2-Categories</h2><p>I talked about 2-categories in the context of <b>Cat</b>, the category of (small) categories. The morphisms between categories are functors, but there is an additional structure: natural transformations between functors. In a 2-category, the objects are often called zero-cells; morphisms, 1-cells; and morphisms between morphisms, 2-cells. In <b>Cat</b> the 0-cells are categories, 1-cells are functors, and 2-cells are natural transformations.</p><p>But notice that functors between two categories form a category too; so, in <b>Cat</b>, we really have a <em>hom-category</em> rather than a hom-set. It turns out that, just like <b>Set</b> can be treated as a category enriched over <b>Set</b>, <b>Cat</b> can be treated as a category enriched over <b>Cat</b>. Even more generally, just like every category can be treated as enriched over <b>Set</b>, every 2-category can be considered enriched over <b>Cat</b>.</p><p>Next: <a href="https://bartoszmilewski.com/2017/07/22/topoi/">Topoi</a>.</p>

 <h2 class="post-title">
 			Topoi		</h2><p>I realize that we might be getting away from programming and diving into hard-core math. But you never know what the next big revolution in programming might bring and what kind of math might be necessary to understand it. There are some very interesting ideas going around, like functional reactive programming with its continuous time, the extention of Haskell’s type system with dependent types, or the exploration on homotopy type theory in programming.</p><p>So far I’ve been casually identifying types with <em>sets</em> of values. This is not strictly correct, because such approach doesn’t take into account the fact that, in programming, we <em>compute</em> values, and the computation is a process that takes time and, in extreme cases, might not terminate. Divergent computations are part of every Turing-complete language. </p><p>There are also foundational reasons why set theory might not be the best fit as the basis for computer science or even math itself. A good analogy is that of set theory being the assembly language that is tied to a particular architecture. If you want to run your math on different architectures, you have to use more general tools. </p><p>One possibility is to use spaces in place of sets. Spaces come with more structure, and may be defined without recourse to sets. One thing usually associated with spaces is topology, which is necessary to define things like continuity. And the conventional approach to topology is, you guessed it, through set theory. In particular, the notion of a subset is central to topology. Not surprisingly, category theorists generalized this idea to categories other than <b>Set</b>. The type of category that has just the right properties to serve as a replacement for set theory is called a <em>topos</em> (plural: topoi), and it provides, among other things, a generalized notion of a subset.</p><h2>Subobject Classifier</h2><p>Let’s start by trying to express the idea of a subset using functions rather than elements. Any function <code>f</code> from some set <code>a</code> to <code>b</code> defines a subset of <code>b</code>–that of the image of <code>a</code> under <code>f</code>. But there are many functions that define the same subset. We need to be more specific. To begin with, we might focus on functions that are injective — ones that don’t smush multiple elements into one. Injective functions “inject” one set into another. For finite sets, you may visualize injective functions as parallel arrows connecting elements of one set to elements of another. Of course, the first set cannot be larger than the second set, or the arrows would necessarily converge. There is still some ambiguity left: there may be another set <code>a'</code> and another injective function <code>f'</code> from that set to <code>b</code> that picks the same subset. But you can easily convince yourself that such a set would have to be isomorphic to <code>a</code>. We can use this fact to define a subset as a family of injective functions that are related by isomorphisms of their domains. More precisely, we say that two injective functions:</p><pre>f :: a -&gt; b
 f':: a'-&gt; b</pre><p>are equivalent if there is an isomorphism:</p><pre>h :: a -&gt; a'</pre><p>such that:</p><pre>f = f' . h</pre><p>Such a family of equivalent injections defines a subset of <code>b</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg"><img data-attachment-id="8934" data-permalink="https://bartoszmilewski.com/2017/07/22/topoi/subsetinjection/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg" data-orig-size="1061,824" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;1.9&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;SM-A520F&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1499858172&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.6&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.03030303030303&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="SubsetInjection" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=300" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=220&amp;h=171" class="alignnone wp-image-8934" src="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=220&amp;h=171" alt="" width="220" height="171" srcset="https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=220&amp;h=171 220w, https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=440&amp;h=342 440w, https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=150&amp;h=116 150w, https://bartoszmilewski.files.wordpress.com/2017/07/subsetinjection.jpg?w=300&amp;h=233 300w" sizes="(max-width: 220px) 100vw, 220px"></a></p><p>This definition can be lifted to an arbitrary category if we replace injective functions with monomorphism. Just to remind you, a monomorphism <code>m</code> from <code>a</code> to <code>b</code> is defined by its universal property. For any object <code>c</code> and any pair of morphisms:</p><pre>g :: c -&gt; a
 g':: c -&gt; a</pre><p>such that:</p><pre>m . g = m . g'</pre><p>it must be that <code>g = g'</code>.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg"><img data-attachment-id="8931" data-permalink="https://bartoszmilewski.com/2017/07/22/topoi/monomorphism/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg" data-orig-size="1280,743" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;1.9&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;SM-A520F&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1499858172&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.6&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.03030303030303&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Monomorphism" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=300&amp;h=174" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=510" class="alignnone size-medium wp-image-8931" src="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=300&amp;h=174" alt="" width="300" height="174" srcset="https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=300&amp;h=174 300w, https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=600&amp;h=348 600w, https://bartoszmilewski.files.wordpress.com/2017/07/monomorphism.jpg?w=150&amp;h=87 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>On sets, this definition is easier to understand if we consider what it would mean for a function <code>m</code> <em>not</em> to be a monomorphism. It would map two different elements of <code>a</code> to a single element of <code>b</code>. We could then find two functions <code>g</code> and <code>g'</code> that differ only at those two elements. The postcomposition with <code>m</code> would then mask this difference.</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg"><img data-attachment-id="8932" data-permalink="https://bartoszmilewski.com/2017/07/22/topoi/notmono/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg" data-orig-size="1280,537" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;1.9&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;SM-A520F&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1499858172&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.6&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.03030303030303&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="NotMono" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=300&amp;h=126" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=510" class="alignnone size-medium wp-image-8932" src="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=300&amp;h=126" alt="" width="300" height="126" srcset="https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=300&amp;h=126 300w, https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=600&amp;h=252 600w, https://bartoszmilewski.files.wordpress.com/2017/07/notmono.jpg?w=150&amp;h=63 150w" sizes="(max-width: 300px) 100vw, 300px"></a></p><p>There is another way of defining a subset: using a single function called the characteristic function. It’s a function <code>χ</code> from the set <code>b</code> to a two-element set <code>Ω</code>. One element of this set is designated as “true” and the other as “false.” This function assigns “true” to those elements of <code>b</code> that are members of the subset, and “false” to those that aren’t. </p><p>It remains to specify what it means to designate an element of <code>Ω</code> as “true.” We can use the standard trick: use a function from a singleton set to <code>Ω</code>. We’ll call this function <code>true</code>:</p><pre>true :: 1 -&gt; Ω</pre><p><a href="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg"><img data-attachment-id="8935" data-permalink="https://bartoszmilewski.com/2017/07/22/topoi/true/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg" data-orig-size="1061,687" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;1.9&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;SM-A520F&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1499858172&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.6&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.03030303030303&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="True" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=190&amp;h=123" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=510" class="alignnone wp-image-8935" src="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=190&amp;h=123" alt="" width="190" height="123" srcset="https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=190&amp;h=123 190w, https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=380&amp;h=246 380w, https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=150&amp;h=97 150w, https://bartoszmilewski.files.wordpress.com/2017/07/true.jpg?w=300&amp;h=194 300w" sizes="(max-width: 190px) 100vw, 190px"></a></p><p>These definitions can be combined in such a way that they not only define what a subobject is, but also define the special object <code>Ω</code> without talking about elements. The idea is that we want the morphism <code>true</code> to represent a “generic” subobject. In <b>Set</b>, it picks a single-element subset from a two-element set <code>Ω</code>. This is as generic as it gets. It’s clearly a proper subset, because <code>Ω</code> has one more element that’s <em>not</em> in that subset.</p><p>In a more general setting, we define <code>true</code> to be a monomorphism from the terminal object to the <em>classifying object</em> <code>Ω</code>. But we have to define the classifying object. We need a universal property that links this object to the characteristic function. It turns out that, in <b>Set</b>, the pullback of <code>true</code> along the characteristic function <code>χ</code> defines both the subset <code>a</code> and the injective function that embeds it in <code>b</code>. Here’s the pullback diagram:</p><p><a href="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg"><img data-attachment-id="8933" data-permalink="https://bartoszmilewski.com/2017/07/22/topoi/pullback/" data-orig-file="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg" data-orig-size="1280,906" data-comments-opened="1" data-image-meta="{&quot;aperture&quot;:&quot;1.9&quot;,&quot;credit&quot;:&quot;&quot;,&quot;camera&quot;:&quot;SM-A520F&quot;,&quot;caption&quot;:&quot;&quot;,&quot;created_timestamp&quot;:&quot;1499858172&quot;,&quot;copyright&quot;:&quot;&quot;,&quot;focal_length&quot;:&quot;3.6&quot;,&quot;iso&quot;:&quot;40&quot;,&quot;shutter_speed&quot;:&quot;0.03030303030303&quot;,&quot;title&quot;:&quot;&quot;,&quot;orientation&quot;:&quot;1&quot;}" data-image-title="Pullback" data-image-description="" data-medium-file="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=232&amp;h=164" data-large-file="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=510" class="alignnone  wp-image-8933" src="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=232&amp;h=164" alt="" width="232" height="164" srcset="https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=232&amp;h=164 232w, https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=464&amp;h=328 464w, https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=150&amp;h=106 150w, https://bartoszmilewski.files.wordpress.com/2017/07/pullback.jpg?w=300&amp;h=212 300w" sizes="(max-width: 232px) 100vw, 232px"></a></p><p>Let’s analyze this diagram. The pullback equation is:</p><pre>true . unit = χ . f</pre><p>The function <code>true . unit</code> maps every element of <code>a</code> to “true.” Therefore <code>f</code> must map all elements of <code>a</code> to those elements of <code>b</code> for which <code>χ</code> is “true.” These are, by definition, the elements of the subset that is specified by the characteristic function <code>χ</code>. So the image of <code>f</code> is indeed the subset in question. The universality of the pullback guarantees that <code>f</code> is injective.</p><p>This pullback diagram can be used to define the classifying object in categories other than <b>Set</b>. Such a category must have a terminal object, which will let us define the monomorphism <code>true</code>. It must also have pullbacks — the actual requirement is that it must have all finite limits (a pullback is an example of a finite limit). Under those assumptions, we define the classifying object <code>Ω</code> by the property that, for every monomorphism <code>f</code> there is a unique morphism <code>χ</code> that completes the pullback diagram.</p><p>Let’s analyze the last statement. When we construct a pullback, we are given three objects <code>Ω</code>, <code>b</code> and <code>1</code>; and two morphisms, <code>true</code> and <code>χ</code>. The existence of a pullback means that we can find the best such object <code>a</code>, equipped with two morphisms <code>f</code> and <code>unit</code> (the latter is uniquely determined by the definition of the terminal object), that make the diagram commute. </p><p>Here we are solving a different system of equations. We are solving for <code>Ω</code> and <code>true</code> while varying both <code>a</code> <em>and</em> <code>b</code>. For a given <code>a</code> and <code>b</code> there may or may not be a monomorphism <code>f::a-&gt;b</code>. But if there is one, we want it to be a pullback of some <code>χ</code>. Moreover, we want this <code>χ</code> to be uniquely determined by <code>f</code>.</p><p>We can’t say that there is a one-to-one correspondence between monomorphisms <code>f</code> and characteristic functions <code>χ</code>, because a pullback is only unique up to isomorphism. But remember our earlier definition of a subset as a family of equivalent injections. We can generalize it by defining a subobject of <code>b</code> as a family of equivalent monomorphisms to <code>b</code>. This family of monomorphisms is in one-to-one corrpespondence with the family of equivalent pullbacks of our diagram. </p><p>We can thus define a set of subobjects of <code>b</code>, <code>Sub(b)</code>, as a family of monomorphisms, and see that it is isomorphic to the set of morphisms from <code>b</code> to <code>Ω</code>:</p><pre>Sub(b) ≅ C(b, Ω)</pre><p>This happens to be a natural isomorphism of two functors. In other words, <code>Sub(-)</code> is a representable (contravariant) functor whose representation is the object Ω.</p><h2>Topos</h2><p>A topos is a category that:</p><ol>
 <li>Is cartesian closed: It has all products, the terminal object, and exponentials (defined as right adjoints to products),</li>
 <li>Has limits for all finite diagrams,</li>
 <li>Has a subobject classifier <code>Ω</code>.</li>
 </ol><p>This set of properties makes a topos a shoe-in for <b>Set</b> in most applications. It also has additional properties that follow from its definition. For instance, a topos has all finite colimits, including the initial object.</p><p>It would be tempting to define the subobject classifier as a coproduct (sum) of two copies of the terminal object –that’s what it is in <b>Set</b>— but we want to be more general than that. Topoi in which this is true are called Boolean.</p><h2>Topoi and Logic</h2><p>In set theory, a characteristic function may be interpreted as defining a property of the elements of a set — a <em>predicate</em> that is true for some elements and false for others. The predicate <code>isEven</code> selects a subset of even numbers from the set of natural numbers. In a topos, we can generalize the idea of a predicate to be a morphism from object <code>a</code> to <code>Ω</code>. This is why <code>Ω</code> is sometimes called the truth object. </p><p>Predicates are the building blocks of logic. A topos contains all the necessary instrumentation to study logic. It has products that correspond to logical conjunctions (logical <em>and</em>), coproducts for disjunctions (logical <em>or</em>), and exponentials for implications. All standard axioms of logic hold in a topos except for the law of excluded middle (or, equivalently, double negation elimination). That’s why the logic of a topos corresponds to constructive or intuitionistic logic. </p><p>Intuitionistic logic has been steadily gaining ground, finding unexpected support from computer science. The classical notion of excluded middle is based on the belief that there is absolute truth: Any statement is either true or false or, as Ancient Romans would say,  <em>tertium non datur</em> (there is no third option). But the only way we can know whether something is true or false is if we can prove or disprove it.  A proof is a process, a computation — and we know that computations take time and resources. In some cases, they may never terminate. It doesn’t make sense to claim that a statement is true if we cannot prove it in finite amount of time. A topos with its more nuanced truth object provides a more general framework for modeling interesting logics.</p><h2>Challenges</h2><ol>
 <li>Show that the function <code>f</code> that is the pullback of <code>true</code> along the characteristic function must be injective.</li>
 </ol>
diff --git a/semi-auto-scraper.js b/semi-auto-scraper.js
 let frag = document.createDocumentFragment();
 document.querySelectorAll(`
  .post-title,
  .post-content > p,
  .post-content > h1,
  .post-content > h2,
  .post-content > h3,
  .post-content > h4,
  .post-content > h5,
  .post-content > h6,
  .post-content > ul,
  .post-content > ol,
  .post-content > pre
 `).forEach(el => frag.appendChild(el.cloneNode(true)));
 console.log(frag);
 document.head.remove();
 document.body.innerHTML = '';
 document.body.appendChild(frag);
 let area = document.createElement('textarea')
 area.value = document.body.innerHTML;
 document.body.innerHTML = '';
 document.body.appendChild(area);
 area.select();
	let frag = document.createDocumentFragment();
	document.querySelectorAll(`
	.post-title,
	.post-content > p,
	.post-content > h1,
	.post-content > h2,
	.post-content > h3,
	.post-content > h4,
	.post-content > h5,
	.post-content > h6,
	.post-content > ul,
	.post-content > ol,
	.post-content > pre
	`).forEach(el => frag.appendChild(el.cloneNode(true)));
	console.log(frag);
	document.head.remove();
	document.body.innerHTML = '';
	document.body.appendChild(frag);
	let area = document.createElement('textarea')
	area.value = document.body.innerHTML;
	document.body.innerHTML = '';
	document.body.appendChild(area);
	area.select();
No results found