<html><head></head><body>No, SQL NULL. An intrinsic `Nothing`.<br><br>For the most part I agree. `compare` for `Double` is should never be emulated. With luck it allows you to sort a list of `Double`s and have the NaNs randomly distributed throughout. Without luck the sort won't terminate.<div style='white-space: pre-wrap'>—<br>Sent from my phone with K-9 Mail.</div><br><br><div class="gmail_quote">On 28 October 2021 05:35:17 UTC, David Feuer <david.feuer@gmail.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre dir="auto" class="k9mail">Let me put it a different way: pretty much *any* function polymorphic<br>over Ord types will have strange, difficult to predict behavior when<br>given NaN. This is a *bad* thing. The last thing we need is to add<br>more types with unlawful Ord instances. There is no *benefit* to<br>giving NULL (by which I assume you mean nullPtr?) special treatment in<br>this regard.<br><br>On Wed, Oct 27, 2021 at 10:38 PM Keith <keith.wygant@gmail.com> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><br> Sure, you can consider NULL to be the top or bottom of the lattice. But in practice what is the point of putting it in a `Set`?<br><br> You extract all the phone numbers from a DB and stick 'em in a `Set`, and every missing number is mapped to the single NULL in the `Set`? And now you know from the `Set` that at least one number was missing?<br> —<br> Sent from my phone with K-9 Mail.<br><br><br> On 28 October 2021 00:14:11 UTC, David Feuer <david.feuer@gmail.com> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"><br> NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or something.<br><br> On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant@gmail.com> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;"><br> For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would also claim than NULL is `GT` NULL.<br><br> (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)<br> —<br> Sent from my phone with K-9 Mail.<br><br><br> On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"><br> On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #e9b96e; padding-left: 1ex;"><br> not necessarily ... there could be  contradictory sets of methods! :)<br><br> like the minimal sets for Field type class,  the xor would be for defining<br> '/' in terms of reciprocal and times or vice versa (/ vs recip) and<br> likewise (negate vs minus) etc etc<br></blockquote><br><br> Logically redundant definitions aren't always redundant in practice if<br> one considers performance, floating point accuracy or even sometimes<br> divergence.<br><br>       For example, foldl on infinite snoc lists is not definable in<br>       terms of foldr which diverges, though admittedly I rather think<br>       that infinite snoc lists violate all reasonable expectations of<br>       a Foldable instance.<br><br> So in many cases redundancy warnings would not be viable.  The Eq<br> situation is likely more the exception that the rule.<br><br> The SQL NULL instances that are False for both "==" and "/=" look<br> like they could be a mistake to me, but presumably they work out<br> OK in practice, and I would expect that e.g. the relevant `Ord`<br> instances do return `EQ` for `compare Null Null`...  Less clear<br> is whether the non-lawful Eq defintion is in some predicably useful<br> way essential.<br><br> --<br>     Viktor.<hr> Libraries mailing list<br> Libraries@haskell.org<br> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote><hr> Libraries mailing list<br> Libraries@haskell.org<br> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote></blockquote><hr> Libraries mailing list<br> Libraries@haskell.org<br> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></blockquote></pre></blockquote></div></body></html>