instantiating visible parameters in when deriving instances
Richard Eisenberg
eir at cis.upenn.edu
Mon Mar 28 19:05:28 UTC 2016
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.scott at 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
More information about the ghc-devs
mailing list