Here's a question, on top of this one: why don't we require template-haskell changes for most corresponding syntax changes? We tend to play catch up with template-haskell sometimes and it's relatively strange. I mean, in some sense, we could have said a while back "This needs another revision, please add template haskell support" and avoided it all. Richard has a better insight into this than I do, I'm sure, but it seems - to me, anyway - like template-haskell support is a reasonable bar for most surface-level syntax change to cross, before getting merged. My intuition tells me that, most of the time, a lot of us simply forget to make the changes, or ask for them in reviews, and so it goes. On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari wrote:

Iavor Diatchki writes:

...

Hello,

Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate.

If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP.

Indeed this is an unfortunate gap. Given that this shouldn't be a terribly invasive change I would be alright with this if Richard approves.

Cheers,

- Ben

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

Hi, objection! :-) 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. 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. -Iavor On Thu, Apr 14, 2016 at 1:59 PM, Richard Eisenberg wrote:

I'm happy to be overruled on this, but I vote against this change for GHC 8. Personally, I like to have a policy of "no TH changes after the first RC". This gives ample time for TH clients to update their code. Iavor's suggestion would likely involve a new part of the InstanceD constructor, which would affect anyone constructing or matching on this constructor. If the change involved, say, only adding new functionality without changing anything existing, I would be more willing to include for GHC 8.

And, yes, I agree with Austin.

Richard

On Apr 14, 2016, at 2:17 PM, Austin Seipp wrote:

...

Here's a question, on top of this one: why don't we require template-haskell changes for most corresponding syntax changes? We tend to play catch up with template-haskell sometimes and it's relatively strange. I mean, in some sense, we could have said a while back "This needs another revision, please add template haskell support" and avoided it all.

Richard has a better insight into this than I do, I'm sure, but it seems - to me, anyway - like template-haskell support is a reasonable bar for most surface-level syntax change to cross, before getting merged.

My intuition tells me that, most of the time, a lot of us simply forget to make the changes, or ask for them in reviews, and so it goes.

On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari wrote:

...

Iavor Diatchki writes:

...

Hello,

Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate.

If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP.

Indeed this is an unfortunate gap. Given that this shouldn't be a terribly invasive change I would be alright with this if Richard approves.

Cheers,

- Ben

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

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 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.

I think a general "no TH changes after the first RC" seems reasonable as part of the broader feature freeze. But this case seems decidedly more of a bug fix than a feature addition, since TH *should* have feature parity with Haskell syntax. So I'd favor merging Iavor's patch. I also like Austin's suggestion that we require template-haskell patches alongside new syntax. Eric On Thu, Apr 14, 2016, at 13:59, Richard Eisenberg wrote:

I'm happy to be overruled on this, but I vote against this change for GHC 8. Personally, I like to have a policy of "no TH changes after the first RC". This gives ample time for TH clients to update their code. Iavor's suggestion would likely involve a new part of the InstanceD constructor, which would affect anyone constructing or matching on this constructor. If the change involved, say, only adding new functionality without changing anything existing, I would be more willing to include for GHC 8.

And, yes, I agree with Austin.

Richard

On Apr 14, 2016, at 2:17 PM, Austin Seipp wrote:

...

Here's a question, on top of this one: why don't we require template-haskell changes for most corresponding syntax changes? We tend to play catch up with template-haskell sometimes and it's relatively strange. I mean, in some sense, we could have said a while back "This needs another revision, please add template haskell support" and avoided it all.

Richard has a better insight into this than I do, I'm sure, but it seems - to me, anyway - like template-haskell support is a reasonable bar for most surface-level syntax change to cross, before getting merged.

My intuition tells me that, most of the time, a lot of us simply forget to make the changes, or ask for them in reviews, and so it goes.

On Thu, Apr 14, 2016 at 1:12 PM, Ben Gamari wrote:

...

Iavor Diatchki writes:

...

Hello,

Now that "OVERLAPPING" and "OVERLAPPABLE" are pragmas on the instances, do we have a way to generate instances with such pragmas using Template Haskell? I can't seem to find a way to do this, which is unfortunate.

If I am not missing anything, would there be objections to adding it to the TH library before the next release---I would volunteer to do the change ASAP.

Indeed this is an unfortunate gap. Given that this shouldn't be a terribly invasive change I would be alright with this if Richard approves.

Cheers,

- Ben

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

-- Regards,

Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs