Shadowing

Loading...

En provenance du cours de University of Washington

Programming Languages, Part A

817 notes

University of Washington

Programming Languages, Part A

817 notes

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.

À partir de la leçon

Section 1 and Homework 1

It's time to dive in! Start with a careful reading of the "Section 1 Welcome Message" and go from there.

ML Variable Bindings and Expressions14:32

Rules for Expressions9:13

The REPL and Errors12:11

Functions Informally7:37

Functions Formally8:56

Pairs and Other Tuples9:16

Introducing Lists10:34

List Functions11:21

Let Expressions7:51

Nested Functions7:38

Let and Efficiency10:10

Booleans and Comparison Operations7:00

Benefits of No Mutation7:24

Optional: Java Mutation4:44

Pieces of a Language6:02

Rencontrer les enseignants

Dan Grossman
Professor
Computer Science & Engineering

[MUSIC]

Okay. In this segment, I want to talk about shadowing.

Shadowing is when you add a variable to an environment when before you added it,

that variable was already in the environment.

So, to do this, we're going to end up having multiple variable bindings for the

same variable in the same file. that can be a little bit confusing.

It's usually poor style to do that, although it does come up with certain

idioms. But it's going to be a great way to make

sure that we really understand how environments work.

So, I'm not going to give you any new rules, there's no new syntax or no new

type checking or evaluation rules here. We're just going to use this idea of

shadowing to really explain how environment and variable bindings work so

that we have that solid foundation we need when we go to add things to the

language. So, let's just start here by adding this

binding, val a = 10 to our environment. And so, we know now that in the static

environment, a will have type int. And in the dynamic environment, a will be

bounded at the value of ten. And so, of course, if we then continued

in our file with a * 2 b would have the value 20.

I'm going to ignore the static environment here just for expediency but,

of course, that's, that's relevant as well.

[COUGH] So now, the interesting thing happens if we say, val a = 5,

alright? And the thing I really want to emphasize,

is that b is still bound to twenty.

And, in fact, if I next said val c = b, even though right here, I had an

environment where a maps to 5 and b maps to 20,

now I have an environment where a maps to 5, b maps to 20, and c maps to 20.

Because we know that the way you evaluate this expression b is you look it up in

the dynamic environment, you get 20 and then you extend the dynamic environment

so that now c maps to that result, alright?

So, the fact that b was earlier created by evaluating a * 2 is no longer

relevant. That was back in an environment where a

mapped to ten. We got twenty, we extended our

environment so that indeed a mapped to 10 and b mapped to 20.

And that's the end of the story. The fact that we had a * 2 is no longer

relevant. And I should emphasize as well, that this

val = 5, this is not an assignment statement,

okay? There's absolutely no way in ML to mutate or change the fact that a mapped

to 10 in the previous environment. All we get is in the subsequent

environment, a is now shadowed. We have a different mapping for a in a

different environment and a is now five. So, that's the idea.

Let's just do a little more examples to make sure we got it.

If I now say val d = a I'm going to end up with an environment with all the

things I did have and now d maps to five because a maps to five in this

environment where I am. If I now say, what about val a = a + 1.

Again, there's no such thing as an assignment and this makes perfect sense.

The way a variable binding works is we evaluate the expression in the current

dynamic environment. So, a maps to five, we add one to that,

we get six and then we create a new dynamic environment where a maps to six

along with everything else we had previously, but we're now shadowing the

fact that a maps to five in an earlier environment or a mapped to ten in an even

earlier environment, okay? So indeed, if we now say, val = a *

2 f will map to twelve. I should emphasize as well that something

you cannot do is a forward reference and we know why for the same reasons.

So, if I had this code here, it would not type check and the reason why is when I

have to go to type check, this expression f - 3, f is not yet in the environment.

So, when I look it up in the static environment, it's not there and now we've

got a type error message. So, that's the example I wanted to show,

let's real quick try it out and make sure that I typed everything in correctly.

Oh, semicolon. Let's there we go, we'll try this again.

Notice I didn't panic when I got an error message, there we go.

And we see all the values I saw but for those earlier a's the read of all print

loop is trying to be helpful and just say, you know, this value can't possibly

be relevant to you. I know it's shadowed in the dynamic

environment you now have down here where a is bound to six.

So, rather than show you what a was back up in this earlier environment, I'll just

print hidden value. Alright.

So, that is the code example, let's go back to the slides here and show you

again that in the key example here, when you have something like val, a = 1, b =

a, a = 2, that in the environment you end up with b is bound to one and a is bound

to two. There's actually two reasons for this,

either one of which would be enough. the first reason is that we evaluated

that expression we used for b, that expression a on the right hand side

of the equals, eagerly back when we evaluated the variable binding for b.

So, after we've done that expression evaluation, b is bound to one and it

doesn't matter how we got that one. It will never effect the fact that we got

a one and that's the end of the story. The second reason b will stay bound to

one is that that second val2 = 2 is not an assignment statement.

The earlier a, the a that leads to the environment that is used to evaluate b is

still one. All we do is create a second variable b

that shadows it. So, it turns out, this is the reason I'm

so insistent on not having use commands in your RPL more than once for the same

file. Because if you say use multiple times for

the same file, you're going to repeat whatever bindings were there the first

time you said use for the file and they are still there the second time you said

use for the file. And while it's legal in ML to have that

sort of shadowing and to reintroduce those bindings, it can be really

confusing, right? Maybe you took a binding out but it's

still there because of the previous use or maybe you have some strange shadowing

that makes it look like your code is correct when, in fact, you're it's, it's

wrong because of how the shadowing happened to work for the multiple use

statements.

Explorer notre catalogue

Rejoignez-nous gratuitement et obtenez des recommendations, des mises à jour et des offres personnalisées.

Coursera propose un accès universel à la meilleure formation au monde, en partenariat avec des universités et des organisations du plus haut niveau, pour proposer des cours en ligne.

© 2018 Coursera Inc. Tous droits réservés.

Télécharger dans l'App Store

Disponible sur Google Play