<div dir="ltr"><div><div><div>Ryan<br><br></div>The discussion was in this thread [1], but went off list at some point.<br><br></div>The relevant part of the off-list discussion, quoting Philip Hölzenspies  is<br><br>"UndecidableInstances comes
 from having to constrain the type that the PostTcType-family projects 
to, besides the arguments of the AST-types;<br>
<br>
instance (<span class="">Data</span> (PostTcType <span class="">id</span>), <span class="">Data</span> <span class="">id</span>) => <span class="">Data</span> (HsIPBinds <span class="">id</span>) where
 ...<br>
<br>
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 "<span class="">id</span>" and, thus, we could actually just 
use "deriving".<br>
<br>
Of the diff, btw, I don't get why PendingRnSplice is suddenly 
parameterised... Thoughts?<br>
<br>
Ph."<br><br></div>and SimonPJ responded<br><br>"<br><p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Why
 do we need UndecidableInstances?</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">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.)</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)">Simon</span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:"Calibri","sans-serif";color:rgb(31,73,125)"> "</span></p><div><br></div><div>So basically there is a mention that it may be possible.<br><br></div><div>Alan<br></div><div><br><div><br><br><br><br>[1] <a href="https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html">https://mail.haskell.org/pipermail/ghc-devs/2014-July/005808.html</a><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 25, 2016 at 9:09 PM, Ryan Scott <span dir="ltr"><<a href="mailto:ryan.gl.scott@gmail.com" target="_blank">ryan.gl.scott@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> 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.<br>
<br>
</span>Do you happen to know where this discussion can be found online? To be<br>
honest, I'm not sure whether closed vs. open type families is even a<br>
relevant distinction in this case. Regardless of where NameOrRdrName<br>
is open or closed, the following code won't compile:<br>
<br>
    data Foo a = Foo (NameOrRdrName a) deriving Data<br>
<br>
And that's simply because GHC hasn't enough information to know<br>
whether Foo a will always resolve to something that's a Data instance.<br>
Even if NameOrRdrName is closed, someone could still use types like<br>
NameOrRdrName Char.<br>
<br>
If NameOrRdrName were somehow made to be injective, then it'd be a<br>
different story. But I doubt that such a thing is possible in this<br>
case (based on the definition of NameOrRdrName you gave), so I think<br>
we'll just have to settle for turning on UndecidableInstances and<br>
writing code that we know won't throw the typechecker into a loop.<br>
<br>
Ryan S.<br>
<div class="HOEnZb"><div class="h5"><br>
On Wed, May 25, 2016 at 2:52 PM, Alan & Kim Zimmerman<br>
<<a href="mailto:alan.zimm@gmail.com">alan.zimm@gmail.com</a>> wrote:<br>
> Ryan / Simon, thanks.<br>
><br>
> I have been working it in the way the PostRn stuff was done, but then it<br>
> struck me there may be an easier way.<br>
><br>
> I recall there was some discussion when the PostRn/PostTc stuff went in<br>
> around the closed type family solution being better, and I thought it was<br>
> that the Data instances would be more easy to define.<br>
><br>
> And I also seem to recall that the closed type families should be able to<br>
> get rid of the UndecidableInstances pragma, but I do not recall the details.<br>
><br>
> We are now able to use closed type families in GHC source, as it is<br>
> supported from GHC 7.8 onwards<br>
><br>
> Regards<br>
>   Alan<br>
><br>
><br>
> On Wed, May 25, 2016 at 8:42 PM, Ryan Scott <<a href="mailto:ryan.gl.scott@gmail.com">ryan.gl.scott@gmail.com</a>> wrote:<br>
>><br>
>> Simon is right, you cannot use a type family as an instance head. But why<br>
>> do you need to? Typically, if you're deriving a Data instance that involves<br>
>> type families, the type families would be inside another data type. A<br>
>> real-world example is HsBindLR [1]:<br>
>><br>
>>     data HsBindLR idL idR<br>
>>       = FunBind {<br>
>>           ...<br>
>>           bind_fvs :: PostRn idL NameSet,<br>
>>           ...<br>
>>         } | ...<br>
>><br>
>> where PostRn is a type family [2]. Now, you can't simply derive Data for<br>
>> HsBindLR, because GHC has no way of knowing what PostRn will evaluate to!<br>
>> But you can use standalone deriving to get what you want:<br>
>><br>
>>     deriving instance (Data (PostRn idL NameSet), ...) => Data (HsBindLR<br>
>> idL idR)<br>
>><br>
>> And in fact, this is what GHC does [3], using a convenient type synonyms<br>
>> for the long, sprawling context you need [4].<br>
>><br>
>> So in your example, while you can't directly create a Data instance for<br>
>> NameOrRdrName itself, you can quite easily create Data instances for<br>
>> anything that might use NameOrRdrName. Does that work for your use cases?<br>
>><br>
>> Ryan S.<br>
>> -----<br>
>> [1]<br>
>> <a href="http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111" rel="noreferrer" target="_blank">http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l111</a><br>
>> [2]<br>
>> <a href="http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47" rel="noreferrer" target="_blank">http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l47</a><br>
>> [3]<br>
>> <a href="http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264" rel="noreferrer" target="_blank">http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/HsBinds.hs#l264</a><br>
>> [4]<br>
>> <a href="http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102" rel="noreferrer" target="_blank">http://git.haskell.org/ghc.git/blob/bdc555885b8898684549eca70053c9ce0ec7fa39:/compiler/hsSyn/PlaceHolder.hs#l102</a><br>
>><br>
>> _______________________________________________<br>
>> ghc-devs mailing list<br>
>> <a href="mailto:ghc-devs@haskell.org">ghc-devs@haskell.org</a><br>
>> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
>><br>
><br>
</div></div></blockquote></div><br></div>