<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:"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;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
@font-face
{font-family:Monaco;
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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.Code, li.Code, div.Code
{mso-style-name:Code;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Courier New";}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.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;}
/* List Definitions */
@list l0
{mso-list-id:547423899;
mso-list-template-ids:1138924592;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1
{mso-list-id:989745627;
mso-list-template-ids:156812662;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2
{mso-list-id:1099909714;
mso-list-template-ids:-800433268;}
@list l2:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l2:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
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-size:12.0pt">I’m basically with you, but I do think that check [2] is qualitatively different to [1]. You say<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">(b) The implementation is good, but the implementation turned out to be more costly than originally anticipated. In this case, code review will ask the contributor to revise their proposal, go back to the GHC
Steering Committee, and get the revision approved. Now, this is the moment where the committee is asked to review the proposal in the light of the newly gained experience.<o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">My concern about the slow accretion of hidden costs is more about the [1] than [2]. In principle, an implementation could be simple, while yet imposing previously unanticipated complexity on the language
design.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">An example: a type inference algorithm might be easy to
<i>implement</i>, but it might behave unpredictably – e.g. if you change (e1,e2) to (e2,e1) the type inference fails – that is, it might be hard to specify in a programmer-accessible way. Actually linear types could be like this. The paper explicitly does
not handle type inference; and neither does the proposal. I’d be surprised if we couldn’t come up with an inference algorithm we all considered acceptable in language-design terms – not just in implementation terms – but still, it’s something we won’t know
for a while.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I’m only saying that at checkpoint [2] the criteria are not
<i>just</i> code/implementation quality and complexity; it also implicitly includes a review of the judgement made at checkpoint [1], in case the “slow accretion” has happened.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">I don’t think there’s any disagreement here. No one wants a feature to end up in GHC that, in retrospect, we can see is mis-designed! We have to balance that with giving contributors confidence, and enough
certainty to invest their most precious resource (their own time) in GHC.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal" style="margin-left:36.0pt">Nevertheless, we do *not* need a priori and inherently imprecise evaluation of whether a proposal is ”big” or complex. In fact, our process (the whole pipeline above) is adaptive<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Yes – I’m not particularly seeking an a-priori evaluation of size (although, thinking aloud, I did speculate about such a thing). But being adaptive is important. A fly and an elephant are creatures on a
continuous scale of creature sizes. There is no point at which we can say “this creature is Big and the next smallest one is NotBig”. And yet in the end elephants and flies really do need rather different treatment.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:12.0pt"><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">From:</span></b><span lang="EN-US"> Manuel M T Chakravarty [mailto:chak@justtesting.org]
<br>
<b>Sent:</b> 15 November 2017 02:26<br>
<b>To:</b> Simon Peyton Jones <simonpj@microsoft.com><br>
<b>Cc:</b> Richard Eisenberg <rae@cs.brynmawr.edu>; ghc-steering-committee@haskell.org<br>
<b>Subject:</b> Re: [ghc-steering-committee] Our process and BIG ideas<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Simon,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">I think, the suggestion to add a formal point about detailing the effect of an extension on Core is fabulous! We should absolutely do that.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It seems the sticky point is your first, the slow accretion of hidden costs. It totally agree that this is the most tricky scenario. However, I am not so sure that there is no moment, where that costs are checked. There is none if we look
at this committee in isolation. However, there is one if we look at the entire process of getting an extension into GHC (and I think, this is key to making this all work elegantly). Here is the pipeline:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> Proposal</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> v</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> [1] (GHC Steering Committee)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> Pull Request/Differential</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> v</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> [2] (Code reviewers)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> Development version</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> v</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> [3] (Release Manager)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> |</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> v</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Monaco",serif"> Released feature</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For anything to get into a stable release, there are three checks [1], [2] & [3] that need to be passed. What I propose is that failure to pass one of the checks doesn’t just prevent you from getting further, but that it may throw you back
to an earlier stage.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In the proposal, we do ask about the implementation costs and costs of feature interaction etc. I like to suggest that if a code contribution backed by a proposal is submitted for consideration for merging, the code reviewers check that
the code contribution actually meets the promises made in the proposal about, for example, implementation costs. If these promises are not met, there are two possibilities:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">(a) The implementation is just not very good. In that case, the contributors can try to improve their code and try again.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">(b) The implementation is good, but the implementation turned out to be more costly than originally anticipated. In this case, code review will ask the contributor to revise their proposal, go back to the GHC Steering Committee, and get
the revision approved. Now, this is the moment where the committee is asked to review the proposal in the light of the newly gained experience.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For example, following your suggestion about explicitly asking proposal authors to detail the impact of an extension on Core. A proposal may claim to not have to change Core at all. Then, it turns out the implementation actually does change
Core, maybe just in a small way. Nevertheless, this clearly signals to code review that the proposal was inaccurate. Hence, the proposal has to go back to the GHC Steering Committee and be re-approved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">As another example, assume that we have got a big complex proposal and the authors write that they are —at this stage— unsure about the exact impact on Core. In this case, just as with the or-patterns and GADTs, we may review the proposal,
but make final approval contingent on understanding the actual impact on Core.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">In this manner, the committee gets to re-check proposals, where substantial new experience was gained during the implementation that altered trade offs of implementation costs, feature interaction etc. Nevertheless, we do *not* need a priori
and inherently imprecise evaluation of whether a proposal is ”big” or complex. In fact, our process (the whole pipeline above) is adaptive. The less accurate a proposal turns out to be (due to complexity or other factors), the more often it’ll be thrown back
and re-evaluated. And maybe the fact that a proposal is thrown back multiple times will make us weary of it and cause us to eventually reject it.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Manuel<o:p></o:p></p>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>>:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">I’m ok with what Manuel says, especially the bit about being more explicit about the implicit conditionality. But I would add</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l1 level1 lfo1"><span style="font-size:12.0pt">Acceptance is always a balance of judgement. Is the extra language and implementation complexity justified by the benefits to the programmer? For “big” features,
that balance may change as we learn more about it.<br>
<br>
<br>
</span><o:p></o:p></li></ul>
<div style="margin-left:36.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt">Manuel takes outright unsoundness as an example, and it is a comforting one because it’s so clear-cut. But in reality I think that it’s more likely that there’ll be a slow accretion of hidden costs that slowly
become apparent. Then it might seem more capricious if the committee’s judgement changed; and in any case there’d be no moment at which the committee was asked to review the proposal in the light of experience.</span><o:p></o:p></p>
</div>
<div style="margin-left:36.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l0 level1 lfo2"><span style="font-size:12.0pt">I think we could address some of this by making the conditionality in acceptance more explicit, just as Manuel says. But in specific terms, not just in general
ones. For example, for or-patterns I think we are edging towards “accept, provided we can resolve the issues around GADTs etc”. For a “bigger” proposal we might have a longer list of things we regarded as danger spots.</span><o:p></o:p></li></ul>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<ul style="margin-top:0cm" type="disc">
<li class="MsoNormal" style="margin-left:0cm;mso-list:l2 level1 lfo3"><span style="font-size:12.0pt">I suggest that we add to our criteria what effect (if any) the proposal has on Core. You may see Core as merely an implementation mechanism, but I regard it
as a solid sanity check. We simply do not have a formal specification for all of Haskell. It’s too big, and if we insisted on that we ‘d never do anything. But we DO have a<span class="apple-converted-space"> </span><a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc%2Fghc%2Ftree%2Fmaster%2Fdocs%2Fcore-spec&data=02%7C01%7Csimonpj%40microsoft.com%7C7e5a91349d674f6305af08d52bd03441%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636463095632609403&sdata=2oE9QdPs5zQ%2FxY%2F3Y%2FPEDeXoujEx3LN212xwvirFgks%3D&reserved=0"><span style="color:purple">formal
spec for Core</span></a>. It is small enough to be intellectually tractable. And, for better or worse, GHC is one of the very few production compilers in the world (I actually do now know of any others) that maintain a statically typed IR right through optimisation
up to code generation.</span><o:p></o:p></li></ul>
<div style="margin-left:36.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<div style="margin-left:36.0pt">
<p class="MsoNormal"><span style="font-size:12.0pt">Most proposals don’t change Core one whit. But for those that do, I think it would be reasonable to ask for a pretty solid spec of what changes are proposed. That would reassure us that the proposal is in
fact sound. All the rest is syntactic sugar, as it were.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt">Simon</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt"> </span><o:p></o:p></p>
</div>
<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">
<div>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span class="apple-converted-space"><span lang="EN-US"> </span></span><span lang="EN-US">Manuel M T Chakravarty [<a href="mailto:chak@justtesting.org">mailto:chak@justtesting.org</a>]<span class="apple-converted-space"> </span><br>
<b>Sent:</b><span class="apple-converted-space"> </span>14 November 2017 01:10<br>
<b>To:</b><span class="apple-converted-space"> </span>Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com">simonpj@microsoft.com</a>><br>
<b>Cc:</b><span class="apple-converted-space"> </span>Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu">rae@cs.brynmawr.edu</a>>;
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br>
<b>Subject:</b><span class="apple-converted-space"> </span>Re: [ghc-steering-committee] Our process and BIG ideas</span><o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">All approval is conditional<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I get the feeling that this discussion is actually really about,<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">> What does approval mean?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Currently, the ghc-proposals' README states,<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-family:"Segoe UI",sans-serif;color:#24292E;background:white">Acceptance of the proposal implies that the implementation will be accepted into GHC provided it is well-engineered, well-documented, and does not complicate
the code-base too much.</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">So, obviously and explicitly all acceptance of proposals by this committee is conditional (there is no unconditional approval). Everything is conditional on a good implementation. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">However, I would argue that —in actual fact— there are some conditions that we have never made explicit as well, and those implicit conditions are at the core of the current discussion. For example, proposals like TypeInType, linear types,
or dependent types may well turn out to be impossible to implement *without complicating the code-base too much* (e.g., because they need to change Core in ways that are too intrusive). In other words, if the required engineering constraints are impossible
to meet for a proposal, then, despite it originally being accepted, we wouldn’t allow it into a shipping compiler.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I will go further and argue that there are conditions that are not mentioned at all. For example, let’s assume I make a convincing argument for a type extension and I have a conference paper and a proof of progress and preservation, and
the committee accepts my proposal. If, during implementation, I or somebody else find that my proof is actually faulty and the system is unsound, would we allow it into the compiler only because we accepted the proposal? Of course not!<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Hence, all accepted proposals are also conditional on that the properties and assumptions stated in the proposal are actually correct. If a proposal claims that an extension is sound, it must be sound. If it states that it doesn’t conflict
with other type extension, it may not conflict. If it argues, the implementation will be efficient, it must be efficient, and so on. If anything turns out to be wrong, the approval, which was issued under these assumptions, is void. (Think of it as a contract
that is voided once any of the clauses is violated.)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">So, I hope we can agree that all approval is conditional. What we need to do is to specify the conditions that we implicitly assign beyond the engineering focused condition that is currently in the README. (Having conditions is fine, but
to be fair to proposal authors, IMHO we need to be explicit about them.)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Size doesn’t matter<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">~~~~~~~~~~~~~~~<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I like to argue that the size of a proposal is much less important than we might think. Fairly small changes can easily turn into a pit of vipers. For example, take generalised new type deriving. It was such a small simple change and easy
to do with System FC’s equality constraints. If we had had GHC proposals at the time, this would have been a small proposal relative to the fancy type family additions and GADTs going on at the time. Nevertheless, I’d argue, generalised newtype deriving was
probably the biggest type soundness nightmare GHC ever had. (How many papers did it take to fix it…kind of?)<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Whether a proposal is long or short, whether it involves complex types, or whether it is just syntax (that may always turn out to be really hard to implement with LALR(1)), I think, we want the same rules and the same conditions attached
to approval of the proposal. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* There needs to a well-engineered implementation.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* It shouldn’t complicate the codebase too much.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* It must not have unexpected interactions with other language features.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code).<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* It must not turn out to be unsound.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* It must not turn out to lead to impossible to understand error messages.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">* What else?<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">What if a condition is violated<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">That depends on whether the problem can be fixed and what kind of fix is needed. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Anything that is ”just” a matter of code quality is a matter for the code reviewers to hold back until it is good enough. Anything destabilising the compiler or turning out to affect performance too much is up to the release manager to
prevent going into an actual release. These issues are not a concern of this committee.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">However, if a conceptual problem is found, a system is unsound, or generally any of the assumptions or statements in the proposal *on which approval was based* turns out to be wrong, the proposal needs to be changed. Once it is changed,
it needs to be approved again. If no acceptable change can be found, the proposal is out.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Summary<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">~~~~~~~<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I propose to make the conditions (that always existed) explicit, check them while a proposal gets refined and potential issues discovered during implementation, and bounce any (significant) changes that need to be made back to the committee.
In this way, I hope, we can address the concerns voiced by Simon and Richard, while being completely transparent to proposal authors. <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Moreover, we don’t need any a priori judgement about whether a proposal is small or large (and where exactly is that boundary). Instead, naturally, anything that leads to issues will be sent back to the committee, which allows for iteration
exactly where this is necessary.<o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal">Cheers,<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">Manuel<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<br>
<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com"><span style="color:purple">simonpj@microsoft.com</span></a>>:<o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">| However, I'm leery of unconditional approval of something as large as the<br>
| linear types proposal.<br>
<br>
If "unconditional approval" means " we agree to include this feature in GHC, regardless of the consequences", then I guess everyone would agree with Richard. It's not just the implementation consequences either: we have to think about the interaction of a
big new feature with all the other aspects of the surface language, and that is really hard to do in advance.<span class="apple-converted-space"> </span><br>
<br>
For little proposals (like commas in export lists) we can be pretty confident that we aren't going to get any major surprises. For big ones like this, our confidence is much lower.<br>
<br>
But we must think of it from the contributors' point of view too. Contributors to GHC want to see a transparent and somewhat predictable pipeline of steps that successively make it more and more likely that a proposal will end up in mainstream GHC. For big
proposals maybe we need more steps. E.g.<br>
<br>
1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language.<br>
<br>
2. Details. Now there are lot of specifics. Interactions with other features of Haskell. If there are going to be changes in Core, a precise specification of those changes would be helpful. (I know that Core is an internal matter, but it's an outstandingly
good sanity-check.)<br>
<br>
3. Implementation. Now we have an implementation.<br>
<br>
4. Merge into HEAD<br>
<br>
We have previously conflated (1) and (2) and that seems fine for a small proposal, but for a big one like this we might want to split the steps, to offer authors the confidence to invest in (2).<br>
<br>
Actually (2) and (3) are likely to be symbiotic, I think.<br>
<br>
Does that make sense?<br>
<br>
Simon<span class="apple-converted-space"> </span><br>
<br>
| -----Original Message-----<br>
| From: ghc-steering-committee [mailto:ghc-steering-committee-<br>
| <a href="mailto:bounces@haskell.org"><span style="color:purple">bounces@haskell.org</span></a>] On Behalf Of Richard Eisenberg<br>
| Sent: 13 November 2017 03:25<br>
| To: Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org"><span style="color:purple">chak@justtesting.org</span></a>><br>
| Cc:<span class="apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org"><span style="color:purple">ghc-steering-committee@haskell.org</span></a><br>
| Subject: Re: [ghc-steering-committee] Our process and BIG ideas<br>
| <br>
| I fully agree that proposals for large new features can reference an<br>
| accompanying paper.<br>
| <br>
| However, I'm leery of unconditional approval of something as large as the<br>
| linear types proposal. GHC is a very large, complex system, and no one can<br>
| anticipate all the interactions that a proposal may have with existing<br>
| features. It's quite possible that something which seems like a good idea<br>
| has a disastrous interaction with some other part of the compiler/language<br>
| definition.<br>
| <br>
| Instead, I would favor a conditional approval that would turn to rejection<br>
| only if further experience (gained through a [partial] implementation)<br>
| reveals a theoretical sticking point. I use "theoretical" here to mean that<br>
| the rejection wouldn't be based on poor code quality or an implementation<br>
| challenge, per se, but by running into a scenario where we are unable to<br>
| specify the correct behavior of the system.<br>
| <br>
| In truth, even an approval that we described as unconditional would really<br>
| be as in the paragraph above -- we simply can't do better. So I guess I'm<br>
| favoring calling such an approval as conditional, just to be clear to<br>
| proposers what we mean.<br>
| <br>
| Richard<br>
| <br>
| > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty<br>
| <<a href="mailto:chak@justtesting.org"><span style="color:purple">chak@justtesting.org</span></a>> wrote:<br>
| ><br>
| > In the light of the linear types proposal PR, SimonPJ’s comment<br>
| ><br>
| ><br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%25"><span style="color:purple">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</span></a><br>
| 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment-<br>
| 343457821&data=02%7C01%7Csimonpj%<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7C15f65c21dafe4d34386108d52afc7993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636462186227822124&sdata=hMwpjjqTh6opD3RikzrDHIikPnly9z%2B8QaeiN4IxjSY%3D&reserved=0"><span style="color:purple">40microsoft.com</span></a>%7C76a50b24b6dc436c9c4808d52<br>
| a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat<br>
| a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0<br>
| ><br>
| > and some uncertainty about the proposal process that has been communicated<br>
| to me via a side channel, it might be worthwhile clarifying our expectations<br>
| for large complex proposals. (I know, we basically punted on these questions<br>
| in our initial discussion on the process with the intention to revisit after<br>
| we gained some experience. It seems this time has come.)<br>
| ><br>
| > Firstly, we usually require proposals to be self-contained. This makes a<br>
| lot of sense for small to medium-sized proposals to limit the time needed by<br>
| the committee to hunt down all the required information. However, in a case,<br>
| such as the linear types work, where there is a highly polished text in the<br>
| form of a research paper (or similar), it seems reasonable to refer to that<br>
| existing work — not only because type rules are a lot nicer to read when<br>
| rendered by LaTeX instead of Markdown.<br>
| ><br>
| > Concretely, I’d like us to give some guidance wrt to this issue to<br>
| proposal authors and document that at<br>
| <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%25"><span style="color:purple">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</span></a><br>
| 2Fghc-proposals%2Fghc-proposals%23ghc-<br>
| proposals&data=02%7C01%7Csimonpj%<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com&data=02%7C01%7Csimonpj%40microsoft.com%7C15f65c21dafe4d34386108d52afc7993%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636462186227822124&sdata=hMwpjjqTh6opD3RikzrDHIikPnly9z%2B8QaeiN4IxjSY%3D&reserved=0"><span style="color:purple">40microsoft.com</span></a>%7C76a50b24b6dc436c9c4808d52<br>
| a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat<br>
| a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0<br>
| ><br>
| > Secondly, Simon, you seem to suggest that a large proposal like this<br>
| wouldn’t be either accepted or rejected, but put into a kind a limbo state<br>
| of further evaluation as seen fit. I agree that instead of outright<br>
| rejection of a proposal that we consider flawed but not hopeless, we might<br>
| request further elaboration and resubmission as we have done in the past.<br>
| However, if a proposal passes muster, I think, we should accept it<br>
| unconditionally, even if it is a large change. (If, say, at the end, the<br>
| implementation is not up to scratch, then it is up to the code reviewers to<br>
| reject the patches, but I don’t think, it is this committee’s job anymore.)<br>
| ><br>
| > In any case, I think, it is important make the process as clear as<br>
| possible to authors, so they know what they are in for.<br>
| ><br>
| > What do you all think?<br>
| ><br>
| > Cheers,<br>
| > Manuel<br>
| ><br>
| > _______________________________________________<br>
| > ghc-steering-committee mailing list<br>
| ><span class="apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org"><span style="color:purple">ghc-steering-committee@haskell.org</span></a><br>
| ><span class="apple-converted-space"> </span><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee"><span style="color:purple">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</span></a><br>
| <br>
| _______________________________________________<br>
| ghc-steering-committee mailing list<br>
| <a href="mailto:ghc-steering-committee@haskell.org"><span style="color:purple">ghc-steering-committee@haskell.org</span></a><br>
| <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee"><span style="color:purple">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</span></a><o:p></o:p></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</body>
</html>