<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>Most of the arguments for making them rings feel kind of
      pedantic, in any case. I can't think of a time I've ever used
      actual ring theory to reason about Ints/Words. <br>
    </p>
    <div class="moz-cite-prefix">On 2/8/19 1:27 PM, Carter Schonwald
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAHYVw0yKpE0K__OzO=+LcV_=RyL56U++6W4pLC-mYzHw1WqT5g@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div>
        <div dir="auto">I’m not sure if they currently have full ring
          structure , but  I do agree that trapping and non trapping int
          and word are useful. </div>
      </div>
      <div dir="auto"><br>
      </div>
      <div dir="auto">Simple example where all the finite signed ints
        work wrong today : </div>
      <div dir="auto"><br>
      </div>
      <div dir="auto">There’s no proper additive inverse for minBound ::
        int </div>
      <div dir="auto"><br>
      </div>
      <div dir="auto">Likewise , what’s our current definition of negate
        on finite word types?</div>
      <div><br>
        <div class="gmail_quote">
          <div dir="ltr">On Fri, Feb 8, 2019 at 2:12 PM David Feuer <<a
              href="mailto:david.feuer@gmail.com" moz-do-not-send="true">david.feuer@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="auto">No, no, no. Int and Word are *rings*, which
              let's us apply a ton of mathematical reasoning to their
              arithmetic. Trapping overflow would throw all that
              completely out the window. If you want to trap overflow,
              please use different types!</div>
            <br>
            <div class="gmail_quote">
              <div dir="ltr">On Fri, Feb 8, 2019, 2:07 PM Lennart
                Augustsson <<a href="mailto:lennart@augustsson.net"
                  target="_blank" moz-do-not-send="true">lennart@augustsson.net</a>
                wrote:<br>
              </div>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                <div>
                  <div dir="auto">I would *hate* to lose quiet NaNs. 
                    They can be very useful.  But I’d be fine having
                    them as a separate type.</div>
                </div>
                <div dir="auto"><br>
                </div>
                <div dir="auto">And while we’re at it, why not make Int
                  overflow and underflow cause a trap as well?  With a
                  different type if you want to wrap. </div>
                <div dir="auto"><br>
                </div>
                <div><br>
                  <div class="gmail_quote">
                    <div dir="ltr">On Fri, Feb 8, 2019 at 08:34 Carter
                      Schonwald <<a
                        href="mailto:carter.schonwald@gmail.com"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">carter.schonwald@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>
                        <div dir="auto">Thanks for eloquently
                          summarizing , better than I would , what I
                          thought I had laid out. </div>
                      </div>
                      <div dir="auto"><br>
                      </div>
                      <div dir="auto">Ieee floating point has fantastic
                        hardware support .  May as well be the first
                        real language to actually use it correctly. :)</div>
                      <div><br>
                        <div class="gmail_quote">
                          <div dir="ltr">On Fri, Feb 8, 2019 at 5:21 AM
                            Merijn Verstraaten <<a
                              href="mailto:merijn@inconsistent.nl"
                              rel="noreferrer" target="_blank"
                              moz-do-not-send="true">merijn@inconsistent.nl</a>>
                            wrote:<br>
                          </div>
                          <blockquote class="gmail_quote"
                            style="margin:0 0 0 .8ex;border-left:1px
                            #ccc solid;padding-left:1ex"><br>
                            <br>
                            > On 8 Feb 2019, at 10:57, Sven Panne
                            <<a href="mailto:svenpanne@gmail.com"
                              rel="noreferrer" target="_blank"
                              moz-do-not-send="true">svenpanne@gmail.com</a>>
                            wrote:<br>
                            > <br>
                            > Am Do., 7. Feb. 2019 um 23:31 Uhr
                            schrieb Merijn Verstraaten <<a
                              href="mailto:merijn@inconsistent.nl"
                              rel="noreferrer" target="_blank"
                              moz-do-not-send="true">merijn@inconsistent.nl</a>>:<br>
                            > Our goal is to make "compare NaN n"
                            impossible to happen. [...]<br>
                            > <br>
                            > Well, what is supposed to happen then
                            when you *do* see a NaN, e.g. one produced
                            from a foreign call? You *will* see NaNs in
                            Haskell if you interact with other
                            languages, most of them take a far less
                            religious approach to floating points
                            calculations.<br>
                            <br>
                            This is not true. As Carter pointed out we
                            can setup the CPU to trap NaNs *even in
                            foreign calls*. So, in theory we CAN rule
                            this out safely. Doing this we can simply
                            convert the trap into an exception at the
                            FFI boundary.<br>
                            <br>
                            Now, there are cases were this is
                            problematic, so as said before we will
                            probably need to allow people to optionally
                            switch on 'value NaNs', because the foreign
                            code isn't exception safe or for other
                            reasons, but this is manageable. Via, for
                            example having an annotation on foreign
                            imports whether you want to trap or not.<br>
                            <br>
                            In the scenario where someone switches to
                            value NaNs, we are *still* not worse off
                            than we are now. The things you suggest
                            already happen *now*, so the only thing
                            we're advocating is making it possible to
                            have more sane behaviour in the future.<br>
                            <br>
                            Any IEEE-754 compliant implementation of
                            Double that doesn't use trapping NaN can, by
                            definition, never ever be a sane
                            implementation of Ord. As IEEE-754
                            *requires* "NaN /= NaN", so equality
                            symmetry doesn't apply to NaNs and there is
                            *no* safe way to sort/order data containing
                            NaNs.<br>
                            <br>
                            I've run into several nasty issues of trying
                            to sort lists containing NaNs (not just
                            Haskell, also Python and C) and it's *not*
                            just the NaNs that are affected, entire
                            subsequences end up getting sorted wrong
                            based on the comparison with NaN and you end
                            up with completely garbled and unsorted
                            data.<br>
                            <br>
                            In other words, there are only two ways to
                            get sane behaviour from Double with regards
                            to ordering:<br>
                            <br>
                            1. Trapping NaN represenation<br>
                            2. Deviate from IEEE-754 semantics<br>
                            <br>
                            To me, option 2 is out of the question, it's
                            the one consistent thing across language we
                            have when it comes to floating point. I
                            understand that *always* using trap
                            representation isn't feasible, but allowing
                            people to optionally switch to value NaNs
                            leaves us no worse off than we are *right
                            now*, and per above, there is literally no
                            way to improve the situation wrt value NaNs
                            without sacrificing IEEE-754 compliance.<br>
                            <br>
                            Cheers,<br>
                            Merijn<br>
