Bottom line: I don't know what the best thing is yet. But Haskell is quite painful in many ways, so I choose to believe that there is some better option out there waiting to be found. :)
I haven't heard any arguments against named instances, but would love to hear some.
Conversation
By named instances do you mean non-coherent instances? Ed Kmett did a loong talk "Type Classes vs. The World" which outlined some of the problems. I don't necessarily agree - I'm interested in exploring the modular type classes approach, but it brings up important points.
1
1
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.
1
1
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! 😬
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.
1
Show replies
afaict both of those words are used by different people to mean the same thing, and also different things. so don't worry about it :p
2