<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">Simon,</div><div class=""><br class=""></div>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.<div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><font face="Monaco" class=""> Proposal</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> v</font></div><div class=""><font face="Monaco" class=""> [1] (GHC Steering Committee)</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> Pull Request/Differential</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> v</font></div><div class=""><font face="Monaco" class=""> [2] (Code reviewers)</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> Development version</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> v</font></div><div class=""><font face="Monaco" class=""> [3] (Release Manager)</font></div><div class=""><font face="Monaco" class=""> |</font></div><div class=""><font face="Monaco" class=""> v</font></div><div class=""><font face="Monaco" class=""> Released feature</font></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class="">(a) The implementation is just not very good. In that case, the contributors can try to improve their code and try again.</div><div class=""><br class=""></div><div class="">(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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Manuel<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; font-family: Helvetica; font-size: 16px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">I’m ok with what Manuel says, especially the bit about being more explicit about the implicit conditionality. But I would add<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 12pt;" class="">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 class=""><br class=""><o:p class=""></o:p></span></li></ul><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">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.<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 12pt;" class="">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.<o:p class=""></o:p></span></li></ul><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><ul type="disc" style="margin-bottom: 0cm; margin-top: 0cm;" class=""><li class="MsoListParagraph" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;"><span style="font-size: 12pt;" class="">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://github.com/ghc/ghc/tree/master/docs/core-spec" style="color: purple; text-decoration: underline;" class="">formal spec for Core</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.<o:p class=""></o:p></span></li></ul><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">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.<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class="">Simon<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-size: 12pt;" class=""><o:p class=""> </o:p></span></div><div style="border-style: none none none solid; border-left-width: 1.5pt; border-left-color: blue; padding: 0cm 0cm 0cm 4pt;" class=""><div class=""><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(225, 225, 225); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""><span class="Apple-converted-space"> </span>Manuel M T Chakravarty [<a href="mailto:chak@justtesting.org" class="">mailto:chak@justtesting.org</a>]<span class="Apple-converted-space"> </span><br class=""><b class="">Sent:</b><span class="Apple-converted-space"> </span>14 November 2017 01:10<br class=""><b class="">To:</b><span class="Apple-converted-space"> </span>Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" class="">simonpj@microsoft.com</a>><br class=""><b class="">Cc:</b><span class="Apple-converted-space"> </span>Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" class="">rae@cs.brynmawr.edu</a>>; <a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><b class="">Subject:</b><span class="Apple-converted-space"> </span>Re: [ghc-steering-committee] Our process and BIG ideas<o:p class=""></o:p></span></div></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">All approval is conditional<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">~~~~~~~~~~~~~~~~~~~~<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I get the feeling that this discussion is actually really about,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">> What does approval mean?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Currently, the ghc-proposals' README states,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span style="font-family: "Segoe UI", sans-serif; color: rgb(36, 41, 46); background-color: white; background-position: initial initial; background-repeat: initial initial;" class="">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 class=""></o:p></div></blockquote><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Size doesn’t matter<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">~~~~~~~~~~~~~~~<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* There needs to a well-engineered implementation.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* It shouldn’t complicate the codebase too much.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* It must not have unexpected interactions with other language features.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* It must not unduly affect the performance of the compiler (neither of compilation nor of the generated code).<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* It must not turn out to be unsound.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* It must not turn out to lead to impossible to understand error messages.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">* What else?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">All these conditions must be met by *all* proposals, large or small. Every approval is always conditional on all of these conditions.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">What if a condition is violated<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">~~~~~~~~~~~~~~~~~~~~~~<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">That depends on whether the problem can be fixed and what kind of fix is needed. <o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Summary<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">~~~~~~~<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">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 class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Cheers,<o:p class=""></o:p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Manuel<o:p class=""></o:p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><br class=""><br class=""><o:p class=""></o:p></div><blockquote style="margin-top: 5pt; margin-bottom: 5pt;" class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" style="color: purple; text-decoration: underline;" class="">simonpj@microsoft.com</a>>:<o:p class=""></o:p></div></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div class=""><div class=""><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">| However, I'm leery of unconditional approval of something as large as the<br class="">| linear types proposal.<br class=""><br class="">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 class=""><br class="">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 class=""><br class="">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 class=""><br class="">1. Philosophically, we like the direction of travel. If there are no surprises, we'd like to have this in the language.<br class=""><br class="">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 class=""><br class="">3. Implementation. Now we have an implementation.<br class=""><br class="">4. Merge into HEAD<br class=""><br class="">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 class=""><br class="">Actually (2) and (3) are likely to be symbiotic, I think.<br class=""><br class="">Does that make sense?<br class=""><br class="">Simon<span class="Apple-converted-space"> </span><br class=""><br class="">| -----Original Message-----<br class="">| From: ghc-steering-committee [mailto:ghc-steering-committee-<br class="">| <a href="mailto:bounces@haskell.org" style="color: purple; text-decoration: underline;" class="">bounces@haskell.org</a>] On Behalf Of Richard Eisenberg<br class="">| Sent: 13 November 2017 03:25<br class="">| To: Manuel M T Chakravarty <<a href="mailto:chak@justtesting.org" style="color: purple; text-decoration: underline;" class="">chak@justtesting.org</a>><br class="">| Cc:<span class="Apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color: purple; text-decoration: underline;" class="">ghc-steering-committee@haskell.org</a><br class="">| Subject: Re: [ghc-steering-committee] Our process and BIG ideas<br class="">| <br class="">| I fully agree that proposals for large new features can reference an<br class="">| accompanying paper.<br class="">| <br class="">| However, I'm leery of unconditional approval of something as large as the<br class="">| linear types proposal. GHC is a very large, complex system, and no one can<br class="">| anticipate all the interactions that a proposal may have with existing<br class="">| features. It's quite possible that something which seems like a good idea<br class="">| has a disastrous interaction with some other part of the compiler/language<br class="">| definition.<br class="">| <br class="">| Instead, I would favor a conditional approval that would turn to rejection<br class="">| only if further experience (gained through a [partial] implementation)<br class="">| reveals a theoretical sticking point. I use "theoretical" here to mean that<br class="">| the rejection wouldn't be based on poor code quality or an implementation<br class="">| challenge, per se, but by running into a scenario where we are unable to<br class="">| specify the correct behavior of the system.<br class="">| <br class="">| In truth, even an approval that we described as unconditional would really<br class="">| be as in the paragraph above -- we simply can't do better. So I guess I'm<br class="">| favoring calling such an approval as conditional, just to be clear to<br class="">| proposers what we mean.<br class="">| <br class="">| Richard<br class="">| <br class="">| > On Nov 12, 2017, at 10:07 PM, Manuel M T Chakravarty<br class="">| <<a href="mailto:chak@justtesting.org" style="color: purple; text-decoration: underline;" class="">chak@justtesting.org</a>> wrote:<br class="">| ><br class="">| > In the light of the linear types proposal PR, SimonPJ’s comment<br class="">| ><br class="">| ><br class="">| <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%25" style="color: purple; text-decoration: underline;" class="">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</a><br class="">| 2Fghc-proposals%2Fghc-proposals%2Fpull%2F91%23issuecomment-<br class="">| 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" style="color: purple; text-decoration: underline;" class="">40microsoft.com</a>%7C76a50b24b6dc436c9c4808d52<br class="">| a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat<br class="">| a=%2FGtP16v%2BiJEDwkd0TpX6yKpXS0bZaOh1HWDCEsPTiDg%3D&reserved=0<br class="">| ><br class="">| > and some uncertainty about the proposal process that has been communicated<br class="">| to me via a side channel, it might be worthwhile clarifying our expectations<br class="">| for large complex proposals. (I know, we basically punted on these questions<br class="">| in our initial discussion on the process with the intention to revisit after<br class="">| we gained some experience. It seems this time has come.)<br class="">| ><br class="">| > Firstly, we usually require proposals to be self-contained. This makes a<br class="">| lot of sense for small to medium-sized proposals to limit the time needed by<br class="">| the committee to hunt down all the required information. However, in a case,<br class="">| such as the linear types work, where there is a highly polished text in the<br class="">| form of a research paper (or similar), it seems reasonable to refer to that<br class="">| existing work — not only because type rules are a lot nicer to read when<br class="">| rendered by LaTeX instead of Markdown.<br class="">| ><br class="">| > Concretely, I’d like us to give some guidance wrt to this issue to<br class="">| proposal authors and document that at<br class="">| <a href="https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%25" style="color: purple; text-decoration: underline;" class="">https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%</a><br class="">| 2Fghc-proposals%2Fghc-proposals%23ghc-<br class="">| 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" style="color: purple; text-decoration: underline;" class="">40microsoft.com</a>%7C76a50b24b6dc436c9c4808d52<br class="">| a463534%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636461403387929271&sdat<br class="">| a=Z8x%2FqlkWGH4dt43vQYpU9yP7YGGBZ4NR920%2FBS6EMA4%3D&reserved=0<br class="">| ><br class="">| > Secondly, Simon, you seem to suggest that a large proposal like this<br class="">| wouldn’t be either accepted or rejected, but put into a kind a limbo state<br class="">| of further evaluation as seen fit. I agree that instead of outright<br class="">| rejection of a proposal that we consider flawed but not hopeless, we might<br class="">| request further elaboration and resubmission as we have done in the past.<br class="">| However, if a proposal passes muster, I think, we should accept it<br class="">| unconditionally, even if it is a large change. (If, say, at the end, the<br class="">| implementation is not up to scratch, then it is up to the code reviewers to<br class="">| reject the patches, but I don’t think, it is this committee’s job anymore.)<br class="">| ><br class="">| > In any case, I think, it is important make the process as clear as<br class="">| possible to authors, so they know what they are in for.<br class="">| ><br class="">| > What do you all think?<br class="">| ><br class="">| > Cheers,<br class="">| > Manuel<br class="">| ><br class="">| > _______________________________________________<br class="">| > ghc-steering-committee mailing list<br class="">| ><span class="Apple-converted-space"> </span><a href="mailto:ghc-steering-committee@haskell.org" style="color: purple; text-decoration: underline;" class="">ghc-steering-committee@haskell.org</a><br class="">| ><span class="Apple-converted-space"> </span><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" style="color: purple; text-decoration: underline;" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">| <br class="">| _______________________________________________<br class="">| ghc-steering-committee mailing list<br class="">| <a href="mailto:ghc-steering-committee@haskell.org" style="color: purple; text-decoration: underline;" class="">ghc-steering-committee@haskell.org</a><br class="">| <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" style="color: purple; text-decoration: underline;" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a></div></div></div></blockquote></div></div></div></div></div></blockquote></div><br class=""></div></body></html>