<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=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On May 18, 2021, at 3:47 AM, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" class="">arnaud.spiwack@tweag.io</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">Sorry, it's a long read. I'd read previous iterations of the proposal, and the wiki page previously. But the current proposal is yet a different text, I didn't want to opine without a proper reading.</div></div></div></blockquote><div><br class=""></div><div>Yes, thank you!</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">The proposal is long, but doesn't really make a lot of concrete design choices.</div></div></div></blockquote><div><br class=""></div><div>Yes, this is intentional.</div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">The language, though, is sometimes interesting:</div><div class=""><br class=""></div><div class="">> By accepting this proposal, the committee reaffirms Haskell's status as
an evolving, forward-thinking language, excited to adopt new ideas.</div></div></div></blockquote><div><br class=""></div><div>Yes, this was an overstep. I've struck this sentence.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">> There remain a few individuals who appear to remain deeply unconvinced. However, these seem to
be a small minority. The reasons they are not convinced appear to be around lack of
understanding of the proposal/design and general worry about unintended consequences.
I have tried to address both of these, but I do not believe my efforts have been fully
successful.</div></div></div></blockquote><div><br class=""></div><div>I stand by this claim -- though I can see how the language here might be off-putting. This section is meant to be a summary of the discussion, and this really was a part of the discussion. However, I have replaced this bullet with a narrower one, describing the particular worry about people being forced to use dependent types because of early library adoption.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">This is really not helpful, I don't think that we want to merge the proposal with this sort of language in it.</div><div class=""><br class=""></div><div class="">I'd add that the following:<br class=""></div><div class=""><br class=""></div><div class="">> Many industrial Haskellers came out of the woodwork to support this proposal.</div><div class=""><br class=""></div><div class="">is rather misleading, since there seem to have been just as many industrial Haskellers which came out opposed to the proposal.</div></div></div></blockquote><div><br class=""></div><div>I disagree here. The GitHub ticket has 412 positive emotions, and 3 negative ones. The 412 might be an overcount, because I believe one individual can put multiple emoji on the same ticket, but there are at least 274 individuals in favor. It's true that I don't know how many of these are industrial users, but there were quite a few people who identified as industrial users in support. I actually don't know that any of the detractors identified themselves as industrial users, though I didn't read through all the comment trail to check this.</div><div><br class=""></div><div>We don't -- and shouldn't -- operate solely (or primarily) on the basis of popularity, but I think both the emoji expressed and the comment trail suggests that this feature is desired in industry more widely than it is opposed.</div><div><br class=""></div><div>Richard</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">---</div><div class=""><br class=""></div><div class="">In summary: I'm in favour of the proposal, as long as Section 5 (Effect and Interaction) and below, are cleaned of the politically charged language.<br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 13, 2021 at 5:09 PM Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div style="overflow-wrap: break-word;" lang="EN-GB" class="">
<div class="gmail-m_-1902739115598012204WordSection1"><p class="MsoNormal">Friends<u class=""></u><u class=""></u></p><p class="MsoNormal">You have now had a month to review my recommendation below, to accept #378: support for dependent types.
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0" target="_blank" class="">
Here it is once more</a><u class=""></u><u class=""></u></p><p class="MsoNormal">I have heard <u class=""></u><u class=""></u></p>
<ul style="margin-top:0cm" type="disc" class="">
<li class="gmail-m_-1902739115598012204MsoListParagraph" style="margin-left:0cm">Support: Joachim, Vitaly, Alejandro, Vlad (plus Richard and myself)<u class=""></u><u class=""></u></li><li class="gmail-m_-1902739115598012204MsoListParagraph" style="margin-left:0cm">Against: no one<u class=""></u><u class=""></u></li></ul><p class="MsoNormal">But that leaves <b class="">Tom, Eric, Arnaud, Cale, Simon M, and Iavor</b> who have not expressed an opinion. Please do!<u class=""></u><u class=""></u></p><p class="MsoNormal">Failing further feedback, I’ll accept on Tuesday next week.<u class=""></u><u class=""></u></p><p class="MsoNormal">There has been some further <a href="https://github.com/ghc-proposals/ghc-proposals/pull/378" target="_blank" class="">
discussion on the pull request</a>, but I don’t think any fundamentally new points have come up. This is clearly a judgement call, but one I think we should make. Haskell has always been a research lab – that’s part of what makes it distinctive. I think
we can continue to celebrate that innovation. But see my email immediately below for what we are and are not accepting.<u class=""></u><u class=""></u></p><p class="MsoNormal">Simon<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt" class="">
<div class="">
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm" class=""><div style="margin: 0cm;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>>
<br class="">
<b class="">Sent:</b> 15 April 2021 10:39<br class="">
<b class="">To:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<b class="">Cc:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>><br class="">
<b class="">Subject:</b> Recommendation for #378: support the design for dependent types<u class=""></u><u class=""></u></span></div>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Dear GHC steering committee<u class=""></u><u class=""></u></p><p class="MsoNormal">OK Richard has now revised the “Design for Dependent Types” proposal, and has resubmitted it. As we asked, it now
<i class="">includes</i> the design sketch that constitutes the direction of travel advocated in the proposal, rather than merely
<i class="">referring</i> to it.<u class=""></u><u class=""></u></p><p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fgoldfirere%2Fghc-proposals%2Fblob%2Fdependent-types%2Fproposals%2F0000-dependent-type-design.rst&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362468484%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=K1JBnklN2ztnUyibLJ%2Bv9q8%2BK%2Bg1Sf%2FHDGjwVmj25Mw%3D&reserved=0" target="_blank" class="">Here
it is once more</a><u class=""></u><u class=""></u></p><p class="MsoNormal">I propose acceptance.<u class=""></u><u class=""></u></p><p class="MsoNormal">Remember:<u class=""></u><u class=""></u></p>
<ul style="margin-top:0cm" type="disc" class="">
<li class="gmail-m_-1902739115598012204MsoListParagraph" style="margin-left:2.5pt">We
<b class="">would not</b> be accepting every detail of the design in Section 4 – rather, we expect further specific proposals as we move in the direction described in the proposal. So we should not debate the fine print of Section 4.
<u class=""></u><u class=""></u></li><li class="gmail-m_-1902739115598012204MsoListParagraph" style="margin-left:2.5pt">We
<b class="">would</b> be accepting that the proposal describes a direction of travel that we are happy with. That in turn gives people the confidence to invest efforts in those more detailed proposals. As the “Proposed change specification” says: “When evaluating
new proposals, the GHC committee would consider compatibility with the design sketch below. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded
by other dependent-type features.”<u class=""></u><u class=""></u></li></ul><p class="MsoNormal">Any views? Questions of clarification or technical questions belong on the comment stream.<u class=""></u><u class=""></u></p><p class="MsoNormal">Thanks<u class=""></u><u class=""></u></p><p class="MsoNormal">Simon<u class=""></u><u class=""></u></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt" class="">
<div class="">
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm" class=""><div style="margin: 0cm;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""> ghc-steering-committee <<a href="mailto:ghc-steering-committee-bounces@haskell.org" target="_blank" class="">ghc-steering-committee-bounces@haskell.org</a>>
<b class="">On Behalf Of </b>Simon Peyton Jones via ghc-steering-committee<br class="">
<b class="">Sent:</b> 06 April 2021 13:58<br class="">
<b class="">To:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<b class="">Subject:</b> Re: [ghc-steering-committee] Recommendation for #378: support the design for dependent types<u class=""></u><u class=""></u></span></div>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Richard and I have discussed this.<u class=""></u><u class=""></u></p><p class="MsoNormal">We concluded that we’d put it back into “Needs revision” status. He’s going to expand it (substantially) to include
<i class=""><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C5Ywef9f5MK4jEc2XfmXeZ26YIdJeP0%2F%2BKfGdIhfkYA%3D&reserved=0" target="_blank" class="">the
proposed design sketch of dependent types on the GHC wiki</a>. </i>Then he’ll resubmit in the hope of getting approval of the design in principle, subject to subsequent discussion of the fine detail.<u class=""></u><u class=""></u></p><p class="MsoNormal">Simon<u class=""></u><u class=""></u></p><p class="MsoNormal"><u class=""></u> <u class=""></u></p>
<div style="border-color:currentcolor currentcolor currentcolor blue;border-style:none none none solid;border-width:medium medium medium 1.5pt;padding:0cm 0cm 0cm 4pt" class="">
<div class="">
<div style="border-color:rgb(225,225,225) currentcolor currentcolor;border-style:solid none none;border-width:1pt medium medium;padding:3pt 0cm 0cm" class=""><div style="margin: 0cm;" class=""><b class=""><span lang="EN-US" class="">From:</span></b><span lang="EN-US" class=""> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>>
<br class="">
<b class="">Sent:</b> 29 March 2021 13:17<br class="">
<b class="">To:</b> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<b class="">Cc:</b> Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank" class="">simonpj@microsoft.com</a>><br class="">
<b class="">Subject:</b> Recommendation for #378: support the design for dependent types<u class=""></u><u class=""></u></span></div>
</div>
</div><p class="MsoNormal"><u class=""></u> <u class=""></u></p><p class="MsoNormal">Dear GHC Steering Committee<u class=""></u><u class=""></u></p><p class="MsoNormal">I’m recommending acceptance of Proposal #378: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fpull%2F378&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362478476%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=%2Bf32VqzdL6HgiF436%2FGWPwBl09c1qo%2BAMbgPY6tJfSI%3D&reserved=0" target="_blank" class="">
Support the design for dependent types</a><u class=""></u><u class=""></u></p><p class="MsoNormal">As you’ll see, there is a lot of useful context, but the payload is pretty simple<u class=""></u><u class=""></u></p><p style="margin-left:36pt" class=""><i class="">When evaluating new proposals, the GHC committee would consider compatibility with
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.haskell.org%2Fghc%2Fghc%2F-%2Fwikis%2Fdependent-haskell&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=1xOofIrHU3rP91mxYwvKnefFqCA5RBHCUUuKHqtdZlo%3D&reserved=0" target="_blank" class="">
the proposed design sketch of dependent types on the GHC wiki</a>. Generally speaking, new proposals should be forward-compatible with the design sketch; that is, the new features proposed would continue to be at home when surrounded by other dependent-type
features.<u class=""></u><u class=""></u></i></p><p style="margin-left:36pt" class=""><i class="">Of course, the committee remains free to revise the design sketch or to accept proposals that encroach upon it (i.e. contradicting this guidance), but such choices should be made explicitly.<u class=""></u><u class=""></u></i></p><p style="margin-left:36pt" class=""><i class="">See also the committee's <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2F%23review-criteria&data=04%7C01%7Csimonpj%40microsoft.com%7Cc0e29b49960a43b4d7ee08d8fff24512%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637540763362488470%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=C%2B6VLghDD03q1Qwqwytrp75eAHQtPF%2FB1SveNIKrymA%3D&reserved=0" target="_blank" class="">
Review Criteria</a>: put another way, this proposal says that we consider the design sketch alongside other features of today's Haskell when assessing a new proposal's fit with the language.<u class=""></u><u class=""></u></i></p><p style="margin-left:36pt" class=""><i class="">Note that compatibility with dependent types is far from the only criterion the committee would use to evaluate a proposal. Other review criteria, such as learnability, clarity of error messages, performance, etc., remain just
as ever.<u class=""></u><u class=""></u></i></p><p class="MsoNormal">Any views? Let’s try to converge rapidly…. the proposal has been substantially refined by a lot of debate.<u class=""></u><u class=""></u></p><p class="MsoNormal">Simon<u class=""></u><u class=""></u></p>
</div>
</div>
</div>
</div>
</div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></body></html>