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 <eir@cis.upenn.edu> wrote:
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