- Libraries - Haskell.org

Make Eq type class single method
by Joachim Breitner 28 Oct '21

28 Oct '21

Hi list, I am revisiting some educational material about Haskell, and I stumble over something that I keep stumbling over. I thought there was prior discussion, but I couldn’t find it (operators hard hard to google for). Why does Eq have a (/=) method? Semantically, I don’t see a reason why an instance might want to behave differently than the default method. And (in contrast to, say, Ord), I would be surprised if there are noticable performance benefits to be gained from implementing (/=) separately. On the other hand, this is likely the first time a learner will encounter a class with default methods, and it’s awkward to explain “this mechanism is useful if you can have an optimized implementation, but, eh, here it isn’t really possible”. If we’d design the language now, would we include (/=) as a method? If no: would it be worth removing it? Yes, every change is annoying, but if are going to keep using Haskell the next 30 days, it may pay off? And it might not be too bad: Remove it from base, but teach GHC to not error out if an instance defines (/=), but print a warning and otherwise ignore it. Libraries can remove it if it is defined, which is a backwards-compatible change. WDYT? Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

18 43

Proposal: deprecate Prelude.read
by Fumiaki Kinoshita 15 Oct '21

15 Oct '21

It is a partial function that does not provide a call stack, and it's very slow too. I propose deprecating Prelude.read. Adding deprecation should not break anything substantial because Hackage rejects -Werror (application code using -Werror is likely to experience a lot more breakage anyway, and I'd say it's their fault if it fails to build due to a use of read along with -Werror). Of course those who still want to use Prelude.read can totally ignore warnings. I believe this proposal is not that controversial.

8 9

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

[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 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