The more I think about this, the more I wonder if we shouldn't treat NT in a similar way that we treat (~); that is, with built-in rules. The point is, we use (a) roles, and (b) visibility of the data constructor to control abstraction via existence/visibility of the instance. We don't really need a third mechanism (c) the presence or absence of a 'deriving' clause Instead, it can syntactically be a class, but be treateded rather like the SingI class which has an infinite number of instances -- that is, the type checker has a built-in way of simplifying NT constraints. For example, the typechecker simplifies [s] ~ [t] to s ~ t (This is just unification.) Similarly it can simplify NT [s] [t] to NT s t (in a role-aware way, of course). I think this will end up being a lot simpler than trying to push it through the full 'deriving' mechanism. Does that make sense? Simon | -----Original Message----- | From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of | Joachim Breitner | Sent: 19 August 2013 15:19 | To: ghc-devs | Subject: Advice about TcDeriv | | Hi, | | to support deriving NT instances properly, TcDeriv needs to be modified. | But there are some structural obstacles: So far, all classes which had | to be had the “type of interest” as their only type argument. Therefore, | DerivSpec, the data structure in that file, carries information about | what instances to derive, in the field dc_tc :: TyCon. | | But with NT it is different: | * It has two parameters, | * the type of interest is likely not the last parameter (e.g. NT Age | Int) | * and it can happen that there is a type variable in the last parameter | (e.g. NT Int a => NT Age a). | All that is difficult to squeeze into the existing data structure. | | The data type also has the ds_tys :: [Type] parameter, which contains | all type parameters to the class (e.g. [Int, a]). So at first I thought | about simply removing dc_tc and use the data from (last ds_tys) whenever | needed. But in the case of type families, ds_tc is not just the type | constructor of (last ds_tys), but rather what it resolves to. | | So before I rewrite lots of code there, I’d like to get some advice: | Should I extend the DerivSpec to support multi-parameter-typeclasses | (and figure out how to support data families here), or rather bypass the | whole lot and handle NT instance generation separately? Or is there | maybe another, more elegant way? | | Thanks, | Joachim | | -- | Joachim “nomeata” Breitner | mail@joachim-breitner.de • http://www.joachim-breitner.de/ | Jabber: nomeata@joachim-breitner.de • GPG-Key: 0x4743206C | Debian Developer: nomeata@debian.org