Drastic Prelude changes imminent

[Greg Weber]

Here is a rough idea for how monomorphic list functions could be handled

1) export monorphic list functions from a differently name module. One
possibility is a `List` module (no `Data` prefix)
2) at some point (perhaps the next GHC release), have a deprecation warning
for the Data.List module

On Wed, Jan 28, 2015 at 5:56 AM, Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

> 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.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150128/eb1cf46a/attachment.html>