February 2020 - Libraries

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

Fwd: add instance PrintfArg Ratio
by Dannyu NDos 10 Feb '20

10 Feb '20

---------- Forwarded message --------- 보낸사람: Dannyu NDos <ndospark320(a)gmail.com> Date: 2020년 2월 9일 (일) 오후 3:14 Subject: Re: add instance PrintfArg Ratio To: Henning Thielemann <lemming(a)henning-thielemann.de> Bugfix: instance (Integral a, PrintfArg a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then let d = " % " ++ formatArg (denominator x) (FieldFormat Nothing Nothing Nothing s l "" 'd') "" (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length d)) w, a) n = formatArg (numerator x) (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'd'}) "" in formatArg (n ++ d) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "doxXb" then formatArg (round x :: Integer) f else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let a' = case a of Just LeftAdjust -> Nothing _ -> a digits = formatArg (truncate (x * 10 ^ p') :: Integer) (f {fmtPrecision = Nothing, fmtAdjust = a', fmtChar = 'd'}) "" (n,sig) = splitAt (length digits - p') digits in formatArg (n ++ '.' : sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) fp = formatArg q (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0)

3 4

Performance of `count`ing a char in a ByteString
by Georg Rudoy 08 Feb '20

08 Feb '20

Hi there, tl;dr: I've noticed ByteString's `count`'s performance can be improved by a factor between 2.5 and 8 by explicitly using certain SIMD extensions, so what's the policy on those? Results of a small C benchmark (since the corresponding BS routine is implemented in C anyway) are available here ( https://github.com/0xd34df00d/counting-chars ), as well as some sample code to give the idea of what's happening (which might be incorrect/suboptimal, my SSE/AVX is rusty). I'll also put a sample input file if I manage to get git-lfs going. This change only really makes sense for large strings, but that's a somewhat common use case at least in my applications, so I wanted to gather some initial feedback, as well as ask a couple of questions and emphasize a couple of points. 1. How are SIMD extensions generally controlled? 2. Is depending on gcc OK? If so, we could leverage gcc's support of automatically generating a dispatching function that'll check cpuid for the supported extensions and call the right implementation. 3. Does BS' allocator give any guarantees on the alignment? It'd be nice to get rid of that "prefix" part that makes sure the SIMD code churns through 64-byte-aligned data. 4. Note that compiling with `-O3 -march=native` makes code effectively non-portable (at least, to CPUs lacking extensions the compiler decides to use), while the code with `-O2`, explicit SIMD versions and a dispatching function will get the best performance using the SIMD extensions available, degrading gracefully on older hardware. So, personally, when I look at that table with the results I compare the SSE4.2/AVX2 implementations against the `-O2` column. 5. Thanks Gregory Collins for mentioning PCMPESTRM somewhere — that remark sparked the desire to do some intrinsics stuff. -- Georg Rudoy

2 2

Fwd: add instance PrintfArg Ratio
by Dannyu NDos 08 Feb '20

08 Feb '20

---------- Forwarded message --------- 보낸사람: Dannyu NDos <ndospark320(a)gmail.com> Date: 2020년 2월 8일 (토) 오전 8:22 Subject: Re: add instance PrintfArg Ratio To: Henning Thielemann <lemming(a)henning-thielemann.de> In that case, here (with some bugfixes): instance (Integral a, PrintfArg a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then let d = " % " ++ formatArg (denominator x) (FieldFormat Nothing Nothing Nothing s l "" 'd') "" (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length d)) w, a) n = formatArg (numerator x) (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'd'}) "" in formatArg (n ++ d) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "doxXb" then formatArg (round x :: Integer) f else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let n = truncate x sig = '.' : goF (x - fromInteger n) p' (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) b = formatArg n (FieldFormat w' Nothing a' s l "" 'd') "" in formatArg (b ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e (w',a') = case a of Just LeftAdjust -> (Nothing, Nothing) _ -> (fmap (subtract (length sig)) w, a) fp = formatArg q (f {fmtWidth = w', fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0) 2020년 2월 8일 (토) 오전 6:44, Henning Thielemann <lemming(a)henning-thielemann.de>님이 작성: > > On Fri, 7 Feb 2020, Dannyu NDos wrote: > > > It just is so convenient. > > > > instance (Integral a, Show a) => PrintfArg (Ratio a) where > > Why should a Printf instance be base on Show? Wouldn't it better to format > numerator and denominator using printf, too? >

