May 2020 - Libraries - Haskell.org

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

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

Deprecate First and Last in Data.Monoid
by Andrew Martin 13 Jun '20

13 Jun '20

I propose that the data types First and Last, provided by Data.Monoid, be marked deprecated in GHC 8.6 and removed in GHC 8.10. The Semigroup-Monoid Proposal (SMP) brought about changes that, I will argue, make these data types (1) unneeded and (2) confusing. Why are they no longer needed? Data.Semigroup provides two identically named data types (First and Last). These have Semigroup instances matches what their names suggest. Additionally, SMP corrects the Monoid instance for Maybe so that it now lifts Semigroup instances instead of Monoid instances. What this means is that, assuming the following imports: import qualified Data.Monoid as M import qualified Data.Semigroup as S We have the following equivalences: M.First a === Maybe (M.First a) M.Last a === Maybe (M.Last a) When I say "equivalence", I mean that their Monoid instances have the same behavior. Their Show/Read instances are certainly different, and I’m not sure about their Ord instances. Getting back to the second reason, removing these data types would eliminate confusion. It’s strange that Semigroup is a superclass of Monoid, yet they have Data types with conflicting names defined in their respective modules. When you see the data type First, you cannot tell what someone is talking additional context. In general, base strives to avoid duplicate identifiers. The only other exception to this rule I can think of is that Bifunctor and Arrow both use the identifiers first and second. But, the situation with Data.Semigroup and Data.Monoid is higher impact since people are more likely to import these modules unqualified together. (As an aside, and the confusion I’m talking about here isn’t entirely hypothetical. I got tripped up by this when I first started using the semigroups library. I had to train myself to stop importing Data.Monoid unqualified, because it kept stealing these identifiers) Again, the two reasons are that these are no longer necessary and that they cause confusion. I would appreciate any feedback, including simple nods of agreement or disagreement. Thanks. -- -Andrew Thaddeus Martin

7 8

Re: [core libraries] Adding Backwards to base, re-export from Control.Applicative
by Baldur Blöndal 07 Jun '20

07 Jun '20

I'll CC Haskell Libraries þri., 12. nóv. 2019 kl. 22:14 skrifaði Ryan Scott <ryan.gl.scott(a)gmail.com>: > This discussion definitely belongs on the mailing list, yes. > > Ryan > > On Tue, Nov 12, 2019 at 11:59 AM chessai . <chessai1996(a)gmail.com> wrote: > >> I support this. +1 >> >> Should we copy in the libraries mailing list? >> >> On Tue, Nov 12, 2019, 5:56 AM Baldur Blöndal <baldurpet(a)gmail.com> wrote: >> >>> Is it time to move Control.Applicative.Backwards module from >>> transformers to base, and maybe re-export it from Control.Applicative. >>> >>> It's an interesting, important, simple property of Applicative that they >>> can be run backwards. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "haskell-core-libraries" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CAK9DwL9vPwA%3DJ%3…> >>> . >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "haskell-core-libraries" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to haskell-core-libraries+unsubscribe(a)googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg… >> <https://groups.google.com/d/msgid/haskell-core-libraries/CAD34_kK6QgQ%2BQmg…> >> . >> >

8 7

Bifoldable instance for Map
by Joseph C. Sible 04 Jun '20

04 Jun '20

I'd like to propose a change to the containers package: adding a Bifoldable instance to Map. I briefly mentioned this on Reddit [1] and no obvious problems were brought up. I submitted a PR implementing it [2]. This seems like an obvious and straightforward instance to me. Thoughts? Joseph C. Sible [1]: https://old.reddit.com/r/haskell/comments/fsgqd6/monthly_hask_anything_apri… [2]: https://github.com/haskell/containers/pull/714

5 18

Improving Random
by dominic＠steinitz.org 03 Jun '20

03 Jun '20

