Haskell，无限列表上的文件夹

Question

I got a question while reading LYAH.

Here is my thought of foldr on infinite list:

foldr (:) [] [1..] = 1:2:...:**∞:[]**

I think GHCi does not know it is list before evaluating ∞:[] .

But GHCi do know.

So i thought it can recognize foldr (:) [] [infinite list] = [infinite list itself].

Prelude> [1..10] == (take 10 $ foldr (:) [] [1..])
True
Prelude> [1..] == (foldr (:) [] [1..])
Interrupted.

However It wasn't.

I want to know what actually happens when GHCi recognizes it is [1..] before evaluating ∞:[].

Just type inference prior to that evaluation?

Answer 1

I want to know what actually happens when GHCi recognizes it is [1..] before evaluating ∞:[] .

GHCi does not recognizes that it is [1...] , this is only the consequence of lazy evaluation.

foldr is implemented as:

foldr _ z [] = z
foldr f z (x:xs) = f x (foldr f z xs)

If you write something like foldr (:) [] [1..] , then Haskell does not evalautes this (directly), it only stores that you want to calculate that.

Now say you for instance want to print (take 3 (foldr (:) [] [1..])) that list, then Haskell is forced to evaluate that, and it will do so by calculating:

take 3 (foldr (:) [] [1..])
-> take 3 ((:) 1 (foldr (:) [] [2..]))
-> (:) 1 (take 2 (foldr (:) [] [2..]))
-> (:) 1 (take 2 ((:) 2 (foldr (:) [] [3..]))
-> (:) 1 ((:) 2 (take 1 (foldr (:) [] [3..])))
-> (:) 1 ((:) 2 (take 1 ((:) 3 (foldr (:) [] [4..]))))
-> (:) 1 ((:) 2 ((:) 3 (take 0 (foldr (:) [] [4..]))))
-> (:) 1 ((:) 2 ((:) 3 [])

so it derives [1, 2, 3] , and due to Haskell's lazyness, it is not interested in what foldr (:) [] [4..] is. Even if that list would eventually stop, it is simply not evaluated.

If you calculate something like [1..] = foldr (:) [] [1..] , then Haskell will check for list equality, list equality is defined as:

[] == [] = True
(x:xs) == (y:ys) = x == y && xs == ys
[] == (_:_) = False
(_:_) == [] = False

So Haskell is forced to unwind the list of the right foldr , but it will keep doing so, until it finds items that are not equal, or one of the list reaches the end. But since each time the elements are equal, and both lists never end, it will never finish, si it will evaluate it like:

   (==) [1..] (foldr (:) [] [1..])
-> (==) ((:) 1 [2..])  ((:) 1 (foldr (:) [] [2..]))

It sees that both are equal, so it recursively calls:

-> (==) ((:) 1 [2..])  ((:) 1 (foldr (:) [] [2..]))
-> (==) [2..] foldr (:) [] [2..])
-> (==) ((:) 2 [3..])  ((:) 2 (foldr (:) [] [3..]))
-> (==) [3..] foldr (:) [] [3..])
-> ...

But as you can see, it will never stop evaluation. Haskell does not know that foldr (:) [] [1..] is equal to [1..] , it aims to evaluate it, and since equality forces it to evaluate the entire list, it will get stuck in an infinite loop.

Yes it would be possible to add a certain pattern in the compiler, such that foldr (:) [] x is replaced with x , and so in the future perhaps a Haskell compiler could return True for these, but this would not solve the problems fundamentally , since if Haskell could derive such things for any type of function (here (:) , then it would solve an undecidable problem, hence it is not possible).

Answer 2

Ghc (at least in theory) doesn't know the difference between a finite list and an infinite list. It can tell that a list is finite by calculating its length. If you try to find the length of an infinite list, you're going to have a bad time as your program will never terminate.

This question is really about lazy evaluation. In a strict language like C or python, you need to know the whole value of something at every step. If you want to add up the elements of a list, you already need to know what things are in it and how many there are before you start.

All data in Haskell has the following form:

1. A primitive fully known thing like an int (not necessarily integer)
2. A data type constructor and its arguments, eg True , Left 7 , (,) 5 'f' (which is the same as (5,'f') ), or (:) 3 []

But in Haskell values come in two “shapes”

• known and fully evaluated (like in C or python)
• not yet evaluated—a function “thunk” that when you call will return the value in a more evaluated way

In Haskell there is a concept called weak head normal form in which:

• anything primitive is fully evaluated
• for anything with a constructor, the constructor is known and the arguments may not have been evaluated yet.

Let's look at the evaluation process for foldr (:) [] [1..] . First the definition of foldr

foldr f a [] = a
foldr f a (x:xs) = f x (foldr xs)

Now what is foldr (:) [] [1..] ?

foldr (:) [] [1..]

It seems it's just a thunk. We don't know anything about it yet. So let's evaluate it into WHNF. First we need to convert the argument [1..] (which is actually enumFrom 1 ) to WHNF so we can pattern match on it:

foldr (:) [] (1:[2..])

And now we can evaluate foldr:

(:) 1 (foldr [] [2..])
1 : (foldr [] [2..])

Thus we have calculated the first element of the list without having to look at its whole infinite length. Similarly we can work out the second element and so on.

So what happens if we do [1..] == [1..] ? Well the definition for == for lists is (omitting three cases)

(x:xs) == (y:ys) = x == y && xs == ys

So trying to reduce to WHNF we get:

[1..] == [1..]
(1 == 1) && ([2..] == [2..])
True && ([2..] == [2..])
[2..] == [2..]
... and so on

Thus we keep on going forever and never get to a constructor which we can use to pattern match (ie inspect) the result on.

Note that we can cancel out True && ... because the definition of && doesn't look at its second argument:

True && x = x
False && _ = False

If we defined && with a full four way truth table, the program could run out of memory much faster (provided the compiler didn't do anything clever) than the above where instead you will just run out of patience (or a cosmic ray hits your ram and makes your program return False )