I started this thread feeling uncomfortable about a `deriving` clause instantiating `k` to `*`. But `deriving` *does* infer constraints. Perhaps it's just inferring a `(k ~ *)` constraint. Thinking of it this way makes me prefer (3).
Richard On Mar 28, 2016, at 5:12 PM, Ryan Scott <ryan.gl.sc...@gmail.com> wrote: >> I don't really expect any of the TypeInType stuff to work with the deriving >> machinery. > > I do! And we can make -XDeriveFunctor work well with -XTypeInType > regardless of which option is picked, so keep that in mind. > >> I think that, at the moment, for a normal deriving clause, GHC never adds in >> constraints (I might be wrong on this). > > GHC does add constraints in some cases. Here's a less dangerous-looking > example: > > data T (a :: k) = T deriving Functor > => > instance Functor T > > The generated instance very subtly constraints k to be *. The > difference in this example, however, is that k is not visible, so it > feels less harmful to constrain it. > >> I don't know if StandaloneDeriving works with DeriveFunctor or not > > It does. -XStandaloneDeriving works with any flavor of deriving out > there, and it's a great backdoor to get around sticky deriving issues > like this (e.g., if a derived instance context would require > undecidable typechecking, we bail out and tell the user to try again > with -XStandaloneDeriving). > > I don't have a strong opinion on whether option 1, 2, or 3 is best, > but if we pick option 1 or 2, I request that the error message tell > the user to try -XStandaloneDeriving. > > Ryan S. > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