Hello Libraries, You may recall that following the blog post <https://alexey.kuleshevi.ch/blog/2019/12/21/random-benchmarks/> by @lehins, a group of us (@curiousleo, @lehins and me) invited participation in February <https://mail.haskell.org/pipermail/libraries/2020-February/030261.html> to take this work and apply it to improving the current random library. Our proximate goals were to fix #25 <https://github.com/haskell/random/issues/25> (filed in 2015) and #51 <https://github.com/haskell/random/issues/51> (filed in 2018). After a lot of discussion and experimentation, we have a proposal that addresses both these issues and also: #26 <https://github.com/haskell/random/issues/26>, #44 <https://github.com/haskell/random/issues/44>, #53 <https://github.com/haskell/random/issues/53>, #55 <https://github.com/haskell/random/issues/55>, #58 <https://github.com/haskell/random/issues/58> and #59 <https://github.com/haskell/random/issues/59>. For backwards compatibility, the proposal retains the old style classes and enhances them. Thus in 1.1 we have class RandomGen g where next :: g -> (Int, g) genRange :: g -> (Int, Int) split :: g -> (g, g) {-# MINIMAL next, split #-} and in 1.2 we have class RandomGen g where next :: g -> (Int, g) genWord8 :: g -> (Word8, g) genWord16 :: g -> (Word16, g) genWord32 :: g -> (Word32, g) genWord64 :: g -> (Word64, g) genWord32R :: Word32 -> g -> (Word32, g) genWord64R :: Word64 -> g -> (Word64, g) genShortByteString :: Int -> g -> (Data.ByteString.Short.Internal.ShortByteString, g) genRange :: g -> (Int, Int) split :: g -> (g, g) {-# MINIMAL split, (genWord32 | genWord64 | next, genRange) #-} and next and genRange are deprecated. This interface is what allows the significantly faster performance as no longer is everything forced to go via Integer. Several new interfaces are introduced and it is recommended that new applications use these and, where feasible, existing applications migrate to using them. The major API addition in this PR is the definition of a new class MonadRandom: -- | 'MonadRandom' is an interface to monadic pseudo-random number generators. class Monad m => MonadRandom g s m | g m -> s where {-# MINIMAL freezeGen,thawGen,(uniformWord32|uniformWord64) #-} type Frozen g = (f :: Type) | f -> g freezeGen :: g s -> m (Frozen g) thawGen :: Frozen g -> m (g s) uniformWord32 :: g s -> m Word32 -- default implementation in terms of uniformWord64 uniformWord64 :: g s -> m Word64 -- default implementation in terms of uniformWord32 -- plus methods for other word sizes and for byte strings -- all have default implementations so the MINIMAL pragma holds Conceptually, in MonadRandom g s m, g s is the type of the generator, s is the state type, and m the underlying monad. Via the functional dependency g m -> s, the state type is determined by the generator and monad. Frozen is the type of the generator's state "at rest". It is defined as an injective type family via f -> g, so there is no ambiguity as to which g any Frozen g belongs to. This definition is generic enough to accommodate, for example, the Gen type from mwc-random, which itself abstracts over the underlying primitive monad and state token. This is the full instance declaration (provided here as an example - this instance is not part of random as random does not depend on mwc-random): instance (s ~ PrimState m, PrimMonad m) => MonadRandom MWC.Gen s m where type Frozen MWC.Gen = MWC.Seed freezeGen = MWC.save thawGen = MWC.restore uniformWord8 = MWC.uniform uniformWord16 = MWC.uniform uniformWord32 = MWC.uniform uniformWord64 = MWC.uniform uniformShortByteString n g = unsafeSTToPrim (genShortByteStringST n (MWC.uniform g)) Pure random number generators can also be made instances of this class providing a uniform interface to both pure and stateful random number generators. An instance for the standard number generator StdGen is provided. The Random typeclass has conceptually been split into Uniform and UniformRange. The Random typeclass is still included for backwards compatibility. Uniform is for types where it is possible to sample from the type's entire domain; UniformRange is for types where one can sample from a specified range: class Uniform a where uniformM :: MonadRandom g s m => g s -> m a class UniformRange a where uniformRM :: MonadRandom g s m => (a, a) -> g s -> m a The proposal is a breaking change but the changes are not very intrusive and we have PRs ready for the affected downstream libraries: requires base >= 4.10 (GHC-8.2) StdGen is no longer an instance of Read randomIO and randomRIO were extracted from the Random class into separate functions In addition, there may be import clashes with new functions, e.g. uniform and uniformR. Further explanatory details may be found here <https://github.com/idontgetoutmuch/random/blob/v1.2-release-notes/RELEASE-N…> and the PR for the proposed new version is here <https://github.com/haskell/random/pull/61>. Here are some benchmarks run on a 3.1 GHz Intel Core i7. The full benchmarks can be run using e.g. stack bench. The benchmarks are measured in milliseconds per 100,000 generations. In some cases, the performance is over x1000(!) times better; the minimum performance increase for the types listed below is more than x35. | Name | Mean (1.1) | Mean (1.2) | Improvement| | ----------------------- | ---------- | ---------- | ---------- | | pure/random/Float | 30 | 0.03 | 1038| | pure/random/Double | 52 | 0.03 | 1672| | pure/random/Integer | 43 | 0.33 | 131| | pure/uniform/Word8 | 14 | 0.03 | 422| | pure/uniform/Word16 | 13 | 0.03 | 375| | pure/uniform/Word32 | 21 | 0.03 | 594| | pure/uniform/Word64 | 42 | 0.03 | 1283| | pure/uniform/Word | 44 | 0.03 | 1491| | pure/uniform/Int8 | 15 | 0.03 | 511| | pure/uniform/Int16 | 15 | 0.03 | 507| | pure/uniform/Int32 | 22 | 0.03 | 749| | pure/uniform/Int64 | 44 | 0.03 | 1405| | pure/uniform/Int | 43 | 0.03 | 1512| | pure/uniform/Char | 17 | 0.49 | 35| | pure/uniform/Bool | 18 | 0.03 | 618| | pure/uniform/CChar | 14 | 0.03 | 485| | pure/uniform/CSChar | 14 | 0.03 | 455| | pure/uniform/CUChar | 13 | 0.03 | 448| | pure/uniform/CShort | 14 | 0.03 | 473| | pure/uniform/CUShort | 13 | 0.03 | 457| | pure/uniform/CInt | 21 | 0.03 | 737| | pure/uniform/CUInt | 21 | 0.03 | 742| | pure/uniform/CLong | 43 | 0.03 | 1544| | pure/uniform/CULong | 42 | 0.03 | 1460| | pure/uniform/CPtrdiff | 43 | 0.03 | 1494| | pure/uniform/CSize | 43 | 0.03 | 1475| | pure/uniform/CWchar | 22 | 0.03 | 785| | pure/uniform/CSigAtomic | 21 | 0.03 | 749| | pure/uniform/CLLong | 43 | 0.03 | 1554| | pure/uniform/CULLong | 42 | 0.03 | 1505| | pure/uniform/CIntPtr | 43 | 0.03 | 1476| | pure/uniform/CUIntPtr | 42 | 0.03 | 1463| | pure/uniform/CIntMax | 43 | 0.03 | 1535| | pure/uniform/CUIntMax | 42 | 0.03 | 1493| Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch

11 21

Re: [core libraries] Improved TimerManager API
by George Wilson 01 Jun '20

01 Jun '20

Admittedly I'm not familiar with that module, but this change seems easy to make. It seems as though these functions don't exactly "fail"; rather they don't bother updating the queue if the change would be redundant. Is that correct? Could you explain why you want to detect this? Cheers, George On Wed, 13 May 2020 at 09:59, Mitchell Rosen <mitchellwrosen(a)gmail.com> wrote: > > Hi all, > > I'd like to propose we modify GHC.Event.updateTimeout and GHC.Event.unregisterTimeout to each return a Bool, indicating whether the update/unregister was successful. > > Thanks, > Mitchell > > -- > You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. > To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-core-libraries/CAKYGvgMMPdWUhjT_C….

3 2

Parsing Ratio with zero denominator
by Dannyu NDos 01 Jun '20

01 Jun '20

Shouldn't the parser be pfail rather than throwing an error?

4 4

What Haskell users are actively maintaining or deving software using ghc <8
by Carter Schonwald 30 May '20

30 May '20

Hey all, What are the oldest ghc versions folks are actually using to build software they actually use ? What are the contexts for these ? I know a lot of library maintainers, myself included try to make it easy to suport as wide a version range of ghc as possible. In my case I find it useful to just have another way to evaluate how stable I can make a library. That said, what actual old ghc versions are folks actually using? Afaict, the oldest ghc currently in a lts linux distro is ghc 7.0 in centos 6 Then centos 7 and the oldest Ubuntu lts are 7.6, then more recent distros plus most other os platforms like the bsds are on 8.0-8.4 as the oldest supported / provided ghc. Who are the users today and how important are they for todays library maintainers ?

15 30

ANN: Data.Monoid.First and Data.Monoid.Last are here to stay
by Simon Jakobi 29 May '20

29 May '20

Hi! I'm happy to report that the planned deprecation of Data.Monoid.{First,Last} [0] has finally been scrapped [1]. The original motivation for removing these newtypes of Maybe was to resolve the name conflict with Data.Semigroup.{First,Last} [2]. Unfortunately, while implementing the deprecation, I ended up discovering a whole host of problems with the suggested migration to (Maybe Data.Semigroup.First) and (Maybe Data.Semigroup.Last), which I have attempted to summarize in my email to the libraries mailing list [3]. I would like to thank everyone who contributed to the discussion of the matter, the CLC, and also everyone who pushed me to finally get the matter resolved. :) Cheers! Simon [0] http://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:Fi… [1] https://gitlab.haskell.org/ghc/ghc/-/commit/f44d7ae08442ae6227db37cacc97fe0… [2] https://mail.haskell.org/pipermail/libraries/2018-April/028712.html [3] https://mail.haskell.org/pipermail/libraries/2020-April/030357.html

1 0