<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=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 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.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
p.Code, li.Code, div.Code
{mso-style-name:Code;
mso-style-link:"Code Char";
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Courier New";}
span.CodeChar
{mso-style-name:"Code Char";
mso-style-link:Code;
font-family:"Courier New";}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
.MsoPapDefault
{mso-style-type:export-only;
margin-top:6.0pt;
margin-right:0cm;
margin-bottom:6.0pt;
margin-left:0cm;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:1396124896;
mso-list-type:hybrid;
mso-list-template-ids:-1441506450 134807553 134807555 134807557 134807553 134807555 134807557 134807553 134807555 134807557;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
text-indent:-18.0pt;
font-family:Wingdings;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></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-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Great. But it still leaves me hazy about precisely what you have agreed for the 8.0 release.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Would it be possible to revise that page and announce “This is what CLC has agreed”? Then (a) I know exactly what David is trying to implement for 8.0, and (b) everyone
is in the loop and can yell if they want.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">More generally, I think it would be great to have an authoritative page (or something) where CLC decisions are recorded. Like minutes of the meeting, as it were,
but recording only outcomes, not discussion. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">thanks<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Calibri",sans-serif;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Edward Kmett [mailto:ekmett@gmail.com]
<br>
<b>Sent:</b> 13 October 2015 16:25<br>
<b>To:</b> Simon Peyton Jones<br>
<b>Cc:</b> core-libraries-committee@haskell.org; David Luposchainsky; ghc-devs@haskell.org<br>
<b>Subject:</b> Re: MonadFail decisions<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:6.0pt;margin-right:0cm;margin-bottom:6.0pt;margin-left:0cm">
On Tue, Oct 13, 2015 at 10:29 AM, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<o:p></o:p></p>
</div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Dear Edward and Core Libraries Committee</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Can you tell us what plan you want to execute for MonadFail? Specifically, in
<a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwiki.haskell.org%2fMonadFail_Proposal&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2acfb3ffbeb44f3d746908d2d3e26ecc%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=PwgFvoyhrYpw5HVj6QFaXyUTUg9u72K%2bo1GOMhYx0Tw%3d" target="_blank">
https://wiki.haskell.org/MonadFail_Proposal</a></span><o:p></o:p></p>
<p><span style="font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri",sans-serif">Is the specification in 1.3 what you have agreed?</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal">The main concern I have with section 1.3 is the statement about view pattern desugaring. It really should just borrow the failability of the pattern part. The view pattern component adds nothing.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Getting better introspection on pattern synonyms to avoid them becoming a huge source of MonadFail constraints would be good as well.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">We can in theory incorporate improvements on this front gradually however.<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p><span style="font-family:Symbol">·</span><span style="font-size:7.0pt">
</span><span style="font-family:"Calibri",sans-serif">Is the transition strategy in 1.7 exactly what you want?</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<div>
<p class="MsoNormal">The "3 release policy" informs the design here a bit. Notably it puts off warnings for this for a while, as we can't warn about it in 8.0 (or really even 8.2) which means that at least in 8.0 this is almost entirely a library change. Under
that policy we can't do the warnings until 8.4 and cut-over til 8.6. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For 8.0 the change to 1.7 basically comes down to "don't turn on the warnings by default yet".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">We can’t implement 8.0 without being sure of the specification! The current Phab is</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"><a href="https://phabricator.haskell.org/D1248" target="_blank">https://phabricator.haskell.org/D1248</a></span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Also, David, did our conversation at HX help you get un-stuck?</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Edward<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Thanks</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif">Simon</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="font-family:"Calibri",sans-serif"> </span><o:p></o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">
<a href="mailto:haskell-core-libraries@googlegroups.com" target="_blank">haskell-core-libraries@googlegroups.com</a> [mailto:<a href="mailto:haskell-core-libraries@googlegroups.com" target="_blank">haskell-core-libraries@googlegroups.com</a>]
<b>On Behalf Of </b>Edward Kmett<br>
<b>Sent:</b> 13 October 2015 01:43<br>
<b>To:</b> <a href="mailto:core-libraries-committee@haskell.org" target="_blank">
core-libraries-committee@haskell.org</a><br>
<b>Subject:</b> [core libraries] Prelude: 3 Release Policy</span><o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Recently there has been a bunch of chatter about ways to mitigate the amount of CPP pushed on users by changes to the Prelude.<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">In particular the discussion has been around the idea of trying to ensure that it is possible to write code in _some_ way without CPP that can run backwards for 3 releases of GHC, preferably
in a -Wall safe manner. The approach they may have to use may not be the idiomatic way, but in general it should exist. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Gershom ran around at the Haskell Exchange sounding folks out about this idea, and it seems to codify a reasonable tension between the "change nothing" and "change everything" camps. The
feedback thus far seems to be noises of "grumbling acceptance" rather than the current state of outright panic that we might do anything at any time.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I'm personally considering this a very high priority for all changes to Prelude going forward. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">The 3 years forms a backward-facing window, not a guarantee against future change, but we should of course try to let folks know what is coming with a decent time horizon so folks can
look forward as well. That is a separate concern, though.<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I'm not ready to give the "3 release policy" outright veto power over new functionality, but at least if we have two plans that can in the end yield the same end state, we should definitely
err on the side of the plan that falls within these guidelines, and be very well ready to explain to a rather irate community when we violate this rubric. It shouldn't be done lightly, if at all, if we can help it!<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">All in all it is a fairly weak guarantee, but it does have some impact on current items under consideration.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Off the top of my head:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">* A number of new members for Floating were passed by proposal back before 7.10 went out the door, but haven't found their way into base yet: expm1, log1p, etc. are absolutely required
for decent precision numerics. When the proposal passed we ultimately decided _not_ to include default definitions for these to force authors to implement them explicitly. Under the guidelines here, the plan would likely have to include default definitions
for these to start when introducing them in 8.0. Then in 8.4 we could in theory remove the defaults and remain in compliance with the letter of the law here or introduce an ad hoc warning about lack of implementation, and remove the defaults in 8.6, depending
on how gradual an introduction we wanted to give. We wouldn't be able to do the warnings in 8.2, however, and remain within the letter of the law, and we wouldn't be able to introduce them without defaults without violating the no-warnings guideline.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">* MonadFail reform proposal wouldn't be able to start issuing warnings about missing instances until 8.4 even if we put in MonadFail into a module today. This would likely delay the full
implementation of the proposal to 8.6 as well.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">* The Semigroup as a superclass of Monoid proposal runs into a similar clock.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">An immediate consequence is that creating a class in base (or moving one into base) and moving it into Prelude changes picks up a 3-4 year window for implementation. (3 years from this
guideline, and a year if we want to / should give warnings about missing instances, which as mentioned above, is a separate concern.)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Observations:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">This doesn't imply the lack of warnings for new names coming into Prelude, because code can be changed to use the new names in a backwards compatible way. The AMP warnings would be in
compliance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I don't think we can viably apply this reasoning to other modules in base or even most other packages under the core libraries purview: It'd be nice, but things like template-haskell change
on too quick a clock. For other modules in base or other libraries in scope of the core libraries process, I'd probably consider this guideline demoted from "should" to "may".<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">When Data.Proxy or Data.Void were brought into base they were brought in more or less unmolested from tagged and void respectively with only minor differences. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">This means that code that wants to use them with older versions of the compiler can use their pre-existing dependency as a conditional (or mandatory) listed dependency. This means that
code that was using them before continues to work fine despite their incorporation into base. Compliance with this rule also acts as a hedge against severe bikeshedding when we incorporate more stuff.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">In the case of Semigroup you can use the semigroups package today in a form that is backwards compatible for a half dozen We could ship a 'fail' package that gave you access to the MonadFail
class across older GHC versions. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">The question then becomes is it worth trying to use the existence of those packages to try to "cheat the clock"? I think we'd almost assuredly be rightly called out for 'cheating' by package
maintainers where a fresh 'fail' package was concerned, but given the widespread distribution of 'semigroups' it might be plausible to use that to justify finishing out that proposal in 8.4 (end of 2017) rather than 8.6 (end of 2018). Personally, I'm content
with the longer clock and don't think it'd be worth doing in this case, but it was an informative exercise to consider. At the least, the existence of such packages lets us go much farther back than 3 releases for folks who have a wider support window.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Again, the above guideline would basically imply that if you wanted to add a thing to base and get it into the Prelude you can't do it in less than 3 years. Given the stability of Prelude
this is the _least_ we can do. Now nobody needs to worry about us rushing off to add Pointed or Semiapplicative to Prelude in the short term. It simply can't move into base and happen that fast.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Things already in base could admittedly take a shorter path and comply, but it is worth noting that this is just one guideline -- both the AMP and Foldable/Traversable Proposal would pass
this litmus test.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I'm mostly just running through active proposals and trying to understand the impact of such a policy, but so far I can't find anything that causes me to object.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">I'm content to codify it as my own personal "best practice", and would be willing to see us as an organization draft it up into a form that other people could rely upon to get a sense
of stability. In all of the above cases I think it actually improves upon the timeline a bit.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Lengthening the timelines above means we'll need to work harder on transferring institutional memory at the very least. Wiki and Trac items for these sorts of proposals will become even
more important. It will become almost impossible to spawn a from-scratch Prelude-affecting proposal and finish it during one 3-year cycle tenure on the committee.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">Ideas?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:6.0pt">-Edward<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span style="color:#888888">--
<br>
You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an email to
<a href="mailto:haskell-core-libraries+unsubscribe@googlegroups.com" target="_blank">
haskell-core-libraries+unsubscribe@googlegroups.com</a>.<br>
For more options, visit <a href="https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fgroups.google.com%2fd%2foptout&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c2b0f672ddfdd4b3fd55208d2d3673d17%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BaJtRHAFWowT0t5EOfmrS%2f5PAdWpnv2VN82LxMMJOgA%3d" target="_blank">
https://groups.google.com/d/optout</a>.<o:p></o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>