You definitely want to avoid Scala's situation where you never are sure what instance you have in scope at any time - and the instance resolution algorithm is mysterious and confusing.
Conversation
Coherent instances also tend to end up with people relying on it when designing their APIs, so you need to figure out how to train people out relying on that and provide alternatives.
1
For example you'll need some way of statically ensuring that hash maps use a consistent hashing implementation over their life, lest all craziness ensue. There are solutions to this, but it does end up looking less 'pretty' than what Haskellers are typically used to.
1
1
Type classes can be used in the way they do because they violate modularity, assuming global coherence across packages. But once you remove, and perhaps even encourage people to break global coherence, you need to have a way to get back what you traded away.
2
1
Scala uses implicits, not named instances. I don't think Ed's talk about type class coherence said anything about named instances, if I recall correctly. His point is that no matter which "path" you choose when solving constraints, you should end up at the same point.
2
From my understanding named instances can be done in such a way as to guarantee this.
1
Interesting! I think I've seen that in passing before, but not looked at it too deeply. I'd be interested to see what they do.
1
Ack, in looking over the modular implicits paper again I think I might be conflating the terms 'canonicity' and 'coherence'. Note that while this topic interests me quite a bit, I'm by no means an expert, nor have I tried implementing it! 😬
2
1
Looked over the named instances paper - it does look quite similar to Idris' approach, but with some extra stuff to emulate module functors I think?
1
1
They don't seem to tackle the problem of Haskell APIs often assuming canonicity to work properly. But I could be misunderstanding. They do give an example of a Set, but don't really say how they'd ensure that the Ord instance used is the same over the lifetime of a specific set.
Anyway, I'd also recommend checking out Modular Type Classes, Modular Implicits, and Instance Arguments as other views on the same thing. I have some links here: github.com/pikelet-lang/p
1