Really, all LGTM!

On 19 Jun 2023, at 22:10, Simon Peyton Jones wrote:

Hello GHC steering committee,

Any views about this?

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note We propose a new package, ghc-experimental, which depends on base. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in ghc-experimental. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to base, which has much stronger stability guarantees. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve changing existing types and functions. It is clearly unproductive for us to debate such things at length, and only then to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out What new types and functions it defines What existing types and functions are changed. We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I have some concern around the discouraging concept as well. 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? However, we don’t have this today, so I wouldn’t want this to block this proposal from progressing. 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. Cheers, Moritz On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack wrote:

I don't have a strong opinion. I trust the people involved.

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).

/Arnaud

On Tue, 20 Jun 2023 at 09:03, Chris Dornan wrote:

...

Really, all LGTM!

On 19 Jun 2023, at 22:10, Simon Peyton Jones wrote:

Hello GHC steering committee,

Any views about this?

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note

1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out

- What new types and functions it defines - What existing types and functions are changed.

We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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. I can not continue spending the obscene amounts we spend for compiler upgrades. 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. 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. 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). 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). 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. 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?! 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. 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). 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. Again, we don’t have the facilities for this today. But I would urge us to get the asap. On a final note:

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.

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. 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. Cheers, Moritz On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

I don't think we want to flag *individual *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 *any module *in ghc-internals casually, without having a Strong Reason to do so. Why discourage?

- 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. - 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).

I have no strong opinion about want form "discourage" takes. Certainly not "prevent".

Simon

On Tue, 27 Jun 2023 at 14:59, Moritz Angermann wrote:

...

I have some concern around the discouraging concept as well.

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?

However, we don’t have this today, so I wouldn’t want this to block this proposal from progressing.

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.

Cheers, Moritz

On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack wrote:

...

I don't have a strong opinion. I trust the people involved.

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).

/Arnaud

On Tue, 20 Jun 2023 at 09:03, Chris Dornan wrote:

...

Really, all LGTM!

On 19 Jun 2023, at 22:10, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Hello GHC steering committee,

Any views about this?

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note

1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out

- What new types and functions it defines - What existing types and functions are changed.

We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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.

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 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 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 hoogle, and going the extra mile to also add the packge to the build-depends in cabal. 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 flagged, and tools could filter/warn on those flags. 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 ensure to petition the CLC for adding this to the stable standard library (base, ...) interface. 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 _if_ they so need to, without having to resort to forking modules. 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. On Tue, 27 Jun 2023 at 17:02, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

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.

I'll all for that!

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).

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.

There is some user interface design here, presumably involving cabal.

Simon

On Tue, 27 Jun 2023 at 15:43, Moritz Angermann wrote:

...

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.

I can not continue spending the obscene amounts we spend for compiler upgrades.

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.

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.

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).

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).

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.

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?!

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.

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).

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.

Again, we don’t have the facilities for this today. But I would urge us to get the asap.

...

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

On a final note: base.

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.

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.

Cheers, Moritz

On Tue, 27 Jun 2023 at 4:10 PM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

I don't think we want to flag *individual *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 *any module *in ghc-internals casually, without having a Strong Reason to do so. Why discourage?

- 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. - 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).

I have no strong opinion about want form "discourage" takes. Certainly not "prevent".

Simon

On Tue, 27 Jun 2023 at 14:59, Moritz Angermann < moritz.angermann@gmail.com> wrote:

...

I have some concern around the discouraging concept as well.

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?

However, we don’t have this today, so I wouldn’t want this to block this proposal from progressing.

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.

Cheers, Moritz

On Tue, 27 Jun 2023 at 3:09 PM, Arnaud Spiwack wrote:

...

I don't have a strong opinion. I trust the people involved.

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).

/Arnaud

On Tue, 20 Jun 2023 at 09:03, Chris Dornan wrote:

...

Really, all LGTM!

On 19 Jun 2023, at 22:10, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Hello GHC steering committee,

Any views about this?

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

