- Libraries - Haskell.org

Add instance Monad ZipList
by Dannyu NDos 05 Jun '20

05 Jun '20

instance Monad ZipList where ZipList [] >>= _ = ZipList [] ZipList (x:xs) >>= f = ZipList $ do let ZipList y' = f x guard (not (null y')) let ZipList ys = ZipList xs >>= ZipList . join . maybeToList . fmap snd . uncons . getZipList . f head y' : ys instance MonadFail ZipList where fail _ = empty instance MonadPlus ZipList

9 19

random library: Request for Carter Tazio Schonwald (@cartazio) to step down as maintainer with immediate effect
by Profpatsch 05 Jun '20

05 Jun '20

I posted this comment on the thread of https://github.com/haskell/random/pull/62#issuecomment-638088258 Since it was deleted and the comment thread locked by Carter, I am escalating this request to the mailing list, where it cannot be deleted. Profpatsch <notifications(a)github.com> writes: > @cartazio Please take even a fleeting look at https://github.com/idontgetoutmuch/random/pulls?q=is%3Apr+is%3Aclosed, notice the amount of discussion and the timeline. > > This is the full-time work of a team of half a dozen of experts, probably breaching one man-year of effort, easily. > It cannot just be discarded out of hand. > > I have been following the discussions (spread over mailinglists, issue trackers and elsewhere), and I propose you hand over maintainership of `random` as a base package. A parallel issue with relevant discussion can be found at https://github.com/haskell/random/pull/61 I am writing this email from my personal account, because I fear for the health of the Haskell ecosystem, and I think Carter’s behaviour is extremely detrimental to it. I think a lot of other people feel the same way, so I encourage you to add your voice publicly. ~ Profpatsch

11 14

Hackage trustee selection process
by David Feuer 04 Jun '20

04 Jun '20

At present, there is no process for selecting Hackage trustees, there are no designated terms for them, and there is no process for removing them. This strikes me as most unfortunate. We trust that these folks will manage Hackage for the benefit of the community, but there is no process the community can rely on for ensuring the right people have trustee powers. Can we fix this situation? A couple specific suggestions: 1. Perhaps the Hackage trustees can adopt organizational standards similar to those of the Core Library Committee to get things going quickly. 2. Perhaps the CLC should be able to designate a certain number of its own members as Hackage trustees.

4 4

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

03 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

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

03 Jun '20

Ben, We invited anyone interested including Carter to participate in the design back in February. He did not do so. How much longer do you think we should give him? No serious work has been done on it since September 2014 and numerous promises to do something have never materialised. Is there any part of Carter’s critique that in your view has not been addressed by replies in this thread? We should be welcoming contributions and improve libraries when the opportunities arise and not wait another 5 years for perfection (which may never arrive). Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > Message: 4 > Date: Wed, 3 Jun 2020 13:11:08 +0200 > From: Ben Franksen <ben.franksen(a)online.de> > To: libraries(a)haskell.org > Subject: Re: Improving Random > Message-ID: <rb80gc$3ong$1(a)ciao.gmane.io> > Content-Type: text/plain; charset=utf-8 > > I agree that communication is an important aspect of maintainership. Not > responding to PRs for a long period of time is bad because it lets > people wonder if anything is being done about it at all. That can be > quite frustrating as I know from my own experience. > > That said, Carter's critique of the proposed API (the classes) looks > valid to me. I understand that coming up with a better API design that > accommodates all the cool permormance improvements may take its time. > > @Carter: why don't you try to eleborate your critique of the proposed > API on the tracker and present a rough sketch of where you think things > should go instead. Then you guys can all work together to flesh this out. > > My experience is that writing things down helps a lot to get them > clearer in my head. If the side effect is people feel that their > contributions are respected and actually worked on, so much the better. > > Cheers > Ben > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > > > ------------------------------ > > End of Libraries Digest, Vol 202, Issue 4 > *****************************************

4 3

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 31 May '20

31 May '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 31 May '20

31 May '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 29 May '20

29 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