GHC 7.8 release?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
62 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Gabriel Dos Reis
In reply to this post by Ian Lynagh-2
On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <ian at well-typed.com> wrote:

> On Sun, Feb 10, 2013 at 09:02:18PM +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.
>
>
> Thanks
> Ian

Releasing GHC early and often (possibly with API breakage) isn't
really the problem.  The real problem is how to coordinate with
library authors (e.g. Haskell Platform), etc.

I suspect GHC should continue to offer a platform for research
and experiments. That is much harder if you curtail the ability to
release GHC early and often.

-- Gaby


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Carter Schonwald
Well said. Having a more aggressive release cycle is another interesting
perspective.
On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <gdr at integrable-solutions.net>
wrote:

> On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <ian at well-typed.com> wrote:
> > On Sun, Feb 10, 2013 at 09:02:18PM +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.
> >
> >
> > Thanks
> > Ian
>
> Releasing GHC early and often (possibly with API breakage) isn't
> really the problem.  The real problem is how to coordinate with
> library authors (e.g. Haskell Platform), etc.
>
> I suspect GHC should continue to offer a platform for research
> and experiments. That is much harder if you curtail the ability to
> release GHC early and often.
>
> -- Gaby
>
> _______________________________________________
> 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/e990d7b3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

John Lato-2
While I'm notionally in favor of decoupling API-breaking changes from
non-API breaking changes, there are two major difficulties: GHC.Prim and
Template Haskell. Should a non-API-breaking change mean that GHC.Prim is
immutable?  If so, this greatly restricts GHC's development.  If not, it
means that a large chunk of hackage will become unbuildable due to deps on
vector and primitive.  With Template Haskell the situation is largely
similar, although the deps are different.

What I would like to see are more patch-level bugfix releases.  I suspect
the reason we don't have more is that making a release is a lot of work.
 So, Ian, what needs to happen to make more frequent patch releases
feasible?



On Mon, Feb 11, 2013 at 7:42 AM, Carter Schonwald <
carter.schonwald at gmail.com> wrote:

> Well said. Having a more aggressive release cycle is another interesting
> perspective.
> On Feb 10, 2013 6:21 PM, "Gabriel Dos Reis" <gdr at integrable-solutions.net>
> wrote:
>
>> On Sun, Feb 10, 2013 at 3:16 PM, Ian Lynagh <ian at well-typed.com> wrote:
>> > On Sun, Feb 10, 2013 at 09:02:18PM +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.
>> >
>> >
>> > Thanks
>> > Ian
>>
>> Releasing GHC early and often (possibly with API breakage) isn't
>> really the problem.  The real problem is how to coordinate with
>> library authors (e.g. Haskell Platform), etc.
>>
>> I suspect GHC should continue to offer a platform for research
>> and experiments. That is much harder if you curtail the ability to
>> release GHC early and often.
>>
>> -- Gaby
>>
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>
>
> _______________________________________________
> 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/20130211/d97757f1/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
On Mon, Feb 11, 2013 at 10:09:56AM +0800, John Lato wrote:
>
> What I would like to see are more patch-level bugfix releases.  I suspect
> the reason we don't have more is that making a release is a lot of work.
>  So, Ian, what needs to happen to make more frequent patch releases
> feasible?

Well,
* actually making a release takes time
* I assume that you also want more patches merged from the HEAD, rather
  than just putting intermediate releases out, in which case merging
  those patches also takes time. And most of the small fixes already get
  merged, so you'd be looking at merging bigger changes which are more
  likely to require resolving conflicts, and so take even more time

so basically to make more releases we'd need to spend less time doing
other stuff (or for someone else to look after the branch).

Bigger changes, and especially changes that need altering for the stable
branch, are also more likely to introduce bugs.


Thanks
Ian



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Gabriel Dos Reis
In reply to this post by Simon Peyton Jones
On Sun, Feb 10, 2013 at 3:30 PM, Simon Peyton-Jones
<simonpj at microsoft.com> 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.  Not such good testing, but much lower costs.  But still (I think) a lot more testing than "compile HEAD" gives us.
>
> Simon

Fitting:

     http://xkcd.com/1172/

(sorry, I couldn't resist)

-- Gaby


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Peyton Jones
In reply to this post by Simon Peyton Jones
(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

These must be social questions (what I was earlier calling ?signposting?) rather than technical ones.  For example, you say that (b) is not subject to any variety of reason, and yet no linux distribution tracks HEAD, does it?  They don?t openly insult anyone who points to a release just because HEAD has new cool stuff!  No, they track things we call ?releases?.  Very well, maybe we should call them ?previews? instead, and only dignify it as a ?release? when, and only when a preview is picked by HP as worthy of incorporation in the next HP.

Or something.   I?m just looking for a way to reconcile

?        Release early, release often

?        Stability for the Haskell Platform
It seems to me that such a reconciliation is within reach, and is actually very close to what we do, if we only signpost what is what far more vigorously and clearly than we do now.  But maybe I?m wrong.

Simon

From: Brandon Allbery [mailto:allbery.b at gmail.com]
Sent: 11 February 2013 01:15
To: Simon Peyton-Jones
Cc: Simon Marlow; Mark Lentczner; Manuel M T Chakravarty; kostirya at gmail.com; glasgow-haskell-users; ghc-devs at haskell.org; Edsko de Vries
Subject: Re: GHC 7.8 release?

On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj at microsoft.com<mailto:simonpj at microsoft.com>> wrote:
What causes the "wave of package updates"?  Just because GHC 7.8 (say) comes out, no package author need lift a finger.  The Haskell Platform sets the pace for package updates. When the Haskell Platform comes out, now THAT is indeed a trigger for a wave of updates.  Authors of packages in HP are forced to act; authors of other packages want their packages to work with the next HP.

(a) There are packages which tend to track GHC's latest version instead of the HP (yesod used to do this, which was a source of much pain).

(b) There are linux distributions which always track the latest everything, often in a rolling-release fashion (notably Arch).  They are actively hostile to the Platform, and a source of even greater pain.  Many package authors update because Arch users demand it and openly insult anyone who points them to the Platform or any policy which suggests that anything other then the absolutely latest version is acceptable.

You *might* be able to control expectations with respect to (a); (b) is not subject to any variety of reason.  It will produce as much pressure as it has users, plus multiply that pressure by the number of package authors who are also users.

--
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com<mailto:allbery.b at gmail.com>                                  ballbery at sinenomine.net<mailto:ballbery at sinenomine.net>
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130211/211f2e22/attachment-0001.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Carter Schonwald
Agreed.

having relatively bug free "technology preview" releases, which (perhaps
ideally) have new functionality included in a way that keeps the breakage
overhead lowish, on a regular basis, is ideal.

one thought on the api hacking front:

the main concern we're hitting is that we want to not "pin" internal GHC
apis, yet we want to make the breakage rate on libraries people may want to
use that might depend on say GHC.Prim or GHC.TH to be minimal.

Is a possible solution that on preview releases we have the changed bits of
API for a module M to be exported in a module M.Experimental?

eg, new ghc primops  in a tech preview release maybe are exported by
GHC.Prim.Experimental
(or something of this sort?)

just throwing out one possible point in the design space.

cheers
-Carter



On Mon, Feb 11, 2013 at 5:31 PM, Simon Peyton-Jones
<simonpj at microsoft.com>wrote:

>  (a) There are packages which tend to track GHC's latest version instead
> of the HP (yesod used to do this, which was a source of much pain).****
>
>                                           ****
>
> (b) There are linux distributions which always track the latest
> everything, often in a rolling-release fashion (notably Arch).  They are
> actively hostile to the Platform, and a source of even greater pain.  Many
> package authors update because Arch users demand it and openly insult
> anyone who points them to the Platform or any policy which suggests that
> anything other then the absolutely latest version is acceptable.****
>
> ** **
>
> These must be *social* questions (what I was earlier calling
> ?signposting?) rather than technical ones.  For example, you say that (b)
> is not subject to any variety of reason, and yet no linux distribution
> tracks HEAD, does it?  They don?t openly insult anyone who points to a
> release just because HEAD has new cool stuff!  No, they track things we
> call ?releases?.  Very well, maybe we should call them ?previews? instead,
> and only dignify it as a ?release? when, and only when a preview is picked
> by HP as worthy of incorporation in the next HP. ****
>
> ** **
>
> Or something.   I?m just looking for a way to reconcile****
>
> **?        **Release early, release often****
>
> **?        **Stability for the Haskell Platform****
>
> It seems to me that such a reconciliation is within reach, and is actually
> very close to what we do, if we only signpost what is what far more
> vigorously and clearly than we do now.  But maybe I?m wrong.****
>
> ** **
>
> Simon****
>
> ** **
>
> *From:* Brandon Allbery [mailto:allbery.b at gmail.com]
> *Sent:* 11 February 2013 01:15
> *To:* Simon Peyton-Jones
> *Cc:* Simon Marlow; Mark Lentczner; Manuel M T Chakravarty;
> kostirya at gmail.com; glasgow-haskell-users; ghc-devs at haskell.org; Edsko de
> Vries
>
> *Subject:* Re: GHC 7.8 release?****
>
>  ** **
>
> On Sun, Feb 10, 2013 at 4:02 PM, Simon Peyton-Jones <simonpj at microsoft.com>
> wrote:****
>
> What causes the "wave of package updates"?  Just because GHC 7.8 (say)
> comes out, no package author need lift a finger.  The Haskell Platform sets
> the pace for package updates. When the Haskell Platform comes out, now THAT
> is indeed a trigger for a wave of updates.  Authors of packages in HP are
> forced to act; authors of other packages want their packages to work with
> the next HP.****
>
>  ** **
>
> (a) There are packages which tend to track GHC's latest version instead of
> the HP (yesod used to do this, which was a source of much pain).****
>
>                                                     ****
>
> (b) There are linux distributions which always track the latest
> everything, often in a rolling-release fashion (notably Arch).  They are
> actively hostile to the Platform, and a source of even greater pain.  Many
> package authors update because Arch users demand it and openly insult
> anyone who points them to the Platform or any policy which suggests that
> anything other then the absolutely latest version is acceptable.****
>
> ** **
>
> You *might* be able to control expectations with respect to (a); (b) is
> not subject to any variety of reason.  It will produce as much pressure as
> it has users, plus multiply that pressure by the number of package authors
> who are also users.****
>
> ** **
>
> -- ****
>
> brandon s allbery kf8nh                               sine nomine
> associates****
>
> allbery.b at gmail.com
> ballbery at sinenomine.net****
>
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net****
>
> _______________________________________________
> 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/20130211/c4f5f8e3/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Johan Tibell-2
Hi,

I think reducing breakages is not necessarily, and maybe not even
primarily, an issue of releases. It's more about realizing that the cost of
breaking things (e.g. changing library APIs) has gone up as the Haskell
community and ecosystem has grown. We need to be conscious of that and
carefully consider if making a breaking change (e.g. changing a function
instead of adding a new function) is really necessary. Many platforms (e.g.
Java and Python) rarely, if ever, make breaking changes. If you look at
 compiler projects (e.g. LLVM and GCC) you never see intentional breakages,
even in major releases*. Here's a question I think we should be asking
ourselves: why is the major version of base bumped with every release? Is
it really necessary to make breaking changes this often? How about aiming
for having GHC 7.10 be a release where we only add new stuff and improve
old stuff?

-- Johan

* A major GCC release usually signifies that some large change to the code
generator was made.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130211/5f9c9a0a/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

kudah
On Mon, 11 Feb 2013 15:03:25 -0800 Johan Tibell
<johan.tibell at gmail.com> wrote:

> Many platforms (e.g. Java and Python) rarely, if ever,
> make breaking changes. If you look at compiler projects (e.g. LLVM
> and GCC) you never see intentional breakages, even in major
> releases*.

Those are very mature platforms, hundreds of millions of people
use them indirectly each day, it's hard to compare GHC to them.
If anything, Haskell is very young for its age, and should rather move
faster. Bad mistakes, accidents and partial or inefficient
implementations proliferate in standard libraries for decades,
tampering GHC's growth as a serious production language.

On Mon, 11 Feb 2013 22:31:53 +0000 Simon Peyton-Jones
<simonpj at microsoft.com> wrote:

> no linux distribution tracks HEAD, does it?

Gentoo packages HEAD just fine.


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Gabriel Dos Reis
In reply to this post by Johan Tibell-2
On Mon, Feb 11, 2013 at 5:03 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> Hi,
>
> I think reducing breakages is not necessarily, and maybe not even primarily,
> an issue of releases. It's more about realizing that the cost of breaking
> things (e.g. changing library APIs) has gone up as the Haskell community and
> ecosystem has grown. We need to be conscious of that and carefully consider
> if making a breaking change (e.g. changing a function instead of adding a
> new function) is really necessary. Many platforms (e.g. Java and Python)
> rarely, if ever, make breaking changes. If you look at  compiler projects
> (e.g. LLVM and GCC) you never see intentional breakages, even in major
> releases*. Here's a question I think we should be asking ourselves: why is
> the major version of base bumped with every release? Is it really necessary
> to make breaking changes this often? How about aiming for having GHC 7.10 be
> a release where we only add new stuff and improve old stuff?
>
> -- Johan
>
> * A major GCC release usually signifies that some large change to the code
> generator was made.

I have some experience with GCC releases -- having served as a GCC
Release Manager for several years. In fact, the release scheme we currently
have has gone through several iterations -- usually after many "existential"
crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
a research compiler and most "research works" are done on forgotten branches
that nobody cares about anymore.  Implementing new standards (e.g. moving
from C++03 to C++11 that has several mandated API and ABI breakage) is a
royal pain that isn't worth replicating in GHC -- at least if you want
GHC to remain a research compiler.

Concerning your question about release number, I would venture that there
is a certain "marketing" aspect to it.  I can tell you that we, the
GCC community,
are very poor at that -- otherwise, we would have been at version 26
or something :-)

-- Gaby


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Johan Tibell-2
On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis <
gdr at integrable-solutions.net> wrote:

> I have some experience with GCC releases -- having served as a GCC
> Release Manager for several years. In fact, the release scheme we currently
> have has gone through several iterations -- usually after many
> "existential"
> crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
> a research compiler and most "research works" are done on forgotten
> branches
> that nobody cares about anymore.  Implementing new standards (e.g. moving
> from C++03 to C++11 that has several mandated API and ABI breakage) is a
> royal pain that isn't worth replicating in GHC -- at least if you want
> GHC to remain a research compiler.
>
> Concerning your question about release number, I would venture that there
> is a certain "marketing" aspect to it.  I can tell you that we, the
> GCC community,
> are very poor at that -- otherwise, we would have been at version 26
> or something :-)
>

