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 Subject:[Haskell-cafe] Odd list comprehension behaviour Hello, I noticed some odd behaviour with list comprehensions. [1..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[1] 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] == [1]. Is there a reason it doesn't work like this? [1] http://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Enum.html#up_li... [1] Thanks,Krisztián Links: ------ [1] http://hackage.haskell.org/package/base-4.8.2.0/docs/src/GHC.Enum.html#up_li...