This course is an introduction to the basic concepts of programming languages, with a strong emphasis on functional programming. The course uses the languages ML, Racket, and Ruby as vehicles for teaching the concepts, but the real intent is to teach enough about how any language “fits together” to make you more effective programming in any language -- and in learning new ones. This course is neither particularly theoretical nor just about programming specifics -- it will give you a framework for understanding how to use language constructs effectively and how to design correct and elegant programs. By using different languages, you will learn to think more deeply than in terms of the particular syntax of one language. The emphasis on functional programming is essential for learning how to write robust, reusable, composable, and elegant programs. Indeed, many of the most important ideas in modern languages have their roots in functional programming. Get ready to learn a fresh and beautiful way to look at software and how to have fun building it. The course assumes some prior experience with programming, as described in more detail in the first module. The course is divided into three Coursera courses: Part A, Part B, and Part C. As explained in more detail in the first module of Part A, the overall course is a substantial amount of challenging material, so the three-part format provides two intermediate milestones and opportunities for a pause before continuing. The three parts are designed to be completed in order and set up to motivate you to continue through to the end of Part C. The three parts are not quite equal in length: Part A is almost as substantial as Part B and Part C combined. Week 1 of Part A has a more detailed list of topics for all three parts of the course, but it is expected that most course participants will not (yet!) know what all these topics mean.
Records
Loading...
From the course by University of Washington
Programming Languages, Part A
1027 ratings
From the lesson
Section 2 and Homework 2
This section is a particularly rewarding one where a lot of ideas come together to reveal a surprisingly elegant underlying structure in ML. As usual, start with the welcome reading, dive into the material, and leave plenty of time to approach the programming assignment methodically.
Meet the Instructors
Dan GrossmanProfessor
Computer Science & Engineering
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.
Explore our Catalog
Join for free and get personalized recommendations, updates and offers.
Coursera provides universal access to the world’s best education,
partnering with top universities and organizations to offer courses online.
© 2019 Coursera Inc. All rights reserved.
