Remove eq and show from num class

[Edward Kmett]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-prime/attachments/20170910/d9d3e1c0/attachment.html>