1 1

Re: Break `abs` into two aspects
by Andrew Lelechenko 08 Feb '20

08 Feb '20

On Tue, 28 Jan 2020, Dannyu NDos wrote: > `abs` represents a norm, but its type is wrong There are two useful meanings of `abs`, which coincide for integers. One is a norm. Another one is to define `abs` as a mapping from a ring R to a factor ring R / U(R), where U(R) is a ring of units, and `signum` as a mapping from R to U(R) such that `abs a * signum a = a`. > This enables us to implement rings (Num) and fields (Fractional) without > concerning about norms. For example, Gaussian integers. For Gaussian integers I find convenient to define `signum z` with a codomain {1, i, -1, -I} (basically, to which quadrant does z belong?) and `abs z` with the first quadrant as a codomain. Best regards, Andrew

5 20

I'm concerned about the affine-types extension and its impact on ghc and haskell at large
by Carter Schonwald 08 Feb '20

08 Feb '20

https://github.com/ghc-proposals/ghc-proposals/pull/111#issuecomment-583664… https://www.reddit.com/r/haskell/comments/f0jigv/im_concerned_about_the_lon… As current maintainer of vector, and a member of the CLC, both of which roles really should be AFFIRMATIONAL stakeholders in this, I only see costs and concerns. As someone who's spent the past few years doing a LOT of modelling and prototyping around marrying linear logic, formal methods, and functional programming in an applied industrial setting, i should be an Affirmational stakeholder. yet again I am not. theres very real costs in the complexity and scope of impact that impact EVERY single user and stakeholder of ghc and haskell. And I do not see any concrete population that benefits. cale even makes a very constructive and articulate point > I don't know how much my opinion matters at this point, but I'd really like to see the non-toy real-world use cases of this before I can even consider thinking that it would be a good idea to merge to the main compiler. It has such a huge potential impact on so many people in the Haskell community: > > * Library maintainers who start getting PRs that make "improvements" to linearity while making their libraries harder to maintain because their interface becomes more rigid, and harder to understand because the types are more complicated. > > * Beginners, or simply ordinary users of the language who have to pay the mental overhead of living with the linear types and polymorphism spreading everywhere as types are adjusted to make terms more usable in places where one is concerned with linearity. > > * Commercial users of the language who pay for the additional time taken by all their employees waiting for the compiler to run, regardless of whether or not they're using the extension. If Carter's 6-7% slowdown is real even in cases where one doesn't care about the extension, I can imagine wanting to make a fork without the extension. The compiler is already 2 orders of magnitude slower than I'd like. If that weren't the case, maybe 6-7% wouldn't be a huge deal. While ghci is often helpful at shortening the feedback loop, it's not always a viable solution. > > > But really, I just want to know how anyone would put this to practical use in a real setting -- it needs to be _really_ compelling to make up for the social cost. It can't be that hard for Tweag, or someone enthusiastic, to live on a fork until they have a decent case study to show the world, so we can say "okay, that's actually really cool, maybe we actually want that everywhere".

1 0

add instance PrintfArg Ratio
by Dannyu NDos 07 Feb '20

07 Feb '20

