removing constraints

[David Feuer]

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" <allbery.b at gmail.com> wrote:

> On Fri, Jan 9, 2015 at 10:38 AM, Roman Cheplyaka <roma at 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 at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150109/879450bd/attachment.html>