February 2020 - Libraries

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

What do you assume when you see fromListN in a library?
by Carter Schonwald 24 May '20

24 May '20

Hey everyone: When you see fromListN as a function in a library, do you assume / presume it’s expecting an exactly N element list ? Or do you expect/tolerate other behavior ? Should it reject shorter lists? Should it truncate or reject longer lists? A corner case of this came up in some bug discussion I was having regarding vector, and I shall claim and or presume that most folks assume exact size with prompt rejection of too long or too short. Thoughts please ? -Carter

13 32

Improved interface to UArray
by Zemyla 04 Mar '20

04 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 29 Feb '20

29 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 23 Feb '20

23 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 14 Feb '20

14 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