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" <ryan.gl.scott@gmail.com> wrote:

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