GHC's policy is: - we do not require that the user installs any libraries or upgrades any libraries in order to build GHC. - we support bootstrapping with the two previous major releases of GHC. So that means, after the 7.8 release, the HEAD will support only 7.6 and 7.8. So that means you'll be able to use containers-0.5 after the 7.8 branch split (but not merge any patches that require it onto the branch). The other way around this is to make containers into a zero-boot package, but we typically wouldn't do this for just one function. The main use case for this is Cabal, which in the past has changed quickly and in tandem with changes in GHC, so we want stage 1 to see the same Cabal as stage 2. Cheers, Simon On 15/12/2013 16:35, Joachim Breitner wrote:
Hi, especially to Austin with his Release Manager hat on,
in my nested-cpr branch I have a few nice patches that clean up, refactor and especially Note’ify the demand analyzer. I’d like to see both my branch to be shorter, and to see those improvements in the mainline independent of whether nested-cpr will turn out to be useful, so I invested some time to rebase my branch and move all these patches below those that actually change the code.
The result is the contents of the wip/nested-cpr branch up to and including the patch “Make types of bothDmdType more precise”, which I find especially useful (currently c26d31, but I tend to rebase while I add more polish or remove typos). I am confident that this is a pure refactoring (validate passes without changes to the testsuite, nofib shows identical Allocation numbers), and I’d like to push this to master.
But one of the patches, “Clarify the default demand on demand environments” (currently 2b6a6a), uses a function from containers (IntMap.mergeWithKey) which was only added in containers-0.5, which ships with GHC 7.6, but not with 7.4. But especially that change is nice, as removes the confusing modifyEnv function and makes the code (IMHO) easier to understand.
What is the policy here? Is it ok to expect the user to upgrade the containers package of the bootstrap compiler? Or can we start building containers before stage-1, so that we can expect the new code (but when I tried it seems that this needs some adjustments to the build system)? Or should I add an alternative definition via CPP in compiler/utils/UniqFM.lhs? Or is it not worth it and I should wait until 7.9 (which would then drop the requirement to be bootstrappable with 7.4, right?)
Thanks, Joachim
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs