Folding Unfolded - Polyglot FP for Fun and Profit - Haskell and Scala - Part 4

Can a le# fold ever work over an inﬁnite list? What about a right fold? Find out.
Learn about the other two func8ons used by func8onal programmers to implement matherma2cal induc2on: itera2ng and scanning.
Learn about the limita8ons of the accumulator technique and about tupling, a technique that is the dual of the accumulator trick.
Part 4 - through the work of
Folding Unfolded
Polyglot FP for Fun and Proﬁt
Haskell and Scala
@philip_schwarzslides by h"ps://www.slideshare.net/pjschwarz
Richard Bird
h*p://www.cs.ox.ac.uk/people/richard.bird/
Tony Morris
@dibblego
h*ps://presenta9ons.tmorris.net/ Sergei Winitzki
sergei-winitzki-11a6431

As promised at the end of Part 3, let’s now resume looking at Tony’s talk.
We last saw him using foldr to implement the ﬂa.en func9on. In the
next slide he uses foldr to implement the ﬁlter func9on.

Filter is a li:le bit ugly. Who’s never heard of the filter func@on? Everyone has heard of it. They are talking about it outside
right now. Filter. We are going to take a predicate and keep the elements that match that predicate. It gets a bit tricky.
What are we going to replace 𝑪𝒐𝒏𝒔 with? We want to take the head at that 𝑪𝒐𝒏𝒔, the A or the B or the C or whatever, and
we want to check if it matches a predicate. And if it does, we are going to 𝑪𝒐𝒏𝒔 that value back on again. If it doesn’t, we are
just going to leave it off and then move on to the next 𝑪𝒐𝒏𝒔 cell.
So we want to say, given x, the element that I am visi@ng, if it matches the predicate, then 𝑪𝒐𝒏𝒔 x, otherwise do nothing, id,
the iden2ty func2on. And replace 𝑵𝒊𝒍 with 𝑵𝒊𝒍.
filter a list on predicate (p)
Supposing
list = 𝑪𝒐𝒏𝒔 A (𝑪𝒐𝒏𝒔 B (𝑪𝒐𝒏𝒔 C (𝑪𝒐𝒏𝒔 D 𝑵𝒊𝒍)))
Tony Morris
@dibblego
right folds replace constructors
Let’s filter a list on predicate
• let 𝑪𝒐𝒏𝒔 = x -> if p x then 𝑪𝒐𝒏𝒔 x else id
• let 𝑵𝒊𝒍 = 𝑵𝒊𝒍

So, if you ever see this code, you’ll know that it is filtering a list. Replace 𝑪𝒐𝒏𝒔 with (x -> if p x then 𝑪𝒐𝒏𝒔 x
else id) and 𝑵𝒊𝒍 with 𝑵𝒊𝒍.
I happen to have a par@cular aversion to the if then else construct by the way. I wish it would die. It takes three arguments
for a start. And for those who a:ended yesterday, what are my favourite func@ons? How many arguments do those take?
One. So I don’t like that one.
There is a func@on that does if then else that does take one argument. It is called bool. I have used it here. And it does if
then else with the arguments the right way. There is a right way. It says, if (p x), then (𝑪𝒐𝒏𝒔 x), else id.
That takes one argument. The reason I like that func@on is because I can get down to that point there (last line above), and
that point means I don’t have to name so many iden@fiers. That’s just my goal in life. That’s not really the point. The point is
that I can do that. I can look at this code and I can say: replace 𝑪𝒐𝒏𝒔 with (bool id . 𝑪𝒐𝒏𝒔 <*> p) and 𝑵𝒊𝒍 with
𝑵𝒊𝒍. What is it going to do? It is going to filter the list on p. OK?
Supposing
applyp = if p x then 𝑪𝒐𝒏𝒔 x else id
list = applyp A (applyp B (applyp C (applyp D 𝑵𝒊𝒍)))
filter p list = foldr (x -> if p x then 𝑪𝒐𝒏𝒔 x else id) 𝑵𝒊𝒍 list
filter p = foldr (x -> if p x then 𝑪𝒐𝒏𝒔 x else id) 𝑵𝒊𝒍
filter p = foldr (x -> bool id (𝑪𝒐𝒏𝒔 x) (p x)) 𝑵𝒊𝒍
filter p = foldr (bool id . 𝑪𝒐𝒏𝒔 <*> p) 𝑵𝒊𝒍
Tony Morris
@dibblego

If you found it challenging at all to understand how that last refactoring of the defini@on of filter works, i.e. what the <*>
operator is doing in the refactored defini@on, then you are not alone.
filter p = foldr (x -> bool id (𝑪𝒐𝒏𝒔 x) (p x)) 𝑵𝒊𝒍
filter p = foldr (bool id . 𝑪𝒐𝒏𝒔 <*> p) 𝑵𝒊𝒍
I am familiar with <*> as Applicative’s apply func@on, which takes a func@on in a context and the func@on’s argument in that
context and returns the result of applying the func@on to its argument, also in that context.
e.g. if I define func@on inc x = x + 1, then if inc is in a Maybe context and 3 is also in a Maybe context, I can use <*> to
apply inc to 3 and return the result 4 in a Maybe context:
> Just inc <*> Just 3
Just 4
Similarly for a List context:
> [inc] <*> [3]
[4]
Well, it turns out that a func@on is also an Applicative, so if I have a func@on f::a->b->c and a func@on g::a->b then I can
use <*> to create a func@on h::a->c which passes its argument a to both f and g as follows: f a (g a).
e.g.
> ((+) <*> inc) 3
7
instance Functor ((->) a) where
fmap = (.) (a -> b) -> (r -> a) -> r -> b
instance Applicative ((->) a) where
pure = const a -> r -> a
(<*>) f g z = f x (g x) (r -> (a -> b)) -> (r -> a) -> r -> b
…
<*> :: (r -> (a -> b)) -> (r -> a) -> r -> b
inc :: Num a => a -> a
(+) :: Num a => a -> a -> a
<*> is called apply or ap, but is also known as the
advanced 2e fighter (|+| being the plain 2e
fighter), the angry parent, and the sad Pikachu.
Tie fighter
advanced
Tie fighter
@philip_schwarz

We are using <*> to produce the 𝛼 → 𝛽 → 𝛽 func@on that we need to pass to 𝒇𝒐𝒍𝒅𝒓
𝒇𝒐𝒍𝒅𝒓 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → 𝛽
to be able to implement filter as follows
filter p = 𝒇𝒐𝒍𝒅𝒓 (bool id . (:) <*> p) []
If we take the signature of <*>
<*> ::(r -> (a -> b)) -> (r -> a) -> r -> b
and make the following subs@tu@ons
a = Bool
b = [a] -> [a]
r = a
we can understand the signature in our context and see the types that <*> is opera@ng on
<*> ::(a -> (Bool -> [a] -> [a])) -> (a -> Bool) -> a -> [a] -> [a]
--------------------------- ----------- ---------------
bool id . (:) even f
That’s why we are able to refactor
x -> bool id ((:) x) (p x)
to
bool id . (:) <*> p
> :type bool id
bool id :: (a -> a) -> Bool -> a -> a
𝒇𝒐𝒍𝒅𝒓 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → 𝛽
𝒇𝒐𝒍𝒅𝒓 𝑓 𝑒 = 𝑒
𝒇𝒐𝒍𝒅𝒓 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑓 𝑥 𝒇𝒐𝒍𝒅𝒓 𝑓 𝑒 𝑥𝑠
> :type (:)
(:) :: a -> [a] -> [a]
> :type (bool id) . (:)
(bool id) . (:) :: a -> Bool -> [a] -> [a]
bool :: a -> a -> Bool -> a
Case analysis for the Bool type. bool x y p evaluates to x when p is False and evaluates
to y when p is True.
This is equivalent to if p then y else x; that is, one can think of it as an if-then-else
construct with its arguments reordered.
> inc x = x + 1
> Just inc <*> Just 3
Just 4
> [inc] <*> [3]
[4]
> ((+) <*> inc) 3
7
> ((+) <*> inc) 3 == (+) 3 (inc 3)
True
>

true = λx.λy.x
if C then P else Q à λc.λp.λq.cpq
Condi&onal Execu&on in the Lambda Calculus
false = λx.λy.y
true 3 4 ----β---> 3
false 3 4 ----β---> 4
For what it is worth, the order of the arguments of a condi@onal if C then P else Q does not
look so ‘wrong’ to me if I think that in the lambda calculus, true is a binary selector func2on
returning its ﬁrst argument, false is a binary selector func2on returning its second argument,
and the condi2onal func2on is one that takes a truth-valued condi2onal expression and two
other alterna2ve expressions and applies the selector func2on that is the result of the ﬁrst
expression to the two other expressions, which results in the selector func2on selec@ng one
of the alterna2ve expressions for evalua@on.
NOTE: Lazy evalua2on is required to stop alterna2ve expressions P and Q from both being
evaluated before they are passed to the selector func@on that is the value of the condi2onal
expression.

Tony’s talk now turns to a very interes9ng subject which is a bit advanced and which we are
going to cover separately in an upcoming part of this series, so we are now going to skip the next
sec9on of his talk and jump to its ﬁnal part, in which he uses foldr to implement a func9on
called heador and also recaps on some of the key things that we have learned in his talk.

I find this one quite interes@ng. So what this func@on does, is it takes an element a, and a list of as, and it returns the first
element out of the list. The first element. But it could be 𝑵𝒊𝒍. And if it’s 𝑵𝒊𝒍 return the other element that I passed in as an
argument. OK, so if this list is 𝑵𝒊𝒍, return the a that is the first argument, otherwise return the first a in the list.
What am I going to replace 𝑪𝒐𝒏𝒔 with? const. const the first argument. I agree. And 𝑵𝒊𝒍? That value there, that’s the thing
that we are returning if 𝑵𝒊𝒍, right? So given an en@re list, if you ever see 𝑵𝒊𝒍, return that value, but if you see 𝑪𝒐𝒏𝒔, then
return the value that is si_ng right at the head of that 𝑪𝒐𝒏𝒔. That will do exactly what our requirements is for this func@on.
So given this list
I want to return A, that’s the first element of that list. Here is a func@on that given the A, and then the rest of the stuff aèr
the 𝑪𝒐𝒏𝒔, just returns A. Replace 𝑪𝒐𝒏𝒔, with that. And replace 𝑵𝒊𝒍, with that default value that came in as an argument.
That will do what it is we need to do.
The head of a list, or default for no head
Supposing
Tony Morris
@dibblego
right folds replace constructors
Let’s get the head of a list, or a default for no head
:: a -> List[a] -> a
• let 𝑪𝒐𝒏𝒔 = x _ -> x
• let 𝑵𝒊𝒍 = the default

So there is the code.
So who remembers wri@ng heador yesterday, in the workshop? We wrote heador, right? This is heador. And we did it with
pa:ern matching and all of that. We could have just wri:en this: fold right, const, or constant, with that argument.
Tony Morris
@dibblego
Supposing
constant x _ = x
heador thedefault list = foldr constant thedefault list
heador thedefault = foldr constant thedefault
heador = foldr constant
From https://hoogle.haskell.org/?hoogle=const:
const x is a unary function which evaluates to x for all inputs.
>>> const 42 "hello"
42
>>> map (const 42) [0..3]
[42,42,42,42]

Fold right may work on an infinite list. So if I had the list from zero to infinity, and I said, call that heador func@on back
here
So here is a list, zero to infinity, and I say OK, pass some number in here, say four, I should get back zero, right? Because that
is the first element of the list zero to infinity. OK? Do you want to see some code? This is an infinite list of ones:
You might not believe me, in which case, do you believe me now?
Observa9ons
• There is no order specified, however, there is associa9vity.
• foldr may work on an infinite list.
• ?
Tony Morris
@dibblego
heador thedefault list = foldr constant thedefault list
heador thedefault = foldr constant thedefault
heador = foldr constant
$ infinity
[1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1
etc, etc
$ infinity = 1 : infinity

OK, so, heador 99 infinity.
This will not go all the way to the right of that list, because when it gets there, there is just a 𝑪𝒐𝒏𝒔 all the way. So I should
get 1. And I do:
Fold right just worked on an infinite list. What’s the complexity of heador? O(1). So, whether or not fold right will work on
an infinite list depends on the strictness of the func@on that we are replacing 𝑪𝒐𝒏𝒔 with.
const, the func@on I just used, is lazy, it ignores the second argument, and therefore it works on an infinite list.
Tony Morris
@dibblego
$ heador a = foldr const a
$ heador 99 infinity
1
$
$ heador 99 infinity
Observa9ons
• Depends on the strictness of the given func9on.
• ?

It only replaces 𝑵𝒊𝒍 if 𝑵𝒊𝒍 ever comes to exist. It doesn’t exist in inﬁnity.
How about this func@on: foldr 𝑪𝒐𝒏𝒔 𝑵𝒊𝒍 ? Leave the list alone. Replace 𝑪𝒐𝒏𝒔 with 𝑪𝒐𝒏𝒔 and 𝑵𝒊𝒍 with 𝑵𝒊𝒍. It does
nothing to the list. It’s an iden2ty func2on. What’s the func@on that gives me an iden@ty for bool? That’s an interes@ng
ques@on? I just showed it to you. I’ll let you think about that.
Tony Morris
@dibblego
Observa9ons
• Replaces the 𝑵𝒊𝒍 constructor if it ever comes to exist
?
Observa9ons
• Replaces the 𝑵𝒊𝒍 constructor if it ever comes to exist
• The expression foldr 𝑪𝒐𝒏𝒔 𝑵𝒊𝒍 leaves the list unchanged.
• In other words, passing the list constructors to foldr produces an iden%ty func9on

Tony just explained that doing a right fold with 𝑪𝒐𝒏𝒔 and 𝑵𝒊𝒍
produces the iden2ty func2on.
In Parts 1 and 3 we saw that doing a leG fold with a ﬂipped 𝑪𝒐𝒏𝒔
and with 𝑵𝒊𝒍 produces the reverse func@on.
The next slide illustrates the above.
@philip_schwarz

∶
/
𝑥1 ∶
/
𝑥2 ∶
/
𝑥3 ∶
/
𝑥4
‥
/
‥ 𝑥4
/
‥ 𝑥3
/
‥ 𝑥2
/
[ ] 𝑥1
∶
/
𝑥4 ∶
/
𝑥3 ∶
/
𝑥2 ∶
/
𝑥1
𝑥4 ∶ (𝑥3 ∶ 𝑥2 ∶ 𝑥1 ∶ )
∶
/
𝑥1 ∶
/
𝑥2 ∶
/
𝑥3 ∶
/
𝑥4
𝑥1: (𝑥2: 𝑥3: 𝑥4: )
(( ‥𝑥1 ‥𝑥2)‥𝑥3)‥𝑥4
var acc = [ ]
foreach(x in xs)
acc = acc ‥x)
return acc
𝑓𝑜𝑙𝑑𝑟 ∶ 𝑥𝑠
𝑓𝑜𝑙𝑑𝑙 ‥ 𝑥𝑠
𝑥𝑠 = [𝑥1, 𝑥2, 𝑥3, 𝑥4]
𝑓𝑜𝑙𝑑𝑟 ∶ = 𝑖𝑑𝑒𝑛𝑡𝑖𝑡𝑦 = 𝑓𝑜𝑙𝑑𝑟 λ𝑥. λ𝑦. 𝑥 ∶ 𝑦
𝑓𝑜𝑙𝑑𝑙 ‥ = 𝑟𝑒𝑣𝑒𝑟𝑠𝑒 = 𝑓𝑜𝑙𝑑𝑙 λ𝑥. λ𝑦. 𝑦 ∶ 𝑥
𝑓𝑜𝑙𝑑𝑟 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → 𝛽
𝑓𝑜𝑙𝑑𝑟 𝑓 𝑒 = 𝑒
𝑓𝑜𝑙𝑑𝑟 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑓 𝑥 𝑓𝑜𝑙𝑑𝑟 𝑓 𝑒 𝑥𝑠
𝑓𝑜𝑙𝑑𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → 𝛽
𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 = 𝑒
𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑓𝑜𝑙𝑑𝑙 𝑓 𝑓 𝑒 𝑥 𝑥𝑠
∶ = λ𝑥. λ𝑦. 𝑥 ∶ 𝑦
‥ = λ𝑥. λ𝑦. 𝑦 ∶ 𝑥
‥ = 𝑓𝑙𝑖𝑝 ∶
𝑤ℎ𝑒𝑟𝑒 𝑓𝑙𝑖𝑝 𝑓 𝑥 𝑦 = 𝑓 𝑦 𝑥
∶
/
ℎ 𝑡
. .
/
𝑡 ℎ
equivalent to
[𝑥4, 𝑥3, 𝑥2, 𝑥1]
𝑖𝑑𝑒𝑛𝑡𝑖𝑡𝑦
𝑟𝑒𝑣𝑒𝑟𝑠𝑒
[𝑥1, 𝑥2, 𝑥3, 𝑥4]
> id = foldr (:) []
> rev = foldl (flip (:)) []
> id [1,2,3,4]
[1,2,3,4]
> rev [1,2,3,4]
[4,3,2,1]
> id = foldr (x y -> x:y) []
> rev = foldl (x y -> y:x) []
> id [1,2,3,4]
[1,2,3,4]
> rev [1,2,3,4]
[4,3,2,1]
𝑟𝑒𝑝𝑙𝑎𝑐𝑒:
∶ 𝑤𝑖𝑡ℎ ∶
𝑤𝑖𝑡ℎ
𝑟𝑒𝑝𝑙𝑎𝑐𝑒:
∶ 𝑤𝑖𝑡ℎ 𝑓
𝑤𝑖𝑡ℎ 𝑒
var acc = e
foreach(x in xs)
acc = f (acc, x)
return acc
folding a list right and le4 using Cons and Nil results in the iden5ty and reverse func9ons

The key intui@on is, the thing to take aways is, a leG fold does a loop, and a right fold does constructor replacement.
If you always remember those two things you’ll never go wrong.
LeG fold will never work on an infinite list. We can see that in the loop. Right fold might. And these are just independent
observa@ons. They have nothing to do with programming languages. I have used Haskell as the example. These things are
independent of the programming language.
So we could solve all these problems, as we just did.
Tony Morris
@dibblego
the key intui9on
• leK fold performs a loop, just like we are familiar with
• right fold performs constructor replacement
from this we derive some observa9ons
• leK fold will never work on an infinite list
• right fold may work on an infinite list
from this we also solve problems
• product
• append
• map
• length
• …
product = foldl (*) 1
append = flip (foldr 𝑪𝒐𝒏𝒔)
map f = foldr (𝑪𝒐𝒏𝒔 . f) 𝑵𝒊𝒍
length = foldl (const . (+ 1)) 0
Summary

I just want to be very clear on this: fold leG does a loop, fold right does constructor replacement, and there are no footnotes
required, this is precise.
I don’t want you to ring me up next week and say ‘you told me it does constructor replacement and it didn’t this @me’. Yes it did. It
always will. OK. There are no footnotes required.
Tony Morris
@dibblego
• intui9vely, this is what list folds do
• foldl performs a loop
• foldr performs constructor replacement
• this intui9on is precise and requires no footnotes
𝑵𝒊𝒍
The End
Thanks!
Summary

In the last part of his talk, Tony explained that whether or not fold right will work on an infinite list depends on the
strictness of the func@on that we are replacing 𝑪𝒐𝒏𝒔 with.
What about in Scala? Is there a no@on of an infinite list? Can a fold right func@on be wri:en which, when used to
replace 𝑪𝒐𝒏𝒔 with a suitable func@on, is able to handle an infinite list?
In Part 1 I said that we weren’t going to be modelling infinity in any of the Scala code in this series of slide decks. I
have changed my mind about that. I do want to look at how to do right folds over large and infinite lists. And the
technique that we’ll be using to do that is also used to address limita@ons in the accumulator technique. So I want
to use it for that too.
Which limita@ons in the accumulator technique I hear you ask? Let’s cover that in this deck. And since we are there,
let’s cover a technique that is the dual of the accumulator trick, i.e. tupling.
And how can an infinite list be created in Scala? We can use the iterate func@on. Let’s cover that in this deck too.
Also, there is something closely related to folding that we have not looked at yet, i.e. scanning. Let’s also cover that
in this deck.
So that means the following subjects will be addressed in Part 5:
• how to do right folds over large and infinite lists
• how to get around limita@ons in the applicability of the accumulator trick

In the next four slides we see how Sergei Winitzki
describe the iterate func@on in his book.

2.3 Converting a single value into a sequence
An aggrega2on converts (“folds”) a sequence into a single value; the opposite opera2on (“unfolding”) converts a single value into
a sequence. An example of this task is to compute the sequence of decimal digits for a given integer:
def digitsOf(x: Int): Seq[Int] = ???
scala> digitsOf(2405)
res0: Seq[Int] = List(2, 4, 0, 5)
We cannot implement digitsOf using map, zip, or foldLeft, because these methods work only if we already have a sequence;
but the func2on digitsOf needs to create a new sequence. We could create a sequence via the expression (1 to n) if the
required length of the sequence were known in advance. However, the func@on digitsOf must produce a sequence whose length
is determined by a condi2on that we cannot easily evaluate in advance.
A general “unfolding” opera2on needs to build a sequence whose length is not determined in advance. This kind of sequence is
called a stream. The elements of a stream are computed only when necessary (unlike the elements of List or Array, which are all
computed in advance). The unfolding opera2on will compute the next element on demand; this creates a stream. We can then
apply takeWhile to the stream, in order to stop it when a certain condi2on holds. Finally, if required, the truncated stream may
be converted to a list or another type of sequence. In this way, we can generate a sequence of ini2ally unknown length according
to any given requirements.
The Scala library has a general stream-producing func2on Stream.iterate. This func2on has two arguments, the ini2al value and a
func2on that computes the next value from the previous one:
scala> Stream.iterate(2) { x => x + 10 }
res0: Stream[Int] = Stream(2, ?)
The stream is ready to start compu2ng the next elements of the sequence (so far, only the ﬁrst element, 2, has been computed). Sergei Winitzki

In order to see the next elements, we need to stop the stream at a finite size and then convert the result to a list:
scala> Stream.iterate(2) { x => x + 10 }.take(6).toList
res1: List[Int] = List(2, 12, 22, 32, 42, 52)
If we try to evaluate toList on a stream without first limi2ng its size via take or takeWhile, the program will keep producing
more elements of the stream un2l it runs out of memory and crashes.
Streams are similar to sequences, and methods such as map, filter, and flatMap are also defined for streams. For instance, the
method drop skips a given number of ini2al elements:
scala> Seq(10, 20, 30, 40, 50).drop(3)
res2: Seq[Int] = List(40, 50)
scala> Stream.iterate(2) { x => x + 10 }.drop(3)
res3: Stream[Int] = Stream(32, ?)
This example shows that in order to evaluate drop(3), the stream had to compute its elements up to 32 (but the subsequent
elements are s2ll not computed).
To figure out the code for digitsOf, we first write this func2on as a mathema2cal formula. To compute the digits for, say, n =
2405, we need to divide n repeatedly by 10, ge_ng a sequence nk of intermediate numbers (n0 = 2405, n1 = 240, ...) and the
corresponding sequence of last digits, nk mod 10 (in this example: 5, 0, ...). The sequence nk is defined using mathema2cal
induc2on:
• Base case: n0 = n, where n is the given ini@al integer.
• Induc2ve step: nk+1 =
nk
10
for k = 1, 2, ...
Here
nk
10
is the mathema@cal nota@on for the integer division by 10.
Sergei Winitzki