It just is so convenient. instance (Integral a, Show a) => PrintfArg (Ratio a) where formatArg x f@(FieldFormat w p a s l _ c) = if elem c "gGv" then showsPrec 0 x else if elem c "doxXb" then formatArg (round x :: Integer) (f {fmtPrecision = Nothing, fmtChar = 'd'}) else case p of Nothing -> error "Text.Printf.formatArg: precision not given" Just p' -> if p' <= 0 then formatArg x (f {fmtPrecision = Nothing, fmtChar = 'd'}) else if elem c "fF" then let n = truncate x sig = '.' : goF (x - fromInteger n) p' b = case a of Just ZeroPad -> formatArg n (f {fmtWidth = fmap (subtract (length sig)) w, fmtPrecision = Nothing, fmtChar = 'd'}) "" _ -> show n in formatArg (b ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else if elem c "eE" then let (q,e) = log10 x sig = c : show e a' = case a of Just ZeroPad -> a _ -> Nothing fp = formatArg q (f {fmtWidth = fmap (subtract (length sig)) w, fmtAdjust = a', fmtChar = 'f'}) "" in formatArg (fp ++ sig) (f {fmtPrecision = Nothing, fmtChar = 's'}) else error "Text.Printf.formatArg: bad format character" where goF _ 0 = "" goF x p = case compare x 0 of LT -> '-' : goF (negate x) p EQ -> "0" GT -> if 1 == p then show (round (10 * x) :: Integer) else let x10 = 10 * x n = truncate x10 in show n ++ goF (x10 - fromIntegral n) (p - 1) log10 x | x < 1 = let (q,e) = log10 (x * 10) in (q, e - 1) | 10 <= x = let (q,e) = log10 (x / 10) in (q, e + 1) | otherwise = (x, 0)

2 1

deepseq: Add more instances. #50
by Travis Whitaker 07 Feb '20

07 Feb '20

Greetings Haskellers, I am writing to draw your attention to https://github.com/haskell/deepseq/pull/50. This PR adds NFData instances for UArray, ForeignPtr, and TVar. The instances for ForeignPtr and TVar have proven to be somewhat controversial. I'll refer to these as "reference types" from here on out, since similar concerns have been raised with respect to e.g. IORef. I think the arguments presented here apply equally well to IORef. In summary: the argument against these instances is that rnf forces the evaluation of the reference value itself, not the value referred to by the reference. This is potentially confusing to NFData users. For example, a user might expect that calling force on a TVar value will leave the value to which the TVar refers in normal form. If this assumption doesn't hold, the user's program will leak thunks. The argument for these instances is as follows: whether or not a reference value is in normal form has nothing to do with whether or not the referred-to value is in normal form. For example, consider ForeignPtr. ForeignPtr's type constructor argument is just a phantom. Each ForeignPtr value is just an Addr# with some finalizers. Whether or not these values are in normal form has nothing to do with whether or not the value the enclosed address may (or may not!) point to is in normal form. Indeed, an NFData instance for ForeignPtr, TVar, or IORef that attempted to force the referred-to value would require unsafe IO. I'm curious to hear other's thoughts about these arguments. I'm hopeful that the proposed instances may be added, since I've encountered these instances as orphans on numerous occasions. Thanks for your time, Travis Whitaker

12 18

Fwd: Misleading documentation for `fail`
by Artem Pelenitsyn 07 Feb '20

07 Feb '20

Hello, The fail package [1] lists libraries(a)haskell.org as maintainer's address, so I'm writing here. The documentation for the single module in the package claims: This module can be imported for defining forward compatible MonadFail instances: import qualified Control.Monad.Fail as Fail instance Monad Foo where (>>=) = {- ...bind impl... -} -- Provide legacy fail implementation for when -- new-style MonadFail desugaring is not enabled. fail = Fail.fail ... But defining the fail method inside a Monad instance will produce an error on GHC 8.8+. Should this bit be removed? -- Best, Artem [1]: http://hackage.haskell.org/package/fail

2 1

Read (Ratio a) should also parse a decimal point literal
by Dannyu NDos 06 Feb '20

06 Feb '20

Given a string representing a decimal point literal (ex. "0.25"), the number it represents is guaranteed to be rational. It seems appropriate for Ratio to parse such strings. readDecimalRatio :: (Integral a, Read a) => ReadPrec (Ratio a) readDecimalRatio = parens $ do Number x <- lexP return (numberToRational x) Combine this by (+++) with the original `readPrec` from the instance Read Ratio.

1 0