Drastic Prelude changes imminent

[Augustsson, Lennart]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20150127/6fee4a73/attachment.html>