Lecture 4.6 - Combinators on Futures 1

Loading...

From the course by École Polytechnique Fédérale de Lausanne

Functional Program Design in Scala

2250 ratings

École Polytechnique Fédérale de Lausanne

Functional Program Design in Scala

2250 ratings

Course 2 of 5 in the Specialization Functional Programming in Scala

In this course you will learn how to apply the functional programming style in the design of larger applications. You'll get to know important new functional programming concepts, from lazy evaluation to structuring your libraries using monads. We'll work on larger and more involved examples, from state space exploration to random testing to discrete circuit simulators. You’ll also learn some best practices on how to write good Scala code in the real world. Several parts of this course deal with the question how functional programming interacts with mutable state. We will explore the consequences of combining functions and state. We will also look at purely functional alternatives to mutable state, using infinite data structures or functional reactive programming. Learning Outcomes. By the end of this course you will be able to: - recognize and apply design principles of functional programs, - design functional libraries and their APIs, - competently combine functions and state in one program, - understand reasoning techniques for programs that combine functions and state, - write simple functional reactive applications. Recommended background: You should have at least one year programming experience. Proficiency with Java or C# is ideal, but experience with other languages such as C/C++, Python, Javascript or Ruby is also sufficient. You should have some familiarity using the command line. This course is intended to be taken after Functional Programming Principles in Scala: https://www.coursera.org/learn/progfun1.

From the lesson

Timely Effects

This week we'll learn a number of important programming patterns via examples, starting with the observer pattern, and then going on to functional reactive programming. We'll learn how latency can be modeled as an effect, and how latency can be handled with Scala's monadic futures. We'll learn the important combinators on futures as well as how they can be composed to build up rich and responsive services.

Lecture 4.1 - Imperative Event Handling: The Observer Pattern12:27

Lecture 4.2 - Functional Reactive Programming20:23

Lecture 4.3 - A Simple FRP Implementation19:32

Lecture 4.4 - Latency as an Effect 17:33

Lecture 4.5 - Latency as an Effect 212:46

Lecture 4.6 - Combinators on Futures 19:20

Lecture 4.7 - Combinators on Futures 27:07

Lecture 4.8 - Composing Futures 14:03

Lecture 4.9 - Implementation of flatMap on Future3:46

Lecture 4.10 - Composing Futures 28:03

Meet the Instructors

Martin Odersky
Professor
Computer Science

Welcome back to our discussion about futures.

And I left you a little bit in the dark the last time,

when I showed you how to express reading from memory

followed by sending the packets from The US and Europe back with futures.

And I don't know if you remember.

But our code looked a little bit like a mess.

Where we couldn't get, you know, everything to wire up together.

But fortunately, futures have a.

A lot of higher order operators defined on them.

And you will recognize the same higher order operators that we saw on try and

that we see on list and that we see many,

many times everywhere such as filter, flatMap.

And then of course there are certain domain-specific

operators that are only defined on future.

And that one is recover width.

And recover width there, you see,

takes a partial function, that takes a throwball, and returns a future.

All right?

And there we have our friends the future constructor.

Now let's see how we can use this to improve our code.

This is what we were stuck with.

We read from memory.

That packet onComplete.

And then we had the confirmation of the right type.

But it's all this pattern matching and nesting.

It just looks messy.

This is not code that looks beautiful and elegant.

And if we're doing functional, programming style coding,

one of the main things that we want to achieve is that the code looks elegant.

This doesn't look elegant.

How can we improve that?

By using flat map.

So flat map, again, will hide all this plumbing and

better matching for us such that we can ride nice smooth straight line code.

So, let's use flat map and here we go What we do is we read from memory.

We get a future of array of bytes that's called that packet.

And then we just flat map over that.

So flat map will take a future array of bytes and

give us in that function p is now of type array of bytes.

And now we can send it to Europe which would return a future of array of bytes.

And the type of flat map go here, will all work out.

So I'm pretty sure that you agree that

this code looks messy, and this code looks beautiful.

So again, flat map comes to the rescue.

All right, now let's dive in a little bit and

look kind of how packets are sent under the covers.

Again, this is all and the reason is that we need some

concrete code to build some examples But this is, of course, not production code.

But let's look here.

Imagine that we have an imaginary HTTP library that has a constructor.

That, given a URL and a request, will return a response.

Now, an HTTP library is probably going to make a call across a network.

So the result of calling apply on HTTP will be a future of a response.

And it runs an HTTP request asynchronously.

We don't care.

As long as, given the URL and the request, we now get a future of a response.

Now how can we implement sent packet from the U.S. to Europe and back with this?

We first create a URL to some server in Europe.

We create a regress from the packet.

And then recall that we could then filter such that the response is okay.

And then we map the response back to an array of bytes.

Now this is still not safe in the general sense because it can still fail.

Because maybe, the packet, the network is down so

this packet will not reach Europe.

So let's try to make this code more resilient, all right?

So we want to make 100% sure that when we send the packet,

that it actually reaches, the server in Europe.

One way to do that is, why don't we send this packet kind of twice.

All right, to two different servers.

So here is what we do,

we send the packet to a mail server in Europe.

We send the packet to a mail server in the U.S. Just, you know, to be safe.

And then we zip The confirmations to get the a pair of

the response from sending the packet to Europe and

the response from sending the packet to the U.S. Right?

So now we should be safe because of our something it's kind of twice.

But is this any better really?

Well not, because if you remember what ZIP does with lists,

ZIP, if it takes an empty list and another list, it will just return the empty list.

So, ZIP will always confirm to the shortest list.

That you're zipping.

And the same is true when you're zipping two futures.

In that case, the error case is the empty list, and

the success case is the non-empty list.

So when I'm zipping two futures, and one of them fails, the whole zip will fail.

So even though I'm doing a lot of work to send this packet

to both Europe and back it doesn't help me

because the zip will fail when one of them fails.

All right, so this is not very resilient.

There was these two functions.

The one that I showed you but there's another one.

recoverwith and recover.

And you can see that recoverwith looks a little bit like a flat map.

Because it takes a function that takes an exception and returns a future.

So it's going to be the error case for flat map and

then we have recover which takes its role every.

Which is kind of the map for the error case.

So let's see if we can use these functions to write a more resilient

version of sending packets.

All right, so there was our old version.

We would just kind of send it.

What we're going to do now is we're going to send the packet to Europe first.

When that fails, we use recoverWith Okay, and then what we get,

is we get a function from to Future of T, right, that's what we need.

So then we just send it to Europe.

And then, or sorry, to the US.

and when that fails, we just return the Array message, with recover,

and if it succeeds, You know, we're done.

All right?

Now the problem with this code is that we're really

trying to send the packet to Europe, but when it goes

wrong sending it to the U.S. we get the error message for the U.S.

So this code is still not really good.

But it's already much better than our naive attempt, right?

The thing here that I want to focus on is that recover and recover with

are like the map and the flat map, but then for the error case of the future.

All right?

So instead of getting the value, they get the exception.

But then the signatures are the same for the rest.

So there's an error channel and a regular channel.

And they have the same operators defined.

On then.

All right.

We're going to revisit this code in the next section.

And then we're going to to do a little bit of geeking out and

trying to do some hipster functional programming.

So see you soon.

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