GHC 7.8 release?

[Carter Schonwald]

Yes, exactly this.

A release where the versions of base, and all other baked in libraries are
only minor version bumps and where breaking changes are localized to
relatively experimental language features / extensions and GHC specific
APIs would ideal.

Eg: I'm OK having to patch ghc-mod so it works with a new intermediate GHC
release.  (Esp since it uses GHC internal apis)

The new scheduler improvements, the recent doh work  , the great SIMD work
/ code generator improvments, the type level nats, ordered type families,
the overloaded list syntax,

All of these extensions and associated API augmentations should not break
stable libraries, at least on minor version bumps, cause
1) maybe experimental new APIs can be included in minor releases as
separate explicitly experimental modules (this gives a way of including new
functionality in a minor release)
2) generally type checking / inference on stable code that doesn't enable
new features stays the same.

I'm probably overlooking some pieces or. Details, and I'm largely restating
what Johan and Manuel have communicated.

-Carter
On Feb 10, 2013 4:43 PM, "Ian Lynagh" <ian at well-typed.com> wrote:

> On Sun, Feb 10, 2013 at 09:30:23PM +0000, Simon Peyton-Jones wrote:
> > |  > You may ask what use is a GHC release that doesn't cause a wave of
> updates?
> > |  And hence that doesn't work with at least some libraries.  Well, it's
> a very useful
> > |  forcing function to get new features actually out and tested.
> > |
> > |  But the way you test new features is to write programs that use them,
> > |  and programs depend on libraries.
> >
> > That is of course ideal, but the ideal carries costs.  A half way house
> is a release whose library support will be patchy.
>
> But that's not what happens. GHC 7.8 is released. Someone installs it in
> order to try to use TypeHoles when developing their program. But their
> program depends on text, so they send Bryan a mail saying that text
> doesn't build with 7.8. And so the wave of updates begins.
>
>
> Thanks
> Ian
>
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130210/e4c1e6b8/attachment.htm>