February 2021 - Libraries

Fwd: New Libraries Proposal process
by Carter Schonwald 01 Jul '21

01 Jul '21

Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. Merry Friday and be well -Carter ---------- Forwarded message --------- From: chessai <chessai1996(a)gmail.com> Date: Fri, Sep 11, 2020 at 10:02 PM Subject: Re: New Libraries Proposal process To: Carter Schonwald <carter.schonwald(a)gmail.com> This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately. > All libraries process needs to start on the libraries mailing list Not anymore. The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise. This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution. Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries. On Fri, Sep 11, 2020, 19:52 Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > Where was this discussed or proposed? All libraries process needs to start > on the libraries mailing list. And soemtimes Perhaps moving to clc list for > resolving tie breaking on controversial choices. > > The libraries archive goes back pretty far and email threading seems to > scale far better for participating in complex discussions than does githubs > comment collapsing on large discussions. > > On Fri, Sep 11, 2020 at 3:20 PM chessai <chessai1996(a)gmail.com> wrote: > >> All, >> >> >> There is a new Libraries Proposal process, inspired by the GHC Proposals >> process. >> >> Core Library APIs are critical. It's easy for a sensible proposal to >> languish or simply get dropped on the floor; and (in the other direction) a >> bit too easy for a proposal to make it into the core libraries without >> receiving the scrutiny it deserves. Most of the proposals that have been >> made on this mailing list, become lost to the archives. It's not easy for >> anyone to answer the question "what decisions has the CLC made recently?" >> without trawling a huge email archive. >> >> Of course, this is mostly for breaking changes or "big" introductions; we >> don't need a full proposal over something tiny, e.g. "a module from vector >> is missing a fold". That would be more appropriate on vector's issue >> tracker, and left to the maintainers to deal with. >> >> I encourage anyone interested to get started by reading the README at >> https://github.com/haskell-core/core-libraries-proposals. >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > >

10 13

New Libraries Proposal process
by chessai 01 Jul '21

01 Jul '21

All, There is a new Libraries Proposal process, inspired by the GHC Proposals process. Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with. I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.

5 7

Proposal: export more Data.Sequence internals
by David Feuer 16 Mar '21

16 Mar '21

I'd like containers to export more Data.Sequence internals, and to do so in a way that allows external users to rely on them. I propose the following: 1. Add a module, Data.FingerTree.IntPlus, abstractly exporting the finger trees used to represent sequences. These can also be used for other finger trees with measurements in the (Int, +) monoid. This would include various basic operations for cons, snoc, and splitting, with most names the same as for sequences. 2. Add a module, Data.FingerTree.IntPlus.Unsafe, exporting efficient mapping/traversing functions that rely on specific preconditions to maintain the internal fingertree annotation invariant. 3. Add a module, Data.Sequence.StableInternal, exporting the internal structure of sequences and also some internal functions that may be useful elsewhere (I'm particularly interested in the `splitMap` function and future variants thereof). Unlike the `.Internal` module, this module would be subject to the package version policy, and would therefore be more suitable for use by other packages. I am very open to suggestions for modifications to the module names. One option might be to put all the FingerTree.IntPlus stuff in the Data.Sequence.StableInternal hierarchy, if folks think it should be buried a bit. David

5 5

Proposal: Add 'Foldable1' to base
by Reed Mullanix 22 Feb '21

22 Feb '21

With the recent discussion around the addition of 'intersection' to containers, I think it might be a good time to re-open the discussion surrounding adding 'Foldable1' to base. For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts folds over non-empty containers. Alternatively, it can be seen as a method of combining together the elements of a container using a semigroup. The contents of this class have been discussed previously (See [1,2]), and the version presented in this proposal is taken from [1]. class Foldable t => Foldable1 t where {-# MINIMAL foldMap1 | foldr1map #-} fold1 :: Semigroup m => t m -> m -- the defining member, like foldMap but only asking for Semigroup foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- strict foldMap1, cf foldMap' foldMap1' :: Semigroup m => (a -> m) -> t a -> m -- analogue of toList toNonEmpty :: t a -> NonEmpty a -- left&right, strict&non-strict folds foldr1 :: (a -> a -> a) -> t a -> a foldr1' :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a foldl1' :: (a -> a -> a) -> t a -> a -- these can have efficient implementation for NonEmptySet maximum1 :: Ord a => t a -> a minimum1 :: Ord a => t a -> a -- head1 have efficient implementation for NonEmpty and Tree -- last1 for symmetry head1 :: t a -> a last1 :: t a -> a -- fold variants with premap. -- Without this map, we cannot implement foldl using foldr etc. foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b This has a couple of benefits. On the practical side, we can provide total alternatives to existing partial functions (IE: 'foldr1' and friends). It also enables us to fold over containers using a semigroup instance, which comes up suprisingly often. Naming: -------------------------------------------------------------------------------- Historically, the biggest source of controversy with this proposal has been over the name. The class currently exists in semigroupoids [3] under the name 'Foldable1', though there was some discussion around renaming it to 'SemiFoldable' [4]. However, if we keep the name unchanged, it makes the migration path nice and straightforward, and the possible name conflict with Data.Functor.Classes seems unlikely. Migration: -------------------------------------------------------------------------------- If we decide to go with 'Foldable1' as the name, we should be able to perform this change with 0 breakage. References: [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup… [4] https://github.com/ekmett/semigroupoids/issues/26

7 7

Text and changing number primops in GHC 9.2
by John Ericson 18 Feb '21

18 Feb '21

Hi all, First, background. I have a PR https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492 <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4492> that is one of the moving pieces for https://gitlab.haskell.org/ghc/ghc/-/issues/19026 <https://gitlab.haskell.org/ghc/ghc/-/issues/19026>, which is slated for 9.2 according to Ben's email https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html <https://mail.haskell.org/pipermail/ghc-devs/2021-February/019478.html>. (I just added the milestone to the issue to reflect this.) Despite this being a breaking change (to unstable interfaces) containers, bytestring, and binary could all updated in a way that didn't used CPP. (See the linked PRs in the GHC !4492's description). Text is a different case, because the unboxed computation there is more pervasive. The current PR is https://github.com/haskell/text/pull/305 <https://github.com/haskell/text/pull/305>, and uses CPP for 9.2. We have a few different options: * Keep as is. There will surely be no perf regressions this way on any of the supported compilers. This does however mean adding CPP for 9.2 before the associated GHC change lands in master. I think that's fine---inevitable even based on the current policy for how GHC submodules are bumped---but it's given many library maintainers the heebie jeebies. * Try the same tricks in the other PRs of using hyper-local unboxing that is easy to unbox away. This will be a bit ugly however than the other cases, and I am not sure whether it won't be a regression for the oldest supported GHCs. * Do the above, but bump the base version to the point where there are no perf regressions with the oldest supported GHCs (because those compilers are no longer supported). If we bump the version more aggressively, perhaps we can get rid of much of the unboxing altogether / otherwise get rid of the ugliness. We'll need to reach some sort of decision here to move forward. I'll also add that while Oleg Grenrus has helped merge a preparatory PR, Oleg expressed a /dis/interest in being de facto text maintainer, so I am emailing the list in part so this does not fall upon Oleg alone any longer. John

3 4

Proposal: Expanding the CLC
by Emily Pillmore 17 Feb '21

17 Feb '21

Hi All, Over the past year, two things have become increasingly clear to me as I've carried out my CLC duties: 1. The CLC is under-resourced. This is evidenced by the fact that several maintainers who are not CLC members have been forced to step up to help take on some of the maintenance burden for many of the CLC libraries. Namely, `vector`, `bytestring`, `random`, `unix`, and more. The current CLC head count is not enough to dedicate at least one maintainer per package, which is leading to us all being spread thin, and the less-loved packages are falling into disrepair as a result. Couple this with the fact that roughly half the CLC do not have these packages actively within their maintenance cycles, and we arrive at the current problem. 2. The current set of "core" libraries does not cover what is generally considered "core" in the community. From now on, I'll refer to "core" packages as "boot" packages, and identify core packages to be those that are have proven to be incredibly popular tools for building things in Haskell. For example `zlib`, `parsec`, `regex-base`, `regex-posix`, `network`, etc. In particular, if any of these core packages saw their current authors disappear, or incapacitated in any sense, it would seriously harm the Haskell ecosystem. `cabal-install`, for example, requires several of those packages as upstream dependencies. Currently, we are dealing with this nightmare situation where work is stalled across many packages due to a particular set of maintainers being very difficult to reach, one of whom having disappeared completely for all maintenance intents and purposes. Ergo, we have a problem. Thankfully, many people have stepped up showing renewed interest in maintaining such packages with the latest crop of CLC folks, and this poses an interesting opportunity. My proposal is this: 1. We expand the CLC from 9 members to 22 members such that we have at least 1 CLC maintainer per boot package. There are a large number of fantastic candidates already available, who would be perfect for the role. In fact, many of the candidates whom we would ask are already maintaining these packages. In particular, Andrew Lelechenko, Simon Jakobi, Viktor Dukhovni, Dominic Steinitz, Alexey Khuedyakov are already serving within this role (and thank you for it!). Andreas Abel has also offered to help take on one of the core packages. 2. We consider a dedicated "Haskell Action Team" (name and idea courtesy of Carter Schonwald) to oversee packages in the Haskell github repo that can act as supplementary maintainers for many of the core packages contained therein. Currently, there are many in need of help. `zlib` comes to mind, which is currently blocking `bytestring-0.11` migration work due to having no available maintainer with the permissions to do a release. This, in turn, is stalling `cabal-install`. Short of taking over the package, we would have to ask for an emergency Hackage release if the neither maintainer shows up to do it in a reasonable time frame. This is just one step towards helping ease the burden of maintenance of so-called core and boot packages. I hope you agree that this is a good idea, and if we get enough thumbs up, then Chessai and I will draw up the necessary changes to the CLC remit and we'll get started! Cheers, Emily

11 15

Takeover / Comaintainership of Selda
by Thomas DuBuisson 17 Feb '21

17 Feb '21

I ask to take comaintainership of the four selda-* packages on hackage. While Anton was active months ago there are fixes that have languished for three weeks. I haven't heard from Anton in over a month, including on my offer to co-maintain a couple weeks back. It isn't my intent to full take over, just help maintain. My first points of action would be: - Merge the three most recent PRs of two critical bug fixes and a clean up. These would have to go on my own fork for the time being. - Release I know 3 weeks is short in the Haskell world for a package takeover. I only want to co-maintain and am ready to wait a while after sending this message in to see if Anton (CCed) awakens. -Tom

5 5

Re: Takeover of hashable and uuid & uuid-types packages
by Oleg Grenrus 16 Feb '21

16 Feb '21

github.com/haskell is fine too. I have uneasy feeling about its current "chaotic good" management model though, but I can live with it. OTOH, you can simply bother me about any package in haskellari org. Clear and simple. - Oleg On 16.2.2021 17.56, Johan Tibell wrote: > I'm not involved anymore so it's fine by me but why > not https://github.com/haskell? > > On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus <oleg.grenrus(a)iki.fi > <mailto:oleg.grenrus@iki.fi>> wrote: > > I ask to take over the maintenance of hashable, uuid and uuid-types > packages. > > I'm a maintainer of packages depending on them (most notably > quickcheck-instances and aeson). > > I should also mention that when we (Herbert and I) took over Antoine > Latter's packages, I took over quickcheck-instances and Herbert took > over uuid and parsec. We should taken over together in the first > place. > > My first points of action would be: > - make a releases supporting latest versions of dependencies (GHC-9.0, > bytestring-0.11) and > - move packages to https://github.com/haskellari organization, so in > case of my absence there are people (Ryan Scott, bodigrim, few others) > who will be able to act. > > Best regards, > Oleg >

5 7

Re: Takeover of hashable and uuid & uuid-types packages
by Oleg Grenrus 16 Feb '21

16 Feb '21

Thank you Johan. Could you add me as maintainer on Hackage as well, my username is phadej there as well. Cheers, Oleg. On 16.2.2021 18.59, Johan Tibell wrote: > Done. > > On Tue, Feb 16, 2021 at 5:54 PM Simon Jakobi > <simon.jakobi(a)googlemail.com <mailto:simon.jakobi@googlemail.com>> wrote: > > Sounds reasonable to me! > > Am Di., 16. Feb. 2021 um 17:42 Uhr schrieb Oleg Grenrus > <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>>: > > I don't disagree. Having hashable live next to > unordered-containers in > https://github.com/haskell-unordered-containers would be fine > too, if you, David, agree with that. > > - Oleg > > On 16.2.2021 18.37, David Feuer wrote: >> My general view is that it's best for each package (or >> closely allied family of packages) to have its own GitHub >> organization. >> >> On Tue, Feb 16, 2021, 11:27 AM Oleg Grenrus >> <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>> wrote: >> >> github.com/haskell <http://github.com/haskell> is fine >> too. I have uneasy feeling about its current "chaotic >> good" management model though, but I can live with it. >> >> OTOH, you can simply bother me about any package in >> haskellari org. Clear and simple. >> >> - Oleg >> >> On 16.2.2021 17.56, Johan Tibell wrote: >>> I'm not involved anymore so it's fine by me but why >>> not https://github.com/haskell? >>> >>> On Tue, Feb 16, 2021 at 4:26 PM Oleg Grenrus >>> <oleg.grenrus(a)iki.fi <mailto:oleg.grenrus@iki.fi>> wrote: >>> >>> I ask to take over the maintenance of hashable, uuid >>> and uuid-types >>> packages. >>> >>> I'm a maintainer of packages depending on them (most >>> notably >>> quickcheck-instances and aeson). >>> >>> I should also mention that when we (Herbert and I) >>> took over Antoine >>> Latter's packages, I took over quickcheck-instances >>> and Herbert took >>> over uuid and parsec. We should taken over together >>> in the first place. >>> >>> My first points of action would be: >>> - make a releases supporting latest versions of >>> dependencies (GHC-9.0, >>> bytestring-0.11) and >>> - move packages to https://github.com/haskellari >>> organization, so in >>> case of my absence there are people (Ryan Scott, >>> bodigrim, few others) >>> who will be able to act. >>> >>> Best regards, >>> Oleg >>> >> _______________________________________________ >> Libraries mailing list >> Libraries(a)haskell.org <mailto:Libraries@haskell.org> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org <mailto:Libraries@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

[ANN] bytestring-0.11.1.0
by Andrew Lelechenko 16 Feb '21

16 Feb '21

On behalf of maintainers I'm happy to announce that bytestring-0.11.1.0 (http://hackage.haskell.org/package/bytestring-0.11.1.0) is finally released. Highlights from the changelog (https://github.com/haskell/bytestring/blob/0.11.1.0/Changelog.md) * Performance improvements for * strict `map` (up to 30% faster), * strict `pack`, `words`, `intersperse`, `findIndex` and `findIndexEnd`, * lazy `takeWhile`, `dropWhile`, `break`, `group` and `groupBy`, * strict and lazy `stimes`. * New functions: * `compareLength` to compare lengths lazily, * `packZipWith` to zip two `ByteString`, * `findIndexEnd` for `Char8` flavours of `ByteString`, * `elemIndexEnd` and `unzip` for `Data.ByteString.Lazy.Char8`, * `takeEnd` and `dropEnd` for strict `ByteString`. * Improvements for `ShortByteString` * `SBS` constructor is now exposed directly from `Data.ByteString.Short`, * `fromShort` does not reallocate its argument, if it is already pinned. Many people contributed their time and effort to make this release happen. Just to name a few in no particular order, mostly according to `git log`: * Ben Gamari * Callan McGill * Dmitry Ivanov * Eli Kogan-Wang * gutjuri * Jaro Reinders * John Ericson * Moritz Angermann * Simon Jakobi * Sylvain Henry * Viktor Dukhovni * Vincent Orr * me Here is an incantation for `stack` folks: resolver: nightly-2021-02-12 packages: - . extra-deps: - bytestring-0.11.0.0 - binary-0.8.8.0 - directory-1.3.6.1 - text-1.2.4.1 - unix-2.7.2.2 - process-1.6.11.0 allow-newer: true Best regards, Andrew

1 0