Thanks for sharing! My perspective is of course as a user. I don't think
I've ever run into a case where the compiler broken a previous work e.g.
C++ program. On the other hand I have to make a release of most of the
libraries I maintain with every GHC release (to bump cabal version
constraints to accept the new base version, if nothing else).

-- Johan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130211/a2ba9de2/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Gabriel Dos Reis
On Mon, Feb 11, 2013 at 6:37 PM, Johan Tibell <johan.tibell at gmail.com> wrote:

> On Mon, Feb 11, 2013 at 4:34 PM, Gabriel Dos Reis
> <gdr at integrable-solutions.net> wrote:
>>
>> I have some experience with GCC releases -- having served as a GCC
>> Release Manager for several years. In fact, the release scheme we
>> currently
>> have has gone through several iterations -- usually after many
>> "existential"
>> crisis.  Yes, we don't break GCC ABI lightly, mostly because GCC isn't
>> a research compiler and most "research works" are done on forgotten
>> branches
>> that nobody cares about anymore.  Implementing new standards (e.g. moving
>> from C++03 to C++11 that has several mandated API and ABI breakage) is a
>> royal pain that isn't worth replicating in GHC -- at least if you want
>> GHC to remain a research compiler.
>>
>> Concerning your question about release number, I would venture that there
>> is a certain "marketing" aspect to it.  I can tell you that we, the
>> GCC community,
>> are very poor at that -- otherwise, we would have been at version 26
>> or something :-)
>
>
> Thanks for sharing! My perspective is of course as a user. I don't think
> I've ever run into a case where the compiler broken a previous work e.g. C++
> program. On the other hand I have to make a release of most of the libraries
> I maintain with every GHC release (to bump cabal version constraints to
> accept the new base version, if nothing else).
>
> -- Johan
>

