QuantifiedConstraints: Reify implication constraints from terms lacking them

This is possibly the same question as #14822 (closed), asked in more general terms. Would it be viable/sound to have a way of extracting implication constraints out of terms which effectively encode such constraints, such as (:-) from Data.Constraint?

Here's how I think about it. a :- b is equivalent to forall r. a => (b => r) -> r. This is a type that, as I read it, expresses "if you can show a, then I can show b". This is very similar to forall r. ((a => b) => r) -> r, which expresses "(without obligations) I can show that a implies b".

It seems to me (and I know this is hand-wavy) like expressions of both of these types actually must have the same "knowledge", i.e. that a imples b. Is this actually correct?

I am wondering whether we could have a built-in function like:

reifyImplication :: forall a b. (forall r. a => (b => r) -> r) -> (forall r. ((a => b) => r) -> r)

We can already write the function that goes the other direction.

There are plenty of ways to represent this conversion. Some more straight-forward, using a :- b or Dict a -> Dict b. I just went with one that doesn't require any types beyond arrows.

I'm curious about the soundness of this. I have tried really hard to implement this function, but I don't think it can be done.

I don't know if this proves anything, but replacing (=>) with (->) and all constraints c with Dict c, this function can be written:

dictReifyImplication :: forall a b. (forall r. Dict a -> (Dict b -> r) -> r) -> (forall r. ((Dict a -> Dict b) -> r) -> r)
dictReifyImplication f g = g (\a -> f a id)

Trac metadata

Trac field	Value
Version	8.5
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related	#14822 (closed)
Blocking
CC
Operating system
Architecture