was the code that I attempted to pass off as code that is easy to understand, that communicates what it intends to do. So that didn’t work, so let’s go back to a fully pointful definition. To get the colour matches of two lists of pegs, what I want to do is count the colours in each of them, I want to zip them together with the minimum of the counts, and I want to add up those counts together. But if you ask me, this really irks me, that I have to say countColours twice here. I have this transformation that kind of looks like this: I have these two lists, that come in together like this, and I have to do something here to put them together, and I have to do something after I have done that, but then before I put them together, I have to run this same transformation on both of them. There is a way around this that is much more elegant. In fact, I have this kind of problem involving combining functions, I wonder, if there might be a combinator? And there is. It’s called the psi combinator, and it actually lives in a Haskell, in a module called Data.Function and it is called on’ And here is the type of on. This looks a little scary, if you are not used to it. So on takes a binary operator that takes two bs and makes them into a c, it also takes a function that takes an a and transforms it into a b, and it will give you back an operator that will take two as and give you a c as a result. So I can use it here, I can take the ‘zipWith min’ on countColours. And here I am using an infix notation instead of a prefix notation, the backticks mean I can put ’on’ in the middle, so this actually reads well. So I countColours with both, zip them together with min, and I get a function that looks like this: two lists of pegs, and that gives me back a list of numbers. @amar47shah Amar Shah It is objectively awful. And if you went to any presentation today where someone told you that you can prove things with code, somebody please prove that this is awful.