_______________________________________________<br>
                            Libraries mailing list<br>
                            <a href="mailto:Libraries@haskell.org"
                              rel="noreferrer" target="_blank"
                              moz-do-not-send="true">Libraries@haskell.org</a><br>
                            <a
                              href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
                              rel="noreferrer noreferrer"
                              target="_blank" moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
                          </blockquote>
                        </div>
                      </div>
                      _______________________________________________<br>
                      Libraries mailing list<br>
                      <a href="mailto:Libraries@haskell.org"
                        rel="noreferrer" target="_blank"
                        moz-do-not-send="true">Libraries@haskell.org</a><br>
                      <a
                        href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
                        rel="noreferrer noreferrer" target="_blank"
                        moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
                    </blockquote>
                  </div>
                </div>
                _______________________________________________<br>
                Libraries mailing list<br>
                <a href="mailto:Libraries@haskell.org" rel="noreferrer"
                  target="_blank" moz-do-not-send="true">Libraries@haskell.org</a><br>
                <a
                  href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries"
                  rel="noreferrer noreferrer" target="_blank"
                  moz-do-not-send="true">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
              </blockquote>
            </div>
          </blockquote>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
Libraries mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Libraries@haskell.org">Libraries@haskell.org</a>
<a class="moz-txt-link-freetext" href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a>
</pre>
    </blockquote>
  </body>
</html>