- Libraries - Haskell.org

Consideration to add `ordering` function to `Data.Ord`
by Ian Treyball 11 Jan '21

11 Jan '21

Good day, In short, I think it would be nice to add the following ordering function to the Data.Ord module: -- | Case analysis for the 'Ordering' type. @'ordering' x y z o @ evaluates to @x@ -- when @o@ is 'LT', @y@ when @o@ is EQ, and evaluates to @z@ when @o@ is 'GT'. ordering :: a -> a -> a -> Ordering -> a ordering lt _ _ LT = lt ordering _ eq _ EQ = eq ordering _ _ gt GT = gt This would be essentially analogous to the bool function from Data.Bool: bool :: a -> a -> Bool -> a bool f _ False = f bool _ t True = t Because the bool function is the case-analysis for the Bool data type, and the order of the parameters matches the order in which the constructors are defined: Data Bool = False | True I decided it would be consistent to follow the same approach for the ordering implementation and so I use the particular ordering (no pun intended) for the parameters to also match the order of the constructors: Data Ordering = LT | EQ | GT I will also add an example use case, here is how show could be implemented using the proposed function (of course, we momentarily assume it is not derived, for sake of simplicity): instance Show Ordering where show :: Ordering -> String show = ordering "LT" "EQ" "GT" Please let me know if you would wish for me to share more compelling examples, I have a few, but they are longer (so not here included for brevity's sake). I hope the formatting comes out okay, I will link to a gist[1], just in case. If this sounds acceptable, please let me know how to proceed (would this fall under "Core Libraries Proposal"[2]? I don't necessarily see adding this function as a breaking change, so I'm not sure, but I can surely fill one out if it's appropriate); otherwise, thank you for your time and consideration. Respectfully, Ian Treyball [1] https://gist.github.com/subttle/b49762a929f25e349381ef161bbc33d0 [2] https://github.com/haskell-core/core-libraries-proposals

3 2

Adding partial foldl1' to Foldable?
by Viktor Dukhovni 11 Jan '21

11 Jan '21

Given that Foldable currently has: - foldr and foldr' - foldl and foldl' - foldMap and foldMap' and also has only: - foldr1 - foldl1 it seems natural to ask whether there it should also have a strict variant of at least foldl1, since the non-strict variant has rather limited applicability, and users would/should in most cases want/use the strict `foldl1'` instead. -- Viktor. P.S. I just joined the list today, but noticed that coincidentally, there's already a recent dicussion of Foldable1, which rather overlaps with this question, and perhaps the partial `foldr1` and `foldl1` should be seen as deprecated, once a suitable class of non-empty containers provides total variants. But perhaps on the other hand, given that the partial functions already exist, perhaps adding the strict companions is warranted? I am asking because I am writing some expository prose for Data.Foldable, to go at the bottom of the document, structurally along the lines of what I contributed for Data.Traversable, but with a fairly different focus. The goal is draw careful distinctions between strict recursive and lazy corecursive reductions, explaining their proper usage and typical implementations. The "missing" `foldl1'` was something I ran into while working on part of the writeup.

5 11

can/should Functor have a quantified coercible constraint?
by Carter Schonwald 08 Jan '21

08 Jan '21

Hey everyone! for context, I have some code where I was seeing how far coerce lets me go to avoid doing wrappers for certain codes, i found i had to write the following (mapping an operation over to its newtyped sibling) ``` -- > :t QRA.wither --- forall a b f . Applicative f => (a -> f (Maybe b)) -> RAList a -> f (RAList b) --- wither :: forall a b f . (Applicative f, (forall c d . Coercible c d => Coercible (f c) (f d)) ) => (a -> f (Maybe b)) -> RAList a -> f (RAList b) wither = \f la -> coerce $ QRA.wither f $ coerce la ``` i'd much rather be able to write ``` wither :: forall a b f . (Applicative f) => (a -> f (Maybe b)) -> RAList a -> f (RAList b) wither = \f la -> coerce $ QRA.wither f $ coerce la ``` this seems like it'd be best done via something like changing the functor class definition to ``` class (forall c d . Coercible c d => Coercible (f c) (f d)) ) => Functor f where .. ``` is there any specific reason why this is not feasible? I cant think of a GADT where this wouldn't be totally safe to do (because unlike in foldable, f is in both the domain and co-domain), but maybe i'm not being imaginative enough? look forward to learning what our obstacles are to making this happen for ghc 9.2 :) -Carter

