<div dir="ltr">Hopefully this URL will be more stable (and reference the rendered proposal): <a href="https://github.com/haskellfoundation/tech-proposals/pull/51">https://github.com/haskellfoundation/tech-proposals/pull/51</a><div><br><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 29 Jun 2023 at 09:27, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The link in the email is broken BTW, is there any updated URL?</div><div><br></div><div>Just based on the summary in the email, what immediately springs to mind is that adding functions to ghc-experimental and then moving them to base implies an extra migration that clients have to do in the future (would the APIs in ghc-experimental be deprecated first? For how long? etc.). It probably makes sense only to do this for additions of fairly large new APIs, and for smaller changes we should probably shortcut the process and make the GHC proposal in conjunction with a CLC proposal and land them in GHC together. Streamlining this process would be good. Maybe the actual proposal already says a lot of this?</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC Steering Committee</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Over the last few weeks, Ben Gamari and I have been discussing with Andrew and Julian from the Core Libraries Committee how to make the Core Libraries Committee and the GHC developers work together more fluidly; and that includes the GHC Steering Committee.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We now have a <a href="https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst" target="_blank">fairly well fleshed out proposal here.</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I hope you like it. As far as this committee is concerned there are two particular points of note</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ol><li>We propose a new package, <b>ghc-experimental</b>, which depends on <b>base</b>. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in <b>ghc-experimental</b>. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to <b>base</b>, which has much stronger stability guarantees.</li><li>Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve <i>changing </i>existing types and functions. It is clearly unproductive for us to debate such things at length, and only <i>then </i>to land it on the CLC.<br><br>Section 5.1 also suggests that proposals should explicitly (in a separate section) call out</li></ol><ul style="margin-left:40px"><li>What new types and functions it defines</li><li>What existing types and functions are changed.<br></li></ul></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">We should add that to our template.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><div>At the moment we are just sharing the proposal with relevant stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any rough edges before making it public.</div><div><br></div><div>So, any views? Personally I think this is a Big Step Forward.<br></div><div><br></div><div>Simon<br></div><div><br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></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>
_______________________________________________<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>