Sorry for a slow reply. You definitely cannot infer kinds for an arbitrary FC program. The right thing to do is to *stop* using Type inside a KindedTyVar (always a hack) and instead use HsType. That'll require some work to make the existing setup work again, but I think it's the Right Thing.
Simon | -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] | On Behalf Of Aaron Tomb | Sent: 14 December 2006 23:52 | To: [EMAIL PROTECTED] | Subject: Parsing kinds in external core | | Hi, | | I encountered what might be a problem with parsing External Core | using HsType to represent types, though it might be possible to work | around it. It comes up when reading in a type variable with a kind | annotation which may be a type equality kind. These are represented | in HsType as the KindedTyVar alternative of HsTyVarBndr, which takes | a Kind as its second argument. However, Kind is just a name for Type | (not HsType), and thus it contains Names. Before type equality kinds | existed, this wasn't a problem, because no kind could contain type | variables. But now they can. | | So, to properly construct an appropriate Kind seems like it would | require running the renamer early on (probably in the parser), which | sounds like a headache, if its even feasible at all. | | Alternatively, we could ignore kind annotations in the parser (at | least for equality kinds) and create UserTyVars instead of | KindedTyVars. I believe it would then be possible to use existing | machinery to infer them later on (and, if I understand correctly, the | old implementation did this). Is it true that we can always infer | kinds? | | One problem with that approach, even if inference is no problem, is | that errors in kind annotations would be ignored. Maybe that doesn't | really matter. | | In any case, it seems to make sense to leave kind annotations in the | concrete syntax for External Core, because even if GHC can infer | them, they might make other implementations that use External Core | somewhat easier. | | Aaron | | _______________________________________________ | Cvs-ghc mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
