All right let's talk about records. These are a new kind of each of type. They're not particularly complicated but then they'll let us have a really interesting conversation where we can start comparing and contrasting them with two poles which are the other way we know to build each of types. So I think it will be easiest to just jump over to the read a valve print loop, and start showing you records. So how about I bind a variable X to a record? this is a new kind of an expression we haven't seen before. The syntax is we're going to put something in between curly braces we haven't used those before in ML. And what were going to do is we're going to have field names which are not variables but can be any sequences of letters we want. So maybe I want a record to have a field bar, and a field foo, and a field bas. I need to separate these by commas. And I need to have an expression to evaluate to create the contents for each field. So maybe for bar I want to evaluate this expression. It can be any expression in the entire language as usual. How about true and also true, which is a really dumb and fancy way of writing true. All right. And then maybe for foo I want to have the expression three comma four and for baz I want to have false comma nine. And this should be a perfectly legal expression, that we will evaluate and bind the result to X. And sure enough the read-eval-print loop comes back and says you now have a record value bound to X. Where bar holds, three comma true, base holds false comma nine, and foo equals seven. So we see two things here. One is it evaluated each of our expressions to a value and then that was the result. Same thing happened when we did two poles. When we built the two pole we evaluated all the pieces and that was the result. The second is the read-eval-print loop seems to have re-ordered our fields. what it actually did was alphabetize them. The order of fields and records does not matter and so the REPL chooses to present them in a uniform or canonical order. And it just chooses alphabetization. It doesn't matter. All right? And as always we have the type. And records have a different type than anything we've seen in the language before. So this is a new kind of type, a new compound type. And these types are written with curly braces, the field names, a colon instead of equals, just because that's ML's way, and then the type of each field. And those are separated by commas. So indeed, we see we've just built a record where bar is type int star bool baz is type bool star int. And foo is type int. We could nest records. We could pass records to functions. We could do all the normal things. Perhaps the only things that seems strange, if you try to compare them to Java classes or c strucks or Python classes is we didn't have to declare our record type, the same way we could just anywhere write and int-star bool without having to say anything ahead of time. We can write this record, which has a BAR-field, a BAS-field and a FOO-field of particular types. And the type checker, using type inference, just figures out the type of the record we have. And we can say, what is the type of X. It says it has the type that it had back when we created it. So let me show you a couple other examples of records just to make sure we have the hang of it. Here's one that kind of represents my niece. she has a name, that name is Amelia. And she has a birthday. She doesn't actually have an ID which maybe is the result of this calculation. And sure enough, I get a record where the ID is 411111, and the name is Amelia. And that has type ID colon and name colon string. And again, you just create any record with any field names you want. and the way, I haven't shown you how to get the pieces yet back. You do that with hash ID, and then something like my niece. So the same way we had hash one and hash two for tuples, for now we have hash field name to get the corresponding piece of a record. And there's no rule that you have to use different, field names for different things. So here is something that also has a field name that as far as M L is the same can be concerned is the same as one of the field names in Amelia, and my niece, but this usually pronounced id but it's the same as ID, it's spelled the same way. And sure enough this created a perfectly good record holding three bools, two of which are false, one of which are true. And the field names are ego, ID, and superego. Okay, so that's your little demo of records. Now let's talk about them from a more interesting perspective. Take a step back to come up with the rules for how you create them and use them. So we have a new kind of value in our language. These are record values. These are things where you have field names and each thing is a value that's the result of evaluating something that builds a record. The types are these record types, where you have the names of the fields and the type that each field has. As I've emphasized in the examples we went through, the order of fields in a record or ty value or record type never matters. So the rapport prints them out alphabetically but the something with the foo holding two and a bar holding four is exactly the same as a bar holding four and a foo holding two because we access the pieces by name with the hash my filed name, the order of the fields is not part of a rapport definition. Okay. So, we've seen this example and I emphasized as we went through it that we didn't have to declare any records types, that we just create a record with expressions that have certain types and then we have a record of the corresponding type. The thing I want to emphasize is that these are a lot like tuples. So we now have two ways to do each of types. If we wanted something that had in it a four, a seven, and a nine, we could write the triple, four comma seven comma nine, or we could write a record using three different field name,. maybe F equals four, G equals seven, H equals nine. So which should we prefer? Which is better? And you know as anything in language design or software design it depends. So the Tuples version is shorter, right? Fewer characters to type but the records are a little easier to remember or which part is which, right? I don't have to remember that oh, my niece's name came first and then her birthday came second. I had useful field names to remind me of that using a name and ID. Okay, so generally the choice here is a bit of a matter of taste. The one thing I would emphasize is if you have a lot of fields, like say eight, or ten, or twelve, or six, usually a record is a better choice. I know I can't keep track of, wait which thing came fifth? Is that hash five? Or am I supposed to use hash seven? Okay. But even more generally what I find fascinating about Tuples and records, this is just one example of a standard choice when you're designing a language construct. Which is, if you have multiple things, you want to indicate which is which by position, the second place, the fourth place, the fifth place or by some sort of name, the foo field, the bar field, the name field, alright? And each construct that has multiple things you can kind of see which way it's doing it. And to point out a common kind of hybrid, it's a little bit of each, look at function arguments as we've been using them in ML or even Java method arguments and similarly in Python. For the caller, to a method or function, it's always by position, the first argument, the second argument, the third argument. That's how you write down the method call or the function call. But then, in the callee we don't access them by position. We access them by name using the variables or formal parameters we used then defining the function or the method. So it's kind of a strange hybrid. And there are other programming languages out there, where the caller, specifies the arguments sort of by name, I want the foo argument to be seven and the bar argument to be nine. And there are probably languages, although I can't think of any off the top of my head where the callee accesses arguments by position. The second argument, the fourth argument, the fifth argument. So whenever learning a concert we have another design choice to think about, which is how you access the pieces, by name or by position. There isn't a huge difference between those and that's why in the next segment I'll actually show you that tuples and records are even more similar than they appear.
