Using features from containers-0.5

[Simon Marlow]

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 at haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>