> 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.

On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman
<alan.zimm@gmail.com> wrote:
> 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 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 <ryan.gl.scott@gmail.com> 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:/compiler/hsSyn/HsBinds.hs#l111
>> [2]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47
>> [3]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264
>> [4]
>> http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>