() => q and q are interchangeable, so it would require compiler support.

The most compelling use case is to make code like

on :: (p a, p b) => (c -> c -> d) -> (forall x. p x => x -> c) -> a -> b -> d

inhabitable for

((++) `on` show)

but it impacts all sorts of unrelated areas in the compiler.

type family Unqualified t :: *
type instance Unqualified (p => q) = q

Alas there is a logical reason why it doesn’t make sense.

{-# LANGUAGE CommunistTypeSynonyms #-}?

type family Constraints t :: Constraints
type instance Constraints (p => q) = p

you just can’t use it anywhere. =/

The compiler complains when you go to use it that you need LiberalTypeSynonyms even if you have LiberalTypeSynonyms turned on. ;)

Probably a good thing, too, because for something like this you wouldn’t want any context reduction in the first place, you’d want the naively inferred context that is based solely on what class functions are actually mentioned in a definition.

This is because you might want to occasionally use an ordering on, say, lists other than the lexical one in the prelude (say, by sum or whatever). If the context gets reduced from Ord ([Salary]) to Ord Salary then you’ve already lost your chance.

Proxies it is.

works fine.

as for whether the type checker has the machinery, that is somewhat harder to answer, becuase it would depend on the details of the largely underspecified constraint simplifier.

I don’t have access to a machine with bleeding edge GHC on it at the moment, but is (c => t) -> Dict c -> t a syntactically valid type? If not, why not?