| > data Wonky f
| > = Wonky
| > | Manky (f (Wonky f))
| > deriving Show
|
| The trouble is that when I ask either hugs -98 or ghci
| -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:
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
| Wonky. Being a naive sort of chap, I thought it might be
|
| show :: (forall a. Show a => Show (f a)) => 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
| unsustainable pretty soon after you leave the safe harbours
| of the Hindley-Milner system. However, lots of lovely
| programs have more interesting types: it would be very
| frustrating if Haskell forbade these programs just because
| their types were not inferrable---not least since, for these
| jobs, we usually do think of the type first and the code
| afterwards. Sensibly, Haskell allows us to write these types
| down, so the machine's task is merely checking. This hybrid
| approach preserves type inference for `old' code, whilst
| promoting more adventurous programming by allowing us to say
| 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
_______________________________________________
Haskell-Cafe mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell-cafe
