<div dir="ltr"><div dir="ltr">I don't have a strong opinion. I trust the people involved.</div><div dir="ltr"><br></div><div dir="ltr">The one thing I'll note is that the part about discouraging people from depending on ghc-internals seems to involve an awful lot of work. I wouldn't count on such work being done promptly. The one thing in the least that can be done reasonably cheaply is making sure that every module in ghc-internals to be annotated with {-# OPTIONS_HADDOCK hide #-} (so that Haddock only generate documentation for the source but not for the module interfaces).</div><div dir="ltr"><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 20 Jun 2023 at 09:03, Chris Dornan <<a href="mailto:chris@chrisdornan.com">chris@chrisdornan.com</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>Really, all LGTM!<br><div><br><blockquote type="cite"><div>On 19 Jun 2023, at 22:10, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Hello 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">Any views about this? </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Jun 2023 at 10:03, 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:1px solid 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>
</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" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></div></blockquote></div><br></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 clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div>