Meeting to discuss GHC and the CLC

[Ben Gamari]

Hi CLC Members,

First, thanks for your continued efforts on the CLC and core libraries
maintenance. It is great to see the CLC becoming so active after a
fairly long hiatus.

As you likely know, over the last few months there have been discussions
regarding the scope of the CLC's role in maintaining parts of `base` and
other libraries which GHC has historically considered to "internal
implementation".

I think it would be helpful for all of us if we scheduled a meeting
between a few GHC maintainers and some subset of the CLC to ensure that
all parties are on the same page with respect to these qusetions.
Specifically,

* Pinning down what sorts of interface changes require CLC intervention,
specifically considering changes in the less-obvious areas like
runtime performance and strictness properties

* Considering how GHC might begin migrating interfaces which we have
historically considered to be GHC-internal (e.g. GHC.TopHandler
recently came up) into an area outside of the CLC's purview and how
changes should be handled until that time.

* Determining the role of the CLC in management of auxiliary libraries
like `ghc-bignum`

Would you be able to meet sometime in the next few weeks to discuss
these and other matters?

Cheers,

- Ben

[Andrew Lelechenko]

Hi Ben,

We are on pause at the moment until new members are elected, so let me answer your questions briefly in writing.

> Pinning down what sorts of interface changes require CLC intervention,
> specifically considering changes in the less-obvious areas like
> runtime performance and strictness properties

https://github.com/haskell/core-libraries-committee#base-package is quite unambiguous: "Changes which affect performance or laziness and similar are deemed visible".

> Considering how GHC might begin migrating interfaces which we have
> historically considered to be GHC-internal (e.g. GHC.TopHandler
> recently came up) into an area outside of the CLC's purview and how
> changes should be handled until that time.

Please see https://github.com/haskell/core-libraries-committee/issues/105#issuecomment-1321276349, where I asked GHC developers to nominate modules to be excluded from CLC purview. None were nominated.

> Determining the role of the CLC in management of auxiliary libraries
> like `ghc-bignum`

Are GHC developers unsatisfied with the status quo?

Best regards,
Andrew

[Ben Gamari]

Andrew Lelechenko <andrew.l...@gmail.com> writes:

> Hi Ben,
>
> We are on pause at the moment until new members are elected, so let me
> answer your questions briefly in writing.

Thanks for the quick response, Andrew!

>> Pinning down what sorts of interface changes require CLC intervention,
>> specifically considering changes in the less-obvious areas like
>> runtime performance and strictness properties
>
> https://github.com/haskell/core-libraries-committee#base-package is
> quite unambiguous: "Changes which affect performance or laziness and
> similar are deemed visible".
>
>> Considering how GHC might begin migrating interfaces which we have
>> historically considered to be GHC-internal (e.g. GHC.TopHandler
>> recently came up) into an area outside of the CLC's purview and how
>> changes should be handled until that time.
>
> Please see
> https://github.com/haskell/core-libraries-committee/issues/105#issuecomment-1321276349,
> where I asked GHC developers to nominate modules to be excluded from
> CLC purview. None were nominated.

Apologies, I had not noticed this particular request. I would be happy to
propose a list which would be appropriate for exclusion in the opinion
of GHC's maintainers.

For what it's worth, I generally agree with the proposal to split
`base` into a `ghc-base` package containing implementation and a stable
`base` package containing re-exports. Such a split would both more
clearly signal our stability contract to users and make GHC maintainers'
lives easier. From my perspective, such a split would be preferrable to
the three-tier scheme proposed in #105. This split would even allow us
to preserve the existing interfaces of things like `GHC.Base` while not
wedding GHC to the status quo.

However, making this split a reality this will take time. It would be
useful to discuss how we will manage `base` in the meantime.

>> Determining the role of the CLC in management of auxiliary libraries
>> like `ghc-bignum`
>
> Are GHC developers unsatisfied with the status quo?

Our concern is that the GHC maintainers consider `ghc-bignum` to be an
detail internal to GHC's implementation of `Integer`. As such, we do not
consider the interfaces to be CLC-relevant. We are content with this
situation.

However, until a fairly recently we held a similar position on most of
the `GHC.*` namespace (especially those modules which we explicitly
marked with `Stability: internal` in their Haddock metadata);
consequently, I want to ensure that we communicate on this matter to
avoid further misunderstandings.

Cheers,

- Ben

[Andrew Lelechenko]

However, until a fairly recently we held a similar position on most of
the `GHC.*` namespace (especially those modules which we explicitly
marked with `Stability: internal` in their Haddock metadata);

Ben, both you and Simon were direct recipients of https://groups.google.com/g/haskell-core-libraries/c/hSl5ZBmSgLs/m/ar2peyZWBwAJ, back in 2021. There’ve been no “fairly recent" change of policy. 

Best regards,

Andrew