- Libraries - Haskell.org

containers-0.6.3.1
by David Feuer 14 Jul '20

14 Jul '20

At long last, we have released containers-0.6.3.1. The most important changes in this release are bug fixes for IntMap traversals: * Fix traverse and traverseWithKey for IntMap, which would previously produce invalid IntMaps when the input contained negative keys (Thanks, Felix Paulusma). * Fix the traversal order of various functions for Data.IntMap: traverseWithKey, traverseMaybeWithKey, filterWithKeyA, minimum, maximum, mapAccum, mapAccumWithKey, mapAccumL, mapAccumRWithKey, mergeA (Thanks, Felix Paulusma, Simon Jakobi). These now traverse in key order; previously they would traverse non-negative keys before negative keys. If you traverse any IntMaps, please take note of these changes. We also have several additions to the API: * Add compose for Map and IntMap (Thanks, Alexandre Esteves). * Add alterF for Set and IntSet (Thanks, Simon Jakobi). * Add Data.IntSet.mapMonotonic (Thanks, Javran Cheng). * Add instance Bifoldable Map (Thanks, Joseph C. Sible). Performance improvements of note: * Make (<*) for Data.Sequence incrementally asymptotically optimal (Thanks, David Feuer). This finally completes the task, begun in December 2014, of making all the Applicative methods for sequences asymptotically optimal even when their results are consumed incrementally. Many thanks to Li-Yao Xia and Bertram Felgenhauer for helping to clean up and begin to document this rather tricky code. * Speed up fromList and related functions in Data.IntSet, Data.IntMap and Data.IntMap.Strict (Thanks, Bertram Felgenhauer). * Use count{Leading,Trailing}Zeros in Data.IntSet internals (Thanks, Alex Biehl). There are also numerous documentation improvements and packaging updates. Please see the changelog for full details. Thanks to all the contributors, The containers team

2 1

Re: Symmetric difference for Set and IntSet
by Andrew Lelechenko 13 Jul '20

13 Jul '20

On 18 Jun 2020, at 23:42, Bardur Arantsson <spam(a)scientician.net> wrote: > I think it's probably going to be useful, but I would suggest an > algorithm which actually returns each of the terms here (as a tuple), i.e. > > The "added" bits > The "removed" bits > The "common" bits > > This may not be *that* useful for sets per se, but I've lost count of > how often I've had to implement a similar thing for maps. This is probably orthogonal to my proposal here, because it does not improve the performance of symmetricDifference. Maps are more flexible in this aspect, because there are merge tactics, which allow to encode any set operation. Best regards, Andrew

3 2

Proposal for adding explicit fixity for (~) and (~~)
by Rinat Stryungis 13 Jul '20

13 Jul '20

Hello, libraries! I want to present a proposal for changes in the `ghc-prim` library. It solves the following issue: https://gitlab.haskell.org/ghc/ghc/-/issues/18252 by adding an explicit fixity for the `(~)` type operator. It is set equal to 4: infix 4 ~, ~~ And there are two reasons for that: 1. These fixities are equal to the corresponding fixities of `(:~:)` and `(:~~:)` 2. They are less than `GHC.TypeLits.+` and expressions like `5 + 5 ~ 10` could be written without brackets. Also, it looks like the change does not break anything and all existing tests are passed. The patch is already implemented and could be seen by the following link: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3610 Also, I've updated documentation and added tests. Welcome to discuss the change and its implementation. Best regards, Rinat Stryungis.

1 0

Package takeover: thyme and enummapset-th
by Fumiaki Kinoshita 12 Jul '20

12 Jul '20

Greetings, I (Hackage: FumiakiKinoshita) would like to take over the maintainership of thyme and enummapset-th. I tried to contact him via email in Jan 2019, but I haven't heard back. Best regards,

2 3

Proposal for removing separate `Nat` in favour of promoted `Natural` type.
by Rinat Stryungis 09 Jul '20

09 Jul '20

Hello, libraries! I want to present a proposal for changes in the `Base` library. The changes in my proposal partially solve the following issue: https://gitlab.haskell.org/ghc/ghc/-/issues/10776 and remove the separate built-in kind `Nat` in favor of promoted type `Natural`. It means that previously one can't directly promote a data type with Natural fields: data MyPointN = PointN Natural Natural -- could not be promoted data MyPointP = PointP Nat Nat -- could be promoted, but uninhabited in terms type M = PointP 1 10 but now one could promote the `Natural` data type: data MyPoint = Point Natural Natural type MyTLPoint1 = Point 1 10 The proposed changes both simplify the internals of the GHC by removing separate kind and related things and make using of the type-level naturals more convenient for users. Also new type synonym type Nat = Natural appeared in the Data.Type.TypeNats in the name of backward compatibility. I've opened a new MR with the patch. In the patch with the already implemented promotion of Naturals, one could find new and updated tests and docs. Also, I want to say about the breakages: 1. One must enable `TypeSynonymInstances` in order to define instances for `Nat`. 2. Different instances for `Nat` and `Natural` won't type check anymore. 3. Type checker plugins that work with the natural numbers now should use `naturalTy` kind instead of removed `typeNatKind` Anyone interested is welcome to look at the MR and discuss the proposal and its implementation. https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3583 The latter is very short and easy, thanks to the recently merged patch with a new `ghc-bignum` library. It greatly simplified my work. Thanks and best regards. Rinat Stryungis.

