On Thu, May 23, 2013 at 04:45:30PM -0700, wren ng thornton wrote:
I am not opposed to change (obviously). I like that Haskell evolves. But the slow trickle of major breaking changes is not so nice. Nor is the accumulation of warts due to this slow tricking of major changes. This is why I suggest aiming for a major breakage in order to fix as much as we can in one fell swoop.
This sounds like a good idea to me. At the moment, I don't remember any changes currently in the git base repo that I expect would have a widespread impact (there have been changes that could cause clashes with particular libraries, but I don't think there's anything that will have a more global effect, like the Num and catch changes did). There are currently a number of proposals that seem to have support (e.g. splitting base, generalising Prelude functions, class hierarchy changes), but I don't think we have patches for any of them yet. So we'd still need (for each proposal) to get agreement, work out the details, make and apply the patch, and then may find that there are unexpected repercussions that we'd like to react to. Now, there's about 4 months until we'd like to be putting GHC 7.8 out, which sounds like a lot of time, but once you take into account ICFP and other absences, finishing the other things we're working on for 7.8, the pre-release frantic bug fixing, and actually getting everything working smoothly so that we can release it, it's really not that long. So I'd suggest that we leave 7.8 as a mostly-compatible release, and while it is still worth people making and discussing these proposals now, we don't actually apply them until just after 7.8 is branched. That gives us the maximum amount of time for them to mature in HEAD before they release with 7.10, and gives us lots of time to think about other changes we'd like to batch together with them. Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/