Lennart, On 2015-01-28 at 11:14:50 +0100, Augustsson, Lennart wrote:
I've updated the Wiki page (https://ghc.haskell.org/trac/ghc/wiki/BurningBridgesSlowly) with what I think would be a sensible course of actions:
[..] While I'm still in the process of thinking through the plans/proposals layed out on that wiki page, I'm somewhat missing what actual problem(s) those proposals are trying to solve. What's the actual problem/risk we're running into, if we instead go with a "Proposal 0" which consists in `base-4.8` as currently implemented in GHC 7.10.1RC2 going forward becoming part of GHC 7.10.1? It's not like having something implemented in GHC makes it magically become written into stone for the next Haskell Report. We've been already preparing Hackage for this change in `base` since even before GHC 7.10.1RC1 was released last year[1], with the implicit assumption that the release-candidate would be very representative of what GHC 7.10.1 is going to look like so Hackage upstream authors could adapt their packages with confidence. When RC1 came out, Michael was so kind to throw the Stackage-machinery at testing GHC 7.10 and informing even more package-authors in case their packages needed attention. Reverting BBP may cause additional work for those package authors that adapted their packages by removing now redundant imports to achieve perfect `-Wall`-hygiene. So what are the tangible problems with the current BBP? Code-breakage doesn't seem to be the issue here. To the contrary, you seem to rather suggest to actively cause a major compatibility breakage in order to do BBP "right" (as you consider generalising the signatures in `Data.List` to be "wrong"[2] -- it would help if you could elaborate more concretely what the actual problem is, so I can actually try to address that concern). -- hvr. [1]: Edward states in https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_propo... that 569 packages of the Stackage-set are building with GHC 7.10.1 just fine [2]: https://www.reddit.com/r/haskell/comments/2ttvsj/major_prelude_changes_propo...