I'm wondering what the relation of category theory to programming language theory is.


I've been reading some books on category theory and topos theory, but if someone happens to know what the connections and could tell me it'd be very useful, as that would give me reason to continue this endeavor strongly, and know where to look.


Motivation: I'm currently researching undergraduate/graduate mathematics education, specifically teaching programming to mathematics grads/undergrads. I'm toying with the idea that if I play to mathematicians strengths I can better instruct them on programming and they will be better programmers, and what they learn will be useful to them. I'm in the process (very early stages) of writing a textbook on the subject.



Relating category theory to programming language theory
The most immediately obvious relation to category theory is that we have a category consisting of types as objects and functions as arrows. We have identity functions and can compose functions with the usual axioms holding (with various caveats). That's just the starting point.


One place where it starts getting deeper is when you consider polymorphic functions. A polymorphic function is essentially a family of functions, parameterised by types. Or categorically, a family of arrows, parameterised by objects. This is similar to what a natural transformation is. By introducing some reasonable restrictions we find that a large class of polymorphic functions are in fact natural transformations and lots of category theory now applies. The standard examples to give here are the free theorems, see Philip Wadler's 1989 article [*Theorems for free!*](https://doi.org/10.1145/99370.99404), in FPCA '89: Proceedings of the fourth international conference on Functional programming languages and computer architecture.


Category theory also meshes nicely with the notion of an 'interface' in programming. Category theory encourages us not to look at what an object is made of, but how it interacts with other objects, and itself. By separating an interface from an implementation a programmer doesn't need to know anything about the implementation. Similarly category theory encourages us to think about objects up to isomorphism - it doesn't precisely proclaim which sets our groups comprise, it just matters what the operations on our groups are. Category theory precisely captures this notion of interface.


There is also a beautiful relationship between pure typed lambda calculus and cartesian closed categories (CCC). Any expression in the lambda calculus can be interpreted as the composition of the standard functions that come with a CCC: like the projection onto the factors of a product, or the evaluation of a function. So lambda expressions can be interpreted as applying to any CCC. In other words, lambda calculus is an internal language for CCCs. This is explicated in Lambek and Scott. This means for instance that the theory of CCCs is deeply embedded in Haskell, because Haskell is essentially pure typed lambda calculus with a bunch of extensions.


Another example is the way structural recursion over recursive datatypes can be nicely described in terms of initial objects in categories of F-algebras. You can find some details in Philip Wadler's note [*Recursive types for free!*](https://homepages.inf.ed.ac.uk/wadler/papers/free-rectypes/free-rectypes.txt) (dated originally to 1990, labelled "DRAFT DRAFT DRAFT DRAFT DRAFT").


And one last example: dualising (in the categorical sense) definitions turns out to be very useful in the programming languages world. For example, in the previous paragraph I mentioned structural recursion. Dualising this gives the notions of F-coalgebras and guarded recursion and leads to a nice way to work with 'infinite' data types such as streams. Working with streams is tricky because how do you guard against inadvertently trying to walk the entire length of a stream causing an infinite loop? The appropriate dual of structural recursion leads to a powerful way to deal with streams that is guaranteed to be well behaved. Bart Jacobs, for example, has many nice papers in this area.


