Drastic Prelude changes imminent

[Augustsson, Lennart]

I see some problems:

 * The changes of types to Data.List functions.  This is very counter-intuitive.
 * I don't think the methods in Foldable are quite the right ones
   (e.g., sum, product should not be there).  This would give the rest of us time
   to experiment with BBP since it would be very easy use (import Prelude(); import PreludeBBP).
 * Peace of mind.  A lot of people (even some in the libraries committee) found these changes
   a surprise.  A ghc warning about Data.List will ensure that everyone knows about them.


-----Original Message-----
From: Herbert Valerio Riedel [mailto:hvr at gnu.org] 
Sent: 28 January 2015 13:46
To: Augustsson, Lennart
Cc: libraries at haskell.org
Subject: Re: Drastic Prelude changes imminent

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_proposed/co2m5su

      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_proposed/co3doue

This email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please delete all copies and notify the sender immediately. You may wish to refer to the incorporation details of Standard Chartered PLC, Standard Chartered Bank and their subsidiaries at 
http://www.standardchartered.com/en/incorporation-details.html

Insofar as this communication contains any market commentary, the market commentary has been prepared by a sales and/or trading desk of Standard Chartered Bank or its affiliate. It is not and does not constitute research material, independent research, recommendation or financial advice. Any market commentary is for information purpose only and shall not be relied for any other purpose, and is subject to the relevant disclaimers available at http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx.

Please visit http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx  for important information with respect to derivative products.