[ghc-steering-committee] Base library organisation

[Moritz Angermann]

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 <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> 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
>>
>>    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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> 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/20230629/1929bbe9/attachment.html>