Lecture 1.3 - Evaluation Strategies and Termination

Loading...

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

Functional Programming Principles in Scala

6186 ratings

École Polytechnique Fédérale de Lausanne

Functional Programming Principles in Scala

6186 ratings

Course 1 of 5 in the Specialization Functional Programming in Scala

Functional programming is becoming increasingly widespread in industry. This trend is driven by the adoption of Scala as the main programming language for many applications. Scala fuses functional and object-oriented programming in a practical package. It interoperates seamlessly with both Java and Javascript. Scala is the implementation language of many important frameworks, including Apache Spark, Kafka, and Akka. It provides the core infrastructure for sites such as Twitter, Tumblr and also Coursera. In this course you will discover the elements of the functional programming style and learn how to apply them usefully in your daily programming tasks. You will also develop a solid foundation for reasoning about functional programs, by touching upon proofs of invariants and the tracing of execution symbolically. The course is hands on; most units introduce short programs that serve as illustrations of important concepts and invite you to play with them, modifying and improving them. The course is complemented by a series programming projects as homework assignments. 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.

From the lesson

Getting Started + Functions & Evaluation

Get up and running with Scala on your computer. Complete an example assignment to familiarize yourself with our unique way of submitting assignments. In this week, we'll learn the difference between functional imperative programming. We step through the basics of Scala; covering expressions, evaluation, conditionals, functions, and recursion

Lecture 1.1 - Programming Paradigms14:32

Lecture 1.2 - Elements of Programming14:25

Lecture 1.3 - Evaluation Strategies and Termination4:22

Lecture 1.4 - Conditionals and Value Definitions8:49

Lecture 1.5 - Example: square roots with Newton's method11:25

Lecture 1.6 - Blocks and Lexical Scope8:00

Lecture 1.7 - Tail Recursion12:32

Meet the Instructors

Martin Odersky
Professor
Computer Science

In the last session, we have explored a formal model of evaluation of expressions

which was called the substitution model. And we have seen that there's more than

one way to evaluate an expression. We have identified the call by name and

call by value evaluation strategies. And in this session, we're going to

compare them a little bit further in particular in what regards termination.

If you look at call by name and call by value and how their related termination

then, we know that both of our reevaluation strategies will always reduce

the same value provided term evaluations terminate.

But, what if evaluations do not terminate? We have seen in the last session that some

of the expressions actually do not give a value in a finite number of steps.

So, there we have an important theorem which says that if the call by value

evaluation of an expression terminates, then the call by name evaluation of that

same expression will terminate also. And furthermore, the other direction is

not true. So, call by name termination does not

imply call by value termination. So, let's see an example.

Can we find an expression that terminates on the call by name, but not on the call

by value? Okay, so let's see how we would go about

that. We define a function first that takes

simply two parameters, x and y and returns the first one x, so it forgets about y.

And then, we consider the expression first of one and loop, so we pass a

non-terminating computation into the second parameter.

And a call by name, what, what will happen?

Well, call by name will reduce the first expression without reducing the argument.

So, it would just yield one in a single step, the first argument.

And the variation would stop in a value, obviously.

And a call by value, we have to reduce the arguments to this expression so we have to

reduce loop. And, well, we know that loop reduces to

itself, so we would reduce the arguments. Infinitely often, the whole expression

would always reduce to itself and we would make no progress.

So, that's another example of an infinite loop.

In Scala, we normally use call by value. You might ask, well, given the advantages

of call by name that it terminates more often, why call by value?

Well, it turns out that, for expressions in practice, call by value is often

exponentially more efficient than call by name because it avoids this repeated

recomputation of argument expressions that call by name entails.

The other argument for call by value is that it plays much nicer with, imperative

effects and side effects because you tend to know much better when expressions will

be evaluated. Since Scala is also an, an imperative

side, call by value is the standard choice.

Except that, sometimes you really want to force call by name, and Scala lets you do

that also. You do that by adding a, an arrow in front

of the parameter type. So, this function constOne takes an x

parameter int and a y parameter of type arrow int.

And that means that the parameter y is also an int, but it will be past call by

name. So, to demonstrate the difference between

the two parameters, let's trace the evaluations of two expressions, constOne

one plus two loop, and constOne of loop and one plus two.

So, the first one, constOne, one plus two loop is, well the first parameter is call

by value, so we have to reduce that to three, so that will be three and the rest

will be kept as it was before. The second parameter, we do not need to

reduce because it's a call by name parameter, so we are done with the

argument lists. We can apply the function and the function

would just always reduce to one. So, it would in fact, would ignore both of

it's parameters. That's the first expression.

The second expression here we would have constOne of loop and one plus two.

While here we have to reduce the first argument because it's call by value, and

we get into the same situation that loop produces to itself.

So, no progress and we get another infinite cycle.

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.

Download on the App Store

Get it on Google Play