Tony Morris

I'm genuinely interested and ready to go down that rabbit hole, but do not mean to presume that you have the time to.

We can start with a shortcut! Have you seen the attempts at a Scala type-class hierarchy, dating back to 2005, using implicits and sub-typing, and still not getting it right? i.e. there is still not a usable type-class hierarchy, 15 years later.

Are we limiting type class to categorial abstractions here? Or do you mean any type class, even ones such as `Eq`, for example?

No limits. Just all the type-classes, including those we haven't thought of yet (and especially, for example, those that we have). Though equality is broken on the JVM from the outset.

Mmm... I'm not following. You're talking about Functor <: Applicative <: Monad <:... right? If we assume that they are broken - you've exposed a bad implementation, but that doesn't invalidate the principle though. It doesn't show it's impossible to implement a sane, say, Show

That's why I asked for a definition. My very informal, likely incorret definition is, a type class is syntactic sugar for passing dictionaries around (+ implicit composition, which is really, really nice). Haskell has that. But so does Scala.

That's the definition of type-classes. It's a 1:1 mapping from class to data type so that it can be implicitly passed. i.e. "global uniqueness" is not a feature, it's in the definition. It's even in the name. "type" "class"

So - if type classes *must* have guaranteed global instance uniqueness, then that's fair - Scala doesn't have type classes according to that definition. But then - why do you consider that Haskell, as implemented in GHC, does?