July 2020 - Libraries

Improving the instances of Data.Functor.{Product,Sum}
by chessai . 26 Jan '21

26 Jan '21

Consider the Eq instance for these types. Currently we rely on: (Eq1 f, Eq1 g, Eq a) But some potential improvements include changing to: (Eq (f (g a))) (FlexibleContexts) or (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a) (QuantifiedConstraints) There was a discussion sometime last year about the same thing regarding Semigroup/Monoid instances for `Compose` [1]. Additionally, the question has been raised again for Data.Functor.{Product,Sum} on Gitlab [2, 3]. There has been no consensus in either case, but that's not too worrying as both discussions have been brief. I'm currently not happy with the {Eq,Ord,Show}{1,2} family of classes, and would hope to work toward their removal, or at least the shrinking of their presence in base. Even though the linked proposals are about a single type, I think it's important that we come up with a decision and stick with it. Having different APIs for different types here would be pretty confusing, and some could even say sloppy. Please let me know your thoughts. [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704

10 22

Fwd: The Char Kind: proposal
by Daniel Rogozin 01 Sep '20

01 Sep '20

Greetings, I would like to propose and discuss several changes related to the character kind. Some of those changes were implemented jointly with Rinat Stryungis, my Serokell teammate. The purpose of this patch is to provide a possibility of analysing type-level strings (symbols) as term-level ones. This feature allows users to implement such programs as type-level parsers. One needs to have full-fledged support of type-level characters as well as we already have for strings and numbers. In addition to this functionality, it makes sense to introduce the set of type-families, counterparts of functions defined in the Data.Char module in order to work with type-level strings and chars as usual (more or less). For more convenience, it’s worth having some of the character-related type families as built-ins and generating the rest of ones as type synonyms. The patch fixes #11342, an issue opened by Alexander Vieth several years ago. In this patch, we introduced the Char Kind, a kind of type-level characters, with the additional type-families, type-level counterparts of functions from the `Data.Char` module. In contrast to Vieth’s approach, we use the same Char type and don’t introduce the different `Character` kind. We provide slightly more helpers to work with the Char kind, see below. You may take a look at this merge request with proposed updates: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3598. First of all, we overview the additional type families implemented by us in this patch. type family CmpChar (a :: Char) (b :: Char) :: Ordering Comparison of type-level characters, as a type family. A type-level analogue of the function `compare` specified for characters. type family LeqChar (a :: Char) (b :: Char) :: Bool This is a type-level comparison of characters as well. `LeqChar` yields a Boolean value and corresponds to `(<=)`. type family ConsSymbol (a :: Char) (b :: Symbol) :: Symbol This extends a type-level symbol with a type-level character type family UnconsSymbol (a :: Symbol) :: Maybe (Char, Symbol) This type family yields type-level `Just` storing the first character of a symbol and its tail if it is nonempty and `Nothing` otherwise. Type-level counterparts of the functions `toUpper`, `toLower`, and `toTitle` from 'Data.Char'. type family ToUpper (a :: Char) :: Char type family ToLower (a :: Char) :: Char type family ToTitle (a :: Char) :: Char These type families are type-level analogues of the functions `ord` and `chr` from Data.Char respectively. type family CharToNat (a :: Char) :: Nat type family NatToChar (a :: Nat) :: Char A type-level analogue of the function `generalCategory` from `Data.Kind`. type family GeneralCharCategory (a :: Char) :: GeneralCategory The second group of type families consists of built-in unary predicates. All of them are based on their corresponding term-level analogues from `Data.Char`. The precise list is the following one: type family IsAlpha (a :: Char) :: Bool type family IsAlphaNum (a :: Char) :: Bool type family IsControl (a :: Char) :: Bool type family IsPrint (a :: Char) :: Bool type family IsUpper (a :: Char) :: Bool type family IsLower (a :: Char) :: Bool type family IsSpace (a :: Char) :: Bool type family IsDigit (a :: Char) :: Bool type family IsOctDigit (a :: Char) :: Bool type family IsHexDigit (a :: Char) :: Bool type family IsLetter (a :: Char) :: Bool We also provide several type-level predicates implemented via the `GeneralCharCategory` type family. type IsMark a = IsMarkCategory (GeneralCharCategory a) type IsNumber a = IsNumberCategory (GeneralCharCategory a) type IsPunctuation a = IsPunctuationCategory (GeneralCharCategory a) type IsSymbol a = IsSymbolCategory (GeneralCharCategory a) type IsSeparator a = IsSeparatorCategory (GeneralCharCategory a) Here is an example of an implementation: type IsMark a = IsMarkCategory (GeneralCharCategory a) type family IsMarkCategory (c :: GeneralCategory) :: Bool where IsMarkCategory 'NonSpacingMark = 'True IsMarkCategory 'SpacingCombiningMark = 'True IsMarkCategory 'EnclosingMark = 'True IsMarkCategory _ = 'False Built-in type families I described above are supported with the corresponding definitions and functions in `compiler/GHC/Builtin/Names.hs`, `compiler/GHC/Builtin/Types.hs`, and `compiler/GHC/Builtin/Types/Literals.hs`. In addition to type families, our patch contain the following updates: 1. parsing the 'x' syntax 2. type-checking 'x' :: Char 3. type-checking Refl :: 'x' :~: 'x' 4. Typeable / TypeRep support 5. template-haskell support 6. Haddock related updates 7. tests At the moment, the merge request has some minor imperfections for polishing and improvement, but we have a prototype of a possible implementation. The aim of my email is to receive your feedback on this patch. Kind regards, Danya Rogozin.

3 2

Deprecating fromIntegral
by Niklas Hambüchen 13 Aug '20

13 Aug '20

This is not a joke. I just found a bug in base (https://ghc.haskell.org/trac/ghc/ticket/14262) import System.IO hWaitForInput stdin 4294968296 This code should wait for 49.something days, but it waits for 1 second. It is caused by a quick use of `fromIntegral` to "convert" `Int -> CInt` (where CInt = Int32), causing an overflow. I argue that `fromIntegral` causes unnoticed data corruption without any warning, and thus are worse than partial functions. In this case, this data corruption occurs in the most fundamental code that we all use and have to rely upon (`base`). So I propose that we add a deprecation pragma to `fromIntegral` (however, keeping it forever, like Java does, as there's no benefit to removing it, we just want that people use safer functions over time), and instead provide a `safeFromIntegral` that can only widen ranges, and one or more `unsafeFromIntegral` or appropriately named functions that can error, wrap, return Maybe, or have whatever desired behaviour when the input value doesn't fit into the output type. For some inspiration, `foundation` provides ideas in that direction: http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-From.html http://hackage.haskell.org/package/basement-0.0.2/docs/Basement-IntegralCon… It is a bit funny how we argue that Haskell is good for high assurance programming, and we build all sorts of fancy constructs to eliminate more run-time errors, when in fact we do worse than C in detecting errors in the most basic types a computer can use, such as converting between 64-bit and 32-bit integers. Let's fix that. It avoids real problems in real production systems that are difficult to debug when they happen (who writes a unit test checking that a timeout of 50 days still works? This is the kind of stuff where you have to rely on -- very basic -- types). I'd like to probe support for such a change before doing any work on it. Niklas

18 58

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

17 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 15 Jul '20

15 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 14 Jul '20

14 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