Drastic Prelude changes imminent

Tue Feb 3 15:45:22 UTC 2015

I've mostly stayed out of this conversation until now, but at Simon PJ's
request I'm writing in officially my thoughts on the subject.

The real reason I haven't participated in any significant way in this
discussion is: I'm very much torn on the issue. I'm *not* a fan of the
current Prelude for numerous reasons, including the lack of generality.
However:

* I have many other complaints about the standard Prelude: partial
functions like `head` and lazy I/O being a recommended default being
primary in that list.
* I've personally moved on from the default Prelude and regularly use
alternate preludes in my own code (classy-prelude being the most common
example, but others existing too). I'm not the only person who does this,
and it solves a lot of the problems.
* The generalization being performed right now does *not* fully solve the
problems I have. For example, Prelude still won't provide functions that
work nicely on ByteString and Text due to their monomorphic nature.

Now that I actually write this all out, I'm beginning to think I *am*
opposed to the proposal overall, though not by a wide margin. It seems to
fall into the "too little, too late" category: the benefits it brings are
not massive due to my three points above, and the disruption introduced to
the ecosystem is potential massive.

I would say that I'm about -0.2 on the proposal, so don't weight my opinion
too heavily.

On Tue Jan 27 2015 at 12:33:22 PM Augustsson, Lennart <
Lennart.Augustsson at sc.com> wrote:

>  The next version (7.10) of GHC is slated to have a drastically changed
> Prelude.
>
> This message is very late in the release process, but I would urge caution
> before changing.
>
>
>
> The changes are (aptly) named the Burning Bridges Proposal (BBP).
>
> Even though the work has been going on for a while, it seems that this
>
> change is coming as a surprise to many people (including Simon Peyton
>
> Jones).  In summary, it generalizes many list operation, e.g., foldr,
>
> to be overloaded.
>
>
>
> There is much to welcome in BBP, but changing the Prelude cannot be
>
> done lightly since it really is like changing the language.
>
> So I think it's really important for a large number of people to be able to
>
> try out such changes before they come into effect, and to have time
>
> to let the changes stabilize (you rarely get it right the first time).
>
>
>
> I've discussed this with a number of people, including Simon PJ, and
>
> we have concrete proposals.
>
>
>
> Proposal 1:
>
> *    Add a new pragma
>
>         {-# LANGUAGE Prelude=AlternativePrelude #-}
>
>       *   This is a new feature, but it is easy and low-risk to implement.
>
>       *   Which Prelude you use really is a language choice; appropriate
> for a LANGUAGE pragma.
>
>       *   Semantics is name-space only: import Prelude (); import
> AlternativePrelude
>
>       *   No effect on desugaring or typing of built-in syntax (list
> comprehensions, do-notation etc).
>
> *    Ship with both old and new prelude.
>
> *    So now old and new behaviour are easy to achieve, in the module or in
> a .cabal file.
>
> *    The question becomes "what is the default".
>
>
>
> Proposal 2:
>
> *    Make the default be the old rather than the new.
>
>       *   Altering the default Prelude API should be done slowly, with
> lots of warning; because all users get it willy-nilly.
>
>       *   Unlike AMP, the change is controversial (clearly).
>
>       *   Easier to make changes to New Prelude if it isn't the default.
>
>
>
> That's it.
>
>
>
>
>
>
>
>
>
> Discussing the BBP proposal we also came up with a number of technical
> questions:
>
>
>
> Q1
>
> An alternative to Foldable would be
>
>   class Enumerable t where
>
>     toList :: t a -> [a]   -- Implementations should use 'build'
>
> Is Foldable more general (or efficient) than a Enumerable class, plus
> fusion?
>
>
>
> Consider a new data type X a.  I write
>
>      foldX :: (a -> b -> b) -> b -> X a -> b
>
>      foldX = ...lots of code...
>
>
>
>      toList :: X a -> [a]  {-# INLINE toList #-}
>
>      toList x = build (\c n. foldX c n x)
>
>
>
> So now toList is small and easy to inline.  Every good list consumer of a
> call to toList will turn into a call to foldX, which is what we want.
>
>
>
> Q2
>
> What are the criteria for being in Foldable?
>
> For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?
>
>
>
>
>
> Q3
>
> What's the relationship of Foldable to GHC.Exts.IsList?
>
> Which also has toList, fromList, and does work with ByteString.
>
> *  For example, could we use IsList instead of Foldable?
>
>     Specifically, Foldable does not use its potential power to apply the
> type constructor t to different arguments.  (Unlike Traversable which does.)
>
>         foldr :: IsList l => (Item l->b->b) -> b -> l -> b
>
>
>
>
>
>   -- Lennart
>
> 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/20150203/bffacf72/attachment.html>