GHC 6.12.1 and impredicative polymorphism
g9ks157k at acme.softbase.org
Thu Feb 4 13:44:09 EST 2010
Am Freitag, 30. Oktober 2009 10:51:37 schrieb Simon Peyton-Jones:
> 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 , 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.
>  http://research.microsoft.com/en-us/um/people/simonpj/papers/boxy/
>  http://research.microsoft.com/en-us/um/people/crusso/qml/
>  http://research.microsoft.com/en-us/um/people/daan/pubs.html
>  http://gallium.inria.fr/~remy/mlf/
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!” . 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.
More information about the Glasgow-haskell-users