June 2020 - Libraries

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

25 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

Deprecating fromIntegral
by Niklas Hambüchen 12 Aug '20

12 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

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

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

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

Symmetric difference for Set and IntSet
by Andrew Lelechenko 18 Jun '20

18 Jun '20

Hi all, I propose to add a new combining function to `Data.Set` and `Data.IntSet` with the following semantics (but better implementation): symmetricDifference :: Set a -> Set a -> Set a symmetricDifference x y = (x \\ y) <> (y \\ x) The context is that Federico (CC'ed) is working on a GSoC project about faster factorisation algorithms in `arithmoi` (http://hackage.haskell.org/package/arithmoi) and the symmetric difference is a basic building block for sparse linear algebra over GF(2) field. Best regards, Andrew

3 2

Should primMonad class live in base or mtl?
by Carter Schonwald 15 Jun '20

15 Jun '20

This is something I’ve pondered on and off, And the classes PrimMonad and PrimMonadBase are super stable Argument in favor of base : there’s absolutely code in base, and packages like array, which would benefit from PrimMonad. Plus it might allow more reuse / encourage more ST monad code in the wild? (I always feel like ST monad is underused. ) Argument against base: Then a lot of PrimMonad instances would need to live in transformers. And I’m not sure if maintainers over there would want that? Argument in favor of mtl: it’s where all the other transformer stack stuff gets defined. So all the upkeep for monad instances is already going on there regularly. Argument against mtl : aside from concentrating the upkeep on transformer stack instances it seems like it wouldn’t enable new improvements to base. Another option is to have some sort of clone of the class in base , as long as it pays for itself in code reuse / simplification within base

4 4