Advice about TcDeriv
simonpj at microsoft.com
Tue Aug 20 09:24:31 CEST 2013
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]
s ~ t
(This is just unification.) Similarly it can simplify
NT [s] [t]
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?
| -----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
| 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
| * 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?
| 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
More information about the ghc-devs