Optional: Racket Macros With define-syntax

Loading...

From the course by University of Washington

Programming Languages, Part B

345 ratings

University of Washington

Programming Languages, Part B

345 ratings

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

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 Grossman
Professor
Computer Science & Engineering

[MUSIC] So now, without further a do, let's learn how to define our own Macros

in Racket. There's a lot of syntax for defining other syntax. But we can just go

through it line by line. And we'll do the 3 examples that. We used, a couple

segments ago when introducing the idea of macros. So the first one I'm going to

define, is my own version of if. Where users will be able to write my-if, some

expression like foo. then bar else baz. And of course, the foo bar and baz can be

any expression, arbitrarily deep as many parentheses as you want. And that will get

expanded into if e foo bar baz, with the same expressions being expanded. So how do

we tell racket that we want to have this macro? We start with the define syntax

keyword. So it's not define, it's define syntax, because we're not defining a

variable or a function, we're defining something different. The name of your

macro, so my if. Then this other keyword, syntax rules. So we're going to give some

rules for the syntax. That's in parentheses, like here. Okay? Then, a list

of the other keywords in this macro besides my if. So, in this case, it's then

and else. And you have to tell it this, because it doesn't know that we want then

and else to be special words. Whereas, the other things, we want to be any arbitrary

expression. So, now we have a list of cases. We can use square brackets for this

to delineate it. We could have second one here and then a third one, but in this

case we always just want to expand the same way no matter how my if is used. So

we're just going to have one, that's fairly common, so we just have one thing

in this list but you need those square parentheses. And now what we say, if you

see something like this. Expand it like this. So what does it mean to see

something like this? It says, if you see something in parentheses that starts with

my if. Then has anything you want, call it e1. And then the word then. This and this.

We know that we mean this particular word, not in anything you want. Because then is

up in this list then anything you want called e2 then exactly else cause that's

up in this list and then an e3 then it matches and the way to transform it is

into this if e1, e2, e3 where kind of line pattern matching expect we're defining a

macro here this E1 is whatever expression was here this e2 is whatever expression

was here and this e3 is whatever expression was here. So this really does

work. Right? If I say my if of true. And plus 3, 4 and 72, I'll get back 7. if I

remember to write them in else. If not, as you see there, you get an error message

that says. I know you're using the my-if macro. But none of the ways I know how to

expand my if match. Because the one rule we have requires then and else in

positions 3 and 5. So there I get 7. There's other things you could screw up.

Maybe you put then here, and then it won't match in so, okay? So we really have

defined our own macro. To us, it's not like my-if is in the language. It will get

expanded to an if and then evaluated whenever we use, okay? So let's do another

one, and now let's do this comment out one. So the idea here is that if you have

something like comment-out how about car of null and then plus 3 4. That this

should macro expand to just plus 3 4 completely throwing away the first line,

and so it's, it's like you didn't have that first one there. So it's really the

same idea. Define syntax, the name of our macro. Syntax rules.

We don't have any extra words here, but you still have to have the list, so just

make it empty, left parenthesis, right parenthesis. Our one case. And then when

we see parentheses comment out 1 thing and then another thing. this is like e1 and

e2, whatever those are, just replace it with the 2nd thing. You'll notice by the

way I did not have these parentheses in here, that would add a calling instead as

a function. And that is not what I want. Alright, so let's try this one out. how

about I just paste down here exactly what we had. I think I'm missing oh, and then

delete this, and I get 7, keeping in mind that car null would be an error, ok? So

that's a couple examples. let me flip back to the slides for our. Third example.

I want to redo My-delay, and My-force from when we studied promises. So, here on this

slide you see how we used to do it. My-delay and My-force were functions.

My-delay took a thunk, returned this mcons, my force took something that was

one of these mcons's and then did the right thing for lazy evaluation. So the

way you would use this, is if you have some function f here at the bottom that

takes in a promise, a caller to f would have to write my-delay of a thunk that

when called evaluates e and then f could force that thing, okay? So what we could

do is define a macro for my-delay, so that programmers don't have to write that

lambda, okay? Whether this is good style or not is somewhat debatable. But we can

do this. It's no problem. A macro can pick up some syntax, put it under a lambda, and

therefore it will delay evaluation, because after macro expansion, it's inside

a function, and functions don't evaluate their bodies until you call them. You

cannot implement this as a function, ok? So here's how the macro looks. If we

define my-delay as a macro. That takes some expression, e, and replaces it with

mcons of false and a thunk that evaluates e, then when we write this my-delay of e,

that will not evaluate e. It will return an mcons. It has a thunk in it that we can

call later to evaluate e. And this simply cannot be done with a function. There is

no function in the world that can take an argument, e, and not evaluate it. Because

in Racket, functions always have their arguments evaluated before you evaluate

the body. So if you want to do this, so that programmers don't write the thunk

when they call my-delay, a macro is really your, your option. That is your approach.

Notice that having done it this way, we do not thunk the argument. If the programmer

comes along and does write lambda parenthesis, parenthesis e, well now we're

going to have a double thunk. We're going to have a thunk that when you call it

returns a thunk. So you have to keep things straight. We are changing, how

clients. Should use my delay by using this macro. So what about my force? Let me just

go back here in a second. We had this function, my force. Should it be a macro?

But I want to argue is that it should not. This is a perfectly good function. We want

to just pass in something, have it use that You should leave it as a function. So

let me show that with a code, so here I've got my delay, just like we defined it.

Suppose you tried to do my force as a macro. So you just said all right, they

can call my force with an e, and I'll expand that I will syntactically replace

that with this if. What's the problem? The problem is now whatever they passed in, is

going to get evaluated multiple times. That's not how the function works. Let me

show this to you. If I call my-force, this is the function version, with some

argument that has some side-effect, like printing hi, and then. has a promise in

it. My-delay, this is a macro now so my-delay of plus 3 4. Print hi once

evaluate to 7. But with this first macro version. , It prints "hi" five times.

It's actually hard to think about how many times it would actually print it. it

depends on this, but what we're doing is we're picking up this syntax and copying

it into. This expansion. Macros are hard to reason about you don't

want to do that. Here's a second version of the macro that actually does the right

thing and it does it by taking in an E and creating a local variable that holds the

results of evaluating E. So, that will evaluate E only once and then we just use

X everywhere. And this macro will behave. How we want, which is to evaluate e once,

and then do the right thing with the result. But there's just no reason to do

this. Using a macro, just to have the exact same semantics as a function. Serves

no useful purpose. So that's why I don't mind my-delay as a macro, but I don't want

my-force as a macro. 'Kay? So, what we've seen here are the basics of

syntax rules, how to use define syntax to define macros. We've often, also started

to see, with this first my-force. The danger of not thinking carefully about

when you evaluate things and how many times you evaluate things, and we'll

continue our study of that in the next segment.

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.

© 2018 Coursera Inc. All rights reserved.

Download on the App Store

Get it on Google Play