<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><title>Re: Proposal: Change to library proposal process</title><style><!--
/* Font Definitions */
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
p.avgcert, li.avgcert, div.avgcert
        {mso-style-name:avgcert;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I agree with Malcolm’s conclusion: a big overhaul by a committed group would be an excellent idea. One of the reasons that I was wary of change is because of the fragility of the current set-up, in both the libraries and the organisation. A group of responsible folks with the job of piloting us to Hackage Nirvana along the lines that Malcolm has outlined would tamp down the fear of change considerably.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Yes, thanks to those who have persisted in showing us the problem – it’s much appreciated!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Chris<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> libraries-bounces@haskell.org [mailto:libraries-bounces@haskell.org] <b>On Behalf Of </b>Malcolm Wallace<br><b>Sent:</b> 07 January 2011 10:34<br><b>To:</b> Simon Marlow<br><b>Cc:</b> Haskell Libraries<br><b>Subject:</b> Re: Proposal: Change to library proposal process<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p><span style='font-size:10.0pt'>On 6 Jan 2011, at 11:32, Simon Marlow wrote:<br><br>> the process would be more appropriate if we were basically happy <br>> with the APIs we have. On the contrary, we have plenty of large-<br>> scale changes that need making in base and other places, and forcing <br>> all changes through the library process is making it hard to get <br>> these cleanups done.<br>><br>> I'm coming around to the view that this small-scale API change <br>> review isn't getting us where we want to go. To really improve APIs <br>> we should have a group of people looking at the whole, and making <br>> strategic decisions. Let's figure out where we're going and how to <br>> get there, rather than making a series of tiny incremental steps <br>> (slowly).<br><br>I think I agree with this. If there is general unhappiness with the <br>basic set of APIs, then doing a big-bang redesign of everything from <br>scratch (yes, even as far as the Prelude) is probably the right way to <br>go. It will be a big discussion, with plenty of arguments, but at <br>least "the libraries committee" might only need to do it once every <br>ten years, rather than the "death by a thousand cuts" model we have now.<br><br>> Let's really make FilePath an ADT, make binary Handles a different <br>> type, move more of base out into separate packages, remove the Show <br>> superclass of Num, overhaul the containers API, finish creating the <br>> Exception hierarchy, etc. etc. We've had a period of stability, <br>> maybe now it's time for change, and lots of it.<br><br>These are all good changes: we have known for a long time they are <br>desirable, but making them would be disruptive. This discussion has <br>persuaded me that we are never going to get them, unless we do them <br>wholesale in a single strike.<br><br>> - maintainers are empowered to make API changes.<br>> - no formal review process for API changes, although there is an<br>> expectation that non-trivial changes would still be discussed on<br>> the list beforehand.<br><br>Actually, I think those process ideas are in danger of being <br>understood to belong to the "incremental" model, not the "wholesale" <br>one. My suggestion would be:<br><br> * appoint (self-select?) a group of people who will commit to <br>actively<br> seeing this wholesale redesign through to the end.<br> * freeze the existing set of core packages, e.g. base, containers, <br>binary, etc.<br> * design from scratch a new-base package.<br> * redesign the other core packages around the new-base.<br> * make a big-bang release of all of the new core packages at once.<br> * encourage other packages on hackage to abandon dependencies on <br>the old base,<br> and move to new-base plus fresh packages that depend on it.<br><br>The design discussions should be public of course, but basically, the <br>job is to critique old code and write new code in collaboration <br>amongst a small group of talented library designers.<br><br>As a target, do you think such a group could aim to complete a draft <br>redesign in time for Haskell 2012?<br><br>Regards,<br> Malcolm<br><br><br>_______________________________________________<br>Libraries mailing list<br><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/libraries">http://www.haskell.org/mailman/listinfo/libraries</a></span> <o:p></o:p></p><div class=MsoNormal align=center style='text-align:center'><hr size=1 width="100%" noshade style='color:#A0A0A0' align=center></div><p class=avgcert>No virus found in this message.<br>Checked by AVG - <a href="http://www.avg.com">www.avg.com</a><br>Version: 10.0.1191 / Virus Database: 1435/3365 - Release Date: 01/07/11<o:p></o:p></p></div></body></html>