GHC 8 and Template Haskell

[Herbert Valerio Riedel]

On 2016-04-14 at 23:11:26 +0200, Iavor Diatchki wrote:

[...]

> If we were to delay things, we would ship a version of the library that has
> missing functionality *and* we'll break everyone's code on the next
> release.

>   If we make the change now, then at least when people fix their TH
> code to work with GHC 8, they'd be getting access to more
> functionality.
>
> This change does indeed change the data structure for declarations, so if
> you were working with it directly, indeed you'll have to make changes.

This so late in the process involves retroactively tighten upper bounds
on template-haskell for existing releases on Hackage which already
extended support to template-haskell-2.11.

Sadly, I have lost track of how many packages were already updated
several weeks ago since the first RC came out to work with
template-haskell-2.11 so I don't have any numbers to offer nor a
concrete list of which packages are likely candidates to become
penalized for having been early adopters of GHC 8.0.

So this will cause a regression on Hackage which will be actionable only
after GHC 8.0 final gets out (unless we happen to have a RC4), as
otherwise we'd break parts of Hackage for GHC 8.0 RC3 users
(this includes Travis jobs already including GHC 8.0 in their configs)

However, I do sympathize with the desire to get this in while it's still
relatively cheap, rather than have to wait a year until it's time for
template-haskell-2.12 ...

Would you be willing to help out with making sure popular packages
depending on template-haskell[1] are brought up speed as soon as your
proposed change lands to reduce the pain/cost of such a last-minute
change?


 [1]: http://packdeps.haskellers.com/reverse/template-haskell


> However, if you use the "smart" constructors in TH, you shouldn't need to
> change anything.
> In particular, I left `instanceD` as before---it does not add any
> overlapping pragmas, and I added a new function `instanceWithOverlapD`,
> which has an extra parameter that allows you to specify pragmas.
>
> I'd like to get this in, if possible, as I have a library that needs this
> feature.  My current work-around it quite ugly:  ask the clients of the
> library to enable "Language OverlappingInstaces", which is cumbersome,
> *and* generates deprecation warnings.