This commit is contained in:
Boris Marinov 2023-09-14 10:40:02 +03:00
parent 0bbc7b6807
commit f2d79ad574
77 changed files with 198 additions and 194 deletions

6
06_functors.md Normal file
View File

@ -0,0 +1,6 @@
<script>
location.href="/category-theory-illustrated/10_functors"
</script>
[Chapter moved, click here](/category-theory-illustrated/10_functors)
---

View File

@ -229,9 +229,9 @@ Some functions in programming (also called methods, subroutines, etc.) kinda res
However functions in most programming languages can also be quite different from mathematical functions &mdash; they can perform various operations that have nothing to do with returning a value. These operations are sometimes called side effects.
Why are functions in programming different? Well, at the time when most programming paradigms that are in use today were created, computer resources were much more limited than today, and programming much more cumbersome, so people had bigger problems than the fact that their functions were not mathematically sound. Nowadays, many people feel that mathematical functions are too limiting and hard to use.
Why are functions in programming different? Well, figuring a way to encode *effectful* functions in a way that is mathematically sound isn't trivial and at the time when most programming paradigms that are in use today were created, people had bigger problems than the their functions not being mathematically sound (e.g. actually being able to run any program at all).
And they might be right. But mathematical functions have one big advantage over non-mathematical ones &mdash; their type signature tells you everything that the function does. This is probably the reason why most functional languages are strongly-typed.
Nowadays, many people feel that mathematical functions are too limiting and hard to use. And they might be right. But mathematical functions have one big advantage over non-mathematical ones &mdash; their type signature tells you almost everything about what the function does (this is probably the reason why most functional languages are strongly-typed).
Purely-functional programming languages
---

View File

