# [Haskell-cafe] Odd list comprehension behaviour

Ben hyarion at iinet.net.au
Thu Mar 17 03:20:48 UTC 2016

```If you actually evaulate [1,1..1] == [1..] in a GHCI prompt it will
tell you False immediately. :)
[1..] evaluates to  [1, 2, 3, 4, 5, 6, ... etc ...
[1,1..1] evaluates to [1, 1, 1, 1, 1, 1 ... etc ...
The syntax where you give 2 elements before the .. is intended to
resemble this style of shorthand for lists: [1, 2, 3, 4, ...10]. The
idea is that Haskell should take the two elements as "example
elements" showing the pattern you want. So [1,1..] is saying you want
a list that starts at 1, then has 1, and continues on like that;
you're specifying a step size of *zero*, not of 1.
You can step 1 by 0 an infinite number of times without exceeding 1,
so [1,1..1] should not be finite.
-- Ben

----- Original Message -----
From: "Krisztian Pinter"
To:
Cc:
Sent:Thu, 17 Mar 2016 03:58:06 +0100

Hello,
I noticed some odd behaviour with list comprehensions.
[1..1] == BUT[1,1..1] == [1..]
I noticed this while writing a Clean program, but it seems Haskell
inherited this as well.In the case of integer lists with step size >=
0 the up_list function is used:

up_list :: Integer -> Integer -> Integer -> [Integer]up_list x0 delta
lim = go (x0 :: Integer)                    where
go x | x > lim   = []
| otherwise = x : go (x+delta)
In the case of [1,1..1] x0 == lim, so go will recurse infinitely,
producing an infinite list.
I think the reasonable behaviour would be [1,1..1] == . Is there a
reason it doesn't work like this?

Thanks,Krisztián