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

[Keith]

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 at 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 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20211028/bb886fc9/attachment.html>