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.

On 04/14/2016 08: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.

ISTM that this kind of thing could be reasonably handled by simply having a checklist for new functionality -- which includes TH support as a checkbox. I'm sure others there are other frequently-forgotten-but-important things that people can think of to put into such a checklist. (Not sure if GHC has a "Release" checklist, but I'd imagine one of those might also be useful.) Checklists can be very effective as long as you remember two rules: [ ] You need be consistent about following them [ ] They need to be kept as short and succinct as possible so that it doesn't become an undue burden (and thus, liable to be ignored). The first point might seem paradoxical given that we're talking about forgetting to do something, but it really isn't. As long as all one has to remember is *one* thing[1], namely to "always do the checklist", then it's easy to remember doing it and to make it a habit. And if you forget, it's easy for others to remember to remind you to go through it. If Phab supports "message templates" for proposed merges, then it'd probably be easiest to just include such a checklist there. Otherwise, a good home might be the wiki so that there's always a fixed place to refer to. As to the "succinct" bit: Whether to have an item on the list is determined by "cost of failure to do" said item and likelihood of forgetting. The list is obviously up for revision as one learns more. If anyone's interested in what checklists can do for you, I'd recommend the marvelous book "The Checklist Manifesto" by Atul Gawande. Regards, [1] Rather than many different things -- the things *on* the checklist.