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

[Keith]

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