CLC: Status of **ALL** proposals

Core Libraries Committee
#1

A couple of weeks ago, I started the initiative to track the progress of all approved proposals in the new CLC process, and I’d like to share the final results.

You can see an example of my tracked progress in the following comment:

All CLC work is done by volunteers in their free time.

Stats

Let’s jump directly to stats without wasting any more time!

Total

At the moment of writing this post, haskell/core-libraries-committee has 22 open and 111 closed proposals.

Of those 111 closed ones:

:white_check_mark: 50 approved (45%)
:arrow_down_small: 26 withdrawn (23%)
:globe_with_meridians: 10 meta (9%)
:desert: 8 abandoned (7%)
:no_entry_sign: 6 declined (5%)
:dart: 7 out of scope (6%)
:zzz: 2 dormant (2%)
:books: 2 core libraries (2%)

Approved

I mostly focused on approved proposals to see which version of base implements the proposal, whether there’s an entry in the changelog, and, most importantly, if the proposal was implemented at all.

I don’t want CLC to end in a situation where we have a huge number of approved and not implemented proposals (although, it’s still possible due to the OSS nature and mostly voluntary effort).

Of all 50 approved proposals,

  • 42 are actually implemented and either already released or will be released with the new version of base :partying_face:
  • 8 proposals have either open Merge Requests or no MR at all (see the next section for more details)

Besides, I was interested to see where each implemented proposal goes. As the result, the following versions of base implement:

  • base-4.16 (GHC 9.2): 1 proposal
  • base-4.17 (GHC 9.4): 11 proposals
  • base-4.18 (GHC 9.6): 22 proposals
  • base-4.19 (GHC 9.8): 8 proposals

Need help! Call for volunteers! :loudspeaker:

Some CLC proposals have documentation mistakes, are blocked by GHC issues, or are not implemented at all. In this section, I’d like to list all these proposals with additional context and ask volunteers for their help! :pray:

Some problems are low-hanging fruits like “missing changelog entry” while others require significant patches to GHC.

  1. Proposal: Remove method (/=) from class Eq · Issue #3 · haskell/core-libraries-committee · GitHub
    • The implementation is blocked by performance regression and needs changes to GHC first
  2. stimes for Endo · Issue #4 · haskell/core-libraries-committee · GitHub
    • Another MR with refactoring needs to be merged first, so the original MR contains only relevant CLC-approved changes
  3. Improve mtimesDefault implementation · Issue #11 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  4. Problem: foldr' has a terribly bad default implementation · Issue #20 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  5. Clarify laws of TestEquality · Issue #21 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  6. Clarify the situation around Data.List · Issue #22 · haskell/core-libraries-committee · GitHub
    • The proposal is about making all functions in Data.List work with [a] instead of Foldable f => f a
    • It was approved long before the current CLC but turned out to break a lot of things
    • It’s blocked by the implementation of the corresponding compatibility warning in GHC
  7. Expand Ord instance for Down · Issue #23 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  8. Add functions traceWith, traceShowWith to Debug.Trace · Issue #36 · haskell/core-libraries-committee · GitHub
  9. Remove default method from Bitraversable · Issue #47 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  10. Make `GHC.Stack.Types.SrcLoc` more strict · Issue #55 · haskell/core-libraries-committee · GitHub
    • The change is approved but it resulted in a performance regression
  11. Add/document laws for `toInteger` and `toRational` · Issue #58 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  12. Make `Data.List.permutations` return a `NonEmpty`? · Issue #68 · haskell/core-libraries-committee · GitHub
    • The MR is open but the author didn’t have the capacity to finish it so far
  13. Add {-# WARNING #-} to Data.List.{head,tail} · Issue #87 · haskell/core-libraries-committee · GitHub
    • The issue was blocked by another CLC proposal and not-implemented but required GHC issue. Everything seem in place and on time for base-4.19 now though.
  14. Change `stimes @Void n x` to be `x` · Issue #95 · haskell/core-libraries-committee · GitHub
    • Changelog entry is missing
  15. Design for dataToTag# · Issue #104 · haskell/core-libraries-committee · GitHub
    • The MR is open but not merged. It’s not clear what’s blocking it atm.
  16. Add `ConstPtr` to Foreign.C.Types · Issue #118 · haskell/core-libraries-committee · GitHub
    • Mistake in a changelog entry (link to a wrong CLC proposal)
  17. Add laws for the Exception class · Issue #135 · haskell/core-libraries-committee · GitHub
    • The proposal is not implemented
24 Likes
CLC Update (April 2023)
#2

Kudos for churning through the proposals and collecting that information, that’s a serious amount of work.

42/50 implemented is really good!

If someone feels inspired, I’d love to see someone keeping tabs on accepted GHC proposals and track their progress towards implementation.
:slight_smile:

4 Likes
#3

Given that an implementation is a prerequisite for a vote, I find this ratio not good.

It means CLC needs to do a better job at determining how complete and feasible an MR is prior to voting. I don’t think it should vote on draft MRs (note that CLC often gives non-binding opinions prior to implementations).

3 Likes
#4

I doubt that that’s reasonable. There is a big difference between “showing something can be done and assess breakage” (which should be sufficient to give the CLC the data it needs to decide) and “fully polished implementation with all documentation and test suite adjustments etc. done”.

Requiring the latter before a vote, which can be negative, is not considerate of proposer’s time and I expect will rightfully scare away contributors. So unless the goal is explicitly to be more gatekeepery and make change harder, this does not seem helpful.

2 Likes
#5

The CLC can and does give non-binding opinions prior to implementations.

So a proposer can make reasonable decisions about how much time they want to invest.

When a vote is cast and passes, that also means the proposal is accepted. I don’t think it’s reasonable to accept proposals where the implementation is in flux. It’s bad form and can have unexpected consequences.

I don’t think that scares anyone away. base should have high quality standards. It’s not a place to come up with half finished ideas.

3 Likes
#6

It depends. Half-jokingly, the most popular reason why MRs get stuck is a merge conflict in changelog. The second most popular is flaky GHC CI.

1 Like
#7

A fully-formed patch also requires time and energy from the maintainers of the affected package(s), so they should at least be included in any decision to make such a thing a requirement.

This is probably an argument in favor of split base happening first, since (I hope) that reduces the scope of any such patch.

But anyway, best of all is to just take things one step at a time. Don’t be slaves to process. I say this a somebody who often falls into that very trap. If it turns out a mistake has been made accepting a proposal that causes too much breakage, deal with it responsibly. Automate what can be automated, and don’t automate what can’t.

1 Like