removing constraints

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

removing constraints

Ross Paterson-2
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
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

David Feuer


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.


_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Roman Cheplyaka-2
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
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Brandon Allbery
On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <[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]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Henning Thielemann


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
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

David Feuer
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:
On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <[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]                                  [hidden email]
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net

_______________________________________________
Libraries mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/libraries
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Roman Cheplyaka-2
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
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Ross Paterson-2
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
Reply | Threaded
Open this post in threaded view
|

Re: removing constraints

Eric Mertens
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