> Dear GHC Steering Committee > > 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. > > We now have a fairly well fleshed out proposal here. > https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos... > > I hope you like it. As far as this committee is concerned there are > two particular points of note > > 1. We propose a new package, *ghc-experimental*, which depends > on *base*. Many GHC proposals involve defining new types and > functions. The idea is that these would initially be in > *ghc-experimental*. After they stabilise and become widely > adopted, the author (or anyone else) can make a CLC proposal to move them > to *base*, which has much stronger stability guarantees. > 2. Section 5.1 suggests a mechanism to involve CLC members in > proposals that involve new functions and types, at an earlier stage. Some > involve *changing *existing types and functions. It is clearly > unproductive for us to debate such things at length, and only *then > *to land it on the CLC. > > Section 5.1 also suggests that proposals should explicitly (in a > separate section) call out > > > - What new types and functions it defines > - What existing types and functions are changed. > > We should add that to our template. > > 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. > > So, any views? Personally I think this is a Big Step Forward. > > Simon > > > > _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Hopefully this URL will be more stable (and reference the rendered proposal): https://github.com/haskellfoundation/tech-proposals/pull/51 On Thu, 29 Jun 2023 at 09:27, Simon Marlow wrote:

The link in the email is broken BTW, is there any updated URL?

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?

Cheers Simon

On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note

1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out

- What new types and functions it defines - What existing types and functions are changed.

We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

This proposal has just popped up in another discussion, and its implications dawned on me. I see two major issues with the proposal in its current form: 1. Proposal authors shouldn't need to interact with two committees instead of one. It is generally fine to have coordination between committees, so I can imagine a system where GHC SC cannot approve a proposal on its own and must contact CLC when a proposal touches base. Proposal authors mustn't be bothered with the intricacies of this process, they need to write a single document, submit it on a single platform, and then either have it accepted or rejected, whether by GHC SC alone or by a joint GHC SC + CLC committee. 2. Proposal implementors need a single source of truth for the accepted changes. If the proposal document has been marked accepted, it means that it's ready for implementation. Now, I have no problem whatsoever with involving CLC before a proposal is accepted, but once it's done, it's done. It's quite important to be able to point potential contributors to a document that describes the changes we want to see in GHC and its libraries, and it can't be that parts of this document are actually accepted and parts of it are kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending. So I agree with the general idea that it's important to get CLC involved, but for the sake of proposal authors and proposal implementors, this should be a committee-to-committee interaction, not a person-to-two-committees interaction; and acceptance of a proposal needs to be a single atomic operation instead of having kind-of-accepted documents floating around in the ghc-proposals repo. Vlad On jeu., juin 29 2023 at 09:49:09 +01:00:00, Simon Peyton Jones wrote:

...

make the GHC proposal in conjunction with a CLC proposal and land them in GHC together. Streamlining this process would be good

That is absolutely an option, yes.

Simon

On Thu, 29 Jun 2023 at 08:27, Simon Marlow mailto:marlowsd@gmail.com> wrote:

...

The link in the email is broken BTW, is there any updated URL?

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?

Cheers Simon

On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees.Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve /changing/existing types and functions. It is clearly unproductive for us to debate such things at length, and only /then/to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out What new types and functions it definesWhat existing types and functions are changed. We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Maybe the proposal template could include a section about potential CLC interactions, to take advantage of the pre-submission discussion. People usually debate minute details on there quite eagerly, and it would provide a contact point and overview for CLC members. On 7/9/23 12:19, Joachim Breitner wrote:

There is clearly an mismatch here that seems to be hard to resolve without changing at least one of the two processes (which are like that for good reasons). But at least we should try to make this transparent: Get a (non-binding) positive assessment of the CLC on proposals that touch base when accepting a GHC proposal, and communicate the need to get final approval when the implementation is done

Hi, Am Sonntag, dem 09.07.2023 um 12:58 +0200 schrieb Torsten Schmits via ghc-steering-committee:

Maybe the proposal template could include a section about potential CLC interactions, to take advantage of the pre-submission discussion. People usually debate minute details on there quite eagerly, and it would provide a contact point and overview for CLC members.

Great idea, yes! Would you care to propose some wording (in a PR updating the template)?

Joachim, there already is a CLC member on the SC!

oh, of course. Sorry, Moritz! Then the question, put bluntly, becomes: Moritz, would you be willing to represent the CLC’s interests in the GHC proposal? (It’s ok to say “no”, we can try to share that responsibility, or try to find someone to fill that role.) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

