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.