- Libraries - Haskell.org

New CLC co-chairs, New maintainers of `base`
by chessai . 13 Mar '20

13 Mar '20

As you know from previous announcements, Edward Kmett is stepping down as CLC Chair, and Ryan Scott is stepping down from the CLC altogether. They are both also stepping down as co-maintainers of base. Carter Schonwald and myself, chessai, will be the new CLC co-chair and co-maintainers of base. Thank you again to Edward and Ryan for all of their accomplishments and hard work. Carter and I look forward to serving this wonderful community.

1 0

Fwd: [nushio3/cmaes] Make work under ghc 8.6.3 (#3)
by dominic＠steinitz.org 07 Mar '20

07 Mar '20

I should have attached this. Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch > Begin forwarded message: > > From: Masahiro Sakai <notifications(a)github.com> > Subject: Re: [nushio3/cmaes] Make work under ghc 8.6.3 (#3) > Date: 1 March 2020 at 02:05:26 GMT > To: nushio3/cmaes <cmaes(a)noreply.github.com> > Cc: idontgetoutmuch <dominic(a)steinitz.org>, Author <author(a)noreply.github.com> > Reply-To: nushio3/cmaes <reply+AAL2POK6HTHVOLJEQ7ZGOCF4M34WNEVBNHHBVVURWQ(a)reply.github.com> > > The author @nushio3 <https://github.com/nushio3> passed away in 2019 and cannot merge this pull request. > It might be better to work on your fork, and possibly to take over ownership of the package on Hackage if you want to continue maintaining. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub <https://github.com/nushio3/cmaes/pull/3?email_source=notifications&email_to…>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAL2POOVBEDDCQULWJGRXNDRF…>. >

1 0

Fwd: [nushio3/cmaes] Make work under ghc 8.6.3 (#3)
by dominic＠steinitz.org 07 Mar '20

07 Mar '20

The owner of https://hackage.haskell.org/package/cmaes has sadly passed away - see below. May I request ownership is transferred to me https://hackage.haskell.org/user/DominicSteinitz. Many thanks Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.org Twitter: @idontgetoutmuch PS > TakayukiMuranushi is part of the following groups: > > Maintainers for Paraiso > Maintainers for authoring > Maintainers for binary-search > Maintainers for citation-resolve > Maintainers for cmaes > Maintainers for doctest-prop > Maintainers for dynamic-object > Maintainers for embeddock-example > Maintainers for embeddock > Maintainers for formura > Maintainers for typelevel-tensor > Maintainers for unicode-show

1 0

Improved interface to UArray
by Zemyla 03 Mar '20

03 Mar '20

It's currently hard to describe that a type should be usable with UArray or IOUArray, and almost impossible to describe without QualifiedConstraints that it should be usable with STUArray. And it's actually impossible to use GeneralizedNewtypeDeriving to derive new instances of IArray or MArray. It also means that it's difficult to keep the three sets of instances in sync. Therefore, there should be (taking inspiration from primitive) a class that describes types which can be used in unboxed arrays. It'd be something along the lines of: class Unboxed e where unsafeNewUArray :: Int# -> e -> State# s -> (# State# s, MutableByteArray# s #) unsafeNewUArray_ :: Const (Int# -> State# s -> (# State# s, MutableByteArray# s #)) e unsafeReadUArray :: MutableByteArray# s -> Int# -> State# s -> (# State# s, e #) unsafeWriteUArray :: MutableByteArray# s -> Int# -> e -> State# s -> State# s unsafeIndexUArray :: ByteArray# -> Int# -> e And then the instances for UArray, STUArray, and IOUArray would be: instance Unboxed e => IArray UArray e where ... instance Unboxed e => MArray IOUArray e IO where ... instance Unboxed e => MArray (STUArray s) e (ST s) where ... Incidentally, this also means it'd be less effort to add instances like Unboxed CInt, Unboxed a => Unboxed (Complex a), and Unboxed Ordering.

3 6

Re: [core libraries] Rename NonEmpty.groupWith/sortWIth to *On*
by Carter Schonwald 29 Feb '20

29 Feb '20

I think I follow. Pedantic point : when you say semantics, it might be less confusing and more precise to performance tradeoffs. My English language and naive preference is to assume *With functions grammar better. Or *by. I think the *on idiom is younger relatively. Can I challenge you to reflect on what challenge you are trying to address with this proposal and if there’s a course of action that you feel improves everything but breaks no code ? And what would make the change an improvement for software using these modules already On Sat, Feb 15, 2020 at 7:36 AM Philip Hazelden <philip.hazelden(a)gmail.com> wrote: > Hi, > > > clc gets / reads libraries anyways, no need to double email : ) > > Fair enough. I tried to follow the process suggested at > https://wiki.haskell.org/Core_Libraries_Committee by emailing both lists. > I was surprised that the mail to libraries@ got rejected. No big deal, > but should that page be updated? > > > are we talking about the specifics of the implementations while stilling > having the same observable pure results, OR something different? > > For sortWith/sortOn, yeah, my proposal #3 would change performance > characteristics but not the pure semantics. > > The existing functions that we have are > > Data.List.sortOn f = > map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` > (y, x)) > GHC.Exts.sortWith f = sortBy (\x y -> compare (f x) (f y)) > Data.List.NonEmpty.sortWith = sortBy . comparing > > Where the first two have type signature `Ord b :: (a -> b) -> [a] -> [a]` > and the last is `Ord b :: (a -> b) -> NonEmpty a -> NonEmpty a`. > > Data.List.sortOn is implemented in a way that calls its projection > function just once per list element, but it allocates an intermediate list. > If the projection function is expensive, that'll be worth it. The style of > the functions named sortWith avoids the intermediate list, but at the cost > of calling the projection twice for each comparison; so that'll be better > if the projection is cheap. > > I bring this up because issue 12044 suggested removing `GHC.Exts.sortWith` > for being semantically the same as `Data.List.sortOn`, and the performance > question was brought up there. To be clear, I don't think it's a big deal. > > > please spell this out more concretely, i'm not able to decode what you > mean unambiguiously. Just changing the names of some functions in base in > isolation breaks code for no reason, > > My proposals #1 and #2 are just to change the names of functions, yeah. > But it's not for no reason. > > There are two problems with the current names. The smaller one, applying > to all of these functions, is that I believe the "On" pattern is more > widely used. And so if a user tries to guess what these functions will be > called, they'll most likely go for that. > > (I don't have any hard data here, admittedly. We see "On" in > Data.List.sortOn, but also many functions in Data.List.Extra like `nubOn`, > `groupOn`, `maximumOn`. Admittedly that's not in base. But I'll also note > that NonEmpty.sortWith was originally called sortOn, and the groupWith > functions were originally requested with the name groupOn; see > https://github.com/ekmett/semigroups/pull/52. So yeah, my sense is that > "On" is what most people will expect.) > > The more significant one, applying to the group functions but not to > sortWith, is that the only other function in base named `groupWith` has a > comparable type signature but different semantics. > Data.List.NonEmpty.groupWith is "group according to a projection function" > while GHC.Exts.groupWith is "sort and group according to a projection > function". If someone gets these behaviours confused, they're going to sort > when they don't intend to, or to not sort when they do intend to. Using > more consistent naming may help avoid that. > > It may be that this isn't enough reason to break code. If the committee > decides that it's not, then fair enough. > > Though, it now occurs to me that renaming `GHC.Exts.groupWith` to > `groupAllOn` or `groupAllWith` or something (in Data.List.Extra it's named > "groupSortOn"), could also help clear up the larger problem while breaking > less code. So I'll offer that possibility for consideration too. > > > > On Thu, Feb 13, 2020 at 10:17 PM Carter Schonwald < > carter.schonwald(a)gmail.com> wrote: > >> Hello Philip, clc gets / reads libraries anyways, no need to double email >> : ) >> >> perhaps i'm missing something, are we talking about the specifics of the >> implementations while stilling having the same observable pure results, OR >> something different? >> >> When does each have a clear performance win? >> >> at least from my native english speaker perspective, sortWith is better >> grammar. Are you describing a choice of performance characteristics >> related to *On vs *With functions? >> >> also, could you spell out which reference implementations of which >> convention enshrine which meanings you have in mind? >> >> I dont see a good reason to change the names that are provided from one >> to the other. Are you merely making the case that both styles should be >> exported from certain places, and that a particular choice of evaluation >> trade offs be enshrined by the respective naming convention? >> >> >> please spell this out more concretely, i'm not able to decode what you >> mean unambiguiously. Just changing the names of some functions in base in >> isolation breaks code for no reason, so if you are arguing for that, i'm >> gonna say nope :) >> >> On Wed, Feb 12, 2020 at 12:58 PM Philip Hazelden < >> philip.hazelden(a)gmail.com> wrote: >> >>> Hi, >>> >>> I'm referring to these functions: `sortWith` `groupWith` `groupAllWith` >>> `groupWith1` `groupAllWith1`. >>> >>> The `On` suffix is more common for such things, and I anticipate it's >>> what most users will normally expect them to be named. >>> >>> Additionally, the name `groupWith` is potentially misleading. That name >>> is also used in GHC.Exts[1], for a function with the same type signature >>> but different semantics. `GHC.Exts.groupWith` sorts its input list, unlike >>> `NonEmpty.groupWith` or `Data.List.Extra.groupOn`. (In NonEmpty, we have >>> `groupAllWith` for group-with-sort. So we have three names, two semantics, >>> and no consistency.) >>> >>> According to https://github.com/ekmett/semigroups/pull/52, `With` was >>> chosen because: >>> >>> > The preferred vocabulary for On here is With to match the combinators >>> in GHC.Exts from the "comprehensive comprehensions" paper. That'd make it >>> so that if you use these with comprehensive comprehensions turned on and >>> RebindableSyntax turned on then you'd get these combinators. >>> >>> But I don't see anything in the docs which suggests that the >>> TransformListComp extension[2] uses these functions implicitly, or >>> interacts with RebindableSyntax[3]. So perhaps I'm missing something, but >>> my guess is this is no longer a concern. >>> >>> The case for `sortWith` is weaker, since it might trip people up but it >>> won't introduce unexpected semantics. There's also a counter argument in >>> https://gitlab.haskell.org/ghc/ghc/issues/12044. `Data.List.sortOn` >>> only computes the mapping function once for each element, while >>> `GHC.Exts.sortWith` computes it every time it does a comparison but uses >>> fewer allocations. `Data.NonEmpty.sortWith` acts like the latter. My >>> suggestion would be to replace it with a `sortOn` implemented like >>> `Data.List.sortOn`, but I also don't think it would be terrible to have >>> both, or even to just rename and leave this small inconsistency. If there's >>> no agreement on this function, I think it would be worth renaming the group >>> functions anyway. >>> >>> And so I propose, in descending order of how much I care: >>> >>> 1. Rename the group functions to be named "On" instead of "With". >>> >>> 2. Rename `sortWith` to `sortOn` In the case of `sortWith`, also >>> reimplement it as >>> >>> 3. Reimplement `sortOn` as >>> >>> sortOn :: Ord b => (a -> b) -> NonEmpty a -> NonEmpty a >>> sortOn = fmap snd . sortBy (comparing fst) . fmap (\x -> let y = f x >>> in y `seq` (y, x)) >>> >>> I assume the process here would be to leave the existing names for a >>> time with deprecation warnings, and then remove them a few versions down >>> the line. >>> >>> [1] >>> https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:grou… >>> [2] >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… >>> [3] >>> https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… >>> >>> Best, >>> Phil >>> >>> -- >>> 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/CALB5dS-5qKjK6rmvF… >>> <https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF…> >>> . >>> >>

5 7

Welcome emily and Cale!!
by Carter Schonwald 28 Feb '20

28 Feb '20

Let’s welcome Cale and emily! Before general announce probably good to figure out that voting for chair thing eds stepping down from. @ed: what does chairing clc entail? Also Neil somehow wasn’t on the list before so Ccing him just in case. -Carter

1 1

Is a a way to do a “Bare” state monad in modern Haskell?
by Carter Schonwald 22 Feb '20

22 Feb '20

1) we have a monad instance for (r -> ) 2) is there some way we can arrange sans newtype an instance for its state monad sibling ( /\ x . s-> (s,x)) without a type lambda or some new type or injective type families? I can definitely see that this is def not possible with h98-h2010, is this otherwise expressible? Mostly just curious if there’s some trick that’s now possible :)