I understand.

Concerning GCC, it is true that the shear size of the user base and the
audience of the compiler ("industrial strength") calls for a very conservative
approach to ABI or API breaking.  On the hand, that means that there are
certain welcomed, beneficial changes that we cannot effect.  For
example, because
libstdc++ has been an early adopter of a reference counted-based implementation
of std::string, we could not switch to more efficient and more
multithread-friendly
implementation.  That was has been contributed for years but has been
sequestered
in some branches and namespaces integrated with the rest of the
library.  That is
a shame, but one that is unavoidable given the expectation of the GCC audience.

It is not clear to me that GHC is ready for that kind of constraints.

We are still describing the C++11 implementation as "experimental"
because we "fear"
that doing otherwise might commit ourselves to an ABI and API that we
may need to
break later -- possibly because of undetected bugs or because we have found
implementations we like better.  Of course, that causes some distress
in the community
because people would like to say "GCC implements C++11."

Finally, we do break API, you have just been lucky :-)

     http://gcc.gnu.org/onlinedocs/libstdc++/manual/api.html

But, we have also developed very elaborate scheme for symbol
versioning and namespace associations to help users digest API breakages
without tears.  Symbol versioning is a very messy business.

I am still of the opinion that the current issue with GHC and HP is
social, and it
can be resolved through communication and coordination between the two
communities for the great good of the Haskell community.

