<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sun, Sep 10, 2017 at 4:48 AM, Anthony Clayden <span dir="ltr"><<a href="mailto:anthony_clayden@clear.net.nz" target="_blank">anthony_clayden@clear.net.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> On Fri Sep 8 15:58:10 UTC 2017, Carter Schonwald wrote:<br>
><br>
> I mostly wanted to confirm that we in fact will actually<br>
say yes<br>
</span>> before doing the formal writtingup :)<br>
<br>
Seriously -- and please stop using smileys:<br>
you're right to be cautious.<br>
You need to rewrite the whole of Section 6.4<br>
(nearly 5 pages), starting with changing the title.<br>
And I think it'll be a struggle to clarify what applies<br>
to genuine numbers vs what applies to 'other stuff'.<br>
<span class="">As Bardur says:<br>
> far from trivial to spec without reference to<br>
implementation details<br>
<br>
</span>I think there's another way: leave Sec 6.4 largely<br>
unchanged.<br>
Add a short note that implementations might extend<br>
class `Num` to include non-numbers.<br>
<br>
GHC 'morally complies' to section 6.4 for Numbers.<br>
(i.e. all number types are members of `Num, Eq, Show`.)<br>
<br>
GHC has (or allows) other types in `Num` which are not<br>
numbers,<br>
so section 6.4 doesn't apply.<br>
<br>
I'm puzzled by Bardur's other comments:<br>
<span class="">> On Fri Sep 8 16:16:54 UTC 2017, Bardur Arantsson wrote:<br>
><br>
> There aren't really any widely used Haskell compilers<br>
</span>> other than GHC ...<br>
<br>
That's true and sad and a weakness for Haskell<br>
in general. On this particular topic there are<br>
other compilers: GHC prior v7.4, Hugs.<br>
<span class=""><br>
> and speccing for things that aren't actually used in<br>
</span>practice ...<br>
<br>
But there's already a spec! namely the existing report.<br>
And `Eq`, `Show` for numbers are used heavily.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think this proposal is not to remove `Eq, Show`<br>
from number types that already have them(?)<br>
But Carter's subject line does seem to be saying that,<br>
which is what alarmed me at first reading.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Edward</div></div></div></div>