[MUSIC] In this segment, I want to introduce type synonyms which are a seperate thing from what we've seen before. And a bit of a digression, of a digression from data type bindings and case expressions but nonetheless helpful for the next homework and a nice contrast with data type bindings. So, data type bindings introduce a new type name. And that new type is different from every other type. The only way to make things of that type is with the constructors that are part of the data type binding. A type synonym is a new construct I'm showing you now for the first time. And all you do is you write type, so that's a new keyword, not datatype, just type. The name for the type, then equals, and then another type. And what I want to emphasize is that the English word synonym is perfect here. It just creates another name for the same type that was already there. And so now, we can use that name wherever we were using t. And we can use t wherever we might use that name. They're interchangeable in every way. And I even want you to not worry about which one the repel prints. The two things, the type t and the name, a name really can be used interchangeably. So, let's go over to some ml codes so I can show you how this works. So first, I have two datatype bindings that we've seen before for suit and rank and those behave just like they did before. But now, I also have a type synonym, where I kind of remind myself and allow myself to use in the program that wherever I have a suit paired with a rank, I can think of that as a type named card. So, the type card is a new type name that will now be in my environment and it means the pair of suit and rank. So, I could write suit star rank or card and that'll be fine. Another common idiom by the way, that I'm not going to use in the rest of the file but I wanted to show is Is to give a name to your record types. It's a huge pain to write down this record type anywhere or to remember, or to even give a name for it. So, instead of just having a comment that says, this record is for describing the names of people in my class along with their student numbers, I can go ahead in my program. give a name to that type, and then, use that type name wherever I want, okay? So now, let me really emphasize this interchangeability aspect. So, here is a short function I wrote called is_Queen_of_Spades. It takes in a C of type card. So notice, I can use that type name that I introduced up here. And it does the appropriate computation of seeing if indeed, the suit is spades and the rank is queen, okay? So now, here are three variable bindings, c1, c2, and c3. c3 is how we've been writing most of our variable bindings where I just create a pair of a Spade and an Ace. And when you see that you might be asking well what's the type of that? Is it suit star rank or is it card? And the answer is it's both because those types are the same. So, in fact c1 and c2 are both perfectly reasonable variable declarations, variable bindings. It turns out you can write the type of a variable if you want with a colon and then, then, the type. And the type checker will make sure that's correct, that the expression over here really does have that type. And what we'll see here when we go over the REPL is all three of these, c1, c2, and c3, will type check just fine. So,. let's just, make sure that's right. And they are. We see all the bindings here. You'll see the REPL printed our datatype bindings, our type synonyms. Then this function is_Queen_of_Spades of type card arrow bool and then it happened to say that c1 is type card, c2 is type suit star rank and c3 is type suit star rank. But I promise you that this works fine, that type checks and runs, this type checks and runs, and this type checks and runs. because anywhere you have card, it is the same thing, it suits star rank. So, I emphasize this because on your next homework, we'll tell you to write functions of certain types, like for example card arrow bool. And if you write a function and it seems to work correctly but it prints out a different type, like maybe suit star rank arrow bool, I want you to recognize that that's the same type and it's okay. And the reason why that's going to come up if I switch back to the code file here is a little thing I haven't shown you yet, which is soon we're going to write functions like is_Queen_of_Spades differently. We're going to use case expressions for that sort of code, too. Even though suit star rank is actually a pair, and not a datatype, it contains datatypes. And once we write is_Queen_of_Spades with case expressions rather than in hash one and hash two, then we won't have to write types on our arguments anymore. We won't have to write c card. We'll be able to just write c. The only disadvantage of that is then the REPL won't know whether we want to see cards or suits star rank. So, we'll just take whichever one it happens to based on its own internal procedures and internal algorithms. But nonetheless, I find this style of coding much more pleasant. Just not writing down the types and letting the type checker figure them out for me for function parameters, the same way we've been doing it for variable bindings. So, that's why this notion of type synonyms and this interchangeability will be so important. it does raise an interesting question though which is, why have this is your language? I mean, if it's really just a convenience. well, let's be honest, sometimes convenient things for programmers are worth putting in the language. If you want to write CARD rather than suit star rank, it's nice to have a facility for doing that. And the only confusion is that if you wanted a function of type card arrow bool and the REPL says, suit star rank arrow bool, you have to realize that that's an equivalent type and it's okay and it's the same thing. So, it doesn't really let us do anything new, yet. But in a couple weeks, later in the course, we will build on top of these type synonyms when we study ml's module system. And there we'll be able to do something pretty special and we'll need these type synonyms in order to do it.
