[ghc-steering-committee] Base library organisation

[Arnaud Spiwack]

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 <chris at chrisdornan.com> wrote:

> Really, all LGTM!
>
> On 19 Jun 2023, at 22:10, Simon Peyton Jones <simon.peytonjones at 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 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
>


-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230627/7468cda4/attachment-0001.html>