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 <e...@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
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs