Tony Morris

Fair enough - what did I miss in my (nasty) bit of code? Doesn't it expose exactly the fact that global uniqueness is not guaranteed by ghc? Who's got the bigger type class implementation is another debate entirely and not at all the point I was making, sorry if it was unclear

The argument is practical Write Haskell; never use orphan instances. This is achievable with little/no penalty Write Scala; never use orphan instances. With this commitment, it's difficult & there's no sweet spot Scala does not have type-classes in any general practical sense

That is entirely besides the point though. My point is: GHC doesn't enforce global instance uniqueness. This is demonstrably true, but exhibiting a program in which global instance uniquess is violated. Whether or not it's easy to avoid is another discussion

Whether or not it's easy to avoid is the *practical* discussion. GHC doesn't enforce it; Haskell does. Neither of these are particularly interesting to me, but I thought we were talking about practical application.

But it's impossible to avoid if you use GHC and have external dependencies though, right? Isn't that practical?

Sorry - it's impossible to guarantee, not to avoid. I do not need to be convinced that it doesn't happen often in practice, my point is just that you can't guarantee it, just observe it.

If a Haskell library implements orphan instances, I typically put it in the "not useful" basket and get on with it. This is a satisfactory optimisation. If a Scala library does it, and it is increasingly the case, I roll me eyes, get over it and accept all the penalties.

This assumes that you have access to the code and are willing to audit it. If the instances aren't exposed explicitly but do nasty things like my ins and ins' example, you won't observe the problem until runtime, when your code does impossible things.