@ -6,7 +6,7 @@
sodipodi:docname="initial_object.svg"
width="595.29999"
height="200"
inkscape:version="1.2.2 (1:1.2.2+202305151914+b0a8486541)"
inkscape:version="1.3 (1:1.3+202307231459+0e150ed6c4)"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
@ -25,7 +25,7 @@
showgrid="false"
inkscape:zoom="0.74330708"
inkscape:cx="313.46399"
inkscape:cy="139.91526"
inkscape:cy="140.58792"
inkscape:window-width="1080"
inkscape:window-height="1864"
inkscape:window-x="0"
@ -33,132 +33,124 @@
inkscape:window-maximized="1"
inkscape:current-layer="svg6444"
inkscape:lockguides="false" />
<g
id="g6440-5"
transform="matrix(0.66438656,0,0,-0.66438656,83.169532,178.26616)">
<circle
opacity="0.14"
stroke="#000000"
stroke-width="6"
stroke-miterlimit="10"
cx="451.76987"
cy="-127.04344"
r="30.9"
id="circle6392-0"
transform="scale(1,-1)" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="6"
stroke-miterlimit="10"
cx="325.66986"
cy="-45.443451"
r="30.9"
id="circle6394-3"
transform="scale(1,-1)" />
<circle
fill="#cee7cc"
stroke="#808285"
stroke-width="6"
stroke-miterlimit="10"
cx="323.36987"
cy="-46.34343"
r="30.9"
id="circle6396-6"
transform="scale(1,-1)"
style="fill:#ffffff" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="6"
stroke-miterlimit="10"
cx="245.36987"
cy="-133.94344"
r="30.9"
id="circle6410-1"
transform="scale(1,-1)" />
<circle
fill="#caebfc"
stroke="#bcbec0"
stroke-width="6"
stroke-miterlimit="10"
cx="242.06987"
cy="-135.84343"
r="30.9"
id="circle6426-0"
transform="scale(1,-1)" />
<ellipse
fill="#e8cae1"
stroke="#bcbec0"
stroke-width="6"
stroke-miterlimit="10"
cx="449.26987"
cy="-128.24342"
rx="30.1"
ry="30.9"
id="ellipse6428-6"
transform="scale(1,-1)" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="6"
stroke-miterlimit="10"
cx="353.06985"
cy="-143.14343"
r="30.9"
id="circle6434-3"
transform="scale(1,-1)" />
<circle
fill="#e2f3f0"
stroke="#bcbec0"
stroke-width="6"
stroke-miterlimit="10"
cx="349.76987"
cy="-144.14343"
r="30.9"
id="circle6436-2"
transform="scale(1,-1)" />
<path
fill="#d1d3d4"
d="m 263.06987,108.14343 1.2,-0.6 c 0.8,-0.4 1.8,-1 3.1,-1.7 2.5,-1.5 5.8,-3.6 8.9,-5.999998 3.1,-2.4 6.1,-4.9 8.2,-6.9 1.1,-1 1.9,-1.9 2.5,-2.5 0.4,-0.5 0.7,-0.7 0.7,-0.7 l -8.3,-8 c 7.8,-1.7 15.6,-4.6 23.3,-8.9 -0.1,8.7 -1.5,18 -4.4,27.199998 l -8.3,-7.999998 -0.7,0.7 -2.6,2.6 c -2.2,2.1 -5.3,4.699998 -8.5,7.199998 -3.2,2.4 -6.6,4.7 -9.2,6.2 -1.3,0.8 -2.4,1.4 -3.2,1.8 -0.8,0.4 -1.2,0.7 -1.2,0.7 z m 78.7,4.1 c -0.4,-3.9 -0.9,-7.8 -1.7,-11.7 l -0.2,-0.899998 -11.3,2.399998 c 0,0 0.6,-1.4 1.3,-3.499998 0.8,-2.2 1.7,-5.1 2.4,-8.2 1.5,-6.1 2.2,-12.7 2.2,-12.7 0,0 0.3,0.2 0.9,0.7 0.6,0.4 1.4,1.1 2.4,1.8 2,1.6 4.5,3.7 7,6.1 5,4.7 9.5,10.3 9.5,10.3 l -11.3,2.4 0.2,0.9 c 0.8,3.999998 1.4,7.999998 1.7,11.999998 z m 80.8,-1.1 c 0,0 -1,-0.2 -2.7,-0.6 -0.9,-0.2 -1.9,-0.4 -3.1,-0.7 -1.2,-0.3 -2.5,-0.6 -4,-1 -5.8,-1.5 -13.4,-4 -20.7,-7.1 -7.3,-3.099998 -14.4,-6.899998 -19.5,-10.099998 -2.5,-1.6 -4.7,-2.9 -6.1,-3.9 l -0.9,-0.6 -6.6,9.5 c -4.3,-8.3 -7.8,-16.7 -10.3,-25.1 8.5,2 17,3.1 25.2,3.4 l -6.5,9.5 0.9,0.6 c 1.4,1 3.5,2.3 6,3.8 5,3.1 11.9,6.8 19.1,9.8 7.2,3.099998 14.6,5.499998 20.3,6.999998 1.4,0.4 2.7,0.7 3.9,1 1.2,0.3 2.2,0.5 3,0.7 1.7,0.4 2.6,0.6 2.6,0.6 z"
id="path6438-0"
sodipodi:nodetypes="cscscccccccccccscccccccccccccccccccscscccccccccccsccc"
style="fill:#4d4d4d" />
<path
d="m 298.88788,92.44315 m 5.43934,72.51093 c 0,0 -0.0934,-1.05761 -0.19221,-2.87316 -0.0641,-0.95772 -0.15745,-2.01533 -0.20959,-3.30207 -0.0521,-1.28673 -0.13355,-2.67337 -0.17373,-4.2891 -0.20201,-6.23388 0.0673,-14.5591 1.02386,-22.76054 0.95658,-8.20143 2.67111,-16.4083 4.37262,-22.44129 0.86541,-2.96656 1.51907,-5.54545 2.10761,-7.23722 l 0.33551,-1.07499 -11.42533,-3.808034 c 7.03083,-6.729036 14.39615,-12.688225 22.05463,-17.648426 0.49411,9.077701 1.88729,17.891556 3.9917,26.17117 l -11.39602,-3.70813 -0.33552,1.07498 c -0.58852,1.69178 -1.27152,4.17078 -2.03703,7.108 -1.63092,5.90378 -3.30419,13.88152 -4.1902,21.95376 -0.98591,8.10153 -1.21391,16.19763 -1.04123,22.33159 0.0109,1.51588 0.0923,2.9025 0.14444,4.18923 0.0521,1.28674 0.14552,2.34435 0.18026,3.20217 0.0988,1.81554 0.16289,2.77327 0.16289,2.77327 z"
style="fill:#4d4d4d;stroke-width:1.56703"
id="path8135-6" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="6"
stroke-miterlimit="10"
cx="306.71149"
cy="-198.46086"
r="30.9"
id="circle6392-2-1"
transform="scale(1,-1)" />
<ellipse
fill="#e8cae1"
stroke="#bcbec0"
stroke-width="6"
stroke-miterlimit="10"
cx="304.21149"
cy="-196.63828"
rx="30.1"
ry="30.9"
id="ellipse6428-2-5"
transform="scale(1,-1)"
style="fill:#ac9393" />
</g>
<circle
opacity="0.14"
stroke="#000000"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="378.48465"
cy="94.022644"
r="22.619894"
id="circle6392" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="286.17496"
cy="153.75673"
r="22.619894"
id="circle6394" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="227.39253"
cy="88.971619"
r="22.619894"
id="circle6410" />
<circle
fill="#caebfc"
stroke="#bcbec0"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="224.97682"
cy="87.58075"
r="22.619894"
id="circle6426" />
<ellipse
fill="#e8cae1"
stroke="#bcbec0"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="376.65454"
cy="93.144226"
rx="22.034267"
ry="22.619894"
id="ellipse6428" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="306.23273"
cy="82.236877"
r="22.619894"
id="circle6434" />
<circle
fill="#e2f3f0"
stroke="#bcbec0"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="303.81702"
cy="81.504837"
r="22.619894"
id="circle6436" />
<path
d="m 256.00087,82.831664 m 20.73152,49.026586 c 0,0 -0.31214,-0.71179 -0.80532,-1.94806 -0.26841,-0.64936 -0.58055,-1.36116 -0.91766,-2.24153 -0.33704,-0.88039 -0.71807,-1.82313 -1.12361,-2.9346 -1.59806,-4.27702 -3.35831,-10.11496 -4.61287,-16.02777 -1.25453,-5.91281 -1.98459,-12.006656 -2.21527,-16.589506 -0.0935,-2.26021 -0.2432,-4.20198 -0.2306,-5.51315 l -0.0187,-0.82417 -8.81603,0.0306 c 3.30335,-6.31205 7.01875,-12.16834 11.17115,-17.4002 2.46576,6.1814 5.49351,11.96947 8.88968,17.22063 l -8.77233,0.093 0.0187,0.82415 c -0.0126,1.31119 0.0934,3.19054 0.24934,5.40702 0.24942,4.47671 0.95451,10.401976 2.22779,16.208656 1.21085,5.85038 2.94616,11.51973 4.50051,15.73429 0.36209,1.04897 0.74286,1.99179 1.07997,2.87216 0.33704,0.88039 0.64924,1.59217 0.87394,2.17909 0.49324,1.23624 0.76159,1.88564 0.76159,1.88564 z"
style="fill:#4d4d4d;stroke-width:1.14712"
id="path8135" />
<path
d="m 307.78646,122.58687 m -31.39521,42.98537 c 0,0 0.46665,-0.62153 1.22952,-1.71224 0.40982,-0.57075 0.87648,-1.19229 1.40602,-1.97223 0.52945,-0.77996 1.11601,-1.61055 1.76501,-2.59981 2.53393,-3.79814 5.58276,-9.07874 8.15643,-14.54788 2.57366,-5.46914 4.67814,-11.23448 5.95086,-15.64308 0.60797,-2.17892 1.19782,-4.03498 1.48546,-5.31428 l 0.20666,-0.79804 8.57533,2.04616 c -1.77209,-6.90026 -4.04958,-13.45109 -6.89529,-19.49401 -3.81419,5.45359 -8.08552,10.39573 -12.5927,14.73094 l 8.51853,2.09692 -0.20667,0.79804 c -0.28764,1.2793 -0.82067,3.08459 -1.47942,5.20667 -1.26671,4.30099 -3.30832,9.90791 -5.87594,15.26946 -2.51682,5.41836 -5.50282,10.54053 -7.97992,14.28788 -0.59242,0.93834 -1.17873,1.76908 -1.70825,2.54901 -0.52947,0.77998 -0.9962,1.40146 -1.34918,1.92144 -0.76292,1.09066 -1.17268,1.66146 -1.17268,1.66146 z"
style="fill:#4d4d4d;stroke-width:1.14712"
id="path8135-3" />
<path
d="m 356.10647,127.6079 m -49.46141,19.67152 c 0,0 0.72591,-0.27766 1.95237,-0.79478 0.65079,-0.26493 1.37672,-0.54261 2.24021,-0.92089 0.86345,-0.37834 1.80217,-0.76913 2.87823,-1.261 4.1671,-1.86599 9.55933,-4.71274 14.64972,-7.97205 5.09039,-3.25933 9.94132,-7.01918 13.36584,-10.0734 1.6747,-1.52074 3.1622,-2.77783 4.08679,-3.70761 l 0.59983,-0.5655 6.16951,6.29764 c 2.1737,-6.78448 3.73355,-13.54222 4.54199,-20.17256 -6.1322,2.58569 -12.37908,4.49505 -18.50243,5.7651 l 6.0944,6.31035 -0.59983,0.56551 c -0.92458,0.92977 -2.33694,2.17412 -4.02437,3.61972 -3.36214,2.96633 -8.07551,6.62557 -13.10351,9.79702 -5.01523,3.2466 -10.26993,5.99269 -14.36187,7.84594 -1.00107,0.4789 -1.93965,0.86995 -2.80313,1.24823 -0.86347,0.37835 -1.58943,0.65594 -2.16506,0.90817 -1.22648,0.51704 -1.87724,0.78206 -1.87724,0.78206 z"
style="fill:#4d4d4d;stroke-width:1.14712"
id="path8135-3-6" />
<path
d="m 240.5982,127.5534 m 47.3974,24.22578 c 0,0 -0.69667,-0.34455 -1.86919,-0.97447 -0.62306,-0.32483 -1.31974,-0.66941 -2.14392,-1.12702 -0.82414,-0.45771 -1.72205,-0.93486 -2.74721,-1.52552 -3.97362,-2.24876 -9.07495,-5.5889 -13.83706,-9.31148 -4.7621,-3.72258 -9.23883,-7.92103 -12.36167,-11.2831 -1.52462,-1.67118 -2.88761,-3.06229 -3.72085,-4.07472 l -0.54412,-0.61928 -6.73323,5.69095 c -1.52751,-6.95851 -2.44639,-13.8328 -2.62912,-20.50974 5.86252,3.14967 11.90268,5.63677 17.87985,7.47578 l -6.65962,5.71066 0.54411,0.61929 c 0.83327,1.01242 2.12264,2.38381 3.66698,3.98137 3.06896,3.26872 7.4182,7.35408 12.12643,10.98332 4.68847,3.70286 9.66232,6.9299 13.56231,9.15892 0.95171,0.57072 1.84947,1.04811 2.67365,1.50574 0.82415,0.4577 1.52085,0.80219 2.07029,1.10732 1.17254,0.62984 1.79557,0.95475 1.79557,0.95475 z"
style="fill:#4d4d4d;stroke-width:1.14712"
id="path8135-3-6-7" />
<circle
opacity="0.14"
stroke="#000000"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="272.29675"
cy="41.742573"
r="22.619894"
id="circle6392-2" />
<ellipse
fill="#e8cae1"
stroke="#bcbec0"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="270.46667"
cy="43.076771"
rx="22.034267"
ry="22.619894"
id="ellipse6428-2"
style="fill:#ac9393" />
<circle
fill="#cee7cc"
stroke="#808285"
stroke-width="4.39221"
stroke-miterlimit="10"
cx="284.49127"
cy="153.09792"
r="22.619894"
id="circle6396"
style="fill:#ffffff" />
<g
aria-label="0"
id="text8350-8-5"
id="text8350-8"
style="font-size:28.9566px;line-height:1.25;word-spacing:0px;fill:#808285;stroke-width:0.723916"
transform="translate(-23.913622,179.83706)">
transform="matrix(1.1018216,0,0,1.1018216,-70.213478,188.75381)">
<path
d="m 324.72717,-32.891166 q 0,-3.95891 -0.74937,-5.570752 -0.73522,-1.625981 -2.48845,-1.625981 -1.75324,0 -2.5026,1.625981 -0.74937,1.611842 -0.74937,5.570752 0,4.001327 0.74937,5.641447 0.74936,1.64012 2.5026,1.64012 1.73909,0 2.48845,-1.64012 0.74937,-1.64012 0.74937,-5.641447 z m 5.4435,0.04242 q 0,5.245556 -2.26223,8.101627 -2.26224,2.841932 -6.41909,2.841932 -4.171,0 -6.43323,-2.841932 -2.26224,-2.856071 -2.26224,-8.101627 0,-5.259695 2.26224,-8.101627 2.26223,-2.856071 6.43323,-2.856071 4.15685,0 6.41909,2.856071 2.26223,2.841932 2.26223,8.101627 z"
style="font-weight:bold;-inkscape-font-specification:'sans-serif Bold'"
id="path16329-4" />
id="path16329" />
</g>
</svg>

