GHC 8 and Template Haskell

[Iavor Diatchki]

Sure, I'd be happy to help whoever needs help---just let me know.

The change that one would have to do is:  whenever you'd used "InstaceD"
 replace it with "InstanceD Nothing".




On Thu, Apr 14, 2016 at 2:33 PM, Herbert Valerio Riedel <hvriedel at gmail.com>
wrote:

> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20160414/e2e7cf93/attachment.html>