September 2021 - Libraries

status of mtl
by Ben Franksen 30 Sep '21

30 Sep '21

I wanted to use the CPS version of RWST from transformers but the latest release of mtl (2.2.2) does not provide instances yet. Looking at the github repo I see that the missing instances were added two years ago, with no release since then. With all due respect to the maintainers and developers, this is disappointing. The ticket for release 2.3 mentions the following TODO items: - Document AccumT and SelectT - MonadAccum (including documentation) - MonadSelect (including documentation) These all concern new additions made in the last two years, some of them quite recent. This style of package maintenance doesn't make sense to me. Why add new features before releasing what's been done years ago? Why accept patches with additional features in the mainline if they are apparently incomplete (e.g. missing documentation) if that blocks progress toward a release? The obvious solution (need i spell it out?) is to move all new features that aren't mature yet to feature branches until they are ready for the mainline. Then take the work that is complete and release that. What's the big deal? Add a few lines to the changelog, bump the version number, upload, announce it on the mailing list. If you don't like to rebase the master branch, fork off a release branch at the appropriate point in the history and do the release on that branch, cherry-picking later patches from master as necessary. (Maintaining a release branch per major version bump is good practice anyway and requires only minimal extra work.) Don't fall into the trap of the perfect becoming the enemy of the good. No release is perfect, nor does it have to be. You can always make patch releases. If you make a mistake and the release is broken, just mark it as such on hackage, so cabal won't pick it by default. Needless to say, none of this is in any way new or original. Cheers Ben -- I would rather have questions that cannot be answered, than answers that cannot be questioned. -- Richard Feynman

4 6

[ANN] CLC Elections Outcome - September 2021
by Emily Pillmore 29 Sep '21

29 Sep '21

Hello Haskell! I'm pleased to announce that the Core Libraries Committee Elections for September 2021 have concluded, and we have selected 2 new CLC members: - [Andrew Lelechenko]( https://github.com/Bodigrim ) - [Melanie Brown]( https://github.com/bi-functor ) The candidate pool was especially broad for this election and it was very difficult to choose, but we'd like to thank everyone for applying nonetheless. It is genuinely heartwarming to see so many people eager to help support the Haskell ecosystem in an official capacity! We encourage any and all candidates to continue helping to support the core libraries as we renovate the CLC. As mentioned in the latest CLC update (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we are set to begin writing a new process and ways of working for the CLC now that the elections have concluded. We aim to have these finished within the month. Happy Hacking! Emily Pillmore - on behalf of the CLC

1 0

Benchmarks making significant use of IntMap
by Callan McGill 17 Sep '21

17 Sep '21

Dear all, I am trying to investigate a recent change we would like to make to `lookup` in IntMap. I wanted to know if any of you had any examples of open source projects that make significant use of IntMap and have benchmarks or performance tests we could run to make sure this change does not introduce significant regressions. Best, Callan

2 2

[ANN] Core Libraries Committee Elections
by Emily Pillmore 13 Sep '21

13 Sep '21

Dear Haskell Community, The Core Libraries Committee is seeking new members! As detailed in recent updates (see: https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat… ), we put out an internal call to discuss restructuring the CLC to better meet the needs of the community. In particular, we are in the planning stages of writing the new process, and are seeking **2** new members who, as part of their standard CLC duties, get to participate in its construction. ## Who should apply? Anyone who meets the following criteria should apply: 1. Candidates should have enough bandwidth to review merge requests to `base` on a semi-frequent basis (2 to 3 per month), and *sustain* this for their term in a healthy manner. 2. Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the new Github-based CLC process on a semi-frequent basis (2 to 3 per month). 3. Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. 4. Candidates should be productive, and be able to follow through on merge requests and conversations to their completion in a diligent and timely manner. We encourage any and all who satisfy these requirements to apply. Please note that we are not looking for the biggest galaxy brain in the room - quite the opposite. We are looking for productive, motivated individuals who want to help support the ecosystem that we love. As such, we hope to build a broad sample of the community. This election is particularly special due to the fact that our new members will have the chance to help shape process for new generations of the CLC to come, and can take ownership from the ground up so to speak. This means that we can help shape a process that works better for us as modern Haskell developers, and help the CLC become a better fit for the community's needs. ## How can I apply? To apply for one of these positions, send an email to the CLC email address ( core-libraries-committee(a)haskell.org ) that consists of the following data: 1. The header "CLC Election September 2021 - <your name>" 2. Why you think you're a good fit given the above criteria 3. If applicable, please point us to some code you've written ## When will elections be decided? Please note the following dates: 1. Election submissions open: Sept 13 2. Election submissions close: Sept 20 3. Election outcome announced: Sept 27 Cheers, Emily - on behalf of the CLC

1 0

Is it possible to update hackage base-4.16.0.0 Data.Foldable HTML?
by Viktor Dukhovni 13 Sep '21

13 Sep '21

The Data.Foldable documentation included with the GHC 9.0 release used a newish haddock syntax `someFunction'` rather than the more traditional 'someFunction''. It turned out that the former was not supported by the version of haddock that builds the "hackage" docs. Thus, in https://hackage.haskell.org/package/base-4.15.0.0/docs/Data-Foldable.html#g… various references to `foldl'` and `foldMap'` are rendered as "foldl`" and "foldMap`" and rather unfortunately hyperlink to the "bare" 'foldl' and 'foldMap' respectively. The non-portable haddock syntax was replaced in a later MR, but the online documentation has not been regenerated since. Is there a mechanism to have the documentation regenerated to read as intended? Either by running a more recent haddock (that supports the new `someFunction'` syntax) or by using a patched Data.Foldable that differs from the 9.0.1 release only in addressing documentation nits? I can build and provide a replacement pre-compiled HTML file if that's the simplest way forward... -- Viktor.

2 1