Re: instances for closed type families

Ryan The discussion was in this thread [1], but went off list at some point. The relevant part of the off-list discussion, quoting Philip Hölzenspies is "UndecidableInstances comes from having to constrain the type that the PostTcType-family projects to, besides the arguments of the AST-types; instance (Data (PostTcType id), Data id) => Data (HsIPBinds id) where ... If we could derive that from the definition of PostTcType (and I don't see why we couldn't from a closed family; not sure about the open ones), we would only need to constrain "id" and, thus, we could actually just use "deriving". Of the diff, btw, I don't get why PendingRnSplice is suddenly parameterised... Thoughts? Ph." and SimonPJ responded " Why do we need UndecidableInstances? I still (currently) think we can use open type families perfectly well. Why won’t that work? (Could switch to closed after GHC’s bootstrap caught up.) Simon " So basically there is a mention that it may be possible. Alan [1] https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html On Wed, May 25, 2016 at 9:09 PM, Ryan Scott wrote:

...

I recall there was some discussion when the PostRn/PostTc stuff went in around the closed type family solution being better, and I thought it was that the Data instances would be more easy to define.

Do you happen to know where this discussion can be found online? To be honest, I'm not sure whether closed vs. open type families is even a relevant distinction in this case. Regardless of where NameOrRdrName is open or closed, the following code won't compile:

data Foo a = Foo (NameOrRdrName a) deriving Data

And that's simply because GHC hasn't enough information to know whether Foo a will always resolve to something that's a Data instance. Even if NameOrRdrName is closed, someone could still use types like NameOrRdrName Char.

If NameOrRdrName were somehow made to be injective, then it'd be a different story. But I doubt that such a thing is possible in this case (based on the definition of NameOrRdrName you gave), so I think we'll just have to settle for turning on UndecidableInstances and writing code that we know won't throw the typechecker into a loop.

Ryan S.

...

Ryan / Simon, thanks.

I have been working it in the way the PostRn stuff was done, but then it struck me there may be an easier way.

I recall there was some discussion when the PostRn/PostTc stuff went in around the closed type family solution being better, and I thought it was that the Data instances would be more easy to define.

And I also seem to recall that the closed type families should be able to get rid of the UndecidableInstances pragma, but I do not recall the

On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman wrote: details.

...

We are now able to use closed type families in GHC source, as it is supported from GHC 7.8 onwards

Regards Alan

On Wed, May 25, 2016 at 8:42 PM, Ryan Scott

wrote:

...

...

Simon is right, you cannot use a type family as an instance head. But

why

...

do you need to? Typically, if you're deriving a Data instance that involves type families, the type families would be inside another data type. A real-world example is HsBindLR [1]:

data HsBindLR idL idR = FunBind { ... bind_fvs :: PostRn idL NameSet, ... } | ...

where PostRn is a type family [2]. Now, you can't simply derive Data for HsBindLR, because GHC has no way of knowing what PostRn will evaluate to! But you can use standalone deriving to get what you want:

deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR idL idR)

And in fact, this is what GHC does [3], using a convenient type synonyms for the long, sprawling context you need [4].

So in your example, while you can't directly create a Data instance for NameOrRdrName itself, you can quite easily create Data instances for anything that might use NameOrRdrName. Does that work for your use cases?

Ryan S. ----- [1]

http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39...

...

[2]

http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39...

...

[3]

http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39...

...

[4]

http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39...

...

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs