On 09/01/15 17:29, David Feuer wrote:

...

The other cases are more arguable. For example the change to Data.Ratio declares that the pair is kept in reduced form, but one could argue that requiring that is no bad thing.

Disagreed. However, some have argued convincingly that the Ratio type as it stands makes little sense anyway.

[citation needed]

On Fri, 9 Jan 2015, Brandon Allbery wrote:

On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka wrote:

[citation needed]

I believe this is referencing a past discussion (possibly on IRC) where it was pointed out that Ratio is a type constructor, but the only instance that makes any sense is Ratio Integer because any bounded integral type will eventually (and usually rather quickly) exceed the bounds and fail rather spectacularly given the lack of exceptions on bounded-integral wraparound?

Maybe this one: https://www.haskell.org/pipermail/libraries/2014-November/024064.html

Thank you all for explaining. I confused Ratio and Rational, as I always do, hence my surprise. On 09/01/15 18:02, David Feuer wrote:

Yes, that is what I was referring to. I don't remember where it was, but IRC is a possibility. The basic problem is that if you consider the types that would make sense as numerators and denominators for a ratio, and you consider the instances of Integral, then their intersection turns out to be, to a close approximation, {Integer}. The problem Brandon Allbery points out restricts things on one side, while the peculiar constraint that Integral is a subclass of Real restricts things on the other.

On Jan 9, 2015 10:44 AM, "Brandon Allbery" mailto:allbery.b@gmail.com> wrote:

On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka mailto:roma@ro-che.info> wrote:

On 09/01/15 17:29, David Feuer wrote: >> The other cases are more arguable. For example the change to Data.Ratio >> declares that the pair is kept in reduced form, but one could argue that >> requiring that is no bad thing. > > Disagreed. However, some have argued convincingly that the Ratio type as > it stands makes little sense anyway.

[citation needed]

I believe this is referencing a past discussion (possibly on IRC) where it was pointed out that Ratio is a type constructor, but the only instance that makes any sense is Ratio Integer because any bounded integral type will eventually (and usually rather quickly) exceed the bounds and fail rather spectacularly given the lack of exceptions on bounded-integral wraparound?

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com mailto:allbery.b@gmail.com ballbery@sinenomine.net mailto:ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Hello, The Core Libraries Committee was asked to discuss the question of removing the unused Ix constraints from various classes and instances in the array package. We came to the consensus that the unused Ix constraint should be removed from both the instances declarations and class method for reasons outlined below. For the constraints pertaining to top-level definitions and instance declarations we agreed that the constraints should accurately reflect the state of the code and that if in the future the constraint became necessary again that it should be added. The question about the class methods IArray.bounds and MArray.getBounds is more interesting because these methods define open interfaces that external instance might (now or in the future) depend on. In this particular case it doesn't seem that the design of the Ix class could offer any interesting methods that would be necessary to an instance of this class. Any such instance would need to store the bounds alongside the array in some fashion, and the Ix methods all have arguments requiring a pair of bounds. Therefore we agreed that the constraint should be removed. Regards, Eric Mertens Core Libraries Committee