higher-kind deriving ... or not

[Simon Peyton-Jones]

| > data Wonky f
| >   =3D Wonky
| >   | Manky (f (Wonky f))
| >   deriving Show
|=20
| The trouble is that when I ask either hugs -98 or ghci=20
| -fglasgow-exts to
|=20
|   show (Wonky :: Wonky Copy)
|=20
| the poor compiler's brain explodes.

I fixed this a few weeks ago.  GHC (5.03) now says:

Foo.hs:3:
    No instance for `Show (f (Wonky f))'
    When deriving the `Show' instance for type `Wonky'

| I tried to guess the type of the show instance derived for=20
| Wonky. Being a naive sort of chap, I thought it might be
|=20
|   show :: (forall a. Show a =3D> Show (f a)) =3D> Wonky f -> String

Not naive.  That's exactly the right type.  See Section 7 of
"Derivable type classes".
http://research.microsoft.com/~simonpj/Papers/derive.htm
Havn't implemented this, yet, alas.

| It's clear that with typing problems, inference becomes=20
| unsustainable pretty soon after you leave the safe harbours=20
| of the Hindley-Milner system. However, lots of lovely=20
| programs have more interesting types: it would be very=20
| frustrating if Haskell forbade these programs just because=20
| their types were not inferrable---not least since, for these=20
| jobs, we usually do think of the type first and the code=20
| afterwards. Sensibly, Haskell allows us to write these types=20
| down, so the machine's task is merely checking. This hybrid=20
| approach preserves type inference for `old' code, whilst=20
| promoting more adventurous programming by allowing us to say=20
| what we mean when the machine is too dim to guess.

I agree wholeheartedly with this; it's exactly the approach I'm trying
to take with GHC.

One obvious extension is to let the user specify the context
for a derived instance decl, but still let the compiler generate
the code.   Havn't done this either!

Simon