Good morning, Am Dienstag, den 20.08.2013, 07:24 +0000 schrieb 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?
it is certainly true that there are many obstacles when trying to use the normal class mechanisms here. One of the main reason we wanted to use (standalone) deriving instances (or even the NT type constructor idea earlier) was to give library authors a way to communicate their abstractions, to avoid the coercion between (Set Int) and (Set (Down Int)). But thanks to Richard’s role annotation, this can be prevented by annotating the Set’s type variables with @N. So far so good. Questions: * Will this annotation have other, possibly unwanted effects? * Should we also simplify constraints like (NT Age a) to (NT Int a) automatically and built-in, or do we still want the user to first tell us that we should do so? * What about the “only do it if constructors are in scope” idea – if the typechecker creates these instances on the fly, it might do so for modules where the constructors are not in scope (either because they are private, or simply because they have not been imported). Greetings, 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