GHC: Ticket #8808: ImpredicativeTypes type checking fails depending on syntax of arguments
http://ghc.haskell.org/trac/ghc/ticket/8808
<p>
g1 and g2 below type check, but g1', g2', and g2<em> don't even though the types are exactly the same.
</em></p>
<pre class="wiki">{-# LANGUAGE ImpredicativeTypes, NoMonomorphismRestriction #-}
module Test where
f1 :: Maybe (forall a. [a] -> [a]) -> Maybe ([Int], [Char])
f1 (Just g) = Just (g [3], g "hello")
f1 Nothing = Nothing
f2 :: [forall a. [a] -> [a]] -> Maybe ([Int], [Char])
f2 [g] = Just (g [3], g "hello")
f2 [] = Nothing
g1 = (f1 . Just) reverse
g1' = f1 (Just reverse)
g2 = f2 [reverse]
g2' = f2 ((:[]) reverse)
g2'' = f2 (reverse : [])
</pre><p>
Compiling it with HEAD gives these errors:
</p>
<pre class="wiki">[1 of 1] Compiling Test ( test.hs, test.o )
test.hs:12:16:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a2] -> [a2]’
In the first argument of ‛Just’, namely ‛reverse’
In the first argument of ‛f1’, namely ‛(Just reverse)’
test.hs:15:17:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a0] -> [a0]’
In the first argument of ‛: []’, namely ‛reverse’
In the first argument of ‛f2’, namely ‛((: []) reverse)’
test.hs:16:12:
Couldn't match expected type ‛forall a. [a] -> [a]’
with actual type ‛[a1] -> [a1]’
In the first argument of ‛(:)’, namely ‛reverse’
In the first argument of ‛f2’, namely ‛(reverse : [])’
</pre>en-usGHChttp://ghc.haskell.org/trac/ghc/chrome/site/ghc_logo.png
http://ghc.haskell.org/trac/ghc/ticket/8808
Trac 1.2simonpjThu, 20 Feb 2014 12:21:44 GMT
http://ghc.haskell.org/trac/ghc/ticket/8808#comment:1
http://ghc.haskell.org/trac/ghc/ticket/8808#comment:1
<p>
Yes, I'm afraid that <code>ImpredicativeTypes</code> is a non-feature right now. As I wrote to the GHC users list yesterday:
</p>
<p>
<code>ImpredicativeTypes</code> is not properly finished. When I first implemented it I implemented a fairly ambitious design based on "boxy types" (see paper with that in the title). But it proved unsustainably complicated, both in the implementation and indeed for programmers to reason about which programs should be accepted and which should not.
</p>
<p>
So I took most of it out. There are some vestiges but to a first approximation it isn't really there at all.
</p>
<p>
My plan is to do something along the lines of QML (again, look at the paper), plus add explicit type application. But there are always too many other things to do.
</p>
<p>
This is swampy territory, and I have spent more time on it that I care to tell you without producing a design that I am satisfied with. So while I would be very happy if someone wants to start helping, you do need a good grasp of type inference first. It's not a project to learn on.
</p>
<p>
However the <em>internal</em> intermediate language, Core, is fully impredicative and always has been. No difficulties there.
</p>
<p>
Simon
</p>
Ticket