Re: MINIMAL XOR (Was: Proposal: Make Eq type class single method)
Keith <[email protected]> Thu, 28 Oct 2021 00:09:01 +0000
| Newsgroups | gmane.comp.lang.haskell.libraries |
|---|---|
| Message-ID | <[email protected]> |
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