Hi, Am Samstag, den 12.10.2013, 12:12 +0000 schrieb Simon Peyton-Jones:
The exact rules you suggest for when "deriving(Coercible)" would be allowed, are the rules we can use for when we need a "from thin air" instance.
right! The important difference is that with deriving, only the the type author can use the features, and can decide whether he wants to allow it for his data type or not.
Moreover, I'm very keen to give a simple, precise answer to the question if s is coercible to t when is (T s) coercible to (T t) I propose that the answer is given by precisely T's roles. At the moment I don't see why we would want to do anything more complicated.
I’m not sure if „... if the roles allow it“ is any simpler than „if there is a Coercible instance for it“, and Haskell programmers might be happier if they can think in terms of type class instances without learning a new concept. But you are right: This thread doesn’t really add any thing new; it would just be an alternative way to specify coercability (explicit instances instead of role annotation), which is a bit more familiar to the programmer, possible more flexible (e.g. some library author could make the instance conditional by adding some fancy type-class-hackery constraints), possibly less flexible (no way to talk about coercing types that involve class class constraints). 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