[As described below, this is Part B of a 3-part course. Participants should complete Part A first -- Part B "dives right in" and refers often to material from Part A.] 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 of Part A. Part B assumes successful completion of Part A. 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. 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.
Optional: Variables, Macros, and Hygiene
Loading...
From the course by University of Washington
Programming Languages, Part B
429 ratings
From the lesson
Section 5 and Homework 4 (First Module with Racket)
Let's get started programming with Racket and then learning idioms related to delaying evaluation. The welcome message has a few additional comments about picking up a new language and how to approach the homework assignment, so let's get started...
Meet the Instructors
Dan GrossmanProfessor
Computer Science & Engineering
, In this segment, I want to continue looking at how Macros interact with the
treatment of variables in our programming language. It turns out that semantics of
Macros is different than the naive sort of macro expansion I've shown you so far,
that's a good thing. It's better in situations where variables may shadow
things that are in a macro. And that better semantics goes by the name of
hygienic macros. That's what I'm going to show you here. So, to do this, I'm going
to use a very simple example, which is a macro that doubles its argument. So, I
want to emphasize first, it says, poor style. If you need something that doubles
its argument, use one of these two functions you see at the top of the slide.
They're both perfectly good and they are equivalent to each other. And no client
can tell how you've implemented it, you just doubling and that's wonderful. But,
for the sake of a short example that will fit on a slide, here are two macro
versions, where the first macro replaces double of some expression x with plus x,
x. The second one replaces double of some expression x with star 2 x. Now, these two
macros are not equivalent to each other. We saw this sort of thing in the previous
segment. If I use the first macro with this argument, something that prints hi
and then returns 42, I do get the result 84. But I also print out hi twice, because
I would replace double of this thing with plus of this thing and this thing and so
each of them will print. Whereas, the second version will only do the printing
once, because the replacement only uses this expression once. So, they're not
equivalent, and we want to study that sort of thing in this segment, and even more
subtle things. So, if you wanted to do something like the first one, you wanted
to implement doubling as adding twice. And you wanted to use a macro and you didn't
want it to print twice. Then, you should do something like this third version. What
you should do is, say, well, when I have double of some expression, let's expand
tha t to a let expression. Let's introduce a local variable y to hold x, so x is some
expression, maybe it prints But then, y will jsut be the result of that
expression, because that's how let expressions work. And then, we'll add y
and y. And this is, these y's, are jsut looking up a variable that holds the
result of a previous computation. So now, this macro seems to work much more like
the version at star 2 x, because it only prints once. Fine, the general technique
here is to use a let expression to make sure that your macro arguments are
evaluated exactly once. Now, that's not always what you want. The my delay macro
we did earlier we didn't necessary want to evaluate it once, we wanted to put it
inside a thunk. Other times, you may want to have some of your macro arguments
purposely be evaluated multiple times because that's the entire purpose of the
macro. In the next segment, I'll show you something with a for loop, where there
actually is some expression we want to evaluate some number of times and then,
you shouldn't do this let expression either. But the technique is to use a let
expression to control the number of times something is evaluated. Another thing you
might think about is the order that your arguments are evaluated. So, here's an
example here on the bottom that does something that you might not want. So,
this defines a macro, take e1 from e2, so this is a subtraction, but in the opposite
order. It says the result should be, the result of evaluating e1 and e2 and then
subtracting from e2, the amount e1. Maybe this is more logical ordering of the
arguments to you. But the way this is being macro expanded, we end up with minus
e2, e1. And that's right for producing the right answer. But if the order of
evaluating your subexpressions matters, this will evaluate e2 before e1, because
we do the expansion, the result of the expansion is a function call and in
Racket, function arguements are evaluated in order from left to right. That might,
can the user of your macro, who doe s not know that this is the macro expansion,
they just read the documentation of use this macro to take e1 from e2, might be
very surprised when things are evaluated in the opposite order that they wrote them
down and you can once again fix this, not shown here, with a let expression to
evalute e1 and then e2 and then use those results in the subtraction.
Okay. So, I'm recommending, for issues like you
see on this slide, putting local variable in your macros. Those of you that have,
perhaps, done a lot of programming with C and C++ macros might be really upset that
I'm doing that. Because in those languages, it's usually very unwise to put
local variables inside of your macros and if you ever need to do it, people end up
using variable names that probably no one else would possibly use anywhere, Like,
__strange_name34. So, for all of you, let me explain why,
people in impoverished macro systems end up doing this and how Racket has a
semantics that makes this unnecessary, you can use local variables in your macros,
and everything works out fine. So, here is an example. Here is yet
another version of double, it's very silly for the purpose of demonstration. So, what
this does is it takes in some expression x and then it does multiply 2 and x. So,
that was the easy version. But then, it also multiplies by y, where y is some
local variable that holds 1. So, it seems clear that this will do the right thing,
it will double its argument, it just has this unnecessary argument y. But now,
here's a very strange use of the macro. It's not strange to the user, makes
perfect sense that I might have some local variable y, that's 7 and then use the
double macro with y. So, if I'm the user of the double macro, I'd expect this to
return 14. The fact that there's some other y up in the macro definition, should
be an implementation detail. But under the naive semantics, I've been kind of
assuming throughout this section, that would not be what happens. If you take
this double y and you replace it, as the rules up here would suggest, you would end
up with let y be 1 in star 2 y, y. All I did was take the body of the macro. But
wherever there is an x, I put the actual argument to the macro, which is y. This is
a problem. If you evaluate this entire result, which is what you would get from
that naive macro expansion, you will not get 14, you'll get 2. Somehow, the y here
at the macro used got captured, got put underneath the y in the macro definition.
This is the sort of thing that can happen in C or C++, this is not what happens in
Racket. Racket gets this right if you have this use, exactly as you see on the slide,
when you run this, you will actually get 14. This is part of what it means for your
macros to be hygienic. They are clean, they keep separate the local variables in
the macro from the any local variables that might be in scope where you're using
the macro. The way Racket does this is it just changes the names of variables in
macro definitions as necessary and we're not going to go into the details of how it
does it. Just rest assured that you get 14 in Racket, you do not get the naive
expansion. So, it turns out that's one of the problems that can come up. There's a
second one, where you also get the wrong answer and that Racket also fixes. So, let
me now show you that one. Here, I have this perfectly reasonable macro. There's
nothing wrong with this macro except that you should define a function and it just
takes double of sum expression x and produces star 2 x. But what if we use that
somewhere, where the function star, and star is just a function, I could have
shown you an example of a function named foo instead of star. What if we used this
macro somewhere where star referred to something else because the built-in
standard library star was shadowed? Here is such a use right here. If I call the
double macro with 42 in an environment where multiplication has been shadowed by
addition, then the naive expansion would be star 2 of 42 in a situation where star
has actually been rebound to plus and I would get 44 instead of 84. And again,
Racket does the right thing. If you have variables like star in a macro definition
that are defined outside the macro definition, you look them up in the
environment where the macro was defined, not in the environment where the macro was
used. This is our old friend lexical scope and its applies to macro definitions in
Racket, the same way it applies function definitions, then this is again, something
that most macro systems including the pre-processor for C and C++ simply do not
do. This is sometimes abused. This sort of dynamic scoping in those languages as a
feature instead of a bug. But I would say that experience suggests that the vast
majority of the time, you would rather have Racket's lexical scope and hygienic
semantics, than what you get in these other systems. Okay.
So, a hygienic macrosystem basically gets these two issues correct. The way it does
it is for the first issue, when you have a macro definition, it secretly replaces all
the local variables with other local variables and uses them consistently so
they can't interfere with anything that might be used in the use of the macro. And
for the second issue it basically uses lexical scope for macros the same way it
does for functions. This is not what you get by naive
expansion so it's actually quite a bit harder to implement Racket's module system
than you would naively think. But the Racket designers and implementers were
able to do that, and were able to enjoy the benefits. I would just remark in
passing, these hygenic rules are not always what you want. They're just what
you want the vast majority of the time. So, there's much more to Racket's module
system. You could read about in the Racket reference if you're implement, interested.
And they even have specific ways to indicate specific places where you don't
want these hygenic rules, and they'll give you a different semantics when that's what
you ask for.
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.
