January 2021 - Libraries

Fwd: New Libraries Proposal process
by Carter Schonwald 01 Jul '21

01 Jul '21

Are you sure about this approach? I think you need to start with an open discussion , And have a open ended thread about ideas for how to improve how we do things. A proposals process / formal process isn’t always a win. This sortah approach demands a lot more dedicated human power and support admin than I think is tenable for the libraries ecosystem today. Merry Friday and be well -Carter ---------- Forwarded message --------- From: chessai <chessai1996(a)gmail.com> Date: Fri, Sep 11, 2020 at 10:02 PM Subject: Re: New Libraries Proposal process To: Carter Schonwald <carter.schonwald(a)gmail.com> This has been discussed on and off for a few months now, amongst CLC, between members of CLC and GHC Steering/Haskell.org, Tweag, Target, IOHK, Serokell, etc. My only regret is that a lot of the conversation happened privately. > All libraries process needs to start on the libraries mailing list Not anymore. The libraries mailing list has proven to be ineffective when it comes to getting stuff done. Mailing lists are not the right format for this. Furthermore, I don't see how emails are more conducive to deep discussion than github comments. There are many GitHub issue trackers and PRs which show otherwise. This new process will never be perfect and of course will need some tweaking, but the current process is very poor and gets little done. Most proposals I ever see end up with no resolution. Since the GHC Proposals process has proven to be a net positive, much of the structure was taken from there and adapted to core libraries. On Fri, Sep 11, 2020, 19:52 Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > Where was this discussed or proposed? All libraries process needs to start > on the libraries mailing list. And soemtimes Perhaps moving to clc list for > resolving tie breaking on controversial choices. > > The libraries archive goes back pretty far and email threading seems to > scale far better for participating in complex discussions than does githubs > comment collapsing on large discussions. > > On Fri, Sep 11, 2020 at 3:20 PM chessai <chessai1996(a)gmail.com> wrote: > >> All, >> >> >> There is a new Libraries Proposal process, inspired by the GHC Proposals >> process. >> >> Core Library APIs are critical. It's easy for a sensible proposal to >> languish or simply get dropped on the floor; and (in the other direction) a >> bit too easy for a proposal to make it into the core libraries without >> receiving the scrutiny it deserves. Most of the proposals that have been >> made on this mailing list, become lost to the archives. It's not easy for >> anyone to answer the question "what decisions has the CLC made recently?" >> without trawling a huge email archive. >> >> Of course, this is mostly for breaking changes or "big" introductions; we >> don't need a full proposal over something tiny, e.g. "a module from vector >> is missing a fold". That would be more appropriate on vector's issue >> tracker, and left to the maintainers to deal with. >> >> I encourage anyone interested to get started by reading the README at >> https://github.com/haskell-core/core-libraries-proposals. >> >> >> >> _______________________________________________ >> >> Libraries mailing list >> >> Libraries(a)haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >> >> > >

10 13

New Libraries Proposal process
by chessai 01 Jul '21

01 Jul '21

All, There is a new Libraries Proposal process, inspired by the GHC Proposals process. Core Library APIs are critical. It's easy for a sensible proposal to languish or simply get dropped on the floor; and (in the other direction) a bit too easy for a proposal to make it into the core libraries without receiving the scrutiny it deserves. Most of the proposals that have been made on this mailing list, become lost to the archives. It's not easy for anyone to answer the question "what decisions has the CLC made recently?" without trawling a huge email archive. Of course, this is mostly for breaking changes or "big" introductions; we don't need a full proposal over something tiny, e.g. "a module from vector is missing a fold". That would be more appropriate on vector's issue tracker, and left to the maintainers to deal with. I encourage anyone interested to get started by reading the README at https://github.com/haskell-core/core-libraries-proposals.

5 7

Proposal: Add 'Foldable1' to base
by Reed Mullanix 22 Feb '21

22 Feb '21

With the recent discussion around the addition of 'intersection' to containers, I think it might be a good time to re-open the discussion surrounding adding 'Foldable1' to base. For context, 'Foldable1' would be a subclass of 'Foldable' that abstracts folds over non-empty containers. Alternatively, it can be seen as a method of combining together the elements of a container using a semigroup. The contents of this class have been discussed previously (See [1,2]), and the version presented in this proposal is taken from [1]. class Foldable t => Foldable1 t where {-# MINIMAL foldMap1 | foldr1map #-} fold1 :: Semigroup m => t m -> m -- the defining member, like foldMap but only asking for Semigroup foldMap1 :: Semigroup m => (a -> m) -> t a -> m -- strict foldMap1, cf foldMap' foldMap1' :: Semigroup m => (a -> m) -> t a -> m -- analogue of toList toNonEmpty :: t a -> NonEmpty a -- left&right, strict&non-strict folds foldr1 :: (a -> a -> a) -> t a -> a foldr1' :: (a -> a -> a) -> t a -> a foldl1 :: (a -> a -> a) -> t a -> a foldl1' :: (a -> a -> a) -> t a -> a -- these can have efficient implementation for NonEmptySet maximum1 :: Ord a => t a -> a minimum1 :: Ord a => t a -> a -- head1 have efficient implementation for NonEmpty and Tree -- last1 for symmetry head1 :: t a -> a last1 :: t a -> a -- fold variants with premap. -- Without this map, we cannot implement foldl using foldr etc. foldrMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b foldlMap1 :: (a -> b) -> (b -> b -> b) -> t a -> b foldrMap1' :: (a -> b) -> (b -> b -> b) -> t a -> b This has a couple of benefits. On the practical side, we can provide total alternatives to existing partial functions (IE: 'foldr1' and friends). It also enables us to fold over containers using a semigroup instance, which comes up suprisingly often. Naming: -------------------------------------------------------------------------------- Historically, the biggest source of controversy with this proposal has been over the name. The class currently exists in semigroupoids [3] under the name 'Foldable1', though there was some discussion around renaming it to 'SemiFoldable' [4]. However, if we keep the name unchanged, it makes the migration path nice and straightforward, and the possible name conflict with Data.Functor.Classes seems unlikely. Migration: -------------------------------------------------------------------------------- If we decide to go with 'Foldable1' as the name, we should be able to perform this change with 0 breakage. References: [1] https://mail.haskell.org/pipermail/libraries/2019-November/030059.html [2] https://gitlab.haskell.org/ghc/ghc/-/issues/13573 [3] https://hackage.haskell.org/package/semigroupoids-5.3.4/docs/Data-Semigroup… [4] https://github.com/ekmett/semigroupoids/issues/26

7 7

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

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