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