September 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

Status of tasty-discover
by John Ky 28 Sep '20

28 Sep '20

Hello, Does anyone know what the status of tasty-discover <https://hackage.haskell.org/package/tasty-discover> is? The package links to http://git.coop/lwm/tasty-discover, which redirects to https://git.coop/decentral1se/tasty-discover, which says *Archived project! Repository and other project resources are read only*. I'd like to raise a ticket on the project, but haven't been able to. Cheers, -John

3 2

Diagonalization/ dupe for monads and tuples?
by Carter Schonwald 26 Sep '20

26 Sep '20

It was pointed out to me in a private communication that the tuple function \x->(x,x) is actually a special case of a diagonalization for biapplicative and some related structures monadicially. Another example in the same flavor is pure impl for the applicative instance for sized lists. diag x = bipure x x So framed a litttle differently, there’s definitely an abstraction or common pattern lurking here. Perhaps folks can help Tease this out. One person I chatted with this morning alluded to it being relevant to computational flavors of adjunctions or some such ? It def matters in a different way when doing computation resource aware programming in a symmetric monoidal category. Let’s collect some ideas and patterns and get to the bottom of this!

18 40

[ANN] bytestring-0.11.0.0
by Andrew Lelechenko 26 Sep '20

26 Sep '20

On behalf of the maintainers team I'm happy to announce that bytestring-0.11.0.0 (http://hackage.haskell.org/package/bytestring-0.11.0.0) is finally released. It is to be shipped with the upcoming GHC 9.0. Highlights from the changelog (https://github.com/haskell/bytestring/blob/0.11.0.0/Changelog.md) * Optimize internal representation of ByteString reducing allocations. * Rewrite rules for {take,drop}While, any, all, findInd{ex,ices} (an order of magnitude faster in certain cases). * Faster (up to 5%-30%) implementations of fold{l,r}, scan{l,r}, mapAccum{L,R}, any, all, filter. * Add indexMaybe and synonym (!?) for safe indexing. * Re-export Data.ByteString.Lazy.{from,to}Strict from Data.ByteString. * Remove deprecated modules and functions. Many people contributed their time and effort to make this release happen. Just to name a few in no particular order, mostly according to `git log`: * Alexandre Esteves * Andreas Klebinger * Andrew Martin * Ben Gamari * Cole Miller * Edward Kmett * Fintan Halpenny * Fumiaki Kinoshita * Hécate Kleidukos * Peter Duchovni * Sergey Vinokurov * Simon Jakobi * Sylvain Henry * Viktor Dukhovni * me Here is an incantation for `stack` folks: resolver: nightly-2020-09-23 packages: - . extra-deps: - bytestring-0.11.0.0 - github: haskell/cabal commit: 5139d6e72d391bffa3cf06f08884277799eb0b45 subdirs: - Cabal - binary-0.8.8.0 - directory-1.3.6.0 - text-1.2.3.2 - unix-2.7.2.2 - parsec-3.1.14.0 - process-1.6.9.0 allow-newer: true Best regards, Andrew

1 0

Correct behaviour of Bounded (Down a)
by David Beacham 22 Sep '20

22 Sep '20

Hi all, The current instance for `Bounded a => Bounded (Down a)` derives the `minBound` and `maxBound` exactly as they are for the underlying type `a` where I think they should be flipped to respect the flipped ordering of `Down a`? I have a feeling this has been come up in some other context/list before but I couldn't find a reference to it when searching - so sorry if this is a duplicate. I've got a corresponding MR here: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/4081 Thanks, David.

9 15

[ANN] bytestring-0.11.0.0-rc1
by Andrew Lelechenko 19 Sep '20

19 Sep '20

On behalf of the maintainers team I'm happy to announce bytestring-0.11.0.0-rc1: https://github.com/haskell/bytestring/tree/0.11.0.0-rc1 This is a first major release since 2012, so I would like to encourage everyone to give it a try before it is shipped with GHC 9.0. The update focuses on performance improvements and removes several deprecated functions and modules. Changelog: https://github.com/haskell/bytestring/blob/0.11.0.0-rc1/Changelog.md Diff: https://github.com/haskell/bytestring/compare/0.10.12.0...0.11.0.0-rc1 Here is an example of cabal.project: packages: . source-repository-package type: git location: https://github.com/haskell/bytestring tag: 0.11.0.0-rc1 allow-newer: *:bytestring And an example of stack.yaml: resolver: nightly-2020-09-16 packages: - . extra-deps: - github: haskell/bytestring commit: 96c95391025c1ce2240f6dc7bcad06d4191e7793 - github: haskell/cabal commit: 5139d6e72d391bffa3cf06f08884277799eb0b45 subdirs: - Cabal - binary-0.8.8.0 - directory-1.3.6.0 - text-1.2.3.2 - unix-2.7.2.2 - parsec-3.1.14.0 - process-1.6.9.0 allow-newer: true Best regards, Andrew

3 2

What to do with Ord1 (Down a) instance
by Fumiaki Kinoshita 18 Sep '20

18 Sep '20

I was looking at the list of highest priority issues, and I noticed that one of them is blocked for a long time: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2158 Is this something we can submit to new core-libraries-proposals repository ( https://github.com/haskell-core/core-libraries-proposals) to get more attention?

2 1

naturalToWord vs 'clampNaturalToWord'
by Keith 16 Sep '20

16 Sep '20

The short of it is, clampNaturalToWord :: Natural → Word clampNaturalToWord n = case n of NatS# w -> W# w _ -> maxBound results in much better space and time use than naturalToWord, which always takes the least significant Word of the Natural. Because naturalToWord takes the least significant Word, you always have to check for size before conversion. Even though you do check, GHC has to assume that, after conversion, the big Natural could have resulted in a small Word and will uselessly duplicate all branches for both cases. Is there anything wrong with clamping by default in this case? --Keith Sent from my phone with K-9 Mail.

3 2