Brian Lonsdorf

SFJS Co-Organizer

In category theory, you need a composition and an identity to form a category. Brian introduces category theory and defines various category laws like left identity, right identity, and associativity.

Brian Lonsdorf: The voyage so I love how big it sounds okay, I'm going to start-

Speaker 2: I can fall in love with that.

Brian Lonsdorf: The voyage. So the point, the point is that If I add one to one, I get another number. That's two. And everybody should know exactly what that does even though you don't know what the implementation is, because it's bigger than what I came up with.

Somebody else came up with it a long time ago. And it's got some properties and laws with it. So we know it's associative. That means it doesn't matter how it's grouped. It's always just going to end up with the same result. It's commutative. We've got identity and down at the bottom, we even know how it works with other functions.

This is incredible. Could you imagine if all of your functions had this book of, you can do this with it? And you can always guarantee, we've got these theorems and formulas. You're basically, you don't have to know it. You can just add without that. But, if you want to, boom, an ocean of knowledge, right?

So that's pretty beneficial. And with other, another cool thing about add, I'm basically regurgitating my fluent talk right now, but I'll get in other stuff. This, right here is, you've got an intuition behind it. And it's polymorphic. So we can add strings together, we can add floats together.

I mean, floats are still numbers but in other languages it still works, big nums, whatever. Down at the bottom we're adding arrays together. There's an intuition behind add, and those laws will still hold. Maybe not for this particular crazy add. But when you work with these other functions that have these laws with them, they'll always hold for every type.

Which is really cool. So you have an intuition and laws attached. Hey, guess what compose is? It's like add. It's got laws and it's got properties, and it's actually polymorphic. You can use it on other things besides just functions. It's incredible. It's just like add. So we're going to go into category theory.

Probably weeping at this point, like, what I did sign up for? But if nobody understands this type signature, because I just threw it up on the screen. The (b -> c) is a function that takes any variable, any type b to any type c. Second one's any function that takes a to b or returning a function a to c.

So basically it runs the middle one, and then the first one, and ends up with the last one. But you guys know what compose does and we'll see a lot more type signatures, it's not real important.

Speaker 3: Is that a Haskell?

Brian Lonsdorf: That's a Haskell.

Speaker 3: That's a Haskell set.

Brian Lonsdorf: That's a Henry Milner, yeah. There's no big deal with it. This is kind of a complicated one. I'll walk through them as we see them. And you don't really need to know this one, but the important part about category theory is that you need a composition and an identity to form a category.

And we're working with the function category when we're dealing with just normal compose and identity on functions. Does everybody know what the identity function is? Basically you give it a value and it just spits it right back out at you. So you're like, why would I need that?

It's pretty valuable when you're doing point-free programming, you could do filter ID to refer to the thing going in. It's kind of weird, so, but the point is you need an identity function and a composition function and you can have the categories. So, it's kind of a design pattern we're going to use in our programs.

So here, there's laws associated with it. That means if I compose the left and right identity, it's always just going to be just like running the normal function. because if identity just spits the argument right back out at you, I mean what's the point? It's always just going to work.

Down at the bottom is associative. That's why we've been able to compose x amount of arguments. It doesn't matter how they're grouped. It's also why we're able to just grab any subcomposition any two functions in a row in our compose, and pull it out into its own function.

So this isn't Haskell syntax, no. Whoa, my mouse is all crazy. That's weird, it's like a delay, okay. So like we saw over in this over here, we could grab out any two. If I had F and G and H right here, I could just be like, these go together.

Boom, and I'll make a new one called J that is the subcomposition of these. And the reason for that is that compose is associated so it doesn't matter how these are grouped together, so you can pull them out in their own functions. So that's really neat. It's just like add.

It doesn't matter if you add 1 and 2 or 2 and 3. They always end up in the same result.