Remove eq and show from num class

[Cale Gibbard]

I fully agree with Edward here. This change to Num has been a positive one.
It also seemed fairly uncontroversial as far as Prelude changes go - many
people wanted to see that change for years. While it caused a handful of
hiccups when it happened, it was generally easy enough to fix code to
support it. If anyone would care to argue against the change, I would
recommend pointing your time machines at the end of 2011.

Regardless of how you may feel about GHC and its derivatives (GHCJS mainly)
being the main implementation, it at least ought to make it easier to
determine what is true of modern Haskell. If we want the Report to continue
to document the Prelude, I would start by looking at what it actually
exports now, and trying to follow that as closely as reasonable. It would
be much more valuable in my opinion if the Report were to document a
language that really exists.
On Sun, Sep 10, 2017, 11:00 Edward Kmett <ekmett at gmail.com> wrote:

> On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <
> anthony_clayden at clear.net.nz> wrote:
>
>> > On Fri Sep 8 15:58:10 UTC 2017, Carter Schonwald wrote:
>> >
>> > I mostly wanted to confirm that we in fact will actually
>> say yes
>> > before doing the formal writtingup :)
>>
>> Seriously -- and please stop using smileys:
>> you're right to be cautious.
>> You need to rewrite the whole of Section 6.4
>> (nearly 5 pages), starting with changing the title.
>> And I think it'll be a struggle to clarify what applies
>> to genuine numbers vs what applies to 'other stuff'.
>> As Bardur says:
>> > far from trivial to spec without reference to
>> implementation details
>>
>> I think there's another way: leave Sec 6.4 largely
>> unchanged.
>> Add a short note that implementations might extend
>> class `Num` to include non-numbers.
>>
>> GHC 'morally complies' to section 6.4 for Numbers.
>> (i.e. all number types are members of `Num, Eq, Show`.)
>>
>> GHC has (or allows) other types in `Num` which are not
>> numbers,
>> so section 6.4 doesn't apply.
>>
>> I'm puzzled by Bardur's other comments:
>> > On Fri Sep 8 16:16:54 UTC 2017, Bardur Arantsson wrote:
>> >
>> > There aren't really any widely used Haskell compilers
>> > other than GHC ...
>>
>> That's true and sad and a weakness for Haskell
>> in general. On this particular topic there are
>> other compilers: GHC prior v7.4, Hugs.
>>
>> > and speccing for things that aren't actually used in
>> practice ...
>>
>> But there's already a spec! namely the existing report.
>> And `Eq`, `Show` for numbers are used heavily.
>>
> I think this proposal is not to remove `Eq, Show`
>> from number types that already have them(?)
>> But Carter's subject line does seem to be saying that,
>> which is what alarmed me at first reading.
>>
>
> Smileys and process aside, all that is being proposed is ratifying the
> actual behavior that GHC has had since 2011. Num would lose Eq and Show
> superclasses in the report. This allows users to create instances like Num
> a => Num (x -> a), overloaded integers for working with non-printable
> expression types, infinite precision real number types that literally
> cannot be safely compared for equality, etc. All of which are fairly common
> things to talk about in haskell today.
>
> Yes, a small section of the report would have to be rewritten slightly to
> codify the change in report behavior, and that numeric literals in pattern
> position need to incur an Eq constraint, which is what they do today in GHC.
>
> Nobody is proposing removing any instances for types that have them,
> merely capturing the existing behavior that having Num a does not imply Eq
> a and Show a. There is simply no good reason other than historical accident
> for it to do so and many good reasons for it to not.
>
> -Edward
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20170910/6c61a5c9/attachment.html>