10 33

Proposal: Export Solo from Data.Tuple
by David Feuer 03 Jan '21

03 Jan '21

GHC.Tuple now exports data Solo a = Solo a for use as the canonical lifted unary tuple. I propose to export it from Data.Tuple. David

3 2

withFile defeats dead handle closure
by David Feuer 31 Dec '20

31 Dec '20

withFile keeps the handle it creates alive until the user action completes. If we want to avoid this, we can. All that's required is to capture the weak reference that holds the handle's finalizer. Then instead of closing the handle in the end (or on exception) using hClose, withFile can run the handle's finalizer. Should we do this? Or does it run too much against the idea that handles should be managed as explicitly as possible?

7 12

containers: intersections for Set, along with Semigroup newtype
by Reed Mullanix 29 Dec '20

29 Dec '20

Hey all, I've found myself reaching for the following function a couple of times now, so I figured it might make a good addition. intersections :: Ord a => NonEmpty (Set a) -> Set a intersections (s :| ss) = Foldable.foldl' intersection s ss In a similar vein, we may as well add the following newtype + instance combo: newtype Intersection a = Intersection { getIntersection :: Set a } instance (Ord a) => Semigroup (Intersection a) where (Intersection a) <> (Intersection b) = Intersection $ intersection a b stimes = stimesIdempotent Would love to hear everyone's thoughts on this! Thanks Reed Mullanix

17 37

Improve documentation for Real
by David Feuer 27 Dec '20

27 Dec '20

The Real class has one method: -- | the rational equivalent of its real argument with full precision toRational :: a -> Rational This is ... pretty weird. What does "full precision" mean? For integral and floating point types, it's fine. It's not at all meaningful for 1. Computable reals 2. Real algebraic numbers 3. Real numbers expressible in radicals 4. Rational numbers augmented with some extra numbers like pi 5. Geometrically constructable reals 6. Etc. Can we settle on a meaning for toRational? The properFraction method of the RealFrac class has basically the same issue.

4 6

Why are `sum` and `product` defined via foldMap' and not foldl'?
by Viktor Dukhovni 24 Dec '20

24 Dec '20

Is there a compelling reason for: sum = getSum #. foldMap' Sum product = getProduct #. foldMap' Product rather than: sum = foldl' (+) 0 product = foldl' (*) 1 A quick ghci session with today's GHC head yields: λ> import qualified Data.Foldable as F λ> :set +s λ> F.sum [0..10000000] 50000005000000 (2.98 secs, 1,612,368,368 bytes) λ> F.foldl' (+) 0 [0..10000000] 50000005000000 (0.28 secs, 880,065,112 bytes) The `foldl'` variant looks substantially more efficient (at least for lists), is there some important context in which `foldMap'` is preferable? -- Viktor.

6 8

Re: type class Boolean
by Johannes Waldmann 22 Dec '20

22 Dec '20

[I sent this to -cafe by mistake] > most useful kind of instance would be symbolic booleans Yes. Ersatz has this: https://hackage.haskell.org/package/ersatz-0.4.8/docs/Ersatz-Bit.html#t:Boo… I also use this class (re-exported) in https://hackage.haskell.org/package/obdd Then modules typically start with import Prelude hiding ( not, and, or, (&&), (||) ) -- possibly more import Ersatz slightly annoying but you get used to it ... - J.

1 0

Numeric supports base 8, 10, 16 but not 2 -- why?
by Artem Pelenitsyn 08 Dec '20

08 Dec '20

Dear Libraries, I noticed the Numeric module has special-cased functions to read and show integral types in bases 8, 10, 16 but not for base 2. There are also generic-over-base versions, so an interested client can implement the special case for base 2 themselves with little hassle. Still, I think base 2 is common enough that we could support it along with base 8, 10, 16 out of the box. What do you think? I'm happy to submit a merge request if you concur. Kind regards, Artem Pelenitsyn

8 8