- Libraries - Haskell.org

Maintenance of text-icu (Bryan O'Sullivan)
by Andreas Abel 14 Feb '21

14 Feb '21

Package text-icu (Bryan O'Sullivan) seems to be unmaintained since 2017 https://github.com/haskell/text-icu/issues/30 with the last release in 2015 https://hackage.haskell.org/package/text-icu-0.7.0.1 Unfortunately, the latest release is incompatible with ICU 68. Has anyone heard from Bryan recently? I mean, he is a Haskell celebrity... His last activity on github.com was in August 2017. Anyone interested in maintaining this package? Since Agda depends on text-icu, I could stand in as a temporary maintainer to at least merge the most important pull requests, until there is a new maintainer. Best regards, Andreas

3 5

Unix package maintenance
by chessai 07 Feb '21

07 Feb '21

All, The unix package, a core library, has been stalling. (just some examples, going back up to 6 years: [1] [2] [3] [4]). Previously, unix was maintained by HVR, a prolific maintainer and open source contributor of the Haskell ecosystem. His work to date has been invaluable for many of us today. However, recently, he's been increasingly unavailable, which happens and is perfectly understandable - life happens. But, the ecosystem cannot stall (eg [5], [6]) because of a single contributor, regardless of that contributor's merits or previous work. Right now, we have many useful (and in some cases necessary for other work, e.g, for hackage-server 2.0) patches to unix which need to be acted on. Additionally, there are potential maintainers willing to do the work ([7], [8], [9], [10]). On behalf of the CLC, which owns unix, I am announcing that the unix library will henceforth be under maintainership of the aforementioned individuals, who are all trusted and knowledgeable members of the community, looking to improve the library. I appreciate everyone who has contributed code to unix, maintained unix in the past, and those who stepped forward to help maintain it going forward. I hope that these changes will help facilitate positive growth for the library and ultimately the community, as they have with other core libraries which have recently been given new supplies of maintainers. [1]: https://github.com/haskell/unix/pull/145 [2]: https://github.com/haskell/unix/pull/21 [3]: https://github.com/haskell/unix/pull/110 [4]: https://github.com/haskell/unix/pull/122 [5]: https://github.com/haskell/zlib/pull/37 [6]: https://github.com/haskell/zlib/pull/39#issuecomment-774598088 [7]: https://github.com/hs-viktor [8]: https://github.com/Bodigrim [9]: https://github.com/emilypi [10]: https://github.com/davean

2 1

Bikeshedding the cstringLength name?
by Viktor Dukhovni 25 Jan '21

25 Jan '21

An equivalent function of course already exists outside base: $ hoogle 'CString -> IO CSize' Data.ByteString.Internal c_strlen :: CString -> IO CSize unsurprisingly defined as: foreign import ccall unsafe "string.h strlen" c_strlen :: CString -> IO CSize Would it make sense to give the proposed new Foreign.C.Types function the same "c_strlen" name? And then at some point in the future, Data.ByteString.Internal can just re-export it? Would using `cstringLength`, as proposed, be too confusable with the `cstringLength#` primop? -- Viktor.

2 2

Improving the instances of Data.Functor.{Product,Sum}
by chessai . 25 Jan '21

25 Jan '21

Consider the Eq instance for these types. Currently we rely on: (Eq1 f, Eq1 g, Eq a) But some potential improvements include changing to: (Eq (f (g a))) (FlexibleContexts) or (forall x. Eq x => Eq (f x), forall x. Eq x => Eq (g x), Eq a) (QuantifiedConstraints) There was a discussion sometime last year about the same thing regarding Semigroup/Monoid instances for `Compose` [1]. Additionally, the question has been raised again for Data.Functor.{Product,Sum} on Gitlab [2, 3]. There has been no consensus in either case, but that's not too worrying as both discussions have been brief. I'm currently not happy with the {Eq,Ord,Show}{1,2} family of classes, and would hope to work toward their removal, or at least the shrinking of their presence in base. Even though the linked proposals are about a single type, I think it's important that we come up with a decision and stick with it. Having different APIs for different types here would be pretty confusing, and some could even say sloppy. Please let me know your thoughts. [1]: https://mail.haskell.org/pipermail/libraries/2019-July/029771.html [2]: https://gitlab.haskell.org/ghc/ghc/issues/17015 [3]: https://gitlab.haskell.org/ghc/ghc/merge_requests/1704

10 22

Proposal: Add atomic IORef operations to Data.IORef
by David Feuer 24 Jan '21

24 Jan '21

GHC.IORef currently exports atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b)) atomicSwapIORef :: IORef a -> a -> IO a atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns both the old value in the IORef and the full result of applying the user-supplied function to that. This is a pretty thin wrapper around the newish atomicModifyMutVar2# primop, which has replaced the less powerful atomicModifyMutVar#. atomicSwapIORef atomically installs a user-supplied value in an IORef and returns the old value. It is currently implemented using atomicModifyIORef2, but it can and should be reimplemented using its own, more efficient primop. I propose to add both of these functions to Data.IORef. David

4 8

expose strlen from Foreign.C.String
by chessai 22 Jan '21

22 Jan '21

I've wanted the following before: foreign import ccall unsafe "strlen" cstringLength# :: Addr# -> Int# cstringLength :: CString -> Int cstringLength (Ptr s) = I# (cstringLength# s) A natural place for this seems to be Foreign.C.String. Thoughts?

7 14

Re: Proposal: Add atomic IORef operations to Data.IORef
by David Feuer 15 Jan '21

15 Jan '21

Please do feel free to suggest a better name. I would certainly have named it better had I been able to think of one. On Fri, Jan 15, 2021 at 3:33 PM <olivercharles(a)fastmail.com> wrote: > > I would suggest better naming that suffixing with '2', if the suggestion was to add them with the same names as GHC.IORef > On 15 Jan 2021, 20:05 +0000, David Feuer <david.feuer(a)gmail.com>, wrote: > > GHC.IORef currently exports > > > atomicModifyIORef2 :: IORef a -> (a -> (a,b)) -> IO (a, (a, b)) > > atomicSwapIORef :: IORef a -> a -> IO a > > > atomicModifyIORef2 is a lot like atomicModifyIORef, but it returns > > both the old value in the IORef and the full result of applying the > > user-supplied function to that. This is a pretty thin wrapper around > > the newish atomicModifyMutVar2# primop, which has replaced the less > > powerful atomicModifyMutVar#. > > > atomicSwapIORef atomically installs a user-supplied value in an IORef > > and returns the old value. It is currently implemented using > > atomicModifyIORef2, but it can and should be reimplemented using its > > own, more efficient primop. > > > I propose to add both of these functions to Data.IORef. > > > David > > _______________________________________________ > > Libraries mailing list > > Libraries(a)haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

1 0

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