Let's rework Data.Type.Equality.==

[David Feuer]

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 at 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 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/20170810/5918a0c1/attachment.html>