The GHC 8.0 feature freeze is coming

[Edward Z. Yang]

Based on my cursory look at the patch, I think it's unlikely to
break existing functionality in subtle ways.  So I'm OK with
trying to ship it in 8.0

Edward

Excerpts from Simon Marlow's message of 2015-12-03 09:50:37 -0800:
> On 03/12/2015 13:50, Ben Gamari wrote:
> > Luite Stegeman <stegeman at gmail.com> writes:
> >
> >> Is Simon's remote GHCi patch planned to go in before the fork? I'm still
> >> working on upgrading GHCJS to work with the master branch, but I haven't
> >> quite finished yet. This change would clearly require some restructuring of
> >> GHCJSi and Template Haskell in GHCJS, and I'm not sure if a week is enough
> >> to test the changes. Also the recent removal of boot file merging
> >> reintroduces a problem with that I'm not sure can be fixed without adding a
> >> new hook.
> >>
> > Simon, what do you think about this?
> >
> > I'm a bit worried that this patch is quite late and breaks users like
> > Luite. Nevertheless, I am willing to hear arguments for merging.
> 
> It doesn't have to go in, but I think it would be nice.  I'd like to 
> have it out for at least one major release in a disabled-by-default 
> state so that we can experiment with it.  But as far as my particular 
> goals for this feature are concerned, I'll backport the patch to 7.10 
> and use it in our local GHC build at Facebook regardless.
> 
> Luite - the hooks you use are still intact, so I don't think you have to 
> do any major restructuring in GHCJS until you're ready.  What I've 
> implemented will almost certainly need work to be usable or shareable 
> with GHCJS, and it's not clear to me exactly what the changes will look 
> like, but for the time being I thought the changes should not impact 
> GHCJS's implementation of TH & GHCi.  I could be wrong though, if so 
> please let me know how it breaks you.
> 
> Cheers,
> Simon
> 
> >> What's the policy on adding hooks or GHC API tweaks after the freeze?
> >>
> > We'll need to work that out when we get to that point. It largely
> > depends upon how confined and "safe" a change appears to be. That being
> > said, given how much other churn has happened for this release, I don't
> > think we want to be sloppy with merge discipline this time around.
> >
> > Austin, what do you think?
> >
> > Cheers,
> >
> > - Ben
> >