Re: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
David Feuer <[email protected]> Thu, 28 Oct 2021 01:35:17 -0400
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <CAMgWh9vvs-JPJ5Z6uzp08R2hJbyvhedDB4v-RUUFdo7Wv_hufA@mail.gmail.com> |
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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >>> >>> _______________________________________________ >>> Libraries mailing list >>> [email protected] >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > _______________________________________________ > Libraries mailing list > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries _______________________________________________ Libraries mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries