G'day. Quoting wren ng thornton :

I'm sure you know *why* it's an infinite list[1], but as for why that's useful I can't say. It has the feel of a bug in implementation, though it is ...consistent.

Right. I have no problem with [5,5..5] being logically an anamorphism, but thinking abstractly about what I'd want it to mean, I'm pretty sure I don't want it to mean an infinite list of 5's. I asked a class of about a dozen bright undergrads about 10 years ago what they thought it should mean, and IIRC the consensus seemed to be split between [5] and [5,5]. Nobody correctly guessed what it actually did. So whether the behaviour is technically right or wrong, it violates the Principle of Least Surprise. Cheers, Andrew Bromage

Darn, I sent this as personal mail the first time. Evan Laforge wrote:

...

In Haskell, "The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3]. The list is empty if e1 > e3."

I like it, since it means that things like [n .. n + length m - 1] work as expected when m is []. Or say 'map (array!) [bsearch x .. bsearch y - 1]'.

Tangent: Of course, I would prefer the range be half-open, which is a pretty consistent standard in the rest of the world. I've had a number of off by one errors from this, and from Array.bounds. I guess it's too late to fix those, though, even if there were agreement that they need to be fixed.

It causes problems with types that have an upper bound. You can't express Haskell's [False .. True] as a half-open range for example. --- One solution would be a new syntax for half-open ranges distinct from that for closed ranges, or maybe a couple of operators. Sketching without a compiler: lo <. hi = takeWhile (< hi) [lo ..] data EnumStart a = a :& a (lo :& mid) <: hi = takeWhile (< hi) [lo, mid ..] So you can do things like (0 <. 10) or (0 :& 2 <: 10) Or one could use the same operator for both, if one defined something like: class OpenEnum bot top where (<.) :: bot -> top -> [top] instance (Enum e) => OpenEnum e e where lo <. hi = takeWhile (< hi) [lo ..] instance (Enum e) => OpenEnum (EnumStart a) a ... (lo :& mid) <. hi = takeWhile (< hi) [lo, mid ..] A better choice of line noise for the operator could still be made though. -- src/

Jonathan Cast wrote:

On Sat, 2008-09-27 at 02:09 +0100, Simon Richard Clarkstone wrote:

...

Darn, I sent this as personal mail the first time.

Evan Laforge wrote:

...

...

In Haskell, "The sequence enumFromTo e1 e3 is the list [e1,e1+1,e1+2,...e3]. The list is empty if e1 > e3." I like it, since it means that things like [n .. n + length m - 1] work as expected when m is []. Or say 'map (array!) [bsearch x .. bsearch y - 1]'.

Tangent: Of course, I would prefer the range be half-open, which is a pretty consistent standard in the rest of the world. I've had a number of off by one errors from this, and from Array.bounds. I guess it's too late to fix those, though, even if there were agreement that they need to be fixed. It causes problems with types that have an upper bound. You can't express Haskell's [False .. True] as a half-open range for example.

[False .. ] works great, though, whether ranges are closed or half-open.

You get problems though if you want to tell a function about a range, passing in a low and a high by some means, and it is expecting a half-open range, but you want to tell it [False..]. For example, creating a new array. BTW, why isn't [..] the notation for the entirety of a Bounded type? --- This mailing list is odd; thunderbird defaults to replying to sender rather than to the whole list. -- src/

On 2008 Sep 22, at 5:46, Jon Fairbairn wrote:

"Richard A. O'Keefe" writes:

...

It is being claimed that the reason for this is that "exceptions are problematic" in Hasell, so the Haskell designers went out of their way to make this function total whether it made sense or not.

I'm pretty sure that's not true. I'd like to be able to say "I know, I was there", but although I was there it was so long ago that my memory isn't clear. But it's clearly the

I would say it's more a matter of Haskell programmers thinking partial functions are evil as a general (mathematical) principle. And the claimant above is thinking of needing to catch exceptions in IO, and probably comes from the school of programming that says that invalid values should raise exceptions. Which sounds like a good idea until you see how often people do try {mumble()} catch {} or similar. (Go look at some Java programs; Java goes even farther with that idea and requires programmers to declare the exceptions they can throw, so many programmers shortcircuit the exceptions away to avoid having to deal with it.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH