November 2020 - 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

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

MonadZip laws
by Joseph C. Sible 28 Nov '20

28 Nov '20

Are either of these statements implied by the MonadZip laws? I don't see a way that they would be. mzipWith f (return x) (return y) = return (f x y) munzip (return (x, y)) = (return x, return y) If so, how? If not, do they make sense to add as laws of their own? Joseph C. Sible

1 0

Re: [Haskell-cafe] Psa : perhaps time for maintainers to start migrating off Travis ci
by Carter Schonwald 20 Nov '20

20 Nov '20

this mirrors my current understanding of all the choices myself, and it certainly helps that GH *explicitly* puts the OSS/free tier on equal or footing with paid customers. which absolutely makes sense given their various corporate structures (GH actions is a path to folks perhaps wanting to use azure services more organically? ) On Mon, Nov 16, 2020 at 5:39 PM Mihai Maruseac <mihai.maruseac(a)gmail.com> wrote: > As a user of all of the following, GitHub Actions > Circle CI > Travis. > > You get much more control on Github Actions, you can cache stuff, you > can control when it runs. > > On Mon, Nov 16, 2020 at 10:17 AM <ulidtko(a)gmail.com> wrote: > > > > Speaking of CI systems and OpenSource, I'd like to mention CircleCI as > > well: https://circleci.com/open-source/ > > (No affiliation, just a happy user.) > > > > Did have slightly negative experience with TravisCI recently, can > > confirm the sentiment. > > > > On Mon, Nov 16 2020 at 12:02:52 PM -0600, Carter Schonwald > > <carter.schonwald(a)gmail.com> wrote: > > > Hey everyone: it looks like, from my perspective and experiences, > > > that Travis ci should perhaps now be viewed as not open source > > > friendly. Or even converging on hostile? > > > > > > 1) crazy long queue times/ latency for oss ci actions to run > > > > > > 2) very low concurrency on oss builds. > > > > > > 3) very low build build minute caps for oss that require high touch > > > customer support contact to adjust. > > > > > > I’ve started moving my own projects slowly to gh actions for now, > > > though there’s also gitlab ci , src hut and other options that may > > > suit different folks. > > > > > > There’s definitely some ways to keep on having the clever cabal > > > caching we know and love that folks like the Haskell-ci folks and > > > others have hacked out for Travis be available on other platforms, > > > though I don’t think there’s consolidated docs for those yet ? > > > Def seen it discussed though. > > > > > > https://github.com/haskell-CI/haskell-ci/issues/411 > > > > > > Heres a url to my dupe ticket where I share an example naive use of > > > the setup Haskell gh actions Config, definitely not perfect. But > > > kinda amazing to have Mac and Linux and windows ci all in one ! :) > > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > To (un)subscribe, modify options or view archives go to: > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > Only members subscribed via the mailman list are allowed to post. > > > > -- > Mihai Maruseac (MM) > "If you can't solve a problem, then there's an easier problem you can > solve: find it." -- George Polya >

3 2

Let ReadP carry a failure message
by Dannyu NDos 20 Nov '20

20 Nov '20

Firstly, I propose a new class. This class is like MonadFail, but with "error bind" operator: class Monad m => FailMsg m where failMsg :: String -> m a (>?=) :: m a -> (String -> m a) -> m a Laws are: * For every (x :: m a), if (x ≡ fail msg) for some (msg :: String), msg shall be unique. * For (x ≡ fail msg), (x >?= f ≡ f msg). If such msg doesn't exist, (x >?= _ ≡ x). Basic instances are: instance e ~ String => FailMsg (Either e) where failMsg = Left Left msg >?= f = f msg x >?= _ = x instance FailMsg IO where failMsg = throwIO . userError action >?= f = catch action (f . ioeGetErrorString) Now let's focus on ReadP. Let P carry a failure message: data P a = Get (Char -> P a) | Look (String -> P a) | Fail String | Result a (P a) | Final (NonEmpty (a,String)) Then we have: instance FailMsg P where fail = Fail Fail msg >?= f = f msg p >?= _ = p instance FailMsg ReadP where fail msg = R (\_ -> fail msg) R m >?= f = R (\k -> case m k of Fail msg -> let R n = f msg in n k p -> p ) This is incredibly useful. This can be used when there are multiple types of parse error.

5 7

improvements in the core libraries sphere
by chessai 20 Nov '20

20 Nov '20

All, I'd like to share that over the past few months, the following core libraries have picked up maintenance pace at an alarmingly great rate: - vector - bytestring - primitive - unix - random Great thanks to the following people: - Andrew Lelechenko (https://github.com/Bodigrim) (has helped with all 5 libraries!) - Simon Jakobi (https://github.com/sjakobi) (has helped with: bytestring) - Viktor Dukhovni (https://github.com/vdukhovni and https://github.com/hs-viktor) (has helped with: bytestring, unix) - Alexey Kuleshevich (https://github.com/lehins) (has helped with: vector, primitive, random) - Alexey Khudyakov (https://github.com/Shimuuar) (has helped with: vector, random) - Dominic Steinitz (https://github.com/idontgetoutmuch) (has helped with: random) - Leonhard Markert (https://github.com/curiousleo) (has helped with: random) - Andrew Martin (https://github.com/andrewthad) (has helped with: primitive, vector) - David Feuer (https://github.com/treeowl) (has helped with: vector, bytestring, primitive, random) The changes they have made represent hundreds of hours of work for the Haskell community. Once languishing core libraries have now been revitalised. I don't have exact numbers, but a quick look at any of these libraries, along with a recollection of how they were before, will show you just how much things are changing for the better. Now, the next biggest hurdle is text. Also, filepath is unmaintained (but at least is mostly stable). If anyone knows of a good maintainer(s) for either of these, please let me know. Thanks

1 0

[Proposal] Integration of helpers to operate on Newtypes in base
by Hécate 12 Nov '20

12 Nov '20

Hello, CLC and haskell-libraries, I am opening a proposal process to consider the integration of several helper functions in `base`, operating on Newtypes, and all based on `coerce`. My motivations are that we ought to provide a minimum set of tools in order to work effectively with one of our most beloved and ubiquitous language features. Now, these functions that I am about to present to you all do not come out of nowhere. They have been integrated to Kowainik's alternative prelude "Relude", and seem to have found their use amongst their users, me included. Their documentation can be found here => https://hackage.haskell.org/package/relude-0.7.0.0/docs/Relude-Extra-Newtyp… but I am reproducing them below for convenience: --- un :: forall a n. Coercible a n => n -> a Unwraps value from newtype. ``` >>> newtype Size = Size Int deriving Show >>> un @Int (Size 5) 5 >>> un (Size 5) == length ['a', 'x', 'b'] False ``` --- wrap :: forall n a. Coercible a n => a -> n Wraps value to newtype. Behaves exactly as 'un' but has more meaningful name in case you need to convert some value to newtype. ``` >>> newtype Flag = Flag Bool deriving (Show, Eq) >>> wrap False == Flag True False ``` --- under :: forall n a. Coercible a n => (n -> n) -> a -> a Applies function to the content of newtype. This function is not supposed to be used on newtypes that are created with the help of smart constructors. ``` >>> newtype Foo = Foo Bool deriving Show >>> under not (Foo True) Foo False >>> newtype Bar = Bar String deriving Show >>> under (filter (== 'a')) (Bar "abacaba") Bar "aaaa" ``` As well as the coerced composition operator: (#.) :: Coercible b c => (b -> c) -> (a -> b) -> (a -> c) (#.) _f = coerce {-# INLINE (#.) #-} Which currently lives in https://hackage.haskell.org/package/base-4.14.0.0/docs/src/Data.Functor.Uti… but is not exported. Regarding the location of these functions, I either see them living in their own "Data.Newtype", or they could join Data.Coerce. I would personally create a new module as to avoid "polluting" Data.Coerce with non-class functions, but this is my personal preference. Thank you for reading. -- Hécate ✨ 🐦: @TechnoEmpress IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

