[ghc-steering-committee] Base library organisation

[Vladislav]

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 at 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 <marlowsd at gmail.com 
> <mailto:marlowsd at 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 
>> <simon.peytonjones at gmail.com <mailto:simon.peytonjones at 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/proposals/accepted/050-ghc-base-libraries.rst>
>>> 
>>> 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 at haskell.org 
>>> <mailto:ghc-steering-committee at haskell.org>
>>> <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230709/3b8b09c7/attachment.html>