<div dir="auto">I won't even commit to making sure Map operations are *deterministic* in the face of a non-reflexive ==.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 29, 2018, 4:01 PM Levent Erkok <<a href="mailto:erkokl@gmail.com">erkokl@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">Johannes:<div><br></div><div>Heartily agreed. In fact, oft-used modules like <font face="monospace, monospace">Data.Map</font> also need to be very clear regarding their requirements for <font face="monospace, monospace">Eq/Ord</font>. It's well known in the folklore that the law:</div><div><br></div><div><font face="monospace, monospace">          M.lookup k (M.insert k v M.empty) == Just v</font></div><div><br></div><div>fails for maps when the key can be floating point:</div><div><span style="font-family:monospace,monospace"><br></span></div><div><span style="font-family:monospace,monospace">    Prelude> import qualified Data</span>.Map<span style="font-family:monospace,monospace"> as M</span></div><div><span style="font-family:monospace,monospace">    Prelude M> let k = 0/0 in let v = 0 in M.lookup k (M.insert k v M.empty) == Just v</span></div><div><span style="font-family:monospace,monospace">    False</span></div><div><br></div><div>Perhaps not a big deal as no-one should use floating-point values as a key to a map, but there's nothing stopping from anyone from doing so. Perhaps more worryingly, the Haskell report is largely silent about  Eq/Ord instances that come out-of-the-box for such gotchas as you yourself observed.</div><div><br></div><div>-Levent.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 29, 2018 at 12:26 PM, Simon Jakobi via Haskell-Cafe <span dir="ltr"><<a href="mailto:haskell-cafe@haskell.org" target="_blank" rel="noreferrer">haskell-cafe@haskell.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Johannes,<div><br></div><div><a href="https://ghc.haskell.org/trac/ghc/ticket/15078" target="_blank" rel="noreferrer">https://ghc.haskell.org/trac/ghc/ticket/15078</a> might be interesting to you.<br></div><div><br></div><div>Cheers,</div><div>Simon</div></div><div class="m_-1361226229243492360HOEnZb"><div class="m_-1361226229243492360h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-05-28 16:47 GMT+02:00 Johannes Waldmann <span dir="ltr"><<a href="mailto:johannes.waldmann@htwk-leipzig.de" target="_blank" rel="noreferrer">johannes.waldmann@htwk-leipzig.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Cafe,<br>
<br>
I am somewhat surprised that the Haskell Standard (*)<br>
<a href="https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1270006.3" rel="noreferrer noreferrer" target="_blank">https://www.haskell.org/onlinereport/haskell2010/haskellch6.html#x13-1270006.3</a><br>
does not contain any<br>
notation for (intended) properties of Eq and Ord instances,<br>
and their relation. For Java (standard library),<br>
the API spec uses wording like "consistent with equals"<br>
<a href="https://docs.oracle.com/javase/10/docs/api/java/lang/Comparable.html" rel="noreferrer noreferrer" target="_blank">https://docs.oracle.com/javase/10/docs/api/java/lang/Comparable.html</a><br>
<br>
I am well aware that semantics (transitivity, etc.)<br>
cannot be enforced statically, in either language.<br>
But both standards still speak of "total order".<br>
Do we (Haskell) need something similar to "consistent with equals"?<br>
<br>
It depends. E.g., looking at a (random) source in containers<br>
(Data.Map.Internal), it seems that it will always use the result of<br>
compare, never of (==), on keys. That's not obvious from the docs.<br>
I just checked -- I can make a type where (==) = undefined,<br>
but write a proper Ord instance, and use it as key type.<br>
<br>
I am asking this because I will be teaching type classes,<br>
with Eq and Ord as examples. I detected the funny situation<br>
that the Java specification looks "more mathematical"<br>
than the corresponding Haskell one. What will the students think ...<br>
<br>
- J.W.<br>
<br>
(*) The Haskell standard is what you find when you scroll<br>
down, down, down to the very bottom of<br>
<a href="https://www.haskell.org/documentation" rel="noreferrer noreferrer" target="_blank">https://www.haskell.org/documentation</a> . So, probably not that important...<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.<br></blockquote></div><br></div>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
To (un)subscribe, modify options or view archives go to:<br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe</a><br>
Only members subscribed via the mailman list are allowed to post.</blockquote></div>