Let us tabulate the evalua@on of the sequence nk for n = 2405:
The numbers nk will remain all zeros a`er k = 4. It is clear that the useful part of the sequence is before it becomes all zeros. In this
example, the sequence nk needs to be stopped at k = 4. The sequence of digits then becomes [5, 0, 4, 2], and we need to reverse it
to obtain [2, 4, 0, 5]. For reversing a sequence, the Scala library has the standard method reverse. So, a complete implementa@on
for digitsOf is:
def digitsOf(n: Int): Seq[Int] =
if (n == 0) Seq(0) else { // n == 0 is a special case.
Stream.iterate(n) { nk => nk / 10 }
.takeWhile { nk => nk != 0 }
.map { nk => nk % 10 }
.toList.reverse
}
We can shorten the code by using the syntax such as (_ % 10) instead of { nk => nk % 10 },
def digitsOf(n: Int): Seq[Int] =
if (n == 0) Seq(0) else { // n == 0 is a special case.
Stream.iterate(n) (_ / 10 )
.takeWhile ( _ != 0 )
.map ( _ % 10 )
.toList.reverse
}
Sergei Winitzki

The type signature of the method Stream.iterate can be wriNen as
def iterate[A](init: A)(next: A => A): Stream[A]
and shows a close correspondence to a defini5on by mathema5cal induc5on. The base case is the first value, init, and
the induc5ve step is a func5on, next, that computes the next element from the previous one. It is a general way of
crea5ng sequences whose length is not determined in advance.
I want to show you another example of using iterate. There is one example that I find quite interes9ng,
which is the computa9on of fibonacci numbers using a technique which is called tupling and which is
the dual of the accumulator technique that we have already seen.
Before we can look at that example, we are going to do the following:
• The next two slides are from Part 2 and remind us of how the accumulator technique can
some9mes be used to transform a program so that it becomes tail recursive. Just skip the slides if
they are s9ll fresh in your mind.
• The two slides aKer that, remind us of how the accumulator technique can some9mes be used to
improve the efficiency of a program.
• The subsequent slide briefly explains how the tupling technique can some9mes be used to increase
the efficiency of a program.

The func2on body of lengthS will evaluate the induc2ve step, that is, the “else” part of the “if/else”, about 100_000 2mes. Each
2me, the sub-expression with nested computa2ons 1+(1+(...)) will get larger.
This intermediate sub-expression needs to be held somewhere in memory, un2l at some point the func2on body goes into the
base case and returns a value. When that happens, the en2re intermediate sub-expression will contain about 100_000_nested
func2on calls s2ll wai2ng to be evaluated.
This sub-expression is held in a special area of memory called stack memory, where the not-yet-evaluated nested func2on calls
are held in the order of their calls, as if on a “stack”. Due to the way computer memory is managed, the stack memory has a fixed
size and cannot grow automa2cally. So, when the intermediate expression becomes large enough, it causes an overflow of the
stack memory and crashes the program.
A way to avoid stack overflows is to use a trick called tail recursion. Using tail recursion means rewri2ng the code so that all
recursive calls occur at the end posi2ons (at the “tails”) of the func2on body. In other words, each recursive call must be itself the
last computa2on in the func2on body, rather than placed inside other computa2ons. Here is an example of tail-recursive code:
def lengthT(s: Seq[Int], res: Int): Int =
if (s.isEmpty)
res
else
lengthT(s.tail, 1 + res)
In this code, one of the branches of the if/else returns a fixed value without doing any recursive calls, while the other branch
returns the result of a recursive call to lengthT(...). In the code of lengthT, recursive calls never occur within any sub-
expressions.
def lengthS(s: Seq[Int]): Int =
if (s.isEmpty) 0
else 1 + lengthS(s.tail)
lengthS(Seq(1, 2, ..., 100000))
= 1 + lengthS(Seq(2, ..., 100000))
= 1 + (1 + lengthS(Seq(3, ..., 100000)))
= ...
Sergei Winitzki

It is not a problem that the recursive call to lengthT has some sub-expressions such as 1 + res as its arguments, because all these
sub-expressions will be computed before lengthT is recursively called.
The recursive call to lengthT is the last computa@on performed by this branch of the if/else. A tail-recursive func@on can have
many if/else or match/case branches, with or without recursive calls; but all recursive calls must be always the last expressions
returned.
The Scala compiler has a feature for checking automa@cally that a func@on’s code is tail-recursive : the @tailrec annota2on. If a
func@on with a @tailrec annota2on is not tail-recursive, or is not recursive at all, the program will not compile.
@tailrec def lengthT(s: Seq[Int], res: Int): Int =
if (s.isEmpty) res
else lengthT(s.tail, 1 + res)
Let us trace the evalua@on of this func@on on an example:
lengthT(Seq(1,2,3), 0)
= lengthT(Seq(2,3), 1 + 0) // = lengthT(Seq(2,3), 1)
= lengthT(Seq(3), 1 + 1) // = lengthT(Seq(3), 2)
= lengthT(Seq(), 1 + 2) // = lengthT(Seq(), 3)
= 3
All sub-expressions such as 1 + 1 and 1 + 2 are computed before recursive calls to lengthT. Because of that, sub-expressions
do not grow within the stack memory. This is the main benefit of tail recursion.
How did we rewrite the code of lengthS to obtain the tail-recursive code of lengthT? An important difference between lengthS
and lengthT is the addi@onal argument, res, called the accumulator argument. This argument is equal to an intermediate result of
the computa2on. The next intermediate result (1 + res) is computed and passed on to the next recursive call via the
accumulator argument. In the base case of the recursion, the func@on now returns the accumulated result, res, rather than 0,
because at that @me the computa@on is finished. Rewri2ng code by adding an accumulator argument to achieve tail recursion is
called the accumulator technique or the “accumulator trick”.
def lengthS(s: Seq[Int]): Int =
if (s.isEmpty) 0
else 1 + lengthS(s.tail)
Sergei Winitzki

That was a reminder of how the accumulator technique can some9mes be used to transform
a program so that it becomes tail recursive.
The next two slides remind us of how the accumulator technique can some9mes be used to
improve the eﬃciency of a program.
@philip_schwarz

If we rewrite a recursive func2on using the accumulator technique then we end up with a tail recursive func2on, i.e. one that is stack-safe. In
Part 3 we saw that some@mes the version using the accumulator is more efficient than the version that doesn’t, but at other @mes it can be less
efficient, or even just as efficient.
Here is how Richard Bird expresses the case where it is more efficient: ”By adding an extra parameter to a func2on we can some2mes improve
the running 2me. The most important use of this idea is to eliminate possibly expensive ⧺ opera2ons from a program“
T 𝑟𝑒𝑣𝑒𝑟𝑠𝑒 𝑛 = Θ 𝑛2 T reverse′ 𝑛 = Θ 𝑛
reverse′ ∷ α → [α]
reverse′ 𝑥𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑥𝑠
𝑎𝑐𝑐𝑢𝑚 𝑤𝑠 = 𝑤𝑠
𝑎𝑐𝑐𝑢𝑚 𝑤𝑠 𝑥 ∶ 𝑥𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑥 ∶ 𝑤𝑠 𝑥𝑠
reverse =
reverse 𝑥 ∶ 𝑥𝑠 = 𝑟𝑒𝑣𝑒𝑟𝑠𝑒 𝑥𝑠 ⧺ [𝑥]
𝑇 concat 𝑚, 𝑛 = Θ(𝑚𝑛) 𝑇 concat′ 𝑚, 𝑛 = Θ(𝑚2 𝑛)
append ∷ [α] → [α] → [α]
append [ ] = 𝑦𝑠
append 𝑥 ∶ 𝑥𝑠 𝑦𝑠 = 𝑥 ∶ (𝑎𝑝𝑝𝑒𝑛𝑑 𝑥𝑠 𝑦𝑠)
append ′ ∷ [α] → [α] → [α]
append ′ 𝑥𝑠 𝑦𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑦𝑠 𝑟𝑒𝑣𝑒𝑟𝑠𝑒 𝑥𝑠
𝑎𝑐𝑐𝑢𝑚 𝑦𝑠 = 𝑦𝑠
𝑎𝑐𝑐𝑢𝑚 𝑦𝑠 𝑥 ∶ 𝑥𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑥 ∶ 𝑦𝑠 𝑥𝑠
𝑇 append 𝑚, 𝑛 = Θ(𝑚) 𝑇 append′ 𝑚, 𝑛 = Θ(𝑚)
concat′ ∷ α → [α]
concat′ 𝑥𝑠𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑥𝑠𝑠
𝑎𝑐𝑐𝑢𝑚 𝑤𝑠 = 𝑤𝑠
𝑎𝑐𝑐𝑢𝑚 𝑤𝑠 𝑥𝑠 ∶ 𝑥𝑠𝑠 = 𝑎𝑐𝑐𝑢𝑚 𝑤𝑠 ⧺ 𝑥𝑠 𝑥𝑠𝑠
concat ∷ [ α ] → [α]
concat =
concat 𝑥𝑠: 𝑥𝑠𝑠 = 𝑥𝑠 ⧺ 𝑐𝑜𝑛𝑐𝑎𝑡 𝑥𝑠𝑠
⧺ = append
the accumulator version
is more efficient
is less efficient
is just as efficient

reverse ∷ α → [α]
reverse = 𝑓𝑜𝑙𝑑𝑟 𝑠𝑛𝑜𝑐
𝒘𝒉𝒆𝒓𝒆 𝑠𝑛𝑜𝑐 𝑥 𝑥𝑠 = append 𝑥𝑠 [𝑥]
reverse′ ∷ α → [α]
reverse′ = 𝑓𝑜𝑙𝑑𝑙 𝑝𝑟𝑒𝑓𝑖𝑥
𝒘𝒉𝒆𝒓𝒆 𝑝𝑟𝑒𝑓𝑖𝑥 𝑥𝑠 𝑥 = 𝑥 : 𝑥𝑠
append ∷ [α] → [α] → [α]
append 𝑥𝑠 𝑦𝑠 = 𝑓𝑜𝑙𝑑𝑟 ∶ 𝑦𝑠 xs
append′ ∷ [α] → [α] → [α]
append′ 𝑥𝑠 𝑦𝑠 = 𝑓𝑜𝑙𝑑𝑙 𝑠𝑐𝑜𝑛 𝑦𝑠 (reverse′ xs)
𝒘𝒉𝒆𝒓𝒆 𝑠𝑐𝑜𝑛 𝑥𝑠 𝑥 = 𝑥 : 𝑥𝑠
concat′ ∷ [ α ] → [α]
concat′ = 𝑓𝑜𝑙𝑑𝑙 append [ ]
concat ∷ [ α ] → [α]
concat = 𝑓𝑜𝑙𝑑𝑟 append [ ]
Since we saw, also in Part 3, that elimina@ng foldr leads to a recursive defini@on of a func@on and elimina@ng
foldl leads to a tail-recursive defini@on of the func@on, one that uses an accumulator, this slide is simply a
restatement of the previous one in which the recursive defini@on has been replaced by a defini@on using foldr
and the tail-recursive defini@on (using an accumulator) has been replaced by a defini@on using foldl.
T 𝑟𝑒𝑣𝑒𝑟𝑠𝑒 𝑛 = Θ 𝑛2 T reverse′ 𝑛 = Θ 𝑛
𝑇 concat 𝑚, 𝑛 = Θ(𝑚𝑛) 𝑇 concat′ 𝑚, 𝑛 = Θ(𝑚2 𝑛)
𝑇 append 𝑚, 𝑛 = Θ(𝑚) 𝑇 append′ 𝑚, 𝑛 = Θ(𝑚)
is more efficient
is less efficient
is just as efficient

That was a reminder of how the accumulator technique can some9mes be used to improve
The next slide brieﬂy explains how the tupling technique can some9mes be used to increase

7.4 Tupling
The technique of program op2misa2on known as tupling is dual to that of accumula2ng parameters: a func2on is generalised,
not by including an extra argument, but by including an extra result. Our aim in this sec@on is to illustrate this important
technique through a number of instruc@ve examples.
…
7.4.2 Fibonacci func5on
Another example where tupling can improve the order of growth of the 2me complexity of a program is provided by the Fibonacci
func@on.
𝑓𝑖𝑏 0 = 0
𝑓𝑖𝑏 1 = 1
𝑓𝑖𝑏 𝑛 + 2 = 𝑓𝑖𝑏 𝑛 + 𝑓𝑖𝑏 𝑛 + 1
The @me to evaluate 𝑓𝑖𝑏 𝑛 by these equa@ons is given by T 𝑓𝑖𝑏 𝑛 , where
T 𝑓𝑖𝑏 0 = 𝑂 1
T 𝑓𝑖𝑏 1 = 𝑂 1
T 𝑓𝑖𝑏 𝑛 + 2 = T 𝑓𝑖𝑏 𝑛 +T 𝑓𝑖𝑏 𝑛 + 1 + 𝑂 1
The timing function T 𝑓𝑖𝑏 therefore satismies equations very like that of 𝑓𝑖𝑏 itself. It is easy to check by induction that
T 𝑓𝑖𝑏 𝑛 = Θ 𝑓𝑖𝑏 𝑛 , so the time to compute 𝑓𝑖𝑏 is proportional to the size of the result. Since 𝑓𝑖𝑏 𝑛 = Θ(𝜙 𝑛), where 𝜙 is
the golden ratio 𝜙 = (1 + 5)/2, the time is therefore exponential in 𝑛. Now consider the function 𝑓𝑖𝑏𝑡𝑤𝑜 demined by
𝑓𝑖𝑏𝑡𝑤𝑜 𝑛 = (𝑓𝑖𝑏 𝑛, 𝑓𝑖𝑏 (𝑛 + 1))
Clearly, 𝑓𝑖𝑏 𝑛 = 𝑓𝑠𝑡(𝑓𝑖𝑏𝑡𝑤𝑜 𝑛). Synthesis of a recursive program for 𝑓𝑖𝑏𝑡𝑤𝑜 yields
𝑓𝑖𝑏𝑡𝑤𝑜 0 = (0,1)
𝑓𝑖𝑏𝑡𝑤𝑜 𝑛 + 1 = 𝑏, 𝑎 + 𝑏 , where 𝑎, 𝑏 = 𝑓𝑖𝑏𝑡𝑤𝑜 𝑛
It is clear that this program takes linear 2me. In this example the tupling strategy leads to a drama2c increase in eﬃciency, from
exponen2al to linear.
Richard Bird

𝑓𝑖𝑏 ∷ 𝑵𝒂𝒕 → 𝑵𝒂𝒕
𝑓𝑖𝑏 𝒁𝒆𝒓𝒐 = 𝒁𝒆𝒓𝒐
𝑓𝑖𝑏 𝑺𝒖𝒄𝒄 𝒁𝒆𝒓𝒐 = 𝑺𝒖𝒄𝒄 𝒁𝒆𝒓𝒐
𝑓𝑖𝑏 𝑺𝒖𝒄𝒄 𝑺𝒖𝒄𝒄 𝑛 = 𝑓𝑖𝑏 𝑺𝒖𝒄𝒄 𝑛 + 𝑓𝑖𝑏 𝑛
𝑓𝑖𝑏 ∷ 𝑵𝒂𝒕 → 𝑵𝒂𝒕
𝑓𝑖𝑏 = 𝑓𝑠𝑡 : 𝑓𝑜𝑙𝑑𝑛 𝑔 (𝒁𝒆𝒓𝒐, 𝑺𝒖𝒄𝒄 𝒁𝒆𝒓𝒐)
where 𝑔 𝑚, 𝑛 = (𝑛, 𝑚 + 𝑛)
𝑓𝑜𝑙𝑑𝑛 ∷ 𝛼 → 𝛼 → 𝛼 → 𝑵𝒂𝒕 → 𝛼
𝑓𝑜𝑙𝑑𝑛 ℎ 𝑐 𝒁𝒆𝒓𝒐 = 𝑐
𝑓𝑜𝑙𝑑𝑛 ℎ 𝑐 𝑺𝒖𝒄𝒄 𝑛 = ℎ 𝑓𝑜𝑙𝑑𝑛 ℎ 𝑐 𝑛
We have actually already been introduced (in Part 1) to the idea of compu@ng Fibonacci
numbers more eﬃciently by using tupling, but in a less formal way. See below for a reminder.
introduce tupling
def fib(n: Nat): Nat = {
def fst(pair: (Nat, Nat)): Nat =
pair match { case (n,_) => n }
def g(pair: (Nat, Nat)): (Nat, Nat) =
pair match { case (m,n) => (n, m + n) }
fst( foldn(g, (Zero, Succ(Zero)), n) )
}
def foldn[A](h: A => A, c: A, n: Nat): A =
n match {
case Zero => c
case Succ(n) => h(foldn(h,c,n))
}
val fib: Nat => Nat = {
case Zero => Zero
case Succ(Zero) => Succ(Zero)
case Succ(Succ(n)) => fib(Succ(n)) + fib(n)
}
introduce tupling
@philip_schwarz

On the previous slide we saw a defini8on of the fibonacci func8on that uses tupling in conjunc8on with foldn, which
operates on the Nat type, i.e. Zero, Succ(Zero), Succ(Succ(Zero)), etc.
What if we want to use Int rather than Nat? Just for curiosity: does it make any sense to try and use foldLe5 to write a
defini8on of the fibonacci func8on that uses tupling?
It does make some sense. Here is how we can do it:
def fibFoldLeft(n: Int): Long =
(1 to n).foldLeft ((0L, 1L)){
case ((f1, f2), _) => (f2, f1 + f2)
}._1
The odd thing about the above func8on is that while it creates a sequence 1 to n, it uses the sequence purely to
determine how many 8mes to iterate: it doesn’t actually use the values in the sequence – e.g. it would work just as well
if the sequence were 101 to 100 + n rather than 1 to n.
S8ll, it works. Let’s compare the 8me taken to compute a large-ish Fibonacci number using both fibFoldLe5 and the
tradi8onal defini8on of the Fibonacci func8on:
def fibonacci(n: Int): Long = n match {
case 0 => 0L
case 1 => 1L
case n =>
fibonacci(n - 1) + fibonacci(n - 2)
}

def eval[A](expression: => A): (A, Duration) = {
def getTime = System.currentTimeMillis()
val startTime = getTime
val result = expression
val endTime = getTime
val duration = endTime - startTime
(result, Duration(duration,"ms"))
}
case 0 => 0L
case 1 => 1L
case n =>
}
def fibFoldLeft(n: Int): BigDecimal =
(1 to n).foldLeft((BigDecimal(0), BigDecimal(1))){
case ((f1, f2), _) => (f2, f1 + f2)
}._1
scala> val (result, duration) = eval(fibonacci(50))
val result: Long = 12586269025
val duration: Duration = 82000 milliseconds
scala> val (result, duration) = eval(fibFoldLeft(50))
val result: BigDecimal = 12586269025
val duration: Duration = 1 millisecond
scala> fibonacci(10_000)
java.lang.StackOverflowError
at fibonacci(<console>:1)
…
scala> val (result, duration) = eval(fibFoldLeft(10_000))
val result: BigDecimal = 3.364476487643178326662161200510745E+2089
Here on the le` is an eval func@on that we can use to @me the
execu@on of different defini@ons of the fibonacci func@on.
Compu@ng fibonacci of 50 with
the standard recursive defini@on
takes a stonking 82 seconds!!!.
Compu@ng fibonacci
of 10,000 fails due to a
stack overflow error.
Compu@ng fibonacci of 50
with fibFoldLeft takes
only 1 millisecond!!!
Compu@ng fibonacci
of 10,000 takes only
8 milliseconds!!!
Here we change the return
type to Bigdecimal to allow
for very large results.
@philip_schwarz