2 1

Replace Random
by dominic＠steinitz.org 18 Feb '20

18 Feb '20

Hello libraries, Following a great blog [post] by @lehins, a group of us (@curiousleo, @lehins and me) are trying to improve the situation with the `random' library. @curiousleo and I have created a [resource] that tests the quality of Haskell random number generators via well known (and not so well known) test suites: dieharder, TestU01, PractRand and gjrand. The current `random' does not fare well especially with the use of the `split' function (but this is well known and the [reason] why `QuickCheck' moved from using it in [2.8] to using [tf-random] in [2.9] and latterly [splitmix] in [2.13]): see [this] for example. On the other hand, `splitmix' [passes] bigcrush[1]. The putative proposal is to replace the current algorithm in `random' with that of `splitmix'[2] and to remove the performance bottleneck by changing the interface (the current interface causes the performance infelicity by making "all of the integral numbers go through the arbitrary precision Integer in order to produce the value in a desired range") - see @lehin's blog for more details. Can anyone interested: * Create a separate issue for each concern they have (eg. range for floats (0, 1] vs [0, 1], etc.) [here]. * Submit PRs with target at the [interface-to-performance] branch (or into master if it is vastly different approach) with your suggested alternatives. If you are going to raise a concern then it might be worth reading some of the [discussions] that have already taken place. We think once we have the API flashed out, switching to splitmix will be a piece of cake and will require an addition of just a few lines of code and removal of current StdGen related functionality. For historical reasons instead of removing it we could move StdGen into a separate module with a disclaimer not to use it, but that isn't terribly important. The Random Team (@lehins, @curiousleo, @idontgetoutmuch) [post] https://alexey.kuleshevi.ch/blog/2019/12/21/random-benchmarks/ [resource] https://github.com/tweag/random-quality [reason] http://publications.lib.chalmers.se/records/fulltext/183348/local_183348.pdf [2.8] https://hackage.haskell.org/package/QuickCheck-2.8 [tf-random] https://hackage.haskell.org/package/tf-random [2.9] https://hackage.haskell.org/package/QuickCheck-2.9 [splitmix] https://hackage.haskell.org/package/splitmix [2.13] https://hackage.haskell.org/package/QuickCheck-2.13 [this] https://github.com/tweag/random-quality/blob/master/results/random-word32-s… [passes] https://github.com/tweag/random-quality/blob/master/results/splitmix-word32… [here] https://github.com/idontgetoutmuch/random/issues [interface-to-performance] https://github.com/idontgetoutmuch/random/tree/interface-to-performance [discussions] https://github.com/idontgetoutmuch/random/pull/1 Footnotes _________ [1] Just to clarify: both random and splitmix pass BigCrush. random fails any statistical test immediately (e.g. [SmallCrush] (https://github.com/tweag/random-quality/blob/master/results/random-word32-s…) and other even smaller ones) when a sequence based on split is used. splitmix passes Crush when split is part of the sequence, but I've seen it fail one test in BigCrush ("LinearComp"). So we should just be careful here: splitmix itself passes BigCrush and split-based sequences all pass Crush, but not all pass BigCrush. [2] `split' is already availaible as an instance: `instance Random SMGen where'.

2 3

Taking over maintainership of cautious-file (or does anyone know of an alternative?)
by Brent Yorgey 13 Feb '20

13 Feb '20

The cautious-file package http://hackage.haskell.org/package/cautious-file has not been updated by the maintainer, Robin Green, since 2013 (though there have been a few Hackage trustee updates since then). The linked source repository was hosted on patch-tag.com and no longer exists. I tried contacting the maintainer on January 25 but have not heard back. I hereby announce my intention to take over as maintainer of the package. (As a side note, as far as I know my diagrams-haddock package is the only thing on Hackage that depends on it.) Alternatively, if anyone knows of a different, actively maintained package that provides similar functionality, I'd love to hear about it! -Brent

3 3

Re: [core libraries] Rename NonEmpty.groupWith/sortWIth to *On*
by Carter Schonwald 13 Feb '20

13 Feb '20

Hello Philip, clc gets / reads libraries anyways, no need to double email : ) perhaps i'm missing something, are we talking about the specifics of the implementations while stilling having the same observable pure results, OR something different? When does each have a clear performance win? at least from my native english speaker perspective, sortWith is better grammar. Are you describing a choice of performance characteristics related to *On vs *With functions? also, could you spell out which reference implementations of which convention enshrine which meanings you have in mind? I dont see a good reason to change the names that are provided from one to the other. Are you merely making the case that both styles should be exported from certain places, and that a particular choice of evaluation trade offs be enshrined by the respective naming convention? please spell this out more concretely, i'm not able to decode what you mean unambiguiously. Just changing the names of some functions in base in isolation breaks code for no reason, so if you are arguing for that, i'm gonna say nope :) On Wed, Feb 12, 2020 at 12:58 PM Philip Hazelden <philip.hazelden(a)gmail.com> wrote: > Hi, > > I'm referring to these functions: `sortWith` `groupWith` `groupAllWith` > `groupWith1` `groupAllWith1`. > > The `On` suffix is more common for such things, and I anticipate it's what > most users will normally expect them to be named. > > Additionally, the name `groupWith` is potentially misleading. That name is > also used in GHC.Exts[1], for a function with the same type signature but > different semantics. `GHC.Exts.groupWith` sorts its input list, unlike > `NonEmpty.groupWith` or `Data.List.Extra.groupOn`. (In NonEmpty, we have > `groupAllWith` for group-with-sort. So we have three names, two semantics, > and no consistency.) > > According to https://github.com/ekmett/semigroups/pull/52, `With` was > chosen because: > > > The preferred vocabulary for On here is With to match the combinators in > GHC.Exts from the "comprehensive comprehensions" paper. That'd make it so > that if you use these with comprehensive comprehensions turned on and > RebindableSyntax turned on then you'd get these combinators. > > But I don't see anything in the docs which suggests that the > TransformListComp extension[2] uses these functions implicitly, or > interacts with RebindableSyntax[3]. So perhaps I'm missing something, but > my guess is this is no longer a concern. > > The case for `sortWith` is weaker, since it might trip people up but it > won't introduce unexpected semantics. There's also a counter argument in > https://gitlab.haskell.org/ghc/ghc/issues/12044. `Data.List.sortOn` only > computes the mapping function once for each element, while > `GHC.Exts.sortWith` computes it every time it does a comparison but uses > fewer allocations. `Data.NonEmpty.sortWith` acts like the latter. My > suggestion would be to replace it with a `sortOn` implemented like > `Data.List.sortOn`, but I also don't think it would be terrible to have > both, or even to just rename and leave this small inconsistency. If there's > no agreement on this function, I think it would be worth renaming the group > functions anyway. > > And so I propose, in descending order of how much I care: > > 1. Rename the group functions to be named "On" instead of "With". > > 2. Rename `sortWith` to `sortOn` In the case of `sortWith`, also > reimplement it as > > 3. Reimplement `sortOn` as > > sortOn :: Ord b => (a -> b) -> NonEmpty a -> NonEmpty a > sortOn = fmap snd . sortBy (comparing fst) . fmap (\x -> let y = f x > in y `seq` (y, x)) > > I assume the process here would be to leave the existing names for a time > with deprecation warnings, and then remove them a few versions down the > line. > > [1] > https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-Exts.html#v:grou… > [2] > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… > [3] > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_ext… > > Best, > Phil > > -- > 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/CALB5dS-5qKjK6rmvF… > <https://groups.google.com/d/msgid/haskell-core-libraries/CALB5dS-5qKjK6rmvF…> > . >

1 0