Before

Width:  |  Height:  |  Size: 6.6 KiB

After

Width:  |  Height:  |  Size: 7.5 KiB

View File

@ -6,7 +6,7 @@
sodipodi:docname="initial_terminal_duality.svg"
width="595.29999"
height="200"
inkscape:version="1.2.2 (1:1.2.2+202305151914+b0a8486541)"
inkscape:version="1.3 (1:1.3+202307231459+0e150ed6c4)"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns="http://www.w3.org/2000/svg"
@ -23,15 +23,15 @@
inkscape:pagecheckerboard="0"
inkscape:deskcolor="#d1d1d1"
showgrid="false"
inkscape:zoom="0.74330708"
inkscape:cx="305.39195"
inkscape:cy="152.02331"
inkscape:zoom="1.4866142"
inkscape:cx="423.78178"
inkscape:cy="151.0143"
inkscape:window-width="1080"
inkscape:window-height="1864"
inkscape:window-x="0"
inkscape:window-y="0"
inkscape:window-maximized="1"
inkscape:current-layer="svg6444"
inkscape:current-layer="g6440"
inkscape:lockguides="false" />
<g
id="g6440"
@ -56,17 +56,6 @@
r="30.9"
id="circle6394"
transform="scale(1,-1)" />
<circle
fill="#cee7cc"
stroke="#808285"
stroke-width="6"
stroke-miterlimit="10"
cx="323.36987"
cy="-46.34343"
r="30.9"
id="circle6396"
transform="scale(1,-1)"
style="fill:#ffffff" />
<circle
opacity="0.14"
stroke="#000000"
@ -119,15 +108,21 @@
id="circle6436"
transform="scale(1,-1)" />
<path
fill="#d1d3d4"
d="m 263.06987,108.14343 1.2,-0.6 c 0.8,-0.4 1.8,-1 3.1,-1.7 2.5,-1.5 5.8,-3.6 8.9,-5.999998 3.1,-2.4 6.1,-4.9 8.2,-6.9 1.1,-1 1.9,-1.9 2.5,-2.5 0.4,-0.5 0.7,-0.7 0.7,-0.7 l -8.3,-8 c 7.8,-1.7 15.6,-4.6 23.3,-8.9 -0.1,8.7 -1.5,18 -4.4,27.199998 l -8.3,-7.999998 -0.7,0.7 -2.6,2.6 c -2.2,2.1 -5.3,4.699998 -8.5,7.199998 -3.2,2.4 -6.6,4.7 -9.2,6.2 -1.3,0.8 -2.4,1.4 -3.2,1.8 -0.8,0.4 -1.2,0.7 -1.2,0.7 z m 78.7,4.1 c -0.4,-3.9 -0.9,-7.8 -1.7,-11.7 l -0.2,-0.899998 -11.3,2.399998 c 0,0 0.6,-1.4 1.3,-3.499998 0.8,-2.2 1.7,-5.1 2.4,-8.2 1.5,-6.1 2.2,-12.7 2.2,-12.7 0,0 0.3,0.2 0.9,0.7 0.6,0.4 1.4,1.1 2.4,1.8 2,1.6 4.5,3.7 7,6.1 5,4.7 9.5,10.3 9.5,10.3 l -11.3,2.4 0.2,0.9 c 0.8,3.999998 1.4,7.999998 1.7,11.999998 z m 80.8,-1.1 c 0,0 -1,-0.2 -2.7,-0.6 -0.9,-0.2 -1.9,-0.4 -3.1,-0.7 -1.2,-0.3 -2.5,-0.6 -4,-1 -5.8,-1.5 -13.4,-4 -20.7,-7.1 -7.3,-3.099998 -14.4,-6.899998 -19.5,-10.099998 -2.5,-1.6 -4.7,-2.9 -6.1,-3.9 l -0.9,-0.6 -6.6,9.5 c -4.3,-8.3 -7.8,-16.7 -10.3,-25.1 8.5,2 17,3.1 25.2,3.4 l -6.5,9.5 0.9,0.6 c 1.4,1 3.5,2.3 6,3.8 5,3.1 11.9,6.8 19.1,9.8 7.2,3.099998 14.6,5.499998 20.3,6.999998 1.4,0.4 2.7,0.7 3.9,1 1.2,0.3 2.2,0.5 3,0.7 1.7,0.4 2.6,0.6 2.6,0.6 z"
id="path6438"
sodipodi:nodetypes="cscscccccccccccscccccccccccccccccccscscccccccccccsccc"
style="fill:#4d4d4d" />
<path
d="m 298.88788,92.44315 m 5.43934,72.51093 c 0,0 -0.0934,-1.05761 -0.19221,-2.87316 -0.0641,-0.95772 -0.15745,-2.01533 -0.20959,-3.30207 -0.0521,-1.28673 -0.13355,-2.67337 -0.17373,-4.2891 -0.20201,-6.23388 0.0673,-14.5591 1.02386,-22.76054 0.95658,-8.20143 2.67111,-16.4083 4.37262,-22.44129 0.86541,-2.96656 1.51907,-5.54545 2.10761,-7.23722 l 0.33551,-1.07499 -11.42533,-3.808034 c 7.03083,-6.729036 14.39615,-12.688225 22.05463,-17.648426 0.49411,9.077701 1.88729,17.891556 3.9917,26.17117 l -11.39602,-3.70813 -0.33552,1.07498 c -0.58852,1.69178 -1.27152,4.17078 -2.03703,7.108 -1.63092,5.90378 -3.30419,13.88152 -4.1902,21.95376 -0.98591,8.10153 -1.21391,16.19763 -1.04123,22.33159 0.0109,1.51588 0.0923,2.9025 0.14444,4.18923 0.0521,1.28674 0.14552,2.34435 0.18026,3.20217 0.0988,1.81554 0.16289,2.77327 0.16289,2.77327 z"
d="M 284.45043,142.33094 M 312.7708,75.357969 c 0,0 -0.42639,0.972345 -1.1001,2.66116 -0.36667,0.887067 -0.79306,1.85941 -1.25358,3.06205 -0.46041,1.202665 -0.98093,2.490483 -1.53491,4.008815 -2.18304,5.842636 -4.58763,13.817586 -6.30143,21.894806 -1.71377,8.07722 -2.71107,16.40175 -3.02618,22.66216 -0.12771,3.08757 -0.33222,5.74014 -0.31502,7.53128 l -0.0255,1.12584 -12.04316,-0.0418 c 4.51254,8.62261 9.58798,16.6226 15.26039,23.76961 3.36836,-8.44412 7.50444,-16.35093 12.14378,-23.5243 l -11.98347,-0.12705 0.0255,-1.12584 c -0.0172,-1.79114 0.12762,-4.35843 0.34062,-7.38628 0.34072,-6.11542 1.3039,-14.20965 3.04328,-22.1419 1.65407,-7.99193 4.0246,-15.736566 6.14793,-21.493887 0.49464,-1.432947 1.01478,-2.72089 1.47529,-3.923521 0.46042,-1.202675 0.88691,-2.174984 1.19385,-2.976761 0.6738,-1.688769 1.04038,-2.575882 1.04038,-2.575882 z"
style="fill:#4d4d4d;stroke-width:1.56703"
id="path8135" />
<path
d="M 355.19235,88.023165 M 312.30478,29.302832 c 0,0 0.63747,0.849043 1.67959,2.339008 0.55984,0.779682 1.19732,1.628735 1.9207,2.694167 0.72327,1.065477 1.52454,2.200109 2.4111,3.551487 3.46149,5.188468 7.62636,12.402052 11.14213,19.873191 3.51575,7.471144 6.39058,15.346914 8.1292,21.369307 0.83051,2.976518 1.63629,5.512 2.02921,7.259596 l 0.28232,1.090165 11.71437,-2.795175 c -2.42078,9.426146 -5.53195,18.374922 -9.41935,26.629872 -5.21039,-7.44989 -11.04526,-14.201122 -17.2023,-20.123247 l 11.63676,-2.864514 -0.28232,-1.090164 c -0.39293,-1.747596 -1.12109,-4.213712 -2.02097,-7.112585 -1.73039,-5.875389 -4.51933,-13.534767 -8.02685,-20.858926 -3.43812,-7.401772 -7.51715,-14.398941 -10.901,-19.518007 -0.80927,-1.281834 -1.6102,-2.416669 -2.33356,-3.482094 -0.72329,-1.065494 -1.36086,-1.914475 -1.84305,-2.6248 -1.04219,-1.489895 -1.60195,-2.269647 -1.60195,-2.269647 z"
style="fill:#4d4d4d;stroke-width:1.56703"
id="path8135-3" />
<path
d="M 421.20009,81.164172 M 353.63312,54.291805 c 0,0 0.99164,0.37931 2.66705,1.085715 0.88901,0.361928 1.88068,0.741242 3.06025,1.257983 1.17951,0.51684 2.46186,1.050689 3.93181,1.722602 5.69249,2.54905 13.05857,6.437852 20.01232,10.890257 6.95374,4.452419 13.58037,9.588581 18.25846,13.760808 2.28774,2.077417 4.31974,3.794668 5.58277,5.064793 l 0.81939,0.772503 8.4279,-8.602907 c 2.96939,9.267961 5.10023,18.49941 6.2046,27.556801 -8.37692,-3.53219 -16.91048,-6.14049 -25.27533,-7.875437 l 8.32529,-8.620285 -0.81939,-0.772501 c -1.26304,-1.270121 -3.1924,-2.969981 -5.49752,-4.944737 -4.59286,-4.052172 -11.03158,-9.05089 -17.9001,-13.383269 -6.85108,-4.435028 -14.02929,-8.186338 -19.6191,-10.717978 -1.3675,-0.654195 -2.64967,-1.188397 -3.82923,-1.705143 -1.17953,-0.516843 -2.17123,-0.896047 -2.95758,-1.240608 -1.67544,-0.706307 -2.56441,-1.068338 -2.56441,-1.068338 z"
style="fill:#4d4d4d;stroke-width:1.56703"
id="path8135-3-6" />
<path
d="m 263.40955,81.238622 m 64.7474,-33.093728 c 0,0 -0.95168,0.470684 -2.55341,1.331178 -0.85113,0.443749 -1.80283,0.914439 -2.92871,1.539582 -1.12581,0.625235 -2.35241,1.277053 -3.75283,2.08393 -5.42819,3.071939 -12.39688,7.634756 -18.90218,12.719999 -6.50528,5.085256 -12.62074,10.820545 -16.8867,15.413318 -2.08272,2.282914 -3.94463,4.183254 -5.0829,5.566288 l -0.74329,0.845979 -9.19795,-7.774148 c -2.08666,9.505695 -3.34189,18.89636 -3.59152,28.01741 8.00853,-4.30262 16.2597,-7.70013 24.42485,-10.21232 l -9.09741,-7.801074 0.74328,-0.845977 c 1.13829,-1.383031 2.89964,-3.256426 5.0093,-5.438763 4.19237,-4.465249 10.13365,-10.046069 16.56535,-15.003819 6.40471,-5.058309 13.19926,-9.466612 18.52686,-12.511583 1.30008,-0.779624 2.52647,-1.431777 3.65234,-2.056923 1.12583,-0.62524 2.07757,-1.095824 2.82812,-1.512649 1.60177,-0.860401 2.45285,-1.304248 2.45285,-1.304248 z"
style="fill:#4d4d4d;stroke-width:1.56703"
id="path8135-3-6-7" />
<circle
opacity="0.14"
stroke="#000000"
@ -150,6 +145,17 @@
id="ellipse6428-2"
transform="scale(1,-1)"
style="fill:#ac9393" />
<circle
fill="#cee7cc"
stroke="#808285"
stroke-width="6"
stroke-miterlimit="10"
cx="323.36987"
cy="-46.34343"
r="30.9"
id="circle6396"
transform="scale(1,-1)"
style="fill:#ffffff" />
</g>
<g
aria-label="0"

