Recent changes to avoid warnings have removed some constraints from
module interfaces: * in Data.Array, Ix i was removed from: instance Ix i => Functor (Array i) instance Ix i => Foldable (Array i) bounds :: Ix i => Array i e -> (i,i) elems :: Ix i => Array i e -> [e] * in Data.Ratio, Integral a was removed from: instance (Integral a, Show a) => Show (Ratio a) numerator :: (Integral a) => Ratio a -> a denominator :: (Integral a) => Ratio a -> a These constraints are not needed by the GHC implementations, but might be needed for other possible implementations, so in a sense the changes are leaking the GHC implementations. This seems most clear in the Functor and Foldable instances for Array, and elems. Portable implementations of these will require the Ix constraint -- I think it should be restored. 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. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Agreed. > The other cases are more arguable. For example the change to Data.Ratio Disagreed. However, some have argued convincingly that the Ratio type as it stands makes little sense anyway. _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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] _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <[hidden email]> wrote: On 09/01/15 17:29, David Feuer wrote: 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 unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
On Fri, 9 Jan 2015, Brandon Allbery wrote: > On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <[hidden email]> 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 _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by Brandon Allbery
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" <[hidden email]> wrote:
_______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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" <[hidden email] > <mailto:[hidden email]>> wrote: > > On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <[hidden email] > <mailto:[hidden email]>> 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 > [hidden email] <mailto:[hidden email]> > [hidden email] <mailto:[hidden email]> > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net > _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
In reply to this post by David Feuer
On Fri, Jan 09, 2015 at 10:29:43AM -0500, David Feuer wrote:
> > On Jan 9, 2015 10:25 AM, "Ross Paterson" <[hidden email]> wrote: > > These constraints are not needed by the GHC implementations, but might be > > needed for other possible implementations, so in a sense the changes are > > leaking the GHC implementations. This seems most clear in the Functor > > and Foldable instances for Array, and elems. Portable implementations > > of these will require the Ix constraint -- I think it should be restored. > > Agreed. > > > 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. I'm not clear what you're disagreeing with here, since my original statement was equivocal. That also leaves the question of the Ix constraint on bounds. Should it be removed, and if so should it also be removed from the bounds methods in the IArray and MArray classes? _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
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 _______________________________________________ Libraries mailing list [hidden email] http://www.haskell.org/mailman/listinfo/libraries |
Free forum by Nabble | Edit this page |