GHC 6.12.1 and impredicative polymorphism

Wolfgang Jeltsch g9ks157k at
Thu Feb 4 13:44:09 EST 2010

Am Freitag, 30. Oktober 2009 10:51:37 schrieb Simon Peyton-Jones:
> Friends
> One more update about GHC 6.12, concerning impredicative polymorphism.
> GHC has had an experimental implementation of impredicative polymorphism
>  for a year or two now (flag -XImpredicativePolymorphism). But
>   a) The implementation is ridiculously complicated, and the complexity
>      is pervasive (in the type checker) rather than localized.
>      I'm very unhappy about this, especially as we add more stuff to
>      the type checker for type families.
>   b) The specification (type system) is well-defined [1], but is also
>  pretty complicated, and it's just too hard to predict which programs will
>  typecheck and which will not.
> So it's time for a re-think.  I propose to deprecate it in 6.12, and remove
> it altogether in 6.14.  We may by then have something else to put in its
> place.  (There is no lack of candidates [2,3,4]!)
> Fortunately, I don't think a lot of people use the feature in anger. 
> Please yell if you *are* using impredicative polymorphism for something
> serious.  But if you are, we need to think of a workaround.  The current
> situation seems unsustainable.
> Simon
> [1]
> [2]
> [3]
> [4]

Hello Simon and others,

unfortunately, I missed this e-mail.

Yes, removal of impredicative polymorphism hurts me, since impredicativity 
plays a crucial role in the Grapefruit FRP library at the moment. This is 
described in section 5 of my paper “Signals, Not Generators!” [5]. It’s 
probably possible to use a workaround involving a newtype wrapper, in case 
polymorphic fields in newtypes are still supported. However, this makes things 
more awkward for library users.

Best wishes,

[5] <>

More information about the Glasgow-haskell-users mailing list