6 12

[Proposal] Unify various specialized mkWeak functions in base?
by Cheng Shao 11 Nov '20

11 Nov '20

Hi everyone, In System.Mem.Weak we have an mkWeak function to create weak pointers. But we also have a lot of specialized mkWeak* functions, e.g. mkWeakIORef, mkWeakThreadId, etc, to ensure that we actually pass the unlifted closure instead of the lifted one as the key to the underlying mkWeak# primop. The various specialized mkWeak* functions' signatures don't have a coherent style. Some functions like mkWeakIORef always take a Haskell finalizer argument, while mkWeakThreadId doesn't take a finalizer argument at all. This is troublesome for users since: * Sometimes a user doesn't want to attach a finalizer at all. They could pass a "pure ()" dummy finalizer, but that'll still come with a minor bit of extra runtime overhead * For mkWeakThreadId, they may want to attach a finalizer. The runtime supports it, but the type signature doesn't say so. Of course, they can always add a few extensions and call mkWeak# as they wish, but it would be nicer if we have a uniform API to allow a Haskell finalizer to be added optionally. The simplest API could be something like (forgive my terrible naming): class WeakKey k where mkWeakWithRealKey :: WeakKey k => k -> v -> Maybe (IO ()) -> IO (Weak v) The WeakKey class is just a way of exposing the unlifted field from a single datacon wrapper type, and I think this can be useful for other purposes as well, so maybe we can do something like: class Unlift a where type Unlifted a :: TYPE 'UnliftedRep unlift :: a -> Unlifted a mkWeakWithRealKey :: Unlift k => k -> v -> Maybe (IO ()) -> IO (Weak v) Thanks for reading so far, what are your thoughts on this? The proposed extended interfaces can be easily implemented in 3rd-party packages, but it would be nice to add to base. Cheers, Cheng Shao

2 2

Min & Max without Bounded
by Jon Purdy 11 Nov '20

11 Nov '20

The ‘Min’ and ‘Max’ newtypes from ‘Data.Semigroup’ require a ‘Bounded’ constraint for their ‘Monoid’ instances, because they wrap a value of type ‘a’ rather than ‘Maybe a’. The latter is something I’ve needed a few times lately for types that cannot be bounded (or just don’t want to be), and it seems base-worthy to me. So if it hasn’t been proposed and dismissed already (or if it has been proposed, but just got backburnered), I’d like to suggest adding the following new types, and at least the following instances, to either ‘Data.Semigroup’ or ‘Data.Monoid’: newtype Minimum a = Minimum { getMinimum :: Maybe a } deriving (Eq, Ord, Monoid, Semigroup) via (Down (Maybe (Down (Max a)))) newtype Maximum a = Maximum { getMaximum :: Maybe a } deriving (Eq, Ord, Monoid, Semigroup) via (Maybe (Max a)) These instances could be specified explicitly instead of with ‘DerivingVia’, but the essential notion here is that ‘Maximum’ uses its empty value ‘Nothing’ as a “negative infinity”, less than all other ‘Just’ values, while ‘Minimum’ reverses that to use ‘Nothing’ as the corresponding “positive infinity”. I assume these would also want more or less the same array of instances as for the existing ‘Min’ and ‘Max’, and there is the usual opportunity to bikeshed about the naming and how these instances ought to relate to one another. I figure that at least the ‘Ord’ instance should match the ordering that the ‘Semigroup’ instance uses, to avoid some potential for confusion/bugs. As for use cases, I tend to reach for these things either in configuration records with many fields that I’m combining by semigroup append (Max, Any, set union, and so on) or when I have a possibly-empty container and don’t want to write e.g. ‘maximum (0 : xs)’ to avoid partiality. For example, ‘foldMap (Minimum . Just &&& Maximum . Just)’ computes the minimum and maximum in a single pass, returning Nothing for a null input. Any thoughts, critiques, questions, rebuttals, edge cases, use cases, &c. are most welcome!

3 4