GHC 6.12.1 and impredicative polymorphism

[Ganesh Sittampalam]

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 
scheme:

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)

Cheers,

Ganesh