2 2

Proposal: k ~ l => IsLabel k (Proxy l)
by Fumiaki Kinoshita 07 Jul '20

07 Jul '20

I propose adding an IsLabel instance to Proxy where fromLabel = Proxy This is the only reasonable instance I can think of, and AFAIK there's no plan which would conflict [0]. The proposed instance allows us to explore API designs involving type-level strings with much less syntactic noise ( #foo is easier to type than @"foo"). I admit that the motivation is weak, but I think it's nice to have. [0] https://gitlab.haskell.org/ghc/ghc/-/wikis/records/overloaded-record-fields…

2 1

Random 1.2 Released
by dominic＠steinitz.org 23 Jun '20

23 Jun '20

After a lot of hard work by Alexey Kuleshevich, Leonhard Markert and Dominic Steinitz with help from Aleksey Khudyakov, I am happy to announce version 1.2 of random has finally landed on hackage. * Much, much faster. * Higher quality default generator. * Addition of a monadic interface to support e.g. mwc-random. See https://github.com/haskell/random/blob/master/CHANGELOG.md for more details. There are a few libraries on hackage that do not compile with the latest version and we are providing PRs to fix those. Let us know if we forgot your favourite package. I'd also like to thank the reviewers especially Andrew Lelechenko and @chessai for taking the time to read through the code thoroughly and provide great feedback. Happy Hacking Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch

1 0

Hackage builds failing due to "no space left on device"
by chessai 22 Jun '20

22 Jun '20

Noticed that esqueleto is not building with the following error: /home/builder/hackage-server/build-cache/tmp-install/haddocks/aeson-1.5.2.0-docs/.copyFile2241-42.tmp: copyFile: resource exhausted (No space left on device) cabal: Leaving directory '/tmp/cabal-tmp-20169/aeson-1.5.2.0' cabal: Error: some packages failed to install: aeson-1.5.2.0-8m7uP0LdEdZJovFbkbnljA failed during the final install step. The exception was: ExitFailure 1 conduit-1.3.2-ByhlA7RsvOCCAVlxG8dMJB depends on conduit-1.3.2 which failed to install. conduit-extra-1.3.5-u7qkGOsMDsAnghfNEDjDE depends on conduit-extra-1.3.5 which failed to install. esqueleto-3.3.3.2-IXlW3QxcWcv1TdnLct1H3o depends on esqueleto-3.3.3.2 which failed to install. monad-logger-0.3.32-5FoF5JZYOM2GJkmQhYs1Qk depends on monad-logger-0.3.32 which failed to install. mono-traversable-1.0.15.1-G4IRQAjn5o89QjeJsBIgGz failed during the final install step. The exception was: ExitFailure 1 persistent-2.10.5.2-9pMXVg6QyyTJGyUOWsNLzx depends on persistent-2.10.5.2 which failed to install. (See full build log here: https://hackage.haskell.org/package/esqueleto-3.3.3.2/reports/3) Is anyone else experiencing this?

2 2

generic implementation of Bits.toIntegralSized
by Henning Thielemann 22 Jun '20

22 Jun '20

Documentation of toIntegralSized gives following generic implementation: toIntegral :: (Integral a, Integral b) => a -> Maybe b toIntegral x | toInteger x == y = Just (fromInteger y) | otherwise = Nothing where y = toInteger x I expect that (toInteger x == toInteger x) is always true because of referential transparency, right? I assume the intent was to compare the Integer representations of the parameter and the result. Maybe it should be this way: toIntegral :: (Integral a, Integral b) => a -> Maybe b toIntegral x | toInteger x == toInteger y = Just y | otherwise = Nothing where y = fromInteger $ toInteger x

1 0

Confusion over bitSize, bitSizeMaybe, and finiteBitSize
by chessai 22 Jun '20

22 Jun '20

The documentation for these functions in Data.Bits say that these functions do not evaluate their arguments. This wording is a bit strange to me, since it seems that does not exactly mean that any such implementation _must not_ evaluate its argument. This may be an issue when dealing with types whose inhabitants have finite but not necessarily fixed sizes. For example, there is a valid Bits instance for strict ByteString, which is finite but not fixed-size. My question is, should the wording be changed to be a bit clearer? Or should this restriction exist in the first place?

2 1