<div dir="ltr">Hello,<div><br></div><div>my preference would be to reject this proposal, and turn the "proposed design for dependent haskell" (the link in Simon's e-mail) into its own proposal so that we can discuss it, and suggest changes. It seems really odd to agree to adhere to a design that we never discussed.</div><div> </div><div>By the way, it's really great to finally see something written down about the actual design of DH. I had a quick read, and I have some questions, which is why I think it makes more sense to have the design as its own proposal. In particular, it seems to me like it might be quite possible to split the DH design into a collection of separate extensions, which might make it easier to understand, although I don't fully understand the whole picture, and might be wrong about that.</div><div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Mar 29, 2021 at 5:17 AM Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB" style="overflow-wrap: break-word;">
<div class="gmail-m_-771383098186206842WordSection1">
<p class="MsoNormal">Dear GHC Steering Committee<u></u><u></u></p>
<p class="MsoNormal">I’m recommending acceptance of Proposal #378: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/378" target="_blank">
Support the design for dependent types</a><u></u><u></u></p>
<p class="MsoNormal">As you’ll see, there is a lot of useful context, but the payload is pretty simple<u></u><u></u></p>
<p style="margin-left:36pt"><i>When evaluating new proposals, the GHC committee would consider compatibility with
<a href="https://gitlab.haskell.org/ghc/ghc/-/wikis/dependent-haskell" target="_blank">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></u><u></u></i></p>
<p style="margin-left:36pt"><i>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></u><u></u></i></p>
<p style="margin-left:36pt"><i>See also the committee's <a href="https://github.com/ghc-proposals/ghc-proposals/#review-criteria" target="_blank">
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></u><u></u></i></p>
<p style="margin-left:36pt"><i>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></u><u></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></u><u></u></p>
<p class="MsoNormal">Simon<u></u><u></u></p>
</div>
</div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>