I like number option number two. I don't really expect any of the
TypeInType stuff to work with the deriving machinery. I think that, at the
moment, for a normal deriving clause, GHC never adds in constraints (I
might be wrong on this). Whenever constraints, I feel like
StandaloneDeriving is the right choice. I don't know if StandaloneDeriving
works with DeriveFunctor or not, but if it does, then this is what I would
expect:
REJECTED
data Proxy k (a :: k) = P
deriving Functor
ACCEPTED
data Proxy k (a :: k) = P
deriving instance (k ~ *) => Functor Proxy k
But if the second code snippet involving StandaloneDeriving can't be made
to work, I would still prefer for the first snippet to be rejected as well.
Just my two cents.
-Andrew Thaddeus Martin
On Mon, Mar 28, 2016 at 8:55 AM, Richard Eisenberg
Hi devs,
Consider the following:
data Proxy k (a :: k) = P deriving Functor
What should happen when this is compiled? 1. Issue an error saying that `deriving` cannot instantiate visible parameters. 2. Type error: cannot match `k` with `*`. 3. Successfully produce `instance (Proxy *)`.
Currently, GHC does #3. But this ends up choosing a value for a visible (i.e. explicit) parameter to Proxy. Is this a good idea? I myself have flip-flopped on this issue; see https://ghc.haskell.org/trac/ghc/ticket/11732, comments 4 and 9.
I'd love to get feedback on this point.
Thanks! Richard _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
-- -Andrew Thaddeus Martin