impredicative polymorphism: seen on HCAR

Isaac Dupree isaacdupree at
Mon Jun 2 10:37:54 EDT 2008

The May 2008 Haskell Communities and Activities Report, GHC 
> Impredicative polymorphism. We are not happy with GHC’s current
> implementation of impredicative polymorphism, which is rather
> complicated and ad hoc. Dimitrios (with Simon and Stephanie)
> wrote a paper about a new and better approach:
> . At the same time, Daan Leijen has been working on his
> closely-related design:
> . Daan’s design has a much simpler implementation, in exchange
> for an (arguably) less-predictable specification. Which of these
> two should we implement? Let us know!

I read the papers...
Dimitrios's *paper* is easier for me to understand than Daan's.  In fact 
they seem quite similar.  I have no idea of any examples where they 
would behave differently.

I don't use impredicative polymorphism much (but maybe because of my 
perception that the existing implementations are poorly designed, and 
that it can usually be avoided by an amount of abstraction that's useful 
anyway).  So I'd say, implement the easier solution.  Is there a paper 
or documentation somewhere, presenting a practical argument for why 
impredicative polymorphism is important in real programs (beyond runST 
$) -- for example, a real program that uses it and has clearer code 
because of it?

I don't really mind writing let/function type-signatures that have weird 
types (unless they're long and repeat information that doesn't need to 
be, which is a different problem).  I wonder how often these proposals 
require type-signatures on lambdas passed to higher-order functions, 

A side-effect is for those of us who want to have any concern for future 
compatibility with non-GHC type systems (or the long future of GHC's, 
even), whether one of the proposals would be likely to be easier for 
someone else to implement in a different compiler.


More information about the Glasgow-haskell-users mailing list