Advice about TcDeriv

[Simon Peyton-Jones]

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 at 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 at joachim-breitner.de • http://www.joachim-breitner.de/
|   Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
|   Debian Developer: nomeata at debian.org