August 2021 - Libraries

[Call for reviewers] Switch `text`'s internal representation to UTF-8
by Hécate 28 Aug '21

28 Aug '21

Hello everyone, After tremendous efforts, the pull request to switch `text`'s internal representation to UTF-8 is here, and unsurprisingly this is a titan's work. It lives here: https://github.com/haskell/text/pull/365 We are sending out a call for reviewers, as this is a cornerstone of our ecosystem. The performance gains from this PR are huge and I would like to ensure we can have a multitude of eyes to take a look. I wish to express my thanks to all of you. This is definitely the kind of advances that will make Haskell a stronger language for the times to come. Cheers, Hécate. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Hecate WWW: https://glitchbra.in RUN: BSD

1 0

Re: [ANNOUNCE] GHC 9.2.1-rc1 now available
by David Feuer 23 Aug '21

23 Aug '21

Sorry, I was unclear. I want it re-exported from Data.Tuple, so I don't need to import ghc-prim:GHC.Tuple. I proposed this on the libraries list last year, and the two people who responded agreed. On Sun, Aug 22, 2021, 9:37 PM Viktor Dukhovni <ietf-dane(a)dukhovni.org> wrote: > > On 22 Aug 2021, at 8:14 pm, David Feuer <david.feuer(a)gmail.com> wrote: > > > > One more question: is Solo exported from Data.Tuple yet, or do we still > have to depend on ghc-prim and import it from GHC.Magic? It would be really > nice to have that fixed by release, and it's so tiny. > > The GHC.Tuple modules (from ghc-prim) are identical in the HEAD and ghc-9.2 > branches. With HEAD I see: > > $ ghci > GHCi, version 9.3.20210809: https://www.haskell.org/ghc/ :? for help > Loaded GHCi configuration from /usr/home/viktor/.ghc/ghci.conf > λ> import GHC.Tuple > λ> :info Solo > type Solo :: * -> * > data Solo a = Solo a > -- Defined in ‘GHC.Tuple’ > instance Applicative Solo -- Defined in ‘GHC.Base’ > instance Functor Solo -- Defined in ‘GHC.Base’ > instance Monad Solo -- Defined in ‘GHC.Base’ > instance Monoid a => Monoid (Solo a) -- Defined in ‘GHC.Base’ > instance Semigroup a => Semigroup (Solo a) -- Defined in ‘GHC.Base’ > instance Show a => Show (Solo a) -- Defined in ‘GHC.Show’ > instance Read a => Read (Solo a) -- Defined in ‘GHC.Read’ > instance Foldable Solo -- Defined in ‘Data.Foldable’ > instance Traversable Solo -- Defined in ‘Data.Traversable’ > > -- > Viktor. > >

3 4

Proposal: add generic helpers for MonadZip
by David Feuer 22 Aug '21

22 Aug '21

