[MUSIC] Okay, now in our study of lexical scope, we can get to the motivation of
why this is the symantecs you want. So remember lexical scope is using the
environment where a function is defined to look up variables in the function
body. The other natural thing you might think
of, go, does have a name, it's called dynamic scope.
If you have dynamic scope use the environment where the function is called.
So decades ago, these were considered reasonable options and in a programming
language course, you would study both and think about which one of language you
might have. I think it's fair to say that, these
days, lexical scope is considered the one that makes sense.
We'll talk a little bit at the end of this segment about things that do work
with dynamic scope, it is occasionally useful.
But lexical scope is really how programming languages work these days.
So, there are reasons for this and these are precise technical reasons.
Sometimes in programming languages, things are just a matter of taste,
but I'm about to show you things that lexical scope let's you do,
ways it let's you reason about code and dynamic scope simply does not,
and that much is not a matter of opinion. The only opinion you might have is
whether or not those reasons are good or important.
So let's just get started. I'll show you three main reasons.
The first two are actually related. The first one I'll say that the meaning
of a function does not depend on what variable names you use.
This is nice, because you can go in and change the
names of your variables, say to make them more informative or to port them to
different human language or something, and you can know that it's not going to
affects any of your callers. So for example, look at this first
function we see here we've seen a function like this before, and suppose
that you come along and say, you know, x is not very, a very good name for that. I
want to call it q of fu or pizza instead. You could change it here and you could
change it here and you would know that no caller can tell.
It's a local variable and the name of local variables should really never
matter. It's good abstraction.
It's good modularity. It's good software engineering and it's
only lexical scope that gives us that. Let me show you that with the code here.
So here, I have the function that we had on the slide,
I've just called it f1 to distinguish it from f2 here.
And f2, I've done the variable renaming I suggested.
It's exactly like f1, except I've used q for my local variable both in its
definition and its use instead of x. And it turns out that no one will ever be
able to tell. If I call (f1 7) and get a function back,
that function is going to add 15 to its argument, 2y + 1.
If I call (f2 7), I will get back a function that adds 15 to its argument.
All callers can tell is that I get back a function that adds 15 to its argument, so
both a1 and a2 will be 19. It doesn't matter that there is an x in scope here.
If we had dynamic scope, if we evaluated these function bodies, x + y + z, q + y +
z, where we called these functions instead of where they were defined, then
under dynamic scop, one of these functions would end up using this 17 and
the other one would actually end up with an unidentified variable.
because we would try to use q and there would not be any q here, that's actually
one of the other reasons we're going to get to, okay? So that's our first reason
is that function domain does not depend on the variable name uses.
I actually already showed you another example of this which is the second
example down here, that it lets you remove unused variables.
In the previous segment, I showed you an example where we had a function body that
was let val x = 3 or something like that, in g called 2.
This val x is irrelevant, so it would be fine to remove it.
On the other hand, if we had dynamic scope, then if the caller to f passed in
some g that had in its function body x, we might end up using that x, because
here is the call site and under dynamic scope, which is not what ML has. We would
end up using the environment where the function was called.
So you really need lexical scope, to reason about these functions this way,
this way, and this is essential, for modularity of
the software. And modularity, in software is one of the
most important features you want from your programming language.
Okay. On to reason two,
somewhat similar. Functions can be type checked and
reasoned about where they're defined not where they're used.
So let's look at this example. we can just look at it on this slide
here. I look at this function f, which we, it's
the same one I've been showing you. And we can reason about the fact that it
returns 2y + 1 and its function that when called returned 2y + 1, excuse me.
And its type is take an int and return an int arrow int.
So its type is int arrow, int arrow int. Once we know that it type checks, we know
that if we call it with an int, that shouldn't lead to any problems.
And indeed, when we call it was 7 here on the second to last line, we get back the
function that will add 15 to its argument and then when we call that with 4 we get
19. What if we had dynamic scope? If we had
dynamic scope, then down here at the bottom, when we end up calling this
function, we go to evaluate x + y + z. What we're going to get back, hm,
we're going to look up x in our environment,
we're going to get a string. That's a really bad idea since you can't
add strings in ML. We're going to look up y in the
environment. We're going to get an undefined variable.
Well, no, y we might get, or z because there is no
y and z here. Those are undefined variables.
So our whole purpose of type checking just got thrown out the window with
dynamic scope, because we end up using the wrong variables in the wrong places.
Okay? Onto our third and probably most exciting example, because it's going to
to let us do new things. Closures just got much more powerful, because we can
use this lexical scope idea to have them store whatever data they need.
And this is, works particularly well with functions like map and filter that I've
showed you before that iterate over data structures.
So, I have the same code over here. Let me get to it here. Alright.
So, we have seen the function filter before.
This is just a function that takes a function f and a list xs and returns a
list that only contains the elements of xs for which f returns true.
Okay? So suppose that I wanted to filter on all
of the, I wanted all the numbers that were greater than negative one or the
nonnegative numbers. Here is the way I could implement that in
these two lines using filter. What I'm going to do is I am going to
define a little high order function here it takes in a number x and it returns the
function that takes a y and returns true if y > x.
So greater than x has type int arrow int arrow int.
So, down here where I call greater than x with minus one, I'll get back an int
arrow int. Okay?
So if I call filter with the result of this call, that's essentially going to be
a function that takes in a y And asks is y > -1?
Filter that over the list, I get a function that takes a list and
returns all the nonnegative numbers in the list, zero or positive.
So where are we using lexical, lexical scope here? In the creation of this
function that would pass the filter, greater than x, when called with minus
one, returns a closure that captures, stores in its environment that x is minus
one. So, when we pass this function into
filter, we will be asking for each element of the list,
is that element greater than minus one? It does not matter that up here in the
body of filter, there's a different x. If we had dynamic scope, this would not
this, would ask is a number greater than itself, we would get false, and we had
filter everything out of our list. What's going on here in general is that
filter just says give me a function, any function f, and it does not care about
the fact that the closure pass then, can have whatever data it needs in its
environment. In this example, it's using just minus
one that was stored when we created the closure here.
I may show you a second example using an unanimous function. We also call filter.
This is a function all greater than or all greater, that takes in a list and a
number and filter out all the numbers less than n, less than or equal to n.
So it only returns strings strictly greater than n.
So, I call filter, I call it with this little anonymous function n, xs, and
notice that when I pass in this function, it's going to end up getting called in
the body of filter between if and then. But we look up variables in the body of
that function, not where the function is called but where the function is defined.
So when we look up this n, we will always get the n that was passed into all
greater. So this will work correctly if you call a
greater with a list and 17, we will filter out anything that is 17 or less
and we need lexical scope to do that. Alright?
Let's go back to the slides we will see more examples of this after I show you
some other high-order functions, but this is really where we get a lot of the power
of closures. And now, let me ask the question, if
dynamic scope is such a bad idea, why do we even have a name for it? Okay?
So, people now do realize that lexical scope for variables is definitely the
right default. It's very common behavior across
programming languages, it's important when designing a language to get this
right. Now, dynamic scope is occasionally
convenient in some situations. And so some languages, for example Racket
which we'll use later in the course have special ways to do it.
You can add to your language a special kind of variable, separate from the
regular variables, that works with dynamic scope.
Most languages don't bother but it can be convenient.
an example is trying to change through dynamic scoping where output is
redirected to certain files and things. I'm not going to show an example here.
The other thing I would like to point out is if you squint a little bit and think
about it, exceptions, which we saw previously in the course, act a little
bit like dynamic scope. If you think about a handle expression
and when you raise an exception, which handler does it go to? It's not lexical.
You don't look at the structure of the code.
It's not the closest handle expression where the raise was defined.
It's the closest handle on the call stack in the current dynamic nesting of calls
and that is much more like dynamic scope. You look up the current handler,
is it, did your caller want to handle this exception? Did its callers want to,
and it's not based on where things were defined.
And lots of experience with exception handling just suggests that for
exceptions, that's a better default, people find that more convenient and
better stylistically when designing their software.
