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.