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.
Shadowing
Loading...
來自 University of Washington 的課程
程序设计语言
881 個評分
從本節課中
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.
與講師見面
Dan GrossmanProfessor
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.
