<div dir="ltr">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.</div><span>
</span><p dir="ltr">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.</p><div class="gmail_quote"><div dir="ltr">On Sun, Sep 10, 2017, 11:00 Edward Kmett <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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>> 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>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>> 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><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-Edward</div></div></div></div>
_______________________________________________<br>
Haskell-prime mailing list<br>
<a href="mailto:Haskell-prime@haskell.org" target="_blank">Haskell-prime@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-prime</a><br>
</blockquote></div>