Closure Idiom: Callbacks

Loading...

From the course by University of Washington

Programming Languages, Part A

818 оценки

University of Washington

Programming Languages, Part A

818 оценки

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. 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 3 and Homework 3 -- and Course Motivation

This section is all about higher-order functions -- the feature that gives functional programming much of its expressiveness and elegance -- and its name! As usual, the first reading below introduces you to the section, but it will make more sense once you dive in to the lectures. Also be sure not to miss the material on course motivation that we have put in a "lesson" between the other videos for this week and the homework assignment. The material is "optional" in the sense that it is not needed for the homeworks or next week's exam, but it is still very highly encouraged to better understand why the course (including Parts B and C) covers what it does and, hopefully, will change the way you look at software forever.

Meet the Instructors

Dan Grossman
Professor
Computer Science & Engineering

We can now move on to our next closure idiom which are callbacks.

Callback style programming is very common these days.

The idiom we're using here is that someone writes a library that takes in from

clients functions that should be called later when some sort of event occurs.

So example libraries are things that

control the keyboard or the mouse or when data arrives from the network.

So programs may want to know.

may want to act on,

keys being pressed on the keyboard.

And so what they will do is pass to

the library code that should execute when a key is pressed.

So we really want first class functions for this so we can pass in

some code that should be called later when an event occurs.

And that's called a callback.

That doesn't have to be this out external data like a keyboard or data from the network.

Sometimes we write games in this style.

Some player in the game maybe an automatic player should register

code that should be called when it's

that player's turn to move around in some virtual world.

Now the way these library should work is they should accept multiple callbacks.

There may be many different parts of the program that all need to know when keys are

pressed on the keyboard and they need different data to act on.

So we don't just need to pass first class functions.

They need to be closures so that each client passing

in a callback can use the private data,

the bindings in the environment where the function was defined,

to have access to the data it's going to need when the callback executes.

So this is where closures are really valuable.

It's important that that private data not show up in the type of the callback

because the library implementer has no idea what that data should be.

Now object-oriented languages for those of

you that are used to them also handle callbacks,

they do it with objects.

I find closure is just as elegant if not more

elegant and you can learn the idea of callbacks either way.

So since we're setting functional languages here we'll do it that way.

So we are going to use mutable state in

our library and I'm going to argue that's appropriate here.

Our library is going to keep track of all the callbacks that have been registered,

all the code that should execute when an event occurs.

And when a new one gets registered we really do want to

update state so that we can have more things,

you know, we can keep track of what we are supposed to do.

So our library is going to maintain that mutable state for what callbacks are

there and it's going to provide a function for

adding a new one to that mutable collection.

Now real library of course would have lots of other features

like for removing a callback that was previously added.

And we're just going to take a very simple approach that what

clients are going to pass us are functions of type int arrow unit.

So you can think of that int as encoding which key on the keyboard was pressed.

Maybe A is one,

B is two, that sort of thing.

So the only public interface to our library is going to be this function onKeyEvent.

It's going to say when a key event occurs you want me to call

this int arrow unit you passed and I will give back

to you the int corresponding to what key was pressed.

So onKeyEvent takes an int arrow unit,

there's no result here,

the unit type has no useful content.

And the result of onKeyEvent is just the side effect that I'll call you back later.

So there is no useful result.

So the result here is also unit.

Okay? So that's the entire interface.

Now we just need a library that will implement that interface.

So here it is, it's in the code file as well but it all fits on the slide.

The library is going to internally maintain

a mutable reference that holds a list of all the callbacks that have been registered.

So we'll initialize that mutable reference to

have contents empty list because none have been added yet.

Then when someone calls onKeyEvent with a function we will assign to cbs,

for callbacks, this list which is made out

of consing f onto the previous contents of cbs.

So this is updating cbs to refer to a list with one more element than it used to.

Perfect. Then when some event actually occurs,

so you know the key is actually pressed.

Let's assume that this function on event is called with a number.

I'm not actually going to show you in ML how to actually hook up to the keyboard.

We're going to fake it through this function,

we're just simulating the idea.

And all this function does,

I will not explain the details to you,

is take the contents of cbs as you see here with

the exclamation point and go through and call each of the functions.

Right? So for each function in that list we will call it

with i that's exactly what a callback library is supposed to do.

So that's the library.

And remember all clients are going to do is call onKeyEvent with appropriate functions.

So here are a couple example clients

and they're always going to pass enclosures that do what they need to do.

So here's my first client here OnKeyEvent.

It actually ignores the integer it's given and all it

does is increment this timesPressed variable.

So the reference that timesPressed refers to.

So timesPressed refers to an int ref,

the contents are initially zero and we register here a callback that every

time it's called it takes timesPressed and

updates it to previous contents of timesPressed plus one.

So this is a logger that is counting how many times keys have been pressed.

Here I have a function that every time you call it registers a callback.

And what it does is when you call printIfPressed with

i it registers a callback that says i,

if you give me back j,

so j was the key that was pressed.

If i equals j I'll print out a message saying you pressed i,

otherwise I'll do nothing.

I only care about the cases where it's i that was pressed.

All right. So that's all good.

Over here in the code I have

all the code I just showed you exactly how I showed it to you.

And then here at the bottom I used that function printIfPressed

to add four more callbacks one for four.

So that will print out you pressed four if indeed four was pressed,

one for 11, one for 23, one for four.

And so with this one up here that keeps track of how many have been pressed we'll have

five total callbacks registered because we call

onKeyEvent five times so that list will have five things in it.

So let's just load it all up and it all loads it's all fine.

We can see that by the time the REPL prints cbs the contents actually is five functions,

it's a list with five elements.

And nothing has been printed yet.

And if I ask timesPressed I get zero because there haven't been any events yet.

So now we're going to simulate events happening with this onEvent function.

So when I call onEvent with a number it's going to pass

that number back to all the closures that were registered with OnKeyEvent.

So if I pass in 11 it prints you pressed 11,

because one of those five callbacks chose to print that.

The other printIfPressed did nothing.

TimesPressed by the way is now one.

So it really did call that code.

We could do onEvent 79, nothing gets printed.

No one wanted to print that.

We could do onEvent four,

that prints it twice because two of

our callbacks chose to print that string. So that's fine.

We could do onEvent 23, it prints once.

We could at any time ask timesPress that's been incremented every

time thanks to one of our callbacks and four because we did four events.

I think we did 11, 79,

four, and 23. All right? So that's callbacks.

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2018 Все права защищены.

Загрузить из App Store

Загрузить в Google Play