higher-kind deriving ... or not

Simon Peyton-Jones simonpj@microsoft.com
Wed, 27 Feb 2002 06:56:28 -0800

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

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

    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
|   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".
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!