We can offer generic helpers for writing MonadZip instances: genericmzipWith :: (Generic1 m, GMonadZip (Rep1 m)) => (a -> b -> c) -> m a -> m b -> m c genericmzipWith f m n = to1 $ gmzipWith f (from1 m) (from1 n) genericmunzip :: (Generic1 m, GMonadZip (Rep1 m)) => m (a, b) -> (m a, m b) genericmunzip m = case gmunzip (from1 m) of (r1, r2) -> (to1 r1, to1 r2) These can be used with appropriate product types (there's no way to zip sums generically). I propose adding these to Control.Monad.Zip. The GMonadZip class and its instances are below. class GMonadZip f where gmzipWith :: (a -> b -> c) -> f a -> f b -> f c gmunzip :: f (a, b) -> (f a, f b) instance MonadZip f => GMonadZip (Rec1 f) where gmzipWith f (Rec1 fa) (Rec1 fb) = Rec1 (mzipWith f fa fb) gmunzip (Rec1 fab) = (Rec1 fa, Rec1 fb) where -- We want to be lazy here, because this might actually -- be recursive. We do a lot of NOINLINE to get selector -- thunks to avoid space leaks. {-# NOINLINE mufab #-} {-# NOINLINE fa #-} {-# NOINLINE fb #-} mufab = munzip fab (fa, fb) = mufab instance (Functor g, MonadZip f, GMonadZip g) => GMonadZip (f :.: g) where gmzipWith f (Comp1 fga1) (Comp1 fga2) = Comp1 $ mzipWith (gmzipWith f) fga1 fga2 gmunzip (Comp1 fgc) = case munzip . fmap gmunzip $ fgc of (p, q) -> (Comp1 p, Comp1 q) -- | @since 4.9.0.0 instance GMonadZip U1 where gmzipWith _ _ _ = U1 gmunzip _ = (U1, U1) -- | @since 4.9.0.0 instance GMonadZip Par1 where gmzipWith = coerce gmunzip = coerce -- | @since 4.9.0.0 deriving instance GMonadZip f => GMonadZip (M1 i c f) -- | @since 4.9.0.0 instance (GMonadZip f, GMonadZip g) => GMonadZip (f :*: g) where gmzipWith f (x1 :*: y1) (x2 :*: y2) = gmzipWith f x1 x2 :*: gmzipWith f y1 y2 -- Why don't we need to be lazy in this munzip? If we're working with -- Rep1, then laziness will be added by the Rec1 instance. If we're working -- with Rep, then we can't have any K1s because K1 isn't an instance of -- Monad, let alone MonadZip! gmunzip (fab :*: gab) | (fa, fb) <- gmunzip fab , (ga, gb) <- gmunzip gab = (fa :*: ga, fb :*: gb)

1 1

FYI
by Carter Schonwald 20 Aug '21

20 Aug '21

This seems to have not been passed along to this yet … https://discourse.haskell.org/t/state-of-the-core-libraries-committee-updat…

1 0

readline library
by Samuel 17 Aug '21

17 Aug '21

Hi, The readline library sets libraries(a)haskell.org as maintainer, so trying to find if anyone is maintaining it in this list. http://hackage.haskell.org/package/readline-1.0.3.0 The library doesn't build properly with Cabal 3, though its cabal file doesn't limit it to Cabal 2. That makes it fail to build in the latest nix packages release. You can see the details in this pull request: https://github.com/NixOS/nixpkgs/pull/111985. This patch seems to be enough to make the library compile again, but I haven't found anywhere to submit it to fix the library code itself. At the moment the patch lives in the nixpkgs repository: https://github.com/samuelrivas/nixpkgs/blob/30eec30626bd7b8c592dab572e74443… Is there any upstream copy of the readline library where I can pull request this patch? Thanks! -- Samuel

2 1

Moving the abstract filepath proposal forward
by Julian Ospald 17 Aug '21

17 Aug '21

Hi, as was discussed some time ago, I'd like to move the AFPP forward: https://discourse.haskell.org/t/reviving-the-abstract-filepath-proposal-afp… If you need a refresher on the original proposal, have a look here: https://gitlab.haskell.org/ghc/ghc/-/wikis/proposal/abstract-file-path The idea was to implement it in user-space first. I think I have now assembled a version that should withstand initial review: * code: https://github.com/hasufell/abstract-filepath * rendered docs: https://files.hasufell.de/jule/abstract-filepath/ What changed wrt the original proposal is this: 1. created a `OsString` newtype and `AbstractFilePath` is just a type synonym to it (this is somewhat similar to how rust does it... filepaths are not the only thing that syscalls expect in UTF16 on windows) 2. added `OsWord` as well The types are all here: * https://files.hasufell.de/jule/abstract-filepath/AFP-OsString-Internal-Type… * https://files.hasufell.de/jule/abstract-filepath/AFP-AbstractFilePath-Inter… How to move forward? 1. get actual code reviews... rather on the issue tracker than here: https://github.com/hasufell/abstract-filepath/pull/4/files 2. discuss whether some of the ByteString stuff (we operate mostly on ShortByteString here and I added lots of new functions) should be fed back into the 'bytestring' package 3. discuss how to split the package (probably need one only for the types, so e.g. core libraries could have a light import) 4. start writing patches for unix and Win32 Please, help and comments appreciated. This can only be done as a combined effort. The CLC, last time I asked, was behind this approach. Cheers, Julian

1 0

Re: Lookup variant for IntMap
by Simon Jakobi 17 Aug '21

17 Aug '21

Am Mo., 16. Aug. 2021 um 17:06 Uhr schrieb Jan-Willem Maessen <jmaessen(a)alum.mit.edu>: > > Reading the issue and the benchmarks, it seems like the right call here might be to make the "throws error" version the one that defers the failure check, and to use a similar algorithm for update (which must search to the leaf in any case). update can terminate fast too. See the nomatch case in updateWithKey: https://hackage.haskell.org/package/containers-0.6.5.1/docs/src/Data.IntMap…

1 0

Lookup variant for IntMap
by Callan McGill 16 Aug '21

16 Aug '21

Hi all, I recently noticed that lookup for IntMap favours searches that can fast-fail - if instead we are in a situation where lookups are mostly successful, then this can be wasteful (see this issue for details: https://github.com/haskell/containers/issues/794) Since both versions are useful, it would be best to offer users both variants. I wondered if people on this list had any suggestions for a name for the new function? David Feuer also wondered which of these two behaviours should be the default. My inclination is for it to be the current version which fails faster (this also guarantees no unfortunate regressions) but it would be useful to run more substantial real-world benchmarks to figure that out (if anyone has any suggestions then do let me know). Best wishes, Callan

3 2

How to use Read for Data.Version
by Andreas Abel 15 Aug '21

15 Aug '21

How is the parser for Data.Version supposed to work? ```haskell import Data.Version readVersion :: String -> Version readVersion = read main :: IO () main = print $ readVersion "8.10.5" -- *** Exception: Prelude.read: no parse ``` P.S.: Maintainer libraries(a)haskell.org

4 4

State of the CLC
by Emily Pillmore 13 Aug '21

13 Aug '21

Hello Haskell! The Core Libraries Committee is undergoing some changes at the moment, and I'd like to fill everyone in about the state of the CLC, what's happening behind the scenes, and what we hope to accomplish in the future. It's no secret that the CLC hasn't been as active as of late, and hopefully this post will serve to clear that up and invite new interest in our plans going forward. ## History of the CLC Originally, the CLC was created to steward the `base` library and review changes to it, which no one was really empowered to do before its inception. In particular, this was extremely helpful in stewarding large changesets such as the FTP and AMP proposals. With the success of these proposal implementations, the responsibilities and headcount of the CLC grew to the point where they were asked to steward not just `base`, but also a collection of "mission critical" libraries that GHC relied upon in order to function. Slowly, the number of these packages grew to 13 including `base`. The previous authors and maintainers of the core libraries slowly exited the community for various reasons, and due to lack of ability to find new maintainers, responsibility devolved to the CLC taking control. The CLC, however, did not grow along with it. CLC members viewed these packages as stable, and therefore not in need of consistent code-changes modulo a version bump here and there, or the odd update for new GHC features. ## CLC as of Today Today , we realize that the perception of a stable set of core libraries is not true to reality. In fact, this was realized about the time I joined in 2019, but it had not quite sunk in: our core libraries are in need of constant maintenance. In fact, many of the core libraries we do have are not stable because they are in a stable, performant and well-maintained state, but are stable because nothing has been done with them. It is a dire error that the two were confused. In many cases, we were the ones blocking the changes! This is not to say that each of the core libraries suffers, but many do, and this is a problem. For example, recently orders of magnitude changes in performance and usability came in the form of pull requests to `random` and `bytestring`, where before they were considered to be completely stable. In the case of `random`, a CLC member stood in the way of that progress. In the case of other libraries, progress stalled because the CLC was not equipped to maintain the libraries it was charged with stewarding, and new maintainers could not be found. However, this is not to heap blame on anyone in particular. The creeping expansion of our responsibilities on the CLC caused two major problems: 1. We had too many responsibilities, and scope kept creeping. What started out as `base` turned into `base` and stewarding core libraries. Stewarding the core libraries turned into maintaining the core libraries. Maintaining turned into architecting new feature changes etc. 2. Despite life generally being balanced with CLC duties, the last few years have also added the weight of a general malaise of stress induced by our respective sociopolitical and economic climates. As a result, despite being 8-strong on paper, the CLC has actually been operating with only 2.5 active people since 2019 (the .5 coming from 2 sporadically active CLC members). This is not enough to keep up with the general workload, nor enough to decide quorum. Behind the scenes, we've been feeling this pressure and working with it since the COVID-19 pandemic started, but at this point in time, we're looking to disband the current iteration of the CLC and work towards a new structure that will be more maintainable in the future. ## CLC in the Future Three weeks ago, I sent out [an email]( https://hackmd.io/rSBGz4bgRgq5w-tUH_m68w ) to the CLC asking for a role call, advertising the will to restructure. With some gentle prodding, we have 3 members who raised their hand (Chessai, myself, and gwils), and 1 who will help us rebuild and reassess their involvement pending the outcome (Cale Gibbard). The 4 of us will meet on Thursday of next week to discuss a restructuring of our responsibilities and what to do moving forward. I expect that the structure of the CLC will scale back to maintaining `base` as a main focus, with a new proposal process in the vein of the Haskell Foundation or GHC tech proposals process, and the designation of new roles to help shepherd issues to us and manage contributors. This will effectively be reasserting the CLC's original mission statement, with some better process for onboarding community-led contributions to `base`, and a clearer notion of what it means to maintain core libraries. Then, finding new maintainers for some of the core libraries will be the final hurdle for the new CLC. I think this is a very necessary change that is possibly 5 years too late, but c'est la vie. I'm happy that the CLC are amenable to this change, and I hope that we see alot of very fruitful discussion amongst the community on how best to structure in a way that meets your demands more effectively. I'm putting a time box on a finished process by mid to late September (give us a month+ to sort it out), and we'll be back and more effective than ever. Also, since the email sent out served as a means of figuring out which members were actively, we will be adding as many or more CLC members to help move things forward. Cheers, and I hope this gives enough detail for everyone. Emily

4 9