<div dir="ltr">> <span style="font-family:tahoma,sans-serif">I think the question is: how do they "explicitly opt in"? One possibility is: they depend on ghc-internals in their .cabal file. That's explicit, and it's opting in. </span><span class="gmail-Apple-converted-space" style="font-family:tahoma,sans-serif"> </span><br><br class="gmail-Apple-interchange-newline"><div>The opt-in needs to explicitly more involved than the same as it is for any other library. For regular libraries we want to make this as easy as possible, we want<br></div><div>people to be able to focus on code, not on maintenance. I can see tools supporting developers (similar to what Java has been doing for decades) in offering them</div><div>to import a module when they type a symbol. (The most likely from the inferred type the symbol would need to have). We kind of have a manual version of this with</div><div>hoogle, and going the extra mile to also add the packge to the build-depends in cabal.</div><div><br></div><div>None of this would be good for ghc-internals. Those symbols need to carry a special tag to indicate their loose stability guarantees. Such that any usesite can be</div><div>flagged, and tools could filter/warn on those flags.</div><div><br></div><div>Ultimately what we say is: this symbol/module/package has reduced/no stability guarantees, use with caution. If you end up using this, and you are _not_ GHC, please</div><div>ensure to petition the CLC for adding this to the stable standard library (base, ...) interface.</div><div><br></div><div>We can see the same topic happening for other packages as well. I remember the discussion around the .Internal module naming, all to _permit_ people to use internals</div><div>_if_ they so need to, without having to resort to forking modules.</div><div><br></div><div>Then again, I think this is getting off the rails a bit here. I am as I have indicate here and elsewhere fine with the proposal, I think it moves us a notch in the right direction. We should have a separate proposal for the INTERNAL marker I believe. But that's not a pre-requisite for this proposal. We will just have to use as much social discouragement as we can muster until we have a more technically enforceable solution.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 17:02, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">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"><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 class="gmail_default" style="font-family:tahoma,sans-serif">
<font style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">And I also
want to strongly discourage people from using escape hatches and rather
motivate them to petition the CLC to extend base with a stable interface
for their needs.</font></div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I'll all for that!</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">
<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="auto">Therefore, I’d want ghc-internals to be flagged as
INTERNAL, GHC itself be built with -fpermit-internals, but everyone else
having explicitly to opt in to that (and for me an easy way to prohibit
the use of any non-whitelisted packages using -fpermit-internals).</div></blockquote>
</div><div style="font-family:tahoma,sans-serif" class="gmail_default"></div><div style="font-family:tahoma,sans-serif" class="gmail_default">I think the question is: how do they "explicitly opt in"? One possibility is: they depend on ghc-internals in their .cabal file. That's explicit, and it's opting in. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">There is some user interface design here, presumably involving cabal. <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 27 Jun 2023 at 15:43, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" target="_blank">moritz.angermann@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="auto">I have strong reasons to discourage them. As a consumer of components that can transitively depend on any of those, I must make sure none of my dependencies depend on these internals (other than GHC itself). Any component that depends on ghc-internals is not fit for use in projects I’d be responsible for.</div><div dir="auto"><br></div><div dir="auto">I can not continue spending the obscene amounts we spend for compiler upgrades.</div><div dir="auto"><br></div><div dir="auto">If someone in a leaf node depends to use internals I have no problem with this. If this unintentionally slips into any library that I transitively depend on, I have a problem. This needs to be *very* loud and explicit. I would almost call it tainted that something depends on APIs that have no stability guarantees.</div><div dir="auto"><br></div><div dir="auto">To illustrate this. Let’s assume we have a Haskell application which depends on pkg A transitively though 10+ pkgs. pkg A-1.0 decides to depend on GHC-internals. Next GHC comes around, breaks GHC-internals, pkg A is now broken. pkg A’s master branch is at 3.0, and will now get the update and be compatible with GHC-internals. What about 1.0? Touch luck. And now this process ripples through 10+ layers of dependencies.</div><div dir="auto"><br></div><div dir="auto">Not only is this exceptionally expensive to adapt to. It also means there is no sensible way to measure regressions of the application. The compiler upgrade has now caused lots of code changes throughout the whole codebase (including dependencies).</div><div dir="auto"><br></div><div dir="auto">Therefore, I’d want ghc-internals to be flagged as INTERNAL, GHC itself be built with -fpermit-internals, but everyone else having explicitly to opt in to that (and for me an easy way to prohibit the use of any non-whitelisted packages using -fpermit-internals).</div><div dir="auto"><br></div><div dir="auto">We want to decouple a stable set of base base libraries from the GHC internal libraries that have less rigorous stability guarantees, because they are explicitly internal after all. However if we let this leak out too easily we have forfeit significant benefits this could bring.</div><div dir="auto"><br></div><div dir="auto">As someone dealing with a massive codebase, how am I justifying spending six figures to just make the code compatible with a new compiler and then find out that I’m now facing performance regressions?!</div><div dir="auto"><br></div><div dir="auto">Thus form a practical point of view, I want to insulate my codebase as much as possible from depending in any form on GHC-internals or other libraries with a reduced stability guarantee.</div><div dir="auto"><br></div><div dir="auto">Depending on ghc-internals (or any such reduced stability library) should come with high hurdles and excessive bells. (Which could be consciously silenced by something like -fpermit-internals).</div><div dir="auto"><br></div><div dir="auto">On the other hand if this is too easy to do, we end up with lots of libraries on hackage depending on GHC-internals, and breaking every release cycle we’ve won nothing but only complicated things.</div><div dir="auto"><br></div><div dir="auto">Again, we don’t have the facilities for this today. But I would urge us to get the asap. </div><div dir="auto"><br></div><div dir="auto">On a final note:</div><div dir="auto">> <span style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">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.</span></div><div dir="auto"><span style="font-family:tahoma,sans-serif;color:rgb(0,0,0)"><br></span></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255);color:rgb(255,255,255)" dir="auto"><font style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">I consider this a very slippery slope. We want the split to be explicit and conscious not for people to end up depending on base and GHC-internal because they just need something. It need to be _strongly_ discouraged to do so, and it need to be more painful to use than petition the CLC to extend base. Otherwise the incentives are aligned in a way that people do not petition the CLC but just use GHC-internals.</font></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><font style="font-family:tahoma,sans-serif;color:rgb(0,0,0)"><br></font></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><font style="font-family:tahoma,sans-serif;color:rgb(0,0,0)">I do not want to prevent people from this. There are escape hatches. I want to to be able to prevent any such software that uses those escape hatches. And I also want to strongly discourage people from using escape hatches and rather motivate them to petition the CLC to extend base with a stable interface for their needs. </font></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span><br></span></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span>Cheers,</span></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span> Moritz</span></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span><br></span></div><div style="background-color:rgba(0,0,0,0);border-color:rgb(255,255,255)" dir="auto"><span>On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:</span><br></div><div><div class="gmail_quote"><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">I don't think we want to flag <i style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif"><li style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">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 style="font-family:tahoma,sans-serif">I have no strong opinion about want form "discourage" takes. Certainly not "prevent".</div></div></div><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">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" target="_blank">moritz.angermann@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="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-width:1px;border-left-style:solid;border-left-color: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-width:1px;border-left-style:solid;border-left-color: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-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" 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>
</blockquote></div></div>
</blockquote></div>
</blockquote></div>