- Libraries - Haskell.org

Alternative instance for Compose
by Asad Saeeduddin 21 Jul '20

21 Jul '20

Hello folks, base 4.14 has the following instance for `Compose f g`: instance (Alternative f, Applicative g) => Alternative (Compose f g) where empty = Compose empty (<|>) = coerce ((<|>) :: f (g a) -> f (g a) -> f (g a)) :: forall a . Compose f g a -> Compose f g a -> Compose f g a This instance doesn't really do anything with the `Applicative g` constraint it is demanding. It's also kind of unclear what utility it delivers, given that the resulting Alternative instance is indistinguishable from the outer functor's Alternative instance. In other words: `getCompose $ Compose x <|> Compose y == x <|> y`. It seems to me a more useful instance would be: instance (Applicative f, Alternative g) => Alternative (Compose f g) where empty = Compose $ pure empty (<|>) = _ $ liftA2 (<|>) This is also nicer in a mathematical sense: `Applicative` functors correspond to lax monoidal functors from `Hask, (- , -), ()` to `Hask, (-, -), ()`. We can interpret `Alternative`s as lax monoidal functors from `Hask, Either - -, Void` to `Hask, (-, -), ()`. Compatible lax monoidal functors compose, but if you think about the relevant "types" of the functors a bit, you'll realize that while we can compose an `Applicative` after an `Alternative` to get another `Alternative`, the reverse does not work. Hence the instance we have today, which has no choice but to just ignore the `Applicative` constraint it is demanding. Does it make sense to replace the instance we have today with the `pure empty`, `liftA2 (<|>)` one? Thanks, Asad

2 1

Laziness on new "random" package
by Dannyu NDos 17 Jul '20

17 Jul '20

Though it is reasonable to make utilities monadic, they lack a crucial property: *laziness*. I have the following datatype: newtype ArbReal = ArbReal (Word -> Integer) This represents arbitrary real numbers by being able to compute arbitrary decimal places after the decimal point. For example, to compute pi, let f be the function passed to constructor ArbReal. Then f 0 = 3, f 1 = 31, f 2 = 314, and so on. I can implement instance Random ArbReal: instance Random ArbReal where random g = let (h, i) = split g d:digits = randomRs (0 :: Word, 9) h getNum [] = 0 getNum (d:ds) = toInteger d + 10 * getNum ds takeDigits n = getNum (reverse (take n digits)) + toInteger (fromEnum (d >= 5)) in (ArbReal (takeDigits . fromIntegral), i) randomR (lo, hi) g = let (x, h) = random g in (lo + x * (hi - lo), h) But I see no way to implement an instance of UniformRange ArbReal, for it relies on randomRs, which is lazy. Neither ST nor IO is able to contain such laziness.

2 1

Looking for co-maintainers(s) for github package.
by Oleg Grenrus 16 Jul '20

16 Jul '20

Hi list, I have now been a maintainer of `github` [1] package for about four years. GitHub still develops and changes their API (good) and still doesn't provide machine readable specification (bad), thus the package needs some active maintenance. As I'm not using the package anymore myself, I often forget about its existence. Therefore I'm looking for a (co-)maintainers which use `github` package themselves, and could eventually take over the maintenance. In the past year I haven't written any code for the package myself, only reviewing and merging other people contributions, and preparing releases when there are enough changes. I don't ask you to do anything else either. - Oleg "phadej" Grenrus [1]: https://hackage.haskell.org/package/github

1 0

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 13 Jul '20

13 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