[Haskell-cafe] Moving "forall" over type constructors

Derek Elkins derek.a.elkins at gmail.com
Tue Jun 10 12:35:44 EDT 2008


On Tue, 2008-06-10 at 18:12 +0200, Roberto Zunino wrote:
> Sean Leather wrote:
> > inside :: ((forall a. W (t a))-> W (forall a. (t a)))
> > --inside (W x) = W x -- (a) FAILS
> > --inside = W . unW -- (b) FAILS
> > inside x = W (unW x) -- (c) WORKS
> >
> > Are there any pointers for developing a better understanding or
> > intuition of this?
> 
> Usually, making type arguments explicit helps: that is, assume that each
> polymorphic value is actually a function expecting a type (the a in
> forall a. ...) and returning the value related to that type. The last
> 'inside' definition becomes:
> 
>   inside x = W (\type -> unW (x type))
> 
> Note that we do not know at this time what will be the actual "type"
> above. But that's OK, since we can return a type-lambda.
> 
> Instead, pattern matching desugars to:
> 
>   inside x = case x of ...
> 
> But wait! x is a function (because it's polymorphic) and we can not
> pattern match on that! And, at this time, we do not know the
> type-argument for x. So we are stuck.
> 
> Also, type-lambdas and type-arguments are hard to insert in W . unW .

This is the lack of impredicativity.

W :: a -> W a
To get the result type W (forall a. t a), W must instantiate the a in
W's type to (forall a. t a).  Further we then pass it to (.) which has
type (b -> c) -> (a -> b) -> a -> c and thus require instantiating both
a and b to higher-rank types.  A predicative type system does not allow
instantiating type variables to quantified types.




More information about the Haskell-Cafe mailing list