<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">I don't think we want to flag <i>individual </i>bindings in ghc-internals; they are all there for a good, internal, non-deprecated reason. What we want to discourage is for GHC clients to depend on <b>any module </b>in ghc-internals casually, without having a Strong Reason to do so. Why discourage?</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>Everything they want should be in base. And maybe it already is! If not, and if they have a need, and base doesn't have it, then they may want to depend on ghc-internals temporarily and petition CLC to extend base.</li><li>If they casually depend on ghc-internals, they impose costs on themselves (when we change the API) and on us (when they complain about us changing the API).</li></ul><div>I have no strong opinion about want form "discourage" takes. Certainly not "prevent".</div><div><br></div><div>Simon<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><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 14:59, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com">moritz.angermann@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="auto">I have some concern around the discouraging concept as well. </div><div dir="auto"><br></div><div dir="auto">Ideally we had some marker INTERNAL like DEPRECATED, that could be attached to individual bindings, complete modules or even packages. If this existed, we could have code either error if it used any INTERNAL binding, and no -fpermit-internals was provided. If this was attached to already exposed bindings we’d want a warning phase for at least two releases which I believe DEPRECATED could do?</div><div dir="auto"><br></div><div dir="auto">However, we don’t have this today, so I wouldn’t want this to block this proposal from progressing.</div><div dir="auto"><br></div><div dir="auto">I’m not so much for hiding it. Reading up on it and knowing the details (or even looking at the source) can be helpful at times. Making discovery harder by hiding it would not be my preferred route. </div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto"> Moritz</div><div dir="auto"><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</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 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" target="_blank">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" style="font-family:tahoma,sans-serif" 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 style="font-family:tahoma,sans-serif"><li style="font-family:tahoma,sans-serif">We propose a new package, <b style="font-family:tahoma,sans-serif">ghc-experimental</b>, which depends on <b style="font-family:tahoma,sans-serif">base</b>. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in <b style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">base</b>, which has much stronger stability guarantees.</li><li style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">changing </i>existing types and functions. It is clearly unproductive for us to debate such things at length, and only <i style="font-family:tahoma,sans-serif">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;font-family:tahoma,sans-serif"><li style="font-family:tahoma,sans-serif">What new types and functions it defines</li><li style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">So, any views? Personally I think this is a Big Step Forward.<br></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div><div style="font-family:tahoma,sans-serif"><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>
_______________________________________________<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></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>