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

Keith <[email protected]> Thu, 28 Oct 2021 02:37:33 +0000
Newsgroups gmane.comp.lang.haskell.libraries
Message-ID <[email protected]>
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