Something stronger than IncoherentInstances needed (Univalent Classes?)

Joachim Breitner mail at
Fri Jul 26 12:27:01 CEST 2013


in the context of the newtype wrapper I have an instance selection
problem where even IncoherentInstances is not liberal enough. Consider
this example:

Prelude> :set -XFlexibleInstances -XIncoherentInstances  -XMultiParamTypeClasses
Prelude> class Class a b where { method :: (a,b); method = undefined }
Prelude> instance Class a b => Class [a] [b]
Prelude> instance Class a a
Prelude> :t method :: ([a],[a])

    Overlapping instances for Class [a1] [a1]
      arising from a use of `method'
    Matching instances:
      instance [incoherent] Class a b => Class [a] [b]
        -- Defined at <interactive>:4:10
      instance [incoherent] Class a a -- Defined at <interactive>:5:10
    In the expression: method :: ([a], [a])

As none of the two instances are more specific than the other, the
typechecker stops despite the incoherent flag.

My suggestion is to add another flag, this time to the class
declaration, marking the class as univalent (different naming
suggestions welcome, of course), indicating that it will generally not
matter which instance is selected, and in the case of overlap the
typechecker should just pick any matching instance.

Would such a feature be welcome?

I could imagine that it might be more useful in other settings as well,
e.g. if type classes are pure predicates about types, without any


PS: I will be on a summer school the next two week. I have written down
the status of the newtype coercion implementation at

Joachim “nomeata” Breitner
  mail at joachim-breitner.de
  Jabber: nomeata at  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the ghc-devs mailing list