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.<div><br></div><div><span style="line-height:19.7999992370605px">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:</span><br></div><div><div style="line-height:19.7999992370605px"><br></div><div style="line-height:19.7999992370605px">* 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.</div><div style="line-height:19.7999992370605px">* 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.</div><div style="line-height:19.7999992370605px">* 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.</div><div style="line-height:19.7999992370605px"><br></div><div style="line-height:19.7999992370605px">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.</div><div style="line-height:19.7999992370605px"><br></div><div style="line-height:19.7999992370605px">I would say that I'm about -0.2 on the proposal, so don't weight my opinion too heavily.</div><div style="line-height:19.7999992370605px"><br></div><div class="gmail_quote">On Tue Jan 27 2015 at 12:33:22 PM Augustsson, Lennart <<a href="mailto:Lennart.Augustsson@sc.com">Lennart.Augustsson@sc.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p class="MsoNormal">The next version (7.10) of GHC is slated to have a drastically changed Prelude.<u></u><u></u></p>
<p class="MsoNormal">This message is very late in the release process, but I would urge caution before changing.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">The changes are (aptly) named the Burning Bridges Proposal (BBP).<u></u><u></u></p>
<p class="MsoNormal">Even though the work has been going on for a while, it seems that this<u></u><u></u></p>
<p class="MsoNormal">change is coming as a surprise to many people (including Simon Peyton<u></u><u></u></p>
<p class="MsoNormal">Jones). In summary, it generalizes many list operation, e.g., foldr,<u></u><u></u></p>
<p class="MsoNormal">to be overloaded.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">There is much to welcome in BBP, but changing the Prelude cannot be<u></u><u></u></p>
<p class="MsoNormal">done lightly since it really is like changing the language.<u></u><u></u></p>
<p class="MsoNormal">So I think it's really important for a large number of people to be able to<u></u><u></u></p>
<p class="MsoNormal">try out such changes before they come into effect, and to have time<u></u><u></u></p>
<p class="MsoNormal">to let the changes stabilize (you rarely get it right the first time).<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">I've discussed this with a number of people, including Simon PJ, and<u></u><u></u></p>
<p class="MsoNormal">we have concrete proposals.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Proposal 1:<u></u><u></u></p>
<p class="MsoNormal">* Add a new pragma<u></u><u></u></p>
<p class="MsoNormal"> {-# LANGUAGE Prelude=AlternativePrelude #-}<u></u><u></u></p>
<p class="MsoNormal"> * This is a new feature, but it is easy and low-risk to implement.<u></u><u></u></p>
<p class="MsoNormal"> * Which Prelude you use really is a language choice; appropriate for a LANGUAGE pragma.<u></u><u></u></p>
<p class="MsoNormal"> * Semantics is name-space only: import Prelude (); import AlternativePrelude<u></u><u></u></p>
<p class="MsoNormal"> * No effect on desugaring or typing of built-in syntax (list comprehensions, do-notation etc).<u></u><u></u></p>
<p class="MsoNormal">* Ship with both old and new prelude.<u></u><u></u></p>
<p class="MsoNormal">* So now old and new behaviour are easy to achieve, in the module or in a .cabal file.<u></u><u></u></p>
<p class="MsoNormal">* The question becomes "what is the default".<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Proposal 2:<u></u><u></u></p>
<p class="MsoNormal">* Make the default be the old rather than the new.<u></u><u></u></p>
<p class="MsoNormal"> * Altering the default Prelude API should be done slowly, with lots of warning; because all users get it willy-nilly.<u></u><u></u></p>
<p class="MsoNormal"> * Unlike AMP, the change is controversial (clearly).<u></u><u></u></p>
<p class="MsoNormal"> * Easier to make changes to New Prelude if it isn't the default.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">That's it.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Discussing the BBP proposal we also came up with a number of technical questions:<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Q1<u></u><u></u></p>
<p class="MsoNormal">An alternative to Foldable would be <u></u><u></u></p>
<p class="MsoNormal"> class Enumerable t where<u></u><u></u></p>
<p class="MsoNormal"> toList :: t a -> [a] -- Implementations should use 'build'<u></u><u></u></p>
<p class="MsoNormal">Is Foldable more general (or efficient) than a Enumerable class, plus fusion?
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Consider a new data type X a. I write<u></u><u></u></p>
<p class="MsoNormal"> foldX :: (a -> b -> b) -> b -> X a -> b<u></u><u></u></p>
<p class="MsoNormal"> foldX = ...lots of code...<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> toList :: X a -> [a] {-# INLINE toList #-}<u></u><u></u></p>
<p class="MsoNormal"> toList x = build (\c n. foldX c n x)<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">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.<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Q2<u></u><u></u></p>
<p class="MsoNormal">What are the criteria for being in Foldable?<u></u><u></u></p>
<p class="MsoNormal">For instance, why are 'sum', 'product' in Foldable, but not 'and', 'or'?<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">Q3<u></u><u></u></p>
<p class="MsoNormal">What's the relationship of Foldable to GHC.Exts.IsList?<u></u><u></u></p>
<p class="MsoNormal">Which also has toList, fromList, and does work with ByteString.<u></u><u></u></p>
<p class="MsoNormal">* For example, could we use IsList instead of Foldable?<u></u><u></u></p>
<p class="MsoNormal"> Specifically, Foldable does not use its potential power to apply the type constructor t to different arguments. (Unlike Traversable which does.)<u></u><u></u></p>
<p class="MsoNormal"> foldr :: IsList l => (Item l->b->b) -> b -> l -> b<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal"> -- Lennart<u></u><u></u></p>
</div>
<br clear="both">
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 <br>
<a href="http://www.standardchartered.com/en/incorporation-details.html" target="_blank">http://www.standardchartered.com/en/incorporation-details.html</a><br>
<br>
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 <a href="http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx" target="_blank">http://wholesalebanking.standardchartered.com/en/utility/Pages/d-mkt.aspx</a>.<br>
<br>
Please visit <a href="http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx" target="_blank">http://wholesalebanking.standardchartered.com/en/capabilities/financialmarkets/Pages/doddfrankdisclosures.aspx</a> for important information with respect to derivative products.<br>
</div>
______________________________<u></u>_________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/<u></u>mailman/listinfo/libraries</a><br>
</blockquote></div></div>