Eleven slides ago I said I wanted to show you a second example of using the iterate func@on. Now that we have gone through the following we
are ﬁnally in a posi@on to look at that example:
• a refresher of the accumulator technique
• a brief introduc@on to the tupling technique
• a look at how to implement a Fibonacci func@on using tupling
The example consists of implemen@ng the Fibonacci func@on using iterate. We are going to use the same tupling technique that we have just
used in fibFoldLeft. When Sergei Winitzki introduced the iterate func@on, we saw that it is a func@on that returns a Stream, e.g.
Stream.iterate(2) { x => x + 10 }. Since Scala 2.13 however, the Stream class is deprecated in favour of LazyList, so we are going to
use LazyList.iterate, whose signature is otherwise iden@cal to that of Stream.iterate.
The fibIterate func@on below is similar to fibFoldLeft from the previous slide in that it uses the same tupling approach, but it is simpler
because it doesn’t have to create a sequence whose data it doesn’t even need. It also performs the same way.
def fibIterate(n: Int) : BigDecimal =
LazyList.iterate ((BigDecimal(0), BigDecimal(1))){
case (f1, f2) => (f2, f1 + f2)
}(n)._1
scala> val (result, duration) = eval(fibIterate(50))
val result: BigDecimal = 12586269025
val duration: Duration = 1 millisecond
scala> val (result, duration) = eval(fibIterate(10_000))
val result: BigDecimal = 3.364476487643178326662161200510745E+2089
/** An infinite LazyList that repeatedly applies a given function
* to a start value.
* @param start the start value of the LazyList
* @param f the function that's repeatedly applied
* @return the Stream returning the infinite sequence
* of values `start, f(start), f(f(start)), ...`
*/
def iterate[A](start: A)(f: A => A): LazyList[A] = …
h+ps://www.scala-lang.org/blog/2018/06/13/scala-213-collec=ons.html
LazyList Is Preferred Over Stream
Stream is deprecated in favor of LazyList. As its name suggests, a LazyList is a
linked list whose elements are lazily evaluated. An important seman=c
diﬀerence with Stream is that in LazyList both the head and the tail are lazy,
whereas in Stream only the tail is lazy.
Instead of using LazyList’s take func@on, we
get the nth element of the LazyList, which is a
tuple, and take the 1st element of the la:er.
fibIterate is as fast
as fibFoldLeft.

