Replacing <Class>1 with QuantifiedConstraints

Are there any problems associated with replacing classes like Show1, NFData1, etc. with an equivalent QuantifiedConstraint-style implementation? e.g. Show1 f becomes forall a . Show a => Show (f a), or if you like:

type Lift c f = (forall s . c s => c (f s) :: Constraint)

And then you have Show1 f becomes Lift Show f, and you don’t have to deal with all these special lifted versions of random typeclasses.

I’ve been using the QuantifiedConstraints-style constraints in my code recently and have found it comparatively much more pleasant to use. Are there any problems with this approach that I haven’t run into yet?

3 Likes

This is interesting – I was looking for something similar to this recently. Do you know if a Lift type/newtype is defined somewhere?

I’m not aware of any easily accessible definition. If no one chimes in with one, I’d be happy to upload a one line library to hackage.