Re: MINIMAL XOR (Was: Proposal: Make Eq type class single method)

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