[ghc-steering-committee] Base library organisation

[Moritz Angermann]

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 <arnaud.spiwack at tweag.io>
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 <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.
> _______________________________________________
> 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/20230627/8e409ea0/attachment.html>