I like how string diagrams show the monad from an adjunction R∘L as just a "fat" picture of a "plain" monad T, and that this fatness doesn't really matter, confirming their equivalence. I guess, according to category theory, a person remains the same person no matter how much weight s/he gains or loses :D, although topology could tell you the same thing.
@@BartoszMilewski More precicely, the set of all lists with generators from a set s with concatenation as multiplication is a free monoid L s. R forgets the multiplication structure and just return the objects of a monoid. So R (L s) is an endofunctor going from a set s to the set of all lists that can be generated from that set, but with multiplication structure forgotten. This should be the unit of some monad, and I'm pretty sure that monad is the list monad.
According to Dan Marsden, Category Theory Using String Diagrams - "functors compose from left to right" (left acts first), so on R∘L diagram L-string should be left.
This is purely a matter of convention. I took the convention from more general monoidal categories, where there is no reason to reverse the order of the tensor product. In the particular monoidal category of endofunctors, the tensor product is composition: f ⊗ g = f ∘ g. Changing the order would be confusing.
Looks like it comes from mathematical habit of writing parameters/arguments at the right of a function. Function is a "code block" that takes input from the right and put result to the left (where it's took by next block). Functions compose from right to left (so do functors). So it's convenient to keep this direction in diagrams. On the other hand the code is read by human from top to bottom and from left to right. And for better understanding it should be executed in same direction - first acts top, then acts bottom. Being on same "hight" (line of code) first acts left, then acts right. This is the direction of "data flow through code" and human reader "follow the data and it's transformation". From this perspective maybe on diagrams functors should "be executed" (and composed) from left to right; and natural transformations from top to bottom? :) And a f∘g composition meaning should be changed to "first f, then g".
Some people find it more convenient to compose haskell functions from left to right: facebook.com/groups/programming.haskell/permalink/2300452119965776/
But going further "left-to-right hole" things become weird. We should reverse a lot of common things. 2 = x //assignment x * x = x square //function definition [1,2,3] (square map) . sum . sqrt //function composition
16:22 - that's the sound of a jaw dropping on a table
I like how string diagrams show the monad from an adjunction R∘L as just a "fat" picture of a "plain" monad T, and that this fatness doesn't really matter, confirming their equivalence. I guess, according to category theory, a person remains the same person no matter how much weight s/he gains or loses :D, although topology could tell you the same thing.
Oh the noise stopped! Also great lecture!
Hah. I tried using the adjoint functors between Set and Mon to understand eta, and realised it was the list monad.
I must try this for other adjunctions from Set.
@@JohanTE When you go to Set, it's usually a forgetful functor, so the adjoint generates free structure. A list is a free monoid.
@@BartoszMilewski More precicely, the set of all lists with generators from a set s with concatenation as multiplication is a free monoid L s. R forgets the multiplication structure and just return the objects of a monoid. So R (L s) is an endofunctor going from a set s to the set of all lists that can be generated from that set, but with multiplication structure forgotten. This should be the unit of some monad, and I'm pretty sure that monad is the list monad.
According to Dan Marsden, Category Theory Using String Diagrams - "functors compose from left to right" (left acts first), so on R∘L diagram L-string should be left.
Bartosz uses the opposite direction. See here th-cam.com/video/eOdBTqY3-Og/w-d-xo.htmlm58s
This is purely a matter of convention. I took the convention from more general monoidal categories, where there is no reason to reverse the order of the tensor product. In the particular monoidal category of endofunctors, the tensor product is composition: f ⊗ g = f ∘ g. Changing the order would be confusing.
Looks like it comes from mathematical habit of writing parameters/arguments at the right of a function. Function is a "code block" that takes input from the right and put result to the left (where it's took by next block). Functions compose from right to left (so do functors). So it's convenient to keep this direction in diagrams.
On the other hand the code is read by human from top to bottom and from left to right. And for better understanding it should be executed in same direction - first acts top, then acts bottom. Being on same "hight" (line of code) first acts left, then acts right. This is the direction of "data flow through code" and human reader "follow the data and it's transformation". From this perspective maybe on diagrams functors should "be executed" (and composed) from left to right; and natural transformations from top to bottom? :)
And a f∘g composition meaning should be changed to "first f, then g".
Some people find it more convenient to compose haskell functions from left to right: facebook.com/groups/programming.haskell/permalink/2300452119965776/
But going further "left-to-right hole" things become weird. We should reverse a lot of common things.
2 = x //assignment
x * x = x square //function definition
[1,2,3] (square map) . sum . sqrt //function composition