I tend to agree with you, although I don't think () is a compelling
argument. Rather, it reuses the name == that Haskellers are accustomed to
defining flexibly. But for that same reason, as well as the convenience, I
do think we should consider using a kind class. That way things at the type
level look pretty much like they do at the term level.
On Aug 10, 2017 10:59 AM, "Ryan Scott"
Personally, I'd be more inclined towards latter approach (in https://phabricator.haskell.org/D3837). After all, one of the key properties of (==) (for which the Haddocks even make a special note) is that it does not attempt to provide an instance that works for every possible kind. Indeed, as you've discovered, there are cases when it doesn't make sense to use DefaultEq, such as for ().
I'll tentatively give my support for D3837, although I'd be curious to hear what Richard has to say about this (since I'm reasonably confident he gave (==) its current implementation).
Ryan S. _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries