Explore
For Enterprise
Join for Free
Log In

Arts and Humanities
Business
Computer Science
Data Science
Information Technology
Health
Math and Logic
Personal Development
Physical Science and Engineering
Social Sciences
Language Learning
Degrees
Certificates

Explore all of Coursera

Browse
Search
For Enterprise
Log In
Join for Free

Records

Loading...

Programming Languages, Part A

University of Washington

4.9 (1,057 ratings) | 64K Students Enrolled

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.

Skills You'll Learn

Recursion, Higher-Order Function, Pattern Matching, Functional Programming

Reviews

4.9 (1,057 ratings)

5 stars
998 ratings
4 stars
52 ratings
3 stars
1 ratings
2 stars
1 ratings
1 star
5 ratings

AL

Mar 22, 2017

Great course!\n\nI think this course has just the right balance of theoretical background, formal definitions, and actual examples to make "just right".\n\nThanks Dan, and everybody else involved!

MK

Jun 17, 2017

Good fundaments for learning new programming languages. Well prepared and challenging homeworks. I learned a lot of functional programming concepts fom this course and I am sure I will use them.

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.

Building Compound Types5:34

Tuples as Syntactic Sugar6:06

Datatype Bindings8:39

Case Expressions10:50

Useful Datatypes11:22

Pattern Matching So Far4:37

Another Expression Example8:01

Type Synonyms6:19

Lists and Options are Datatypes9:10

Polymorphic Datatypes8:11

Each of Pattern Matching / Truth About Functions14:30

A Little Type Inference6:28

Polymorphic and Equality Types8:00

Nested Patterns10:32

More Nested Patterns10:43

Nested Patterns Precisely6:35

Optional: Function Patterns3:40

Tail Recursion9:44

Accumulators for Tail Recursion7:40

Perspective on Tail Recursion5:33

Taught By

Dan Grossman
Professor

Transcript

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.

Download on the App Store

Get it on Google Play

Coursera
About
Leadership
Careers
Catalog
Certificates
MasterTrack™ Certificates
Degrees
For Enterprise
For Government

Community
Learners
Partners
Developers
Beta Testers
Translators

Connect
Blog
Facebook
LinkedIn
Twitter
Instagram
YouTube
Tech Blog

More
Terms
Privacy
Help
Accessibility
Press
Contact
Directory
Affiliates