[Haskell-cafe] Odd list comprehension behaviour
targen at gmail.com
Fri Mar 18 23:30:37 UTC 2016
On Thu, Mar 17, 2016 at 6:47 PM, Richard A. O'Keefe <ok at cs.otago.ac.nz> wrote:
> 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.
Indeed! I agree completely that this is not consistent with the
current rules in Haskell, and I agree completely that this is a
complicating addition to those rules that is in no way derived from
the way things currently work or from some clear greater principle.
> 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.)
To be clear: I’m not proposing this, I’m just exploring how such a
rule may be specified. Although my current intuition agrees with the
original post’s stated intuition in that I was surprised to find
[1,1..1] is not finite, I personally don’t think it’s necessarily
better to have an intuitive rule: I generally favor rules that are
simple to state and reason about, rather than rules that produce
superficially intuitive results at the expense of special cases and
conceptual complexity — and I certainly hope saying that does not
derail this conversation into other recent discussions with similar
If I were to propose this, which I’m not, I would discuss what the
[a,b..c] notation is meant to represent. To me, personally and for no
good reason, it looks like an iterator that yields numbers starting at
a, adding (b-a) at each step and yielding the next number as long as
it’s less than or equal to c, and continuing as long as c is neither
reached nor exceeded. I make no claim on the universality of this
interpretation or the naturality of its deduction as a result of some
prior notational intuition, and I likewise make no claim about the
adequacy of this intuition as the foundation for the rules in Haskell.
In any case, I would personally never find it reasonable for a
proposal to suggest changing the rules Haskell uses to assign meaning
to this notation, unless there was very wide community consensus and
interest in such a change, which I find doubtful as it’s such a minor
detail. I would prefer to see this turn into, say, a very short note
in the documentation pointing out this curiosity that may be
inconsistent with the intuitive expectations of some of us.
>> [6,6..6] would have the initial 6, and then it should have no other
>> element beyond 6, so it should in fact equal  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.
I misspoke again, indeed! I should have said «it should have no other
element beyond the first 6». Note I also purposely avoided cases with
b < a and c < a, as those confuse me even further, and I have no
opinion or solid intuition about them.
More information about the Haskell-Cafe