[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.
Dan GrossmanProfessor
