- Libraries - Haskell.org

text-2.0 with UTF8 is finally released!
by Andrew Lelechenko 27 Dec '21

27 Dec '21

I’m happy to announce that text-2.0 with UTF-8 underlying representation has been finally released: https://hackage.haskell.org/package/text-2.0. The release is identical to rc2, circulated earlier. Changelog: https://hackage.haskell.org/package/text-2.0/changelog Please give it a try. Here is a cabal.project template: https://gist.github.com/Bodigrim/9834568f075be36a1c65e7aaba6a15db This work would not be complete without a blazingly-fast UTF-8 validator, submitted by Koz Ross into bytestring-0.11.2.0, whose contributions were sourced via HF as an in-kind donation from MLabs. I would like to thank Emily Pillmore for encouraging me to take on this project, helping with the proposal and permissions. I’m grateful to my fellow text maintainers, who’ve been carefully reviewing my work in course of the last six months, as well as helpful and responsive maintainers of downstream packages and GHC developers. Thanks all, it was a pleasant journey! Best regards, Andrew

6 5

CLC Election January 2022
by Andrew Lelechenko 24 Dec '21

24 Dec '21

The Core Libraries Committee is seeking for a new member! # Who should apply? Anyone who meets the following criteria should apply: * 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 3 years term in a healthy manner. * Candidates should be able to contribute opinions and analysis to issues raised by the community as a part of the CLC proposal process on a semi-frequent basis (2 to 3 per month). * Candidates should be good communicators, and at least be able to articulate to the CLC team when they will be available vs. unavailable. * 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. Candidates, who stand for CLC Elections back in September, are most welcome to apply again. # How can I apply? To apply for one of these positions, send an email to core-libraries-committee(a)haskell.org that consists of the following data: * The header "CLC Election January 2022 - {your name}". * Why you think you’re a good fit given the above criteria. * If applicable, please point us to some code you’ve written. Please apply before Feb 1. Best regards, Andrew

1 0

Add non-escaping show functions
by Kai Ma 20 Dec '21

20 Dec '21

Hi all! A few months ago I proposed to change the escaping behavior of `show`. The general consensus is that it will introduce hard-to-find and unpredictable amount of breakage. However, I still think there should be a standard (i.e. living in base) solution to that problem. Instead of changing existing instances, we can add new functions. Therefore, I propose: 1. Add `showNE` [1] to `Show`, with a default implementation `showNE = show`. 2. Add `printNE x = putStrLn (showNE x)`. 3. Change ghci’s default print function to `printNE`. 4. Document that `show` escapes strings so its output will support ASCII terminals, where `showNE` is limited to only terminals that support Unicode. This proposal benefits ghci without breaking any existing code, and the older behavior can be restored by `:set -interactive-print print`. Q&A: - Why not just use existing packages, like pretty-simple, for this purpose? I believe ghci should support this behavior (non-escaping) out of box without installing any third-party packages. - Why not just add `printNE` which undoes escaping? Definitely doable. However, it feels more like a hack than a solution. According to the new CLC process, this proposal should be submitted to https://github.com/haskell/core-libraries-committee/issues. But I’d like to hear some early feedback, and I will implement this proposal. [1] “NE” stands for non-escaping. This is only a temporary name in order to avoid bike-shedding. Regards, Kai

4 5

bytestring-0.11.2.0
by Andrew Lelechenko 11 Dec '21

11 Dec '21

On behalf of maintainers I'm happy to announce that bytestring-0.11.2.0 (http://hackage.haskell.org/package/bytestring-0.11.2.0) is finally released. Highlights from the changelog (https://github.com/haskell/bytestring/blob/0.11.2.0/Changelog.md) * New functions: * ultra-fast SIMD-based `isValidUtf8` validator, * `foldr'`, `foldr1'`, `scanl1`, `scanr`, `scanr1`, `takeEnd`, `dropEnd`, `takeWhileEnd`, `dropWhileEnd`, `spanEnd`, `breakEnd` for lazy `ByteString`, * `writeFile` to dump `Builder` directly, * `fromFilePath` and `toFilePath` for locale-aware conversions. * Performance improvements: * speed up `floatDec` and `doubleDec` up to 10x using Ryu algorithm, * new SIMD-based `count` is up to 5x faster, * improve inlining of `foldl`, `foldl'`, `foldr`, `foldr'`, `mapAccumL`, `mapAccumR`, `scanl`, `scanr` and `filter`, * faster internal loop in `unfoldrN`, * use a static lookup table for Base16 `Builder`s. * Add `Lift` instances for `ByteString` and `ShortByteString`. * Put `HasCallStack` constraints onto partial functions. 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`: * Koz Ross * Lawrence Wu * Sylvain Henry * Andreas Abel * Ignat Insarov * Luke Clifton * Kyriakos Papachrysanthou * Oleg Grenrus * Simon Jakobi * Cameron SkamDart * Callan McGill * Georg Rudoy * Nanami Yokodake * Hécate Kleidukos * Viktor Dukhovni * me Best regards, Andrew

