No, SQL NULL. An intrinsic `Nothing`.

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.
—
Sent from my phone with K-9 Mail.


On 28 October 2021 05:35:17 UTC, David Feuer <david.feuer@gmail.com> wrote:
Let me put it a different way: pretty much *any* function polymorphic
over Ord types will have strange, difficult to predict behavior when
given NaN. This is a *bad* thing. The last thing we need is to add
more types with unlawful Ord instances. There is no *benefit* to
giving NULL (by which I assume you mean nullPtr?) special treatment in
this regard.

On Wed, Oct 27, 2021 at 10:38 PM Keith <keith.wygant@gmail.com> wrote:

 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`?

 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?
 —
 Sent from my phone with K-9 Mail.


 On 28 October 2021 00:14:11 UTC, David Feuer <david.feuer@gmail.com> wrote:

 NULL is not like NaN. It's perfectly sensible to stick `NULL` in a `Set` or something.

 On Wed, Oct 27, 2021, 8:09 PM Keith <keith.wygant@gmail.com> wrote:

 For what it's worth, Haskell says that NaN is `GT` NaN. So maybe it would also claim than NULL is `GT` NULL.

 (NaN is not `==` to NaN, and is not `<=` to NaN, so it must be GT.)
 —
 Sent from my phone with K-9 Mail.


 On 27 October 2021 15:32:40 UTC, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:

 On Wed, Oct 27, 2021 at 11:14:45AM -0400, Carter Schonwald wrote:

 not necessarily ... there could be  contradictory sets of methods! :)

 like the minimal sets for Field type class,  the xor would be for defining
 '/' in terms of reciprocal and times or vice versa (/ vs recip) and
 likewise (negate vs minus) etc etc


 Logically redundant definitions aren't always redundant in practice if
 one considers performance, floating point accuracy or even sometimes
 divergence.

       For example, foldl on infinite snoc lists is not definable in
       terms of foldr which diverges, though admittedly I rather think
       that infinite snoc lists violate all reasonable expectations of
       a Foldable instance.

 So in many cases redundancy warnings would not be viable.  The Eq
 situation is likely more the exception that the rule.

 The SQL NULL instances that are False for both "==" and "/=" look
 like they could be a mistake to me, but presumably they work out
 OK in practice, and I would expect that e.g. the relevant `Ord`
 instances do return `EQ` for `compare Null Null`...  Less clear
 is whether the non-lawful Eq defintion is in some predicably useful
 way essential.

 --
     Viktor.
 Libraries mailing list
 Libraries@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
 Libraries mailing list
 Libraries@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
 Libraries mailing list
 Libraries@haskell.org
 http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries