<div dir="ltr"><div>Sure, I'd be happy to help whoever needs help---just let me know.</div><div><br></div><div>The change that one would have to do is:  whenever you'd used "InstaceD"  replace it with "InstanceD Nothing".</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 14, 2016 at 2:33 PM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:<br>
<br>
[...]<br>
<span class=""><br>
> If we were to delay things, we would ship a version of the library that has<br>
> missing functionality *and* we'll break everyone's code on the next<br>
> release.<br>
<br>
>   If we make the change now, then at least when people fix their TH<br>
> code to work with GHC 8, they'd be getting access to more<br>
> functionality.<br>
><br>
> This change does indeed change the data structure for declarations, so if<br>
> you were working with it directly, indeed you'll have to make changes.<br>
<br>
</span>This so late in the process involves retroactively tighten upper bounds<br>
on template-haskell for existing releases on Hackage which already<br>
extended support to template-haskell-2.11.<br>
<br>
Sadly, I have lost track of how many packages were already updated<br>
several weeks ago since the first RC came out to work with<br>
template-haskell-2.11 so I don't have any numbers to offer nor a<br>
concrete list of which packages are likely candidates to become<br>
penalized for having been early adopters of GHC 8.0.<br>
<br>
So this will cause a regression on Hackage which will be actionable only<br>
after GHC 8.0 final gets out (unless we happen to have a RC4), as<br>
otherwise we'd break parts of Hackage for GHC 8.0 RC3 users<br>
(this includes Travis jobs already including GHC 8.0 in their configs)<br>
<br>
However, I do sympathize with the desire to get this in while it's still<br>
relatively cheap, rather than have to wait a year until it's time for<br>
template-haskell-2.12 ...<br>
<br>
Would you be willing to help out with making sure popular packages<br>
depending on template-haskell[1] are brought up speed as soon as your<br>
proposed change lands to reduce the pain/cost of such a last-minute<br>
change?<br>
<br>
<br>
 [1]: <a href="http://packdeps.haskellers.com/reverse/template-haskell" rel="noreferrer" target="_blank">http://packdeps.haskellers.com/reverse/template-haskell</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
> However, if you use the "smart" constructors in TH, you shouldn't need to<br>
> change anything.<br>
> In particular, I left `instanceD` as before---it does not add any<br>
> overlapping pragmas, and I added a new function `instanceWithOverlapD`,<br>
> which has an extra parameter that allows you to specify pragmas.<br>
><br>
> I'd like to get this in, if possible, as I have a library that needs this<br>
> feature.  My current work-around it quite ugly:  ask the clients of the<br>
> library to enable "Language OverlappingInstaces", which is cumbersome,<br>
> *and* generates deprecation warnings.<br>
</div></div></blockquote></div><br></div>