Deriving for indexed data types
authorManuel M T Chakravarty <chak@cse.unsw.edu.au>
Mon, 18 Dec 2006 21:12:05 +0000 (21:12 +0000)
committerManuel M T Chakravarty <chak@cse.unsw.edu.au>
Mon, 18 Dec 2006 21:12:05 +0000 (21:12 +0000)
commit380512de6eef0cbb17431d9e64007a9320914e23
treed1453f0a15d4f437168716210d38057e123cefd2
parent5f8b35ad729740cab1cb8c884deb405dcc758683
Deriving for indexed data types
- This patch implements deriving clauses for data instance declarations
  (toplevel and associated)
- Doesn't support standalone deriving.  This could be easily supported,
  but requires an extension of the syntax of standalone deriving clauses.
  Björn, fancy adding this?
- We cannot derive Typeable.  This seems a problem of notation, more than
  anything else.  Why?  For a binary vanilla data type "T a b", we would
  generate an instance Typeable2 T; ie, the instance is for the constructor
  alone.  In the case of a family instance, such as (S [a] (Maybe b)), we
  simply have no means to denote the associated constuctor.  It appears to
  require type level lambda - something like (/\a b. S [a] (Maybe b).
- Derivings are for *individual* family *instances*, not for entire families.
  Currently, I know of no simple translation of class instances for entire
  families to System F_C.  This actually seems to be similar to implementing
  open data types à la Löh & Hinze.
- This patch only covers data types, not newtypes.
compiler/typecheck/TcDeriv.lhs
compiler/typecheck/TcEnv.lhs
compiler/types/FamInstEnv.lhs
compiler/types/Type.lhs