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. _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
