higher-kind deriving ... or not
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!