Ralf, I'm a bit snowed under at the moment with the POPL PC meeting, but I'm quite open to changing GHC's "deriving" behaviour. It's not hard to change. The hard thing is figuring out just what the specification should be. So if you and others are able to evolve a better design, I'd be happy to implement it. (And of course think about it too.) I'm afraid that full-blown kind polymorphism is probably a bit of a stretch, though it comes up every now and again. So the best monomorphic compromise would be good. There's also the question of whether we should make any changes in GHC's libraries to take SYB3 (using classes) into account... Simon | -----Original Message----- | From: Ralf Lammel | Sent: 19 September 2005 04:34 | To: frederik@ofb.net | Cc: haskell-cafe@haskell.org; Simon Peyton-Jones | Subject: RE: [Haskell-cafe] generics question, logical variables | | Hi Frederik, | | [I call this "the dreadful lack of kind polymorphism strikes back" :-)] | | I put SPJ on cc; perhaps he can suggest a way to improve in this area. Based on input, I could try to | work on this issue in the not so remote future. | | Let me briefly recapitulate. My recollection is that deriving works for Typeable, Tyepable1, ..., if all | type parameters are of type kind "*". Whenever you can derive a Typeablen instance with n > 0, you | can instead ask for Typeable to be derived. The reason why you cannot get both a Typeable and say a | Typeable42 instance is that there are generic instances for getting an "n-1 instance" from the "n | instance". However, this is also precisely the reason why you don't want them both. That is, you get | everything you can ask for, if you have the "n instance" for the actual arity of the type constructor in | question. (Getting a smaller n or no n just means that you limit polymorphic type case.) Recall that | you *may* need a n>0 instance if you want to do polymorphic type case according to the SYB2 paper. | As long as you are fine with monomorphic generic function extension, the plain Typeable instance | should be fine. | | However, the real limitation is here, *indeed*, as said, that GHC does not derive Typeable[1|2|...] for | parameter kinds other than "*". This was the reason that I had to hand-code some Typeable instances | in your original example. | | Let us also be honest about another limitation of the current deriving code. "deriving Data" gives you | Data instances that do *not* support polymorphic type case. That is the following code prints 0, 1, 0 | whereas you may expect 0, 1, 2. | | newtype Foo x = Foo x deriving (Typeable, Data) | | f :: Data a => a -> Int | f = const 0 | `ext1Q` (\(_::Maybe x) -> 1) | `ext1Q` (\(_::Foo y) -> 2) | | main = do | print $ f True | print $ f (Just True) | print $ f (Foo (Just True)) | | | This is the reason that I had to handcode some Data instances in your original example, which wasn't | hard BTW. We thought that these two limitations were Ok since we didn't expect people to write many | polymorphic datatype constructors on which SYB should work. Sounds like a feature request. | | Now I wonder how much work it is to improve the situation. We need to make the GHC deriving code | a bit more kind-aware. I guess we are still not at the point where we want to add kind polymorphism | to Haskell? Would be a nice topic for future work on SYB. Clearly, the GH folks have done splendid | work in this area. Getting full-blown kind polymorphism in normal Haskell though seems to be less of a | topic, simply because we do not have many scenarios around that would *really* require it. | | Does anyone want to speak up and mention scenarios that would benefit from kind polymorphism? (In | Haskell, we are likely to see kind polymorphism, if at all, in the form of type classes whose type | parameters can be of different, perhaps of all kinds.) | | Frederik, for the time being I propose to look into TH code for deriving Tyepable/Data instances and to | make it fit for your purposes. There are several versions of Ulf Norell's code around. You may also use | SYB3 with the TH code that readily comes with it. | | Thanks for bringing this up. | | Regards, | Ralf