-- Gaby


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Manuel M T Chakravarty
In reply to this post by Simon Peyton Jones
Simon Peyton-Jones <simonpj at microsoft.com>:
> |  > 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.  Not such good testing, but much lower costs.  But still (I think) a lot more testing than "compile HEAD" gives us.

I don't think so. In my experience, library support is not patchy, but virtually non-existent as some of the very widely used libraries (like Text) break, and everything else depends on them in one way or another.

If we don't make sure that the commonly used libraries work with these "preview" releases, I don't think those releases are worth the effort.

I understand that we can't really guarantee API backwards compatibility for the GHC API (but that's ok as few packages depend on that). Critical are all the libraries bundled with GHC. Adding to them is fine, but no API definitions should change or be removed.

Manuel



Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Marlow-7
In reply to this post by Johan Tibell-2
On 11/02/13 23:03, Johan Tibell wrote:

> Hi,
>
> I think reducing breakages is not necessarily, and maybe not even
> primarily, an issue of releases. It's more about realizing that the cost
> of breaking things (e.g. changing library APIs) has gone up as the
> Haskell community and ecosystem has grown. We need to be conscious of
> that and carefully consider if making a breaking change (e.g. changing a
> function instead of adding a new function) is really necessary. Many
> platforms (e.g. Java and Python) rarely, if ever, make breaking changes.
> If you look at  compiler projects (e.g. LLVM and GCC) you never see
> intentional breakages, even in major releases*. Here's a question I
> think we should be asking ourselves: why is the major version of base
> bumped with every release? Is it really necessary to make breaking
> changes this often?