1 0

Can't upload a package named "oath" to Hackage
by Fumiaki Kinoshita 09 Dec '21

09 Dec '21

I tried to upload a package called "oath". However I got the following error message: cabal upload --publish dist-newstyle/sdist/oath-0.0.tar.gz hackage.haskell.org username: FumiakiKinoshita hackage.haskell.org password: Uploading dist-newstyle/sdist/oath-0.0.tar.gz... Error uploading dist-newstyle/sdist/oath-0.0.tar.gz: http code 403 Error: Upload failed You are not authorised to upload new versions of this package. The package 'oath' exists already and you are not a member of the maintainer group for this package. If you believe you should be a member of the maintainer group for this package, then ask an existing maintainer to add you to the group. If this is a package name clash, please pick another name or talk to the maintainers of the existing package. However, https://hackage.haskell.org/package/oath does not exist. I'm not sure what is going on

12 18

[ANN] Release candidate for `mtl-2.3`
by Emily Pillmore 19 Nov '21

19 Nov '21

Hello all, Chessai and I are excited to announce a release candidate for `mtl`: [`mtl-2.3-rc3`]( https://github.com/haskell/mtl/releases/tag/v2.3-rc3 )! ## Timeline The timeline for release will be as follows: - This announcement marks the start of the timeline - We will give 2 weeks of testing before considering release - If no major issues are filed before then, `mtl-2.3-rc3` will be released as `mtl-2.3`, and if issues are found, they will be amended, and a new release candidate will be announced, resetting the 2 week period. To test `mtl-2.3-rc3` for yourself, please feel free to add the following to your `cabal.project`: ``` source-repository-package type: git location: https://github.com/haskell/mtl.git tag: 5d0f62b8007bb96e49f36a5544741cfe96a97130 ``` or, if you're a stack user add this entry to your `extra-deps`: ``` - git: https://github.com/haskell/mtl.git commit: 5d0f62b8007bb96e49f36a5544741cfe96a97130 ``` And make sure to adjust all bounds/`allow-newer` accordingly. Please note that this release of `mtl` is a full major version release, and *will be the last of the 2.x series before work begins on updating the mtl class hierarchy*. ## Changelog * Add instances for `Control.Monad.Trans.Writer.CPS` and `Control.Monad.Trans.RWS.CPS` from `transformers` 0.5.6 and add `Control.Monad.Writer.CPS` and `Control.Monad.RWS.CPS`. * `Control.Monad.Cont` now re-exports `evalCont` and `evalContT` * Add `tryError`, `withError`, `handleError`, and `mapError` to `Control.Monad.Error.Class`, and re-export from `Control.Monad.Except`. * Remove `Control.Monad.List` and `Control.Monad.Error` * Remove instances of deprecated `ListT` and `ErrorT` * Remove re-exports of `Error` * Add instances for `Control.Monad.Trans.Accum` and ` Control.Monad.Trans.Select ( http://control.monad.trans.select/ ) ` * Remove re-exports of `Control.Monad`, `Control.Monad.Fix` and `Data.Monoid` modules I'd like to thank the many contributors who offered patches, tickets, and other help in the preparation of this release. We appreciate all of your help! Happy hacking! Emily

1 0

aws package looking for maintainers
by Andrew Lelechenko 13 Nov '21

13 Nov '21

aws package (https://hackage.haskell.org/package/aws <https://hackage.haskell.org/package/aws>) is looking for a new maintainer: https://github.com/aristidb/aws/pull/276#issuecomment-956212074 <https://github.com/aristidb/aws/pull/276#issuecomment-956212074> Best regards, Andrew

2 1

New CLC proposal process
by Andrew Lelechenko 12 Nov '21

12 Nov '21

I'm happy to announce that Core Libraries Committee has completed post-election reboot and now has a new home at https://github.com/haskell/core-libraries-committee <https://github.com/haskell/core-libraries-committee> and a new GitHub-based process: https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md <https://github.com/haskell/core-libraries-committee/blob/main/PROPOSALS.md>. From now on proposals to change base should be raised as GitHub issues instead of emails to libraries@. Best regards, Andrew

6 12

interaction of "local" and "callCC"?
by Viktor Dukhovni 29 Oct '21

29 Oct '21

I've stumbled into a not immediately intuitive distinction when mixing "local" and "callCC" (from the `transformers` package) with one of: * ReaderT e (ContT r m) a * ContT r (ReaderT e m) a Specifically, this concernts the expected `Reader` environment when the current continuation passed via callCC is invoked. * With ContT as the inner monad, the Reader environment of the current continuation is not affeced by an enclosing call to "local": flip runConT finalK $ flip runReaderT env $ do ... x <- liftCallCC callCC $ \ k -> do local f (ask >>= k) ... ask >>= cc x in this form, `k` (i.e. `\x -> ask >>= c x`) sees the original environment `env` from `runReaderT`, only the first `ask` call sees `f env` interposed by `local`. * With ReaderT as the inner monad, the environment of the current continuation is affeced by an enclosing call to "liftLocal": flip runReaderT env $ flip runConT (lift . finalK) $ do ... x <- callCC $ \ k -> do liftLocal ask local f (lift ask >>= k) ... lift ask >>= cc x in this form, both `k` and the firt `lift ask` see the modified environment `f env` interposed by `liftLocal`. Of course in the simple example above, one could just write: liftLocal ask local f (lift ask) >>= k and avoid the issue, but in more complex nesting of code, this can be rather more difficult. My intuition is that the behaviour when ContT is the inner monad (first example) is closer to what one might generally hope to see. The rationale is that a more flexible definition of `local` and `liftLocal` might be generalised from taking `f :: env -> env` to taking `f :: env -> newenv` for some related environment type `newenv`, and in that case, the second example would no longer typecheck, because the current continuation would now have to have both `env` and `newenv` for its environment type. It seems likely that the different behaviours are largely unavoidable, because `liftLocal` does not know that there's a current continuation that might need the original environment, and `callCC` does not know that the base monad is a `ReaderT` and the current continuation needs to see the Reader's original environment. It seems this issue is explicitly covered in the case of StateT: -- | Uniform lifting of a @callCC@ operation to the new monad. -- This version rolls back to the original state on entering the -- continuation. liftCallCC :: CallCC m (a,s) (b,s) -> CallCC (StateT s m) a b liftCallCC callCC f = StateT $ \ s -> callCC $ \ c -> runStateT (f (\ a -> StateT $ \ _ -> c (a, s))) s {-# INLINE liftCallCC #-} -- | In-situ lifting of a @callCC@ operation to the new monad. -- This version uses the current state on entering the continuation. -- It does not satisfy the uniformity property (see "Control.Monad.Signatures"). liftCallCC' :: CallCC m (a,s) (b,s) -> CallCC (StateT s m) a b liftCallCC' callCC f = StateT $ \ s -> callCC $ \ c -> runStateT (f (\ a -> StateT $ \ s' -> c (a, s'))) s {-# INLINE liftCallCC' #-} where in the "Signatures" module we see: -- | Signature of the @callCC@ operation, -- introduced in "Control.Monad.Trans.Cont". -- Any lifting function @liftCallCC@ should satisfy -- -- * @'lift' (f k) = f' ('lift' . k) => 'lift' (cf f) = liftCallCC cf f'@ -- type CallCC m a b = ((a -> m b) -> m a) -> m a Playing with a prototype "flat" (ContT + ReaderT) monad: newtype RContT e r m a = RContT { runRContT :: (a -> e -> m r) -> e -> m r } which directly supports both ReaderT and ContT features, I found it natural to define a "local" that can change the environment type, and then of course had no choice but to pass an unmodified enviroment to the current continuation. local :: (e -> e') -> RContT e' r m a -> RContT e r m a local f m = RContT $ \k e -> runRContT m (\a _ -> k a e) (f e) callCC :: ((a -> RContT e' r m b) -> RContT e r m a) -> RContT e r m a callCC f = RContT $ \k e -> runRContT (f (\x -> RContT (\_ _ -> k x e))) k e I don't know where it might be appropriate to document "correct" use of callCC in transformer stacks with `ReaderT` environments. Perhaps it would be reasonable to document that one should generally have "ContT" just above the base monad, and use "liftCallCC" upstairs, rather than use "liftLocal" from ContT, unless of course one wants the current continuation to be exposed to a modified environment in some cases. Is there an expected "uniformity" property here that's not covered by the "Signatures"? -- Viktor.

1 0

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