A little deriving for GADTs

[guest]

For GADTs that are really enumerations, I think deriving Show should work. E.g.

data T a where
    Foo :: T Int
    Bar :: T Bool
    deriving (Show)

There's no(?) intricate behaviour of the derived functions, so why not?

-- Lennart

[simonpj]

Good suggestion. In general I'm all for it. But why just Show? And is enumerations the right restriction? I suppose you could say that any extra stuff is an improvement, but the less ad hoc the better.

In general, to do 'deriving' you need to solve two problems

1. Figure out the right context for the instance declaration.
2. Guarantee the the code generated for the instance will typecheck.

There are plenty of details. For example, (1) isn't necessary for "standalone deriving" because the programmer specifies the context. If he specifies the wrong context, the generated instance may not typecheck, so we cannot guarantee (2). So perhaps we should accept ANY data type (GADT or whatever) with standalone deriving, and say "it's your fault" if the derived code doesn't typecheck?

I don't have a strong position on any of this. If someone wants to figure out the detailed spec, implementation is probably not hard.

Simon

(Lennart, are you sure you don't want a Trac login of your own?)

[igloo]

We're going to typecheck the derived code anyway, right? I don't think it's worth trying to predict in advance whether or not this will succeed, especially as the prediction has the potential to not exactly match what the actual type checker will accept.

[FSalad]

Replying to simonpj:

So perhaps we should accept ANY data type (GADT or whatever) with standalone deriving, and say "it's your fault" if the derived code doesn't typecheck?

Sounds like a good idea. I've written several completely boilerplate instances for GADTs recently and this would have been very convenient :) I wouldn't find "it's your fault"-type behaviour unintuitive for StandaloneDeriving?.

[simonpj]

OK it's done

Thu Jul 23 06:01:45 PDT 2009  simonpj@microsoft.com
  * Fix Trac #3012: allow more free-wheeling in standalone deriving
  Ignore-this: 357580b9388ccbe1da3c1da3ba90e456
  
  In standalone deriving, we now do *not* check side conditions.
  We simply generate the code and typecheck it.  If there's a type
  error, it's the programmer's problem. 
  
  This means that you can do 'deriving instance Show (T a)', where
  T is a GADT, for example, provided of course that the boilerplate
  code does in fact typecheck.
  
  I put some work into getting a decent error message.  In particular
  if there's a type error in a method, GHC will show the entire code
  for that method (since, after all, the user did not write it).
  Most of the changes are to achieve that goal.
  
  Still to come: changes in the documentation.
  

    M ./compiler/typecheck/TcClassDcl.lhs -1 +1
    M ./compiler/typecheck/TcDeriv.lhs -25 +27
    M ./compiler/typecheck/TcEnv.lhs -2 +3
    M ./compiler/typecheck/TcInstDcls.lhs -8 +22
    M ./compiler/typecheck/TcMatches.lhs -1 +2
    M ./compiler/typecheck/TcRnMonad.lhs -21 +31
    M ./compiler/typecheck/TcRnTypes.lhs -6 +9
    M ./compiler/utils/Outputable.lhs -3 +3

Simon