One reason for the major version bumps is that base is a big
conglomeration of modules, ranging from those that hardly ever change
(Prelude) to those that change frequently (GHC.*). For example, the new
IO manager that is about to get merged in will force a major bump of
base, because it changes GHC.Event.  The unicode support in the IO
library was similar: although it only added to the external APIs that
most people use, it also changed stuff inside GHC.* that we expose for a
few clients.

The solution to this would be to split up base further, but of course
doing that is itself a major upheaval.  However, having done that, it
might be more feasible to have non-API-breaking releases.

Of course we do also make well-intentioned changes to libraries, via the
library proposal process, and some of these break APIs.  But it wouldn't
do any harm to batch these up and defer them until the next API-changing
release.

It would be great to have a list of the changes that had gone into base
in the last few major releases, any volunteers?

Cheers,
        Simon




Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Bardur Arantsson-2
On 02/12/2013 09:37 AM, Simon Marlow wrote:
> On 11/02/13 23:03, Johan Tibell wrote:
>> Hi,
>>
> Of course we do also make well-intentioned changes to libraries, via the
> library proposal process, and some of these break APIs.  But it wouldn't
> do any harm to batch these up and defer them until the next API-changing
> release.

Indeed. It might even be preferable to just have one "huge" breakage
every year than having lots of minor breakages which require updating
packages (and dependencies). At least you'll feel you're getting your
money's worth.




Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Sergei Trofimovich
In reply to this post by Johan Tibell-2

> Thanks for sharing! My perspective is of course as a user. I don't think
> I've ever run into a case where the compiler broken a previous work e.g.
> C++ program. On the other hand I have to make a release of most of the
> libraries I maintain with every GHC release (to bump cabal version
> constraints to accept the new base version, if nothing else).

Just don't set upper version of base on the packages when you are not sure
they will break. Write tested ghc versions in comments instead.
You can't install separate base for a given ghc, so why bother?

According to PVP you need to use 'base < 4.7' in version,
    BUT IT IS INSANE

How do you expect users to test new ghc release (preview, name it
any way), if you require them to unpack every nonresolvable package
and update depends by hands?

It's very fun to check -HEAD version for fixed bugs in that respect.
Luckily many devs are not that insane and use arbitrary 'base < 5' or
'base < 10', which will break randomly at an arbitrary base-5 release.

--

  Sergei
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130212/9775db23/attachment.pgp>

Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Simon Marlow-7
In reply to this post by Johan Tibell-2
On 13/02/13 07:06, wren ng thornton wrote:

> On 2/12/13 3:37 AM, Simon Marlow wrote:
>> One reason for the major version bumps is that base is a big
>> conglomeration of modules, ranging from those that hardly ever change
>> (Prelude) to those that change frequently (GHC.*). For example, the new
>> IO manager that is about to get merged in will force a major bump of
>> base, because it changes GHC.Event.  The unicode support in the IO
>> library was similar: although it only added to the external APIs that
>> most people use, it also changed stuff inside GHC.* that we expose for a
>> few clients.
>>
>> The solution to this would be to split up base further, but of course
>> doing that is itself a major upheaval.  However, having done that, it
>> might be more feasible to have non-API-breaking releases.
>
> While it will lead to much wailing and gnashing of teeth in the short
> term, if it's feasible to break GHC.* off into its own package, then I
> think we should. The vast majority of base seems quite stable or else is
> rolling along at a reasonable pace. And yet, every time a new GHC comes
> out, there's a new wave of fiddling the knobs on cabal files because
> nothing really changed. On the other hand, GHC.* moves rather quickly.
> Nevertheless, GHC.* is nice to have around, so we don't want to just
> hide that churning. The impedance mismatch here suggests that they
> really should be separate packages. I wonder whether GHC.* should be
> moved in with ghc-prim, or whether they should remain separate...
>
> But again, this depends on how feasible it would be to actually split
> the packages apart. Is it feasible?