Before

Width:  |  Height:  |  Size: 22 KiB

After

Width:  |  Height:  |  Size: 23 KiB

View File

@ -20,7 +20,7 @@ The category of sets
We began by reviewing the mother of all categories --- *the category of sets*.
![The category of sets](../06_functors/category_sets.svg)
![The category of sets](../10_functors/category_sets.svg)
We also saw that it contains within itself many other categories, such as the category of types in programming languages.
@ -29,21 +29,21 @@ Special types of categories
We also learned about other algebraic objects that turned out to be just *special types of categories*, like categories that have just one *object* (monoids, groups) and categories that have only one *morphism* between any two objects (preorders, partial orders).
![Types of categories](../06_functors/category_types.svg)
![Types of categories](../10_functors/category_types.svg)
Other categories
---
We also defined a lot of *categories based on different concepts*, like the ones based on logics/programming languages, but also some "less-serious ones", as for example the color-mixing partial order/category.
![Category of colors](../06_functors/category_color_mixing.svg)
![Category of colors](../10_functors/category_color_mixing.svg)
Finite categories
---
And most importantly, we saw some categories that are *completely made up*, such as my soccer player hierarchy. Those are formally called *finite categories*.
![Finite categories](../06_functors/finite_categories.svg)
![Finite categories](../10_functors/finite_categories.svg)
Although they are not useful by themselves, the idea behind them is important --- we can draw any combination of points and arrows and call it a category, in the same way that we can construct a set out of every combination of objects.
@ -54,21 +54,21 @@ For future reference, let's see some important finite categories.
The simplest category is $0$ (enjoy the minimalism of this diagram).
![The finite category 0](../06_functors/finite_zero.svg)
![The finite category 0](../10_functors/finite_zero.svg)
The next simplest category is $1$ --- it is comprised of one object no morphism besides its identity morphism (which we don't draw, as usual)
![the finite category 1](../06_functors/finite_one.svg)
![the finite category 1](../10_functors/finite_one.svg)
If we increment the number of objects to two, we see a couple of more interesting categories, like for example the category $2$ containing two objects and one morphism.
![the finite category 2](../06_functors/finite_two.svg)
![the finite category 2](../10_functors/finite_two.svg)
**Task:** There are just two more categories that have 2 objects and at most one morphism between two objects, draw them.
And finally the category $3$ has 3 objects and also 3 morphisms (one of which is the composition of the other two).
![the finite category 3](../06_functors/finite_three.svg)
![the finite category 3](../10_functors/finite_three.svg)
Categorical isomorphisms
===
@ -80,7 +80,7 @@ Set isomorphisms
In chapter 1 we talked about *set isomorphisms*, which establish an equivalence between two sets. In case you have forgotten, a set isomorphism is a *two-way function* between two sets.
![Set isomorphism](../06_functors/set_isomorphism.svg)
![Set isomorphism](../10_functors/set_isomorphism.svg)
It can alternatively be viewed as two "twin" functions such that each of which equals identity, when composed with the other one.
@ -90,7 +90,7 @@ Order isomorphisms
Then, in chapter 4, we encountered *order isomorphisms* and we saw that they are like set isomorphisms, but with one extra condition --- aside from just being there, the functions that define the isomorphism have to preserve the order of the object e.g. the greatest object of one order should be connected to the greatest object of the other one, the least object of one order should be connected to the least object of the other one, and same for all objects that are in between.
![Order isomorphism](../06_functors/order_isomorphism.svg)
![Order isomorphism](../10_functors/order_isomorphism.svg)
Or more formally put, for any $a$ and $b$ if we have $a ≤ b$ we should also have $F(a) ≤ F(b)$ (and vise versa).
@ -101,11 +101,11 @@ Now, we will generalize the definition of an order isomorphism, so it also appli
> Given two categories, an isomorphism between them is an invertible mapping between the underlying sets of objects, *and* an invertible mapping between the morphisms that connect them, which maps each morphism from one category to a morphism *with the same signature*.
![Category isomorphism](../06_functors/category_isomorphism.svg)
![Category isomorphism](../10_functors/category_isomorphism.svg)
After examining this definition closely, we realize that, although it *sounds* a bit more complex (and *looks* a bit messier) than the one we have for orders *it is actually the same thing*. It is just that the so-called "morphism mapping" between categories that have just one morphism for any two objects are trivial, and so we can omit them.
![Order isomorphism](../06_functors/category_order_isomorphism_2.svg)
![Order isomorphism](../10_functors/category_order_isomorphism_2.svg)
**Question:** What are the morphism functions for orders?
@ -115,7 +115,7 @@ We always map the single morphism of the source category to the single morphism
However, when we can have more than one morphism between two given objects, we need to make sure that each morphism in the source category has a corresponding morphism in the target one, and for this reason we need not only a mapping between the categories' objects, but one between their morphisms.
![Category isomorphism](../06_functors/category_order_isomorphism.svg)
![Category isomorphism](../10_functors/category_order_isomorphism.svg)
By the way, what we just did (taking a concept that is defined for a more narrow structure (orders) and redefining it for a more broad one (categories)) is called *generalizing* of the concept.
@ -142,13 +142,13 @@ The logician Rudolf Carnap coined the term "functor" as part of his project to f
In other words, a functor is a phrase that *acts as a function*, only not a function between sets, but one between *linguistic concepts* (such as times and temperature).
![Functor, as envisioned by Rudolf Carnap.](../06_functors/functor_carnap.svg)
![Functor, as envisioned by Rudolf Carnap.](../10_functors/functor_carnap.svg)
Later, one of the inventors of category theory Sanders Mac Lane borrowed the word, to describe a something that *acts as function between categories*, which he defined in the following way:
> A functor between two categories (let's call them $A$ and $B$) consists of two mappings --- a mapping that maps each *object* in $A$ to an object in $B$ and a mapping that maps each *morphism* between any objects in $A$ to a morphism between objects in $B$, in a way that *preserves the structure* of the category.
![Functor](../06_functors/functor.svg)
![Functor](../10_functors/functor.svg)
Now let's unpack this definition by going through each of its components.
@ -157,7 +157,7 @@ Object mapping
In the definition above we use the word "mapping" to avoid misusing the word "function" for something that isn't exactly a function. But in this particular case, calling the mapping a function would barely be a misuse --- if we forget about morphisms and treat the source and target categories as sets, the object mapping is nothing but a regular old function.
![Functor for objects](../06_functors/functor_objects.svg)
![Functor for objects](../10_functors/functor_objects.svg)
A more formal definition of object mapping involves the concept of an *underlying set* of a category: Given a category $A$, the underlying set of $A$ is a set that has the objects of $A$ as elements. Utilizing this concept, we say that the object mapping of a functor between two categories is *a function between their underlying sets*. The definition of a function is still the same:
@ -168,11 +168,11 @@ Morphism mapping
The second mapping that forms the functor is a mapping between the categories' morphisms. This mapping resembles a function as well, but with the added requirement that each morphism in $A$ a given source and target must be mapped to a morphism with the corresponding source and target in $B$, as per the object mapping.
![Functor for morphisms](../06_functors/functor_morphisms.svg)
![Functor for morphisms](../10_functors/functor_morphisms.svg)
A more formal definition of a morphism mapping involves the concept of the *homomorphism set*: this is a set that contains all morphisms that go between given two objects in a given category. When utilizing this concept, we say that a mapping between the morphisms of two categories consists of a *set of functions between their respective homomorphism sets*.
![Functor for morphisms](../06_functors/functor_morphisms_formal.svg)
![Functor for morphisms](../10_functors/functor_morphisms_formal.svg)
Note how the concepts of *homomorphism set* and of *underlying set* allowed us to "escape" to set theory when defining categorical concepts and define everything using functions.
@ -188,11 +188,11 @@ So these are the two mappings (one between objects and one between morphisms) th
So this definition translates to the following two *functor laws*
1. Functions between morphisms should *preserve identities* i.e. all identity morphisms should be mapped to other identity morphisms.
![Functor](../06_functors/functor_laws_identity.svg)
![Functor](../10_functors/functor_laws_identity.svg)
2. Functors should also *preserve composition* i.e. for any two morphisms $f$ and $g$, the morphism that corresponds to their composition $F(g•f)$ in the source category should be mapped to the morphism that corresponds to the composition of their counterparts in the target directory, so $F(g•f) = F(g)•F(f)$.
![Functor](../06_functors/functor_laws_composition.svg)
![Functor](../10_functors/functor_laws_composition.svg)
And these laws conclude the definition of functors --- a simple but, as we will see shortly, very powerful concept.
@ -211,7 +211,7 @@ For example, in chapter 1 we presented the following definition of functional co
> The composition of two functions $f$ and $g$ is a third function $h$ defined in such a way that this diagram commutes.
![Functional composition - general definition](../06_functors/functions_compose_general.svg)
![Functional composition - general definition](../10_functors/functions_compose_general.svg)
We all see the benefit of defining stuff by means of diagrams as opposed to writing lengthy definitions like
@ -221,13 +221,13 @@ However, it (defining stuff by means of diagrams) presents a problem --- definit
So how can we do that? One key observation is that diagrams look as finite categories, as, for example, the above definition looks in the same way as the category $3$.
![the finite category 3](../06_functors/finite_three.svg)
![the finite category 3](../10_functors/finite_three.svg)
However, this is only part of the story as finite categories are just structures, whereas diagrams are *signs*. They are "something by knowing which we know something more.", as Peirce famously put it (or "...which can be used in order to tell a lie", in the words of Umberto Eco).
For this reason, aside from a finite category that encodes the diagram's structure, the definition of a diagram must also include a way for "interpreting" this category in some other context i.e. they must include *functors*.
![diagram as a functor](../06_functors/diagram_functor.svg)
![diagram as a functor](../10_functors/diagram_functor.svg)
This is how the concept of functors allows us to formalize the notion of diagrams:
@ -250,11 +250,11 @@ Maps are functors
Functors are sometimes called "maps" for a good reason --- maps, like all other diagrams, are functors. If we consider some space, containing cities and roads that we travel by, as a category, in which the cities are objects and roads between them are morphisms, then a road map can be viewed as category that represent some region of that space, together with a functor that maps the objects in the map to real-world objects.
![A map and a preorder of city pathways](../06_functors/preorder_map_functor.svg)
![A map and a preorder of city pathways](../10_functors/preorder_map_functor.svg)
In maps, morphisms that are a result of composition are often not displayed, but we use them all the time --- they are called *routes*. And the law of preserving composition tells us that every route that we create on a map corresponds to a real-world route.
![A map and a preorder of city pathways](../06_functors/preorder_map_functor_route.svg)
![A map and a preorder of city pathways](../10_functors/preorder_map_functor_route.svg)
Notice that in order to be a functor, a map does not have to list *all* roads that exist in real life, and *all* traveling options ("the map is not the territory"), the only requirement is that *the roads that it lists should be actual* --- this is a characteristic shared by all many-to-one relationships (i.e. functions).
@ -265,11 +265,11 @@ We saw that, aside from being a category-theoretic concept, functors are connect
My thesis is that to perceive the world around us, we are going through a bunch of functors that go from more raw "low-level" mental models to more abstract "high-level" ones. For example, our brain creates a functor between the category of raw sensory data that we receive from our senses, to a category containing some basic model of how the world works (one that tells us where are we in space, how many objects are we seeing etc.). Then we are connecting this model to another, more abstract model, which provides us with a higher-level view of the situation that we are in, and so on.
![Perception is functorial](../06_functors/chain.svg)
![Perception is functorial](../10_functors/chain.svg)
You can view this as a progression from simpler to more abstract from categories with less morphisms to categories with more morphisms --- we start with the category of pieces of sensory data that have no connections between one another, and proceed to another category where some of these pieces of data are connected. Then, we transfer this structure in another category with even more connections.
![Perception is functorial](../06_functors/logic_thought.svg)
![Perception is functorial](../10_functors/logic_thought.svg)
All this is, of course, just a speculation, but we might convince yourself that there is some basis for it, especially after we see how significant functors are for the mathematical structures that we saw before.
@ -282,22 +282,22 @@ Hey, do you know that in group theory, there is this cool thing called *group ho
So, for example, If the time of the day right now is 00:00 o'clock (or 12 PM) then what would the time be after $n$ hours? The answer to this question can be expressed as a function with the set of integers as source and target.
![Group homomorphism as a function](../06_functors/group_homomorphism_function.svg)
![Group homomorphism as a function](../10_functors/group_homomorphism_function.svg)
This function is interesting --- it preserves the operation of (modular) addition: if, 13 hours from now the time will be 1 o'clock and if 14 hours from now it will be 2 o'clock, then the time after (13 + 14) hours will be (1 + 2) o'clock.
![Group homomorphism](../06_functors/group_homomorphism.svg)
![Group homomorphism](../10_functors/group_homomorphism.svg)
Or to put it formally, if we call it (the function) $F$, then we have the following equation: $F(a + b) = F(a) + F(b)$ (where $+$ in the right-hand side of the equation means modular addition). Because this equation holds, the $F$ function is a *group homomorphism* between the group of integers under addition and the group of modulo arithmetic with base 11 under modular addition (where you can replace 11 with any other number).
The groups don't have to be so similar for there to be a homomorphism between them. Take, for example, the function that maps any number $n$ to 2 to the *power of $n$,* so $n \to 2ⁿ$ (here, again, you can replace 2 with any other number). This function gives a rise to a group homomorphism between the group of integers under addition and the integers under multiplication, or $F(a + b) = F(a) \times F(b)$.
![Group homomorphism between different groups](../06_functors/group_homomorphism_addition_multiplication.svg)
![Group homomorphism between different groups](../10_functors/group_homomorphism_addition_multiplication.svg)
Wait, what were we talking about, again? Oh yeah --- group homomorphisms are functors. To see why, we switch to the category-theoretic representation of groups and revisit our first example and (to make the diagram simpler, we use $mod2$ instead of $mod11$).
![Group homomorphism as a functor](../06_functors/group_homomorphism_functor.svg)
![Group homomorphism as a functor](../10_functors/group_homomorphism_functor.svg)
It seems that when we view groups/monoid as one-object categories, a group/monoid homomorphism is just a functor between these categories. Let's see if that is the case.
@ -330,11 +330,11 @@ And now let's talk about a concept that is completely unrelated to functors, nud
For example, the function that maps the current time to the distance traveled by some object is monotonic because the distance traveled increases (or stays the same) as time increases.
![A monotonic function](../06_functors/monotone_map.svg)
![A monotonic function](../10_functors/monotone_map.svg)
If we plot this or any other monotonic function on a line graph, we see that it goes just one direction (i.e. just up or just down).
![A monotonic function, represented as a line-graph](../06_functors/monotone_map_plot.svg)
![A monotonic function, represented as a line-graph](../10_functors/monotone_map_plot.svg)
Now we are about to prove that monotonic functions are functors too, ready?
@ -381,13 +381,13 @@ In calculus, there is this concept of *linear functions* (also called "degree on
But if we start plotting some such functions we will realize that there is another way to describe them --- their graphs are always comprised of straight lines.
![Linear functions](../06_functors/linear_functions.svg)
![Linear functions](../10_functors/linear_functions.svg)
**Question:** Why is that?
Another interesting property of these functions is that most of them *preserve* addition, that is for any $x$ and $y$, you have $f(x) + f(y) = f(x + y)$. We already know that this equation is equivalent to the second functor law. So linear functions are just *functors between the group of natural numbers under addition and itself.* As we will see later, they are example of functors in the *category of vector spaces*.
![Linear functions](../06_functors/linear_function_functor.svg)
![Linear functions](../10_functors/linear_function_functor.svg)
**Question:** Are the two formulas we presented to define linear functions completely equivalent?
@ -416,7 +416,7 @@ And if we view that natural numbers as an order, linear functions are also funct
Note, however, that not all functions that are plotted straight lines preserve addition --- functions of the form $f(x) = x * a + b$ in which $b$ is non-zero, are also straight lines (and are also called linear) but they don't preserve addition.
![Linear functions](../06_functors/linear_function_non_functor.svg)
![Linear functions](../10_functors/linear_function_non_functor.svg)
For those, the above formula looks like this: $f(x) + b + f(y) + b = f(x + y) + b$.
@ -433,7 +433,7 @@ Functors in programming. The list functor
Types in programming language form a category, associated to that category are some functors that programmers use every day, such as the list functor, that we will use as an example. The list functor is an example of a functor that maps from the realm of simple (primitive) types and functions to the realm of more complex (generic) types and functions.
![A functor in programming](../06_functors/functor_programming.svg)
![A functor in programming](../10_functors/functor_programming.svg)
But let's start with the basics: defining the concept of a functor in programming context is as simple as changing the terms we use, according to the table in chapter 2 (the one that compares category theory with programming languages), and (perhaps more importantly) changing the font we use in our formulas from "modern" to "monospaced".
@ -446,7 +446,7 @@ Type mapping
The first component of a functor is a mapping that converts one type (let's call it `A`) to another type (`B`). So it is *like a function, but between types*. Such constructions are supported by almost all programming languages that have static type checking in the first place --- they go by the name of *generic types*. A generic type is nothing but a function that maps one (concrete) type to another (this is why generic types are sometimes called *type-level functions*).
![A functor in programming - type mapping](../06_functors/functor_programming_objects.svg)
![A functor in programming - type mapping](../10_functors/functor_programming_objects.svg)
Note that although the diagrams they look similar, a *type-level* function is completely different from a *value-level* function. A value-level function from `String`, to `List<String>` (or in mathy Haskell/ML-inspired notation $string \to List\ string$ is) converts a *value* of type `String` (such as `"foo"`) and to a value of type `List<String>`. You even have (as we will see later) a value-level functions with signature $a \to List\ a$ that can convert any value to a list of elements containing that value, but this is different from the *type-level* function `List<A>` as that one converts a *type* $a$ to a *type* $List\ a$ (e.g. the type `string` to the type $List\ string$, $number$ to $List\ number$ etc.).
@ -455,7 +455,7 @@ Function mapping
So the type mapping of a functor is simply a generic type in a programming language (we can also have functors between two generic types, but we will review those later). So what is the *function mapping* --- this is a mapping that convert any function operating on simple types, like $string \to number$ to a function between their more complex counterparts e.g. $List\ string \to List\ number$.
![A functor in programming - function mapping](../06_functors/functor_programming_morphisms.svg)
![A functor in programming - function mapping](../10_functors/functor_programming_morphisms.svg)
In programming languages, this mapping is represented by a higher-order function called `map` with a signature (using Haskell notation), $(a \to b) \to (Fa \to Fb)$, where $F$ represents the generic type.
@ -514,11 +514,11 @@ Endofunctors
To understand what pointed endofunctors are, we have to first understand what are *endofunctors*, and we already saw some examples of those in the last section. Let me explain: from the way the diagrams there looked like, we might get the impression that different type families belong to different categories.
![A functor in programming](../06_functors/functor_programming.svg)
![A functor in programming](../10_functors/functor_programming.svg)
But that is not the case - all type families from a given programming language are actually part of one and the same category - the category of *types*.
![A functor in programming](../06_functors/functor_programming_endo.svg)
![A functor in programming](../10_functors/functor_programming_endo.svg)
Wait, so this is permitted? Yes, these are exactly what we call *endofunctors* i.e. ones that have one and the same category as source and target.
@ -527,7 +527,7 @@ The identity functor
So, what are some examples of endofunctors? I want to focus on one that will probably look familiar to you - it is the *identity functor* of each category, the one that maps each object and morphism to itself.
![Identity functor](../06_functors/identity_functor.svg)
![Identity functor](../10_functors/identity_functor.svg)
And it might be familiar, because an identity functor is similar to an identity morphism - it allow us to talk about value-related stuff without actually involving values.
@ -536,19 +536,19 @@ Pointed functors
Finally, the identity functor, together with all other functors to which the identity functor can be *naturally transformed* are called *pointed functors* (i.e. a functor is pointed if there exist a morphism from the identity functor to it). As we will see shortly, the list functor is a pointed functor.
![Pointed functor](../06_functors/pointed_functor.svg)
![Pointed functor](../10_functors/pointed_functor.svg)
We still haven't discussed what does it mean for one functor to be naturally transformed to another one (although the commuting diagram above can give you some idea). This is a complex concept and we have a whole chapter about it (the next one).
However if we concentrate solely on the category of types in programming languages, then *a natural transformation is just a function* that translates each value of what we called the "simple types" to a value of the functor's generic type i.e. $a \to F\ a$), in a way that this diagram commutes.
![Pointed functor in Set](../06_functors/pointed_functor_set.svg)
![Pointed functor in Set](../10_functors/pointed_functor_set.svg)
What does it take for this diagram to commute? It means that when you have two equivalent routes for reaching from the top-left diagonal to the bottom-right diagonal i.e. that applying any function between any two types ($a \to b$), followed by the lifting function ($b \to F\ b$), is equivalent to applying the lifting function first ($a \to F\ a$), and then the mapped version of the original function second ($F\ a \to F\ b$).
The list functor is pointed, because such a function exist for the list functor - it is the function $a \to [\ a\ ]$ that puts every value in a "singleton" list. So, for every function between simple types, such as the function $length:\ string \to number$ we have a square like this one.
![Pointed functor in Set](../06_functors/pointed_functor_set_internal.svg)
![Pointed functor in Set](../10_functors/pointed_functor_set_internal.svg)
And the fact that the square commutes is expressed by the following equality:
@ -562,7 +562,7 @@ The category of small categories
Ha, I got you this time (or at least I *hope* I did) - you probably thought that I won't introduce another category in this chapter, but this is exactly what I am going to do now. And (surprise again) the new category won't be the category of functors (don't worry, we will introduce that in the next chapter). Instead, we will examine the category of (small) categories, that has all the categories that we saw so far as objects and functors as its morphisms, like $Set$ - the category of sets, $Mon$, the category of monoids, $Ord$, the category of orders etc.
![The category of categories](../06_functors/category_of_categories.svg)
![The category of categories](../10_functors/category_of_categories.svg)
We haven't yet mentioned the fact that functors compose (and in an associative way at that), but since a functor is just a bunch of functions, it is no wonder that it does.

View File

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

View File

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 9.8 KiB

After

Width:  |  Height:  |  Size: 9.8 KiB

View File

Before

Width:  |  Height:  |  Size: 38 KiB

After

Width:  |  Height:  |  Size: 38 KiB

View File

Before

Width:  |  Height:  |  Size: 11 KiB

After

Width:  |  Height:  |  Size: 11 KiB

View File

Before

Width:  |  Height:  |  Size: 5.2 KiB

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

Before

Width:  |  Height:  |  Size: 6.8 KiB

After

Width:  |  Height:  |  Size: 6.8 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 44 KiB

After

Width:  |  Height:  |  Size: 44 KiB

View File

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

View File

Before

Width:  |  Height:  |  Size: 2.1 KiB

After

Width:  |  Height:  |  Size: 2.1 KiB

View File

Before

Width:  |  Height:  |  Size: 6.4 KiB

After

Width:  |  Height:  |  Size: 6.4 KiB

View File

Before

Width:  |  Height:  |  Size: 3.7 KiB

After

Width:  |  Height:  |  Size: 3.7 KiB

View File

Before

Width:  |  Height:  |  Size: 1.5 KiB

After

Width:  |  Height:  |  Size: 1.5 KiB

View File

Before

Width:  |  Height:  |  Size: 5.2 KiB

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

Before

Width:  |  Height:  |  Size: 22 KiB

After

Width:  |  Height:  |  Size: 22 KiB

View File

Before

Width:  |  Height:  |  Size: 5.2 KiB

After

Width:  |  Height:  |  Size: 5.2 KiB

View File

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

View File

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

View File

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 19 KiB

View File

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

View File

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

View File

Before

Width:  |  Height:  |  Size: 22 KiB

After

Width:  |  Height:  |  Size: 22 KiB

View File

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

View File

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

View File

Before

Width:  |  Height:  |  Size: 24 KiB

After

Width:  |  Height:  |  Size: 24 KiB

View File

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View File

Before

Width:  |  Height:  |  Size: 22 KiB

After

Width:  |  Height:  |  Size: 22 KiB

View File

Before

Width:  |  Height:  |  Size: 79 KiB

After

Width:  |  Height:  |  Size: 79 KiB

View File

Before

Width:  |  Height:  |  Size: 17 KiB

After

Width:  |  Height:  |  Size: 17 KiB

View File

Before

Width:  |  Height:  |  Size: 30 KiB

After

Width:  |  Height:  |  Size: 30 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 21 KiB

View File

Before

Width:  |  Height:  |  Size: 39 KiB

After

Width:  |  Height:  |  Size: 39 KiB

View File

Before

Width:  |  Height:  |  Size: 26 KiB

After

Width:  |  Height:  |  Size: 26 KiB

View File

Before

Width:  |  Height:  |  Size: 66 KiB

After

Width:  |  Height:  |  Size: 66 KiB

View File

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View File

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

Before

Width:  |  Height:  |  Size: 12 KiB

After

Width:  |  Height:  |  Size: 12 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 21 KiB

After

Width:  |  Height:  |  Size: 21 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 27 KiB

After

Width:  |  Height:  |  Size: 27 KiB

View File

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View File

Before

Width:  |  Height:  |  Size: 31 KiB

After

Width:  |  Height:  |  Size: 31 KiB

View File

Before

Width:  |  Height:  |  Size: 6.5 KiB

After

Width:  |  Height:  |  Size: 6.5 KiB

View File

Before

Width:  |  Height:  |  Size: 35 KiB

After

Width:  |  Height:  |  Size: 35 KiB

View File

Before

Width:  |  Height:  |  Size: 43 KiB

After

Width:  |  Height:  |  Size: 43 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB

View File

Before

Width:  |  Height:  |  Size: 15 KiB

After

Width:  |  Height:  |  Size: 15 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

Before

Width:  |  Height:  |  Size: 34 KiB

After

Width:  |  Height:  |  Size: 34 KiB

View File

Before

Width:  |  Height:  |  Size: 18 KiB

After

Width:  |  Height:  |  Size: 18 KiB

View File

Before

Width:  |  Height:  |  Size: 10 KiB

After

Width:  |  Height:  |  Size: 10 KiB

View File

Before

Width:  |  Height:  |  Size: 14 KiB

After

Width:  |  Height:  |  Size: 14 KiB

View File

Before

Width:  |  Height:  |  Size: 16 KiB

After

Width:  |  Height:  |  Size: 16 KiB

View File

Before

Width:  |  Height:  |  Size: 13 KiB

After

Width:  |  Height:  |  Size: 13 KiB