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.