- Libraries - Haskell.org

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

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

27 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 22 Aug '21

22 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 21 Aug '21

21 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 19 Aug '21

19 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 16 Aug '21

16 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 16 Aug '21

16 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