. Alright in this lecture I want to show you something kind of neat about tuples, and to use that to introduce this really important concept in programming languages called syntactic sugar. So let me just show this to you in the repple. we have already seen how to build pairs. Here's a pair. Three plus one, four plus two creates the pair (4,6), no problem. And, similarly, we could create a record, maybe with a field second of four2, plus two and a field first of three1. plus one. Alright? So nothing unusual there. We see the tuples and records are similar, but different. But now, suppose I did something kind of strange, and I made a record. But I made the field names, say, one and two, in whatever order I want, because the order never matters. Something like this. Watch this. Oh isn't that weird. I made a record with field names one and two and the repple printed it out as a pair, (6,5), and it printed the type as int * int. Its like it turned my record into a tuple or something. Of course this is no problem, right? If I wanted to say, take a hash one of a pair, and add to that hash two of another pair. Oop. underscore not plus, there we go. I get nine of type int and you know for hash one and hash two it doesn't really matter. Hash two can mean get the second component of a pair or it can say get field two of a record. Right? So it doesn't seem to matter. and just to show that you really can give numeric field names to records if I had a record like this with three and one, alright, well that prints as a normal record. it has type one:bool three:string. But if I had something with three equals hi, one equals true, two equals, say, three plus two. Now I have a triple, (true, five, hi,) bool * int * string. And what I want to convince you is that this is because there is no such thing as tuples in ML, there are only records and tuples are just a way, a different way of writing records that you as a programmer can use whenever you want. And the repple always chooses to use of a [INAUDIBLE] and this is because tuples are just "syntactic sugar" for records. So lets unpack that idea little bit here. Okay. Previously, I taught you tuples as though they're in ML. We gave syntax, we gave type-checking rules, and we gave evaluation rules. But we could've done something else instead. I could've taught you records first, even though they're a little more complicated, and then told you that there's some special syntax for writing certain kinds of records. That whenever you write the syntax for building a tuple, e1 comma up to en, in parentheses, that that's just another way of writing the record with field names one up to n, and with the corresponding expressions. And whenever you write the type for a tuple type with those stars in between the component pieces, that's just another way of writing the record type where, again, the field names are one through N. In other words, tuples are nothing more and nothing less than records with particular field names. And that is how the ML Language definition actually works. That all there is about tuples are special syntax that you can use when writing programs, and that we print when we write the results of things in the rupple. So you really can write things like the record one equals four, two equals seven, three equals nine. It's terrible style. I don't know why you would do this. The tuple syntax is easier to read, it's what people expect. I just showed you this for the purpose of teaching you this idea. But it really is that in ML we have records, tuples are just a particular way of writing particular records. So, what we say in programming language speak, is that tuples are just syntactic sugar for records with fields named one, two, up to N. So, I'm going to use this phrase a lot in the course, so let's understand exactly what it means. Syntactic because we can describe the semantics, the evaluation rules and typing rules for tuples, completely in terms of something else. Right? We do this. Just you wrote this. It's like you wrote that. And then we can use all the semantic rules we have for a different language construct. So that's why it's called syntactic when we do this. We call it sugar because it makes the language sweeter. It's a pleasant thing to use and see. So we call it syntactic sugar. We're going to see many more examples of this. there, syntacic sugar is great because it simplifies our understanding of the language. Once you understand how tuples are really a form of records, you understand everything there is to know about tuples, as long as you understand records. They also simplify implementing the language. The ML implementation just has to convert tuples into the corresponding records and there isn't as much duplicative work to do. We only have to implement one kind of each of type, instead of two. Okay. So this is far from the only example we'll see. there are other examples of syntactic sugar and actu, we, we've already seen one other. You can think of e1 and also e2 as being syntactic sugar for, if e1, then e2, else false. Right? We can explain everything there is to explain about and also, in terms of that syntactic transformation in terms of an if-then-else. And also is better styled, but we can define its semantics in terms of another concept, we already understand. So that's syntactic sugar. And now we understand the truth about tuples