X-Git-Url: http://git.megacz.com/?p=ghc-hetmet.git;a=blobdiff_plain;f=utils%2Fext-core%2FREADME;fp=utils%2Fext-core%2FREADME;h=4fb16ffcf2dfb1260a6faa76515a853fbcec9a8a;hp=9afd388175b1367cd1466f7963ee42c52aaaf08e;hb=10704b34c1928dde3d0ef33fe37c3eb7b948975f;hpb=b0045fdd4404f3ac2ddacad8c39a017f01f8ff6b

diff --git a/utils/ext-core/README b/utils/ext-core/README
index 9afd388..4fb16ff 100644
--- a/utils/ext-core/README
+++ b/utils/ext-core/README
@@ -9,15 +9,20 @@ tjc April 2008:
 ==== Notes ====
 
 The checker should work on most programs. Bugs I'm aware of:
-1. GHC generates some questionable coercion applications involving
-   partially-applied function arrows (for details, see:
+1. There's some business I don't quite understand involving
+   coercions and subkinding (for details, see:
    http://www.haskell.org/pipermail/cvs-ghc/2008-April/041949.html)
    This shows up when typechecking a few of the library modules.
-
+   
 2. There's some weirdness involving funny character literals. This can
    be fixed by writing a new lexer for chars rather than using Parsec's
    built-in charLiteral lexer. But I haven't done that.
 
+3. When typechecking the ghc-prim:GHC.PrimopWrappers library module,
+   some declarations seem to have the wrong type signature (due to 
+   confusion between (forall (t::*) ...) and (forall (t::?) ...).)
+   This may be a GHC bug.
+
 Typechecking all the GHC libraries eats about a gig of heap and takes a
 long time. I blame Parsec. (Someone who was bored, or understood happy
 better than I do, could update the old happy parser, which is still in the