Re: GHC 8 and Template Haskell

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