Here is the Haskell version fibIterate. Just
like the Scala version, it is blazingly fast.
> fibIterate 50
12586269025
> fibIterate 10000
3364476487643178326662161200510754331030214846068006390656476997468008144216666236815559551363373402558206533268083615937373479
0483865268263040892463056431887354544369559827491606602099884183933864652731300088830269235673613135117579297437854413752130520
5043477016022647583189065278908551543661595829872796829875106312005754287834532155151038708182989697916131278562650331954871402
1428753269818796204693609787990035096230229102636813149319527563022783762844154036058440257211433496118002309120828704608892396
2328835461505776583271252546093591128203925285393434620904245248929403901706233888991085841065183173360437470737908552631764325
7339937128719375877468974799263058370657428301616374089691784263786242128352581128205163702980893320999057079200643674262023897
8311147005407499845925036063356093388383192338678305613643535189213327973290813373264265263398976392272340788292817795358057099
3691049175470808931841056146322338217465637321248226383092103297701648054726243842374862411453093812206564914032751086643394517
5121615265453613331113140424368548051067658434935238369596534280717687753283482343455573667197313927462736291082106792807847180
3532913117677892465908993863545932789452377767440619224033763867400402133034329749690202832814593341882681768389307200363479562
3117103101291953169794607632737589253530772552375943788434504067715555779056450443016640119462580972216729758615026968443146952
0346149322911059706762432685159928347098912847067408620085871350162603120719031720860940812983215810772820763531866246112782455
3720853236530577595643007251774431505153960090516860322034916322264088524885243315805153484962243484829938090507048348244932745
3732624567755879089187190803662058009594743150052402532709746995318770724376825907419939632265984147498193609285223945039707165
4431564213281576889080587831834049174345562705202235648464951961124602683139709750693826487066132645076650746115126775227486215
9864253071129844118262266105716351506926002986170494542504749137811515413994155067125627119713325276363193960690289565028826860
8362241082050562430701794976171121233066073310059947366875
>
fibIterate n = fst (fib2 !! n)
where fib2 = iterate f (0,1)
where f (a,b) = (b,a+b)
fib 0 = 0
fib 1 = 0
fib n = fib (n-1) + fib (n-2)
> fib 10
55
> fib 20
6765
> fib 30
832040
> fib 40
I got bored of waiting
so I interrupted it
Remember how the naive Scala deﬁni@on of the ﬁbonacci func@on
was taking over 80 seconds to compute the 50th Fibonacci number?
Well the Haskell version seems to be even slower!

Next, let’s look at some of the things that Richard Bird
has to say about the iterate func@on.
@philip_schwarz

…there are three kinds of list:
• A finite list, which is built from (:) and [] ; for example, 1:2:3:[]
• A par)al list, which is built from (:) and undefined; for example, the list filter (<4) [1..] is the par2al list
1:2:3:undefined. We know there is no integer aèr 3 that is less than 4, but Haskell is an evaluator, not a theorem prover, so
it ploughs away without success looking for more answers.
• An infinite list, which is built from (:) alone; for example, [1..] is the infinite list of nonnega@ve integers.
All three kinds of list arise in everyday programming. Chapter 9 is devoted to exploring the world of infinite lists and their uses. For
example, the prelude func@on iterate returns an infinite list:
𝑖𝑡𝑒𝑟𝑎𝑡𝑒 ∷ 𝑎 → 𝑎 → 𝑎 → 𝑎
𝑖𝑡𝑒𝑟𝑎𝑡𝑒 𝑓 𝑥 = 𝑥 ∶ 𝑖𝑡𝑒𝑟𝑎𝑡𝑒 𝑓 (𝑓 𝑥)
In par@cular, 𝑖𝑡𝑒𝑟𝑎𝑡𝑒 +1 1 is an infinite list of the posi@ve integers, a value we can also write as [1..].
Richard Bird
The type of 1 `div` 0 is an integral number.
ghci> :type 1 `div` 0
1 `div` 0 :: Integral a => a
The expression 1 `div` 0 is therefore well-formed and
possesses a value.
ghci> 1 `div` 0
*** Exception: divide by zero
GHCi returns an error message. So what is the type of 1 `div`
0? The answer is that it is a special value, wri:en
mathema@cally as ⊥ and pronounced ‘bobom’.
In fact, Haskell provides a predefined name for this value,
except that it is called undefined, not ⊥.
ghci> :type undefined
undefined :: a
ghci> undefined
*** Exception: Prelude.undefined
Haskell is not expected to produce the value ⊥. It may return
with an error message, or remain perpetually silent,
compu@ng an infinite loop, un@l we interrupt the
computa@on. It may even cause GHCi to crash.

…consider the following three defini@ons of the standard prelude func@on 𝑖𝑡𝑒𝑟𝑎𝑡𝑒:
𝑖𝑡𝑒𝑟𝑎𝑡𝑒1 𝑓 𝑥 = 𝑥 ∶ 𝑖𝑡𝑒𝑟𝑎𝑡𝑒1 𝑓 𝑓 𝑥
𝑖𝑡𝑒𝑟𝑎𝑡𝑒2 𝑓 𝑥 = 𝑥𝑠 𝑤ℎ𝑒𝑟𝑒 𝑥𝑠 = 𝑥 ∶ 𝑚𝑎𝑝 𝑓 𝑥𝑠
𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 𝑓 𝑥 = 𝑥 ∶ 𝑚𝑎𝑝 𝑓 (𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 𝑓 𝑥)
All three func@ons have type 𝑎 → 𝑎 → 𝑎 → 𝑎 and produce an infinite list of iterates of 𝑓 applied to 𝑥. The three func@ons are
equal… The first defini@on is the one used in the standard prelude, but it does not create a cyclic list. The second defini@on does,
and the third is obtained from the second by elimina@ng the 𝑤ℎ𝑒𝑟𝑒 clause.
Assuming 𝑓 𝑥 can be computed in constant @me, the first defini@on takes 𝛩 𝑛 steps to compute the first 𝑛 elements of the result,
but the third takes 𝛩 𝑛2 steps:
𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 2 ∗ 1
= 1 ∶ 𝑚𝑎𝑝 2 ∗ 𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 2 ∗ 1
= 1 ∶ 2 ∶ 𝑚𝑎𝑝 2 ∗ (𝑚𝑎𝑝 2 ∗ (𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 2 ∗ 1) )
= 1 ∶ 2 ∶ 4 ∶ 𝑚𝑎𝑝 2 ∗ (𝑚𝑎𝑝 2 ∗ (𝑚𝑎𝑝 2 ∗ (𝑖𝑡𝑒𝑟𝑎𝑡𝑒3 2 ∗ 1) ))
Evalua@ng the 𝑛th element requires 𝑛 applica@ons of 2 ∗ , so it takes 𝛩 𝑛2 to produce the first 𝑛 elements.
That leaves the second defini@on. Does it take linear or quadra2c @me? The evalua@on of 𝑖𝑡𝑒𝑟𝑎𝑡𝑒2 2 ∗ 1 proceeds as follows:
𝑥𝑠 𝑤ℎ𝑒𝑟𝑒 𝑥𝑠 = 1 ∶ 𝑚𝑎𝑝 2 ∗ 𝑥𝑠
1: 𝑦𝑠 𝑤ℎ𝑒𝑟𝑒 𝑦𝑠 = 𝑚𝑎𝑝 2 ∗ (1: 𝑦𝑠)
1: 2: 𝑧𝑠 𝑤ℎ𝑒𝑟𝑒 𝑧𝑠 = 𝑚𝑎𝑝 2 ∗ (2: 𝑧𝑠)
1: 2: 4: 𝑡𝑠 𝑤ℎ𝑒𝑟𝑒 𝑡𝑠 = 𝑚𝑎𝑝 2 ∗ (4: 𝑧𝑠)
Each element of the result is produced in constant @me, so 𝑖𝑡𝑒𝑟𝑎𝑡𝑒2 2 ∗ 1 takes 𝛩 𝑛 steps to produce 𝑛 elements. Richard Bird

Now that we have covered the iterate func@on and the tupling technique, let’s turn
to the subject of scanning.
In the next two slides we see how Sergei Winitzki describes scanning in his book.

2.4 Transforming a sequence into another sequence
We have seen methods such as map and zip that transform sequences into sequences. However, these methods cannot express a
general transforma2on where the elements of the new sequence are defined by induc2on and depend on previous elements.
An example of this kind is compu@ng the par2al sums of a given sequence 𝑥𝑖, say 𝑏 𝑘 = ∑!"#
$%&
𝑥𝑖 . This formula defines 𝑏0 = 0, 𝑏1 =
𝑥0, 𝑏2 = 𝑥0 + 𝑥1, 𝑏3 = 𝑥0 + 𝑥1 + 𝑥3, etc. A defini@on via mathema2cal induc2on may be wri:en like this:
• Base case: 𝑏0 = 0
• Induc2ve step: Given 𝑏 𝑘, we define 𝑏 𝑘 + 1 =
𝑏𝑘 + 𝑥 𝑘 for 𝑘 = 0,1,2, …
The Scala library method scanLeft implements a general, sequence to sequence transforma@on defined in this way. The code
implemen@ng the par@al sums is
def partialSums(xs: Seq[Int]): Seq[Int] =
xs.scanLeft(0){ (x, y) => x + y }
scala> partialSums(Seq(1, 2, 3, 4))
val res0: Seq[Int] = List(0, 1, 3, 6, 10)
The first argument of scanLeft is the base case, and the second argument is an updater func2on describing the induc2ve step. In
general, the type of elements of the second sequence is different from that of the first sequence. The updater func2on takes an
element of the first sequence and a previous element of the second sequence, and returns the next element of the second
sequence. Note that the result of scanLeft is one element longer than the original sequence, because the base case provides an
ini2al value.
Un@l now, we have seen that foldLeft is sufficient to re-implement almost every method that works on sequences, such as map,
filter, or flaben. Let us show, as an illustra2on, how to implement the method scanLeft via foldLeft.
Sergei Winitzki

In the implementa@on, the accumulator contains the previous element of the second sequence together with a growing fragment
of that sequence, which is updated as we iterate over the first sequence. The code is
def scanLeft[A, B](xs: Seq[A])(b0: B)(next: (B, A) => B): Seq[B] = {
val init: (B, Seq[B]) = (b0, Seq(b0))
val (_, result) = xs.foldLeft(init) {
case ((b, seq), x) =>
val newB = next(b, x)
(newB, seq :+ newB)
}
result
}
To implement the (nameless) updater func2on for foldLeft we used the Scala feature that makes it easier to define func@ons with
several arguments containing tuples. In our case, the updater func2on in foldLeft has two arguments: the first is a tuple (B,
Seq[B]), the second is a value of type A. The pa:ern expression case ((b, seq), x) => appears to match a nested tuple. In
reality, this expression matches the two arguments of the updater func2on and, at the same @me, destructures the tuple argument
as (b, seq).
Sergei Winitzki

def scanLeft[A, B](xs: Seq[A])(b0: B)(next: (B, A) => B): Seq[B] = {
val init: (B, Seq[B]) = (b0, Seq(b0))
val (_, result) = xs.foldLeft(init) {
case ((b, seq), x) =>
val newB = next(b, x)
(newB, seq :+ newB)
}
result
}
While in his explana@on of the scanLeG func@on, Sergei showed us (for illustra@on only) that it is possible to
implement scanLeG using foldLeG, I was a bit surprised by the fact that he did not men@on that the meaning
of the scanLeG func@on is very closely related to that of foldLeG.
That close rela@onship is one of the things we are going to learn in the next ﬁve slides, in which Richard Bird
explains le` and right scans.
Before we do that, I am just going to have a go at a Haskell version Sergei’s implementa@on of scanLeG in terms
of foldLeG (again, for illustra@on only).
scanleft f e xs = snd (foldl g (e, [e]) xs)
where g (e, res) x = (next, res ++ [next])
where next = f e x
Haskell> scanleft (+) 0 [1,2,3,4]
[0,1,3,6,10]
>
scala> scanleft(List(1,2,3,4))(0)(_+_)
val res0: Seq[Int] = List(0, 1, 3, 6, 10)
scala>
@philip_schwarz

4.5.2 Scan le5
Some@mes it is convenient to apply a 𝑓𝑜𝑙𝑑𝑙 opera@on to every ini@al segment of a list. This is done by a func@on 𝑠𝑐𝑎𝑛𝑙
pronounced ‘scan leG’. For example,
𝑠𝑐𝑎𝑛𝑙 ⊕ 𝑒 𝑥0, 𝑥1, 𝑥2 = [𝑒, 𝑒 ⊕ 𝑥0, (𝑒 ⊕ 𝑥0) ⊕ 𝑥1, ((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2]
In par@cular, 𝑠𝑐𝑎𝑛𝑙 + 0 computes the list of accumulated sums of a list of numbers, and 𝑠𝑐𝑎𝑛𝑙 × 1 [1. . 𝑛] computes a list of
the first 𝑛 factorial numbers. … We will give two programs for 𝑠𝑐𝑎𝑛𝑙; the first is the clearest, while the second is more efficient.
For the first program we will need the func@on inits that returns the list of all ini2al segments of a list. For Example,
𝑖𝑛𝑖𝑡𝑠 𝑥0, 𝑥1, 𝑥2 = [[ ], 𝑥0 , 𝑥0, 𝑥1 ,
𝑥0, 𝑥1, 𝑥2 ]
The empty list has only one segment, namely the empty list itself; A list 𝑥: 𝑥𝑠 has the empty list as its shortest ini2al segment,
and all the other ini2al segments begin with 𝑥 and are followed by an ini2al segment of 𝑥𝑠. Hence
𝑖𝑛𝑖𝑡𝑠 ∷ α → α
𝑖𝑛𝑖𝑡𝑠 = [ ]
𝑖𝑛𝑖𝑡𝑠 𝑥: 𝑥𝑠 = ∶ 𝑚𝑎𝑝 (𝑥: )(𝑖𝑛𝑖𝑡𝑠 𝑥𝑠)
The func@on 𝑖𝑛𝑖𝑡𝑠 can be defined more succinctly as an instance of 𝑓𝑜𝑙𝑑𝑟 :
𝑖𝑛𝑖𝑡𝑠 = 𝑓𝑜𝑙𝑑𝑟 𝑓 [ ] 𝑤ℎ𝑒𝑟𝑒 𝑓 𝑥 𝑥𝑠𝑠 = ∶ 𝑚𝑎𝑝 𝑥: 𝑥𝑠𝑠
Now we define
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑙 𝑓 𝑒 = 𝑚𝑎𝑝 𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 . 𝑖𝑛𝑖𝑡𝑠
This is the clearest defini@on of 𝑠𝑐𝑎𝑛𝑙 but it leads to an inefficient program. The func@on 𝑓 is applied k @mes in the evalua@on of Richard Bird

𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 on a list of length k and, since the ini2al segments of a list of length n are lists with lengths 0,1,…,n, the func@on 𝑓 is
applied about n2/2 @mes in total.
Let us now synthesise a more efficient program. The synthesis is by an induc2on argument on 𝑥𝑠 so we lay out the calcula@on in
the same way.
<…not shown…>
In summary, we have derived
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑙 𝑓 𝑒 = [𝑒]
𝑠𝑐𝑎𝑛𝑙 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑒 ∶ 𝑠𝑐𝑎𝑛𝑙 𝑓 𝑓 𝑒 𝑥 𝑥𝑠
This program is more efficient in that func@on 𝑓 is applied exactly n @mes on a list of length n.
Richard Bird
𝑠𝑐𝑎𝑛𝑙 ⊕ 𝑒 𝑥0, 𝑥1, 𝑥2
⬇
[𝑒, 𝑒 ⊕ 𝑥0, (𝑒 ⊕ 𝑥0) ⊕ 𝑥1, ((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2]
𝑓𝑜𝑙𝑑𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → 𝛽
𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 = 𝑒
𝑓𝑜𝑙𝑑𝑙 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑓𝑜𝑙𝑑𝑙 𝑓 𝑓 𝑒 𝑥 𝑥𝑠
Note the similari@es and differences between 𝑠𝑐𝑎𝑛𝑙 and 𝑓𝑜𝑙𝑑𝑙, e.g. the le` hand sides of their equa@ons are the
same, and their signatures are very similar, but 𝑓𝑜𝑙𝑑𝑙 returns [𝛽] rather than 𝛽 and while 𝑓𝑜𝑙𝑑𝑙 is tail recursive,
𝑠𝑐𝑎𝑛𝑙 isn’t.
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑓𝑜𝑙𝑑𝑙 ⊕ 𝑒 𝑥0, 𝑥1, 𝑥2
⬇
((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2

𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑙 𝑓 𝑒 𝑥𝑠 = 𝑒 ∶ 𝑠𝑐𝑎𝑛𝑙'
𝑓 𝑒 𝑥𝑠
where 𝑠𝑐𝑎𝑛𝑙'
𝑓 𝑒 =
𝑠𝑐𝑎𝑛𝑙'
𝑓 𝑒 𝑦: 𝑦𝑠 = 𝑠𝑐𝑎𝑛𝑙 𝑓 𝑓 𝑒 𝑦 𝑦𝑠
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
⬇
[𝑒, 𝑒 ⊕ 𝑥0, (𝑒 ⊕ 𝑥0) ⊕ 𝑥1, ((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2]
By the way, just for completeness, the appendix of Richard Bird’s
book, contains the following addi@onal deﬁni@on of 𝑠𝑐𝑎𝑛𝑙
And just for comparison, here are the other deﬁni@ons of 𝑠𝑐𝑎𝑛𝑙
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]

4.5.3 Scan right
The dual computa@on is given by scanr.
𝑠𝑐𝑎𝑛𝑟 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑟 𝑓 𝑒 = 𝑚𝑎𝑝 𝑓𝑜𝑙𝑑𝑟 𝑓 𝑒 . 𝑡𝑎𝑖𝑙𝑠
The func@on 𝑡𝑎𝑖𝑙𝑠 returns the tail segments of a list. For example,
𝑡𝑎𝑖𝑙𝑠 𝑥0, 𝑥1, 𝑥2 = [ 𝑥0, 𝑥1, 𝑥2 , 𝑥1, 𝑥2 , 𝑥2 , [ ]]
Note that while 𝑖𝑛𝑖𝑡𝑠 produces a list of ini2al segments in increasing order of length, tails produces the tail segments in
decreasing order of length. We can deﬁne 𝑡𝑎𝑖𝑙𝑠 by
𝑡𝑎𝑖𝑙𝑠 ∷ α → α
𝑡𝑎𝑖𝑙𝑠 = [ ]
𝑡𝑎𝑖𝑙𝑠 𝑥: 𝑥𝑠 = 𝑥: 𝑥𝑠 ∶ 𝑡𝑎𝑖𝑙𝑠 𝑥𝑠
The corresponding eﬃcient program for 𝑠𝑐𝑎𝑛𝑟 is given by
𝑠𝑐𝑎𝑛𝑟 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑟 𝑓 𝑒 = [𝑒]
𝑠𝑐𝑎𝑛𝑟 𝑓 𝑒 𝑥: 𝑥𝑠 = 𝑓 𝑥 ℎ𝑒𝑎𝑑 𝑦𝑠 : ys
where 𝑦𝑠 = 𝑠𝑐𝑎𝑛𝑟 𝑓 𝑒 𝑥𝑠
Richard Bird
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑖𝑛𝑖𝑡𝑠 𝑥0, 𝑥1, 𝑥2 = [[ ], 𝑥0 , 𝑥0, 𝑥1 ,
𝑥0, 𝑥1, 𝑥2 ]
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑠𝑐𝑎𝑛𝑟 ⊕ 𝑒 𝑥0, 𝑥1, 𝑥2
⬇
[(𝑥0 ⊕ (𝑥1 ⊕ (𝑥2 ⊕ 𝑒))), 𝑥1 ⊕ (𝑥2 ⊕ 𝑒), 𝑥2 ⊕ 𝑒, 𝑒]
⬇
[𝑒, 𝑒 ⊕ 𝑥0, (𝑒 ⊕ 𝑥0) ⊕ 𝑥1, ((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2]
for reference: a reminder of what 𝑠𝑐𝑎𝑛𝑟 and 𝑠𝑐𝑎𝑛𝑙 do

𝑠𝑐𝑎𝑛𝑟 ∷ 𝛼 → 𝛽 → 𝛽 → 𝛽 → 𝛼 → 𝛽
𝑠𝑐𝑎𝑛𝑟 𝑓 𝑒 = 𝑚𝑎𝑝 𝑓𝑜𝑙𝑑𝑟 𝑓 𝑒 . 𝑡𝑎𝑖𝑙𝑠
𝑠𝑐𝑎𝑛𝑟 ⊕ 𝑒 𝑥0, 𝑥1, 𝑥2
⬇
[(𝑥0 ⊕ (𝑥1 ⊕ (𝑥2 ⊕ 𝑒))), 𝑥1 ⊕ (𝑥2 ⊕ 𝑒), 𝑥2 ⊕ 𝑒, 𝑒]
⬇
[𝑒, 𝑒 ⊕ 𝑥0, (𝑒 ⊕ 𝑥0) ⊕ 𝑥1, ((𝑒 ⊕ 𝑥0) ⊕ 𝑥1) ⊕ 𝑥2]
𝑡𝑎𝑖𝑙𝑠 𝑥0, 𝑥1, 𝑥2 = [ 𝑥0, 𝑥1, 𝑥2 , 𝑥1, 𝑥2 , 𝑥2 , [ ]]𝑖𝑛𝑖𝑡𝑠 𝑥0, 𝑥1, 𝑥2 = [[ ], 𝑥0 , 𝑥0, 𝑥1 ,
𝑥0, 𝑥1, 𝑥2 ]
𝑠𝑐𝑎𝑛𝑙 ∷ 𝛽 → 𝛼 → 𝛽 → 𝛽 → 𝛼 → [𝛽]
𝑖𝑛𝑖𝑡𝑠 𝑥: 𝑥𝑠 = ∶ 𝑚𝑎𝑝 𝑥: (𝑖𝑛𝑖𝑡𝑠 𝑥𝑠)
𝑡𝑎𝑖𝑙𝑠 ∷ α → α
𝑡𝑎𝑖𝑙𝑠 = [ ]
𝑡𝑎𝑖𝑙𝑠 𝑥: 𝑥𝑠 = 𝑥: 𝑥𝑠 ∶ 𝑡𝑎𝑖𝑙𝑠 𝑥𝑠
𝑖𝑛𝑖𝑡𝑠 2,3,4 = [[ ], 2 , 2,3 ,
2,3,4 ] 𝑡𝑎𝑖𝑙𝑠 2,3,4 = [ 2,3,4 , 3,4 , 4 , [ ]]
𝑠𝑐𝑎𝑛𝑙 + 0 = [0, 2, 5, 9] 𝑠𝑐𝑎𝑛𝑟 + 0 = [9, 7, 4, 0]
𝑓𝑜𝑙𝑑𝑙 + 0 [ ] =0
𝑓𝑜𝑙𝑑𝑙 + 0 2 = 2
𝑓𝑜𝑙𝑑𝑙 + 0 2,3 = 5
𝑓𝑜𝑙𝑑𝑙 + 0 2,3,4 = 9
𝑓𝑜𝑙𝑑𝑟 + 0 2,3,4 = 9
𝑓𝑜𝑙𝑑𝑟 + 0 3,4 = 7
𝑓𝑜𝑙𝑑𝑟 + 0 4 = 4
𝑓𝑜𝑙𝑑𝑟 + 0 [ ] =0
𝑠𝑐𝑎𝑛𝑟 + 0 2,3,4
⬇
[(2 + (3 + (4 + 0))), 3 + (4 + 0), 4 + 0, 0]
𝑠𝑐𝑎𝑛𝑙 + 0 2,3,4
⬇
[0, 0 + 2, 0 + 2 + 3, 0 + 2 + 3 + 4]
Let’s try out 𝑠𝑐𝑎𝑛𝑙 and
𝑠𝑐𝑎𝑛𝑟 with (+) and 0
𝑠𝑐𝑎𝑛𝑙
applies 𝑓𝑜𝑙𝑑𝑙 to every
ini2al segment of a list
𝑠𝑐𝑎𝑛𝑟
applies 𝑓𝑜𝑙𝑑𝑟 to every
tail segment of a list
@philip_schwarz

Now that we have seen the iterate func@on and the scanning func@ons, let’s see
how Sergei Winitzki describes that fact that folding, itera2ng and scanning are
what we use in func2onal programming to implement mathema2cal induc2on.

2.5 Summary
We have seen a broad overview of transla@ng mathema2cal induc2on into Scala code.
What problems can we solve now?
• Compute mathema2cal expressions involving arbitrary recursion.
• Use the accumulator trick to enforce tail recursion.
• Implement func@ons with type parameters.
• Use arbitrary induc2ve (i.e., recursive) formulas to:
• convert sequences to single values (aggrega2on or “folding”);
• create new sequences from single values (“unfolding”);
• transform exis@ng sequences into new sequences.
Table 2.1: Implemen@ng mathema2cal induc2on
Table 2.1 shows Scala code implemen2ng those tasks. Itera2ve calcula2ons are implemented by transla2ng mathema2cal
induc2on directly into code. In the func2onal programming paradigm, the programmer does not need to write any loops or use
array indices. Instead, the programmer reasons about sequences as mathema2cal values: “Star2ng from this value, we get that
sequence, then transform it into this other sequence,” etc. This is a powerful way of working with sequences, dic2onaries, and
sets. Many kinds of programming errors (such as an incorrect array index) are avoided from the outset, and the code is shorter
and easier to read than conven2onal code wriben using loops.
Sergei Winitzki

The next slide is a reminder of the Func2onal Programming triad of folding, scanning
and itera2on, with some very simple examples of their usage in Scala and Haskell.

fold
λ
Haskell> foldl (+) 0 [1,2,3,4]
10
Haskell> take 4 (iterate (+ 1) 1)
[1,2,3,4]
Haskell> scanl (+) 0 [1,2,3,4]
[0,1,3,6,10]
Haskell>
scala> List(1,2,3,4).foldLeft(0)(_+_)
val res0: Int = 10
scala> Stream.iterate(1)(_ + 1).take(4).toList
val res1: List[Int] = List(1, 2, 3, 4)
scala> List(1,2,3,4).scanLeft(0)(_+_)
val res2: List[Int] = List(0, 1, 3, 6, 10)
scala>
Implementing mathematical induction

Remember when we tried to compute the ten-thousandth Fibonacci number using the tradi@onal recursive defini@on of the
fibonacci func@on, and we got a stack overflow error?
With a func@on like Factorial, which makes a single recursive call, we can address the problem simply by using the accumulator
technique to write a tail recursive version of the func@on.
But some@mes it is not possible to do that. E.g. if a func@on makes more than one recursive call to itself, it is not possible to rewrite
those two calls as one.
In the par@cular case of the Fibonacci func@on, which calls itself recursively twice, we can get round the problem by complemen@ng
the accumulator technique with tupling:
On the next slide we conclude this part with Sergei Winitzki describing the limita@ons of the accumulator technique.
case 0 => 0L
case 1 => 1L
case n =>
}
scala> fibonacci(10_000)
java.lang.StackOverflowError
…
def factorial(n: Int): Long = {
if (n == 0) 1L
else n * factorial(n – 1L)
}
faciter 0 acc = acc
faciter n acc = faciter (n - 1) (n * acc)
fac n = faciter n 1 > map fac [0..10]
[1,1,2,6,24,120,720,5040,40320,362880,3628800]
fibiter 0 (a,b) = a
fibiter n (a,b) = fibiter (n-1) (b,a+b)
fib n = fibiter n (0,1)
> map fib [0..10]
[0,1,1,2,3,5,8,13,21,34,55]
@philip_schwarz

Sergei Winitzki
We cannot implement a non-tail-recursive func@on without stack overflow
(i.e., without unlimited growth of intermediate expressions).
The accumulator trick does not always work! In some cases, it is
impossible to implement tail recursion in a given recursive computa@on.
An example of such a computa@on is the “merge-sort” algorithm where
the func@on body must contain two recursive calls within a single
expression. (It is impossible to rewrite two recursive calls as one.)
What if our recursive code cannot be transformed into tail-recursive code
via the accumulator trick, but the recursion depth is so large that stack
overflows occur? There exist special tricks (e.g., “con@nua@ons”” and
“trampolines”) that convert non-tail-recursive code into itera@ve code
without stack overflows. Those techniques are beyond the scope of this
chapter.

That’s all for Part 4. See you in Part 5.

Folding Unfolded - Polyglot FP for Fun and Profit - Haskell and Scala - Part 4

More Related Content

What's hot

Similar to Folding Unfolded - Polyglot FP for Fun and Profit - Haskell and Scala - Part 4

More from Philip Schwarz

Recently uploaded

Folding Unfolded - Polyglot FP for Fun and Profit - Haskell and Scala - Part 4