This protocol is tricky to get right. But I think that the ideas sketched in Section 6.1 come close. (For completeness, here is the current draft plan.) https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos... First, we should make explicit in every proposal what library changes (if any) there are, and to which libraries. All by itself that will be helpful. Second. the ghc-experimental library provides authors with more options than we had in the past: - They can propose changes to base, and accept the additional constraints of discussing with the CLC; including any changes that subsequently prove to be necessary or desirable - Or, in many cases, they can deliver their proposal through ghc-experimental, which CLC is quite content for the GHC CS to curate. Third, we envisage that the shepherd will explicitly invite the CLC to express a non-binding opinion about any proposal modifying base. That greatly lessens the risk of a proposal being accepted that the CLC is unhappy with. No one wins if that happens! The "non-binding" bit is important: the devil is sometimes in the details. But remember that acceptance of a GHC proposal is *also* non-binding. We explicitly say that if the implementation adds too much complexity, or shows up new issues that were not discussed when the proposal was accepted, then we may not land it. Acceptance is a decision in principle. (Side note. I don't think we should be legalistic about this, but if CLC does not voice any objection to changes to base explicitly called out in the proposal, then it would be very unusual for them to subsequently reject outright a CLC proposal to implement those same changes. Let's jump that bridge if we come to it; I don't think we will!) So fourth, the protocol does envisage that, as part of the implementation process, the implementor will make a CLC proposal. It should be no more than a copy/paste of the relevant section from the proposal, but it'll be at the point of "I firmly intend to implement this proposal, so it is worth requesting CLC bandwidth to discuss the detailed specifics of the API changes". This all makes sense to me. I hope it does to you all, as members of the GHC SC. Please say if not. I'm keen to get this tied up so we can publicise it. I would be happy to elaborate Section 6.1, to make it more clear and specific, if anyone has some draft text they would like to propose. Simon On Sun, 9 Jul 2023 at 05:53, Vladislav wrote:

This proposal has just popped up in another discussion, and its implications dawned on me.

I see two major issues with the proposal in its current form:

1. Proposal authors shouldn't need to interact with two committees instead of one. It is generally fine to have coordination between committees, so I can imagine a system where GHC SC cannot approve a proposal on its own and must contact CLC when a proposal touches base. Proposal authors mustn't be bothered with the intricacies of this process, they need to write a single document, submit it on a single platform, and then either have it accepted or rejected, whether by GHC SC alone or by a joint GHC SC + CLC committee.

2. Proposal implementors need a single source of truth for the accepted changes. If the proposal document has been marked accepted, it means that it's ready for implementation. Now, I have no problem whatsoever with involving CLC before a proposal is accepted, but once it's done, it's done. It's quite important to be able to point potential contributors to a document that describes the changes we want to see in GHC and its libraries, and it can't be that parts of this document are actually accepted and parts of it are kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending.

So I agree with the general idea that it's important to get CLC involved, but for the sake of proposal authors and proposal implementors, this should be a committee-to-committee interaction, not a person-to-two-committees interaction; and acceptance of a proposal needs to be a single atomic operation instead of having kind-of-accepted documents floating around in the ghc-proposals repo.

Vlad

On jeu., juin 29 2023 at 09:49:09 +01:00:00, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

make the GHC proposal in conjunction with a CLC proposal and land them

...

in GHC together. Streamlining this process would be good

That is absolutely an option, yes.

Simon

On Thu, 29 Jun 2023 at 08:27, Simon Marlow wrote:

...

The link in the email is broken BTW, is there any updated URL?

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?

Cheers Simon

On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note

1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out

- What new types and functions it defines - What existing types and functions are changed.

We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Dear GHC steering committee I didn't get any further feedback, so I declare the support of the GHC steering committee for the base-library plan https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos... . The CLC and HF technical working group both voted in favour, so it has now been merged in the HF TWG repository. Onward and upward! Simon On Mon, 10 Jul 2023 at 23:05, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

Dear Ghc-Steering-Committee

Any further views about the base-library plan https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...?

We have Torsten's helpful patch https://github.com/ghc-proposals/ghc-proposals/pull/602to our GHC Proposal template. Any views about that?

RSVP. If you want to see any changes, can you offer concrete text that you'd prefer to see?

I'd like to indicate our assent as a committee -- but only if we are all happy! CLC is voting in favour -- I expect a result in a day or two.

RSVP. I'll take silence as assent by say Thursday. Yell if you need more time.

Simon

On Thu, 15 Jun 2023 at 10:03, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

Dear GHC Steering Committee

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.

We now have a fairly well fleshed out proposal here. https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/propos...

I hope you like it. As far as this committee is concerned there are two particular points of note

1. We propose a new package, *ghc-experimental*, which depends on *base*. Many GHC proposals involve defining new types and functions. The idea is that these would initially be in *ghc-experimental*. After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to *base*, which has much stronger stability guarantees. 2. Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage. Some involve *changing *existing types and functions. It is clearly unproductive for us to debate such things at length, and only *then *to land it on the CLC.

Section 5.1 also suggests that proposals should explicitly (in a separate section) call out

- What new types and functions it defines - What existing types and functions are changed.

We should add that to our template.

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.

So, any views? Personally I think this is a Big Step Forward.

Simon