Axel Simon
writes:
...
In recent years I acquired the view that type inferences should have some sort of semantic completeness property ...
If you want 'semantic completeness', don't use IncoherentInstances. (As several have said, it's not a popular extension; more of a 'necessary evil' to use with caution. That's why it's a good suggestion to limit it's 'reach' to particular instances.) The price to pay for avoiding IncoherentInstances might be: - adding extra instances to avoid partial overlap - adding type annotations - 'helper' classes to resolve type-ambivalent instances (see Oleg's work for examples of these) - fancy uses of FunDeps - ultimately, programs that fail to compile
... With "semantic completeness" I mean "the best possible type that that can be expressed by the type language". ...
If there is a (unique) 'best possible type', then you don't need IncoherentInstances, IMO. AntC