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