So I think we'd need to add another package, call it ghc-base perhaps.
The reason is that ghc-prim sits below the integer package
(integer-simple or integer-gmp).

It's feasible to split base, but to a first approximation what you end
up with is base renamed to ghc-base, and then the new base contains just
stub modules that re-export stuff from ghc-base.  In fact, maybe you
want to do it exactly like this for simplicity - all the code goes in
ghc-base.  There would be some impact on compilation time, as we'd have
twice as many interfaces to read.

I believe Ian has done some experiments with splitting base further, so
he might have more to add here.

Cheers,
        Simon



Reply | Threaded
Open this post in threaded view
|

base package (was: GHC 7.8 release?)

Roman Cheplyaka-2
* Simon Marlow <marlowsd at gmail.com> [2013-02-13 09:00:15+0000]
> It's feasible to split base, but to a first approximation what you
> end up with is base renamed to ghc-base, and then the new base
> contains just stub modules that re-export stuff from ghc-base.

It would be great to have a portable base, without any GHC-specific
stuff in it. After all, modules like Control.Monad or Data.Foldable are
pure Haskell2010.

The only obstacle I see is that ghc-base, as you call it, uses some
amount of base definitions, and so we have a loop.

How hard would it be to break this loop?

That is, either make GHC.* modules self-contained, or make base not to
depend on GHC.*?

Roman


Reply | Threaded
Open this post in threaded view
|

GHC 7.8 release?

Ian Lynagh-2
In reply to this post by Simon Marlow-7
On Wed, Feb 13, 2013 at 09:00:15AM +0000, Simon Marlow wrote:
>
> I believe Ian has done some experiments with splitting base further,
> so he might have more to add here.

There are some sensible chunks that can be pulled out, e.g. Foreign.*
can be pulled out into a separate package fairly easily IIRC.

Part of the problem is that it's hard to see what's possible without
actually doing it, because base is so large, and has so many imports and
import loops. IMO by far the easiest way to improve base would be to
start off by breaking it up into lots of small packages (some of which
will probably be single-module packages, others may contain an entire
hierarchy like Foreign.*, and others may contain an odd mixture of
modules due to dependency problems).

Then we can look at which packages ought to be split up, which ought to
be coalesced, and which ought to be moved higher up or lower down the
dependency tree, and then look at which module imports are preventing
what we want to do and see if there's a way to fix them (either by
moving a definition and reversing an import, or by changing an import to
import something lower down the dependency tree instead).

If we go this route, then we would probably want to end up without a
package called 'base', and then to make a new package called 'base' that
just re-exports modules from all the new packages. I imagine the first
release would let people use the new base without warnings, a year later
new base would give deprecated warnings, and the following year we'd
remove it. We could do this process slower, but the sooner packages move
off of base, the sooner they benefit from fewer major version bumps.

The advantages would be:
* the new packages would be easier to maintain than base is
* we could more easily make other improvements we'd like to make, e.g.
  we could move the unix and Win32 packages further down the tree
  without having to do it in one big leap, and without having to put
  them below the whole of base
* if one module causes a major version bump, then only libraries using
  that functionality would need to relax their dependencies, rather than
  every single package
* some targets (JS, JVM, .NET, etc) or other implementations might want
  to do things like IO, concurrency, etc, completely differently. This
  way they'd just use a different io/concurrency package, rather than
  having to have a different implementation of parts of base
* it would be nice if pure libraries could simply not depend on the io
  package etc, and thus clearly do no IO

The disadvantage is that, at some point between the first release and
the release that removes base, each package will have to have its
dependencies updated.


Thanks
Ian



1234