[Haskell-cafe] Odd list comprehension behaviour

[Richard A. O'Keefe]

On 17/03/16 7:25 pm, Manuel Gómez wrote:
> Perhaps I should instead have said «ends at c at the furthest».
>
> The intuition I refer to is that c is a possibly included bound for
> the list [a,b..c], so that the list [a,b..c] certainly shall not have
> any element beyond c, but if it does actually get to c, that’s where
> it ends.

That's closer to other languages, but the bit "if it does actually get to c,
that's where it ends" is smuggled in from somewhere.  For cases where
a and b are different, you don't *need* that bit; it's easier to understand
without the extra cruft.  For cases where a and b are equal, it's magic,
come from nowhere, just to bodge in a finite answer for one special case.

Let me rephrase that.  To me, that "if it does actually get to c" bit is
NOT a consequence of my understanding of the general rules for
enumeration in Haskell, they are a complicating ADDITION to those rules
just for a case that I would be very upset to see happening in code of mine.

I mean, this is an *extremely* special case.  [1.0,1.0..x] :: [Double
is an infinite list for ALL x >= 1.0 in Haskell; you want to change this
to be [1.0] if x happens to be the very special case 1.0, and I do
not understand why.  Why is [1.0,1.0..1.0+epsilon] being infinite,
[1.0,1.0,..1.0-epsilon] being empty, but [1.0,1.0..1.0] having one
element USEFUL?  (And while you are at it, explain your reasoning
for [x,x..negate x] when x is 0.0.)
> [6,6..6] would have the initial 6, and then it should have no other
> element beyond 6, so it should in fact equal [6] under this intuition.

But [6,6,6,6,6,6,6,6,6,6,6....] ALSO has no other element beyond 6.
"Not going beyond 6" is one thing, "stopping exactly at 6" is another.