GHC 6.12.1 and impredicative polymorphism

Ganesh Sittampalam ganesh at
Mon Nov 2 16:10:38 EST 2009

On Fri, 30 Oct 2009, Sittampalam, Ganesh wrote:

> Simon Peyton-Jones wrote:
>> 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.
> I think darcs is using it. At least, I had to enable
> ImpredicativePolymorphism to successfully build darcs with GHC 6.11 (a
> snapshot from about February), although the flag is not required with
> GHC 6.10. I haven't had a chance to try with the RC yet, but will do
> this weekend.
> I'll have to check the full details of why it's needed, but from memory
> I think it can be worked around at the cost of more verbosity by using
> some newtypes in appropriate places.

OK, I confirm the changes are fairly trivial. The main issue is that a 
couple of functions want to instantiate the argument to IO with a type 

restrictBoring :: IO (forall t m. FilterTree t m => t m -> t m)

The newtype workaround works fine here and doesn't affect too much of the 
code. In one other place some code had type [(String, Foo)] where Foo is a 
type synonym for (forall x y . <something>), but it turned out the nested 
quantification wasn't required so (forall x y . [(String, <something>)]) 
was ok in this case, if a little uglier.

(Patch sent to darcs-users)



More information about the Glasgow-haskell-users mailing list