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

[David Feuer]

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 at 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 at 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 at 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 at 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 at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries