October 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

Stepping away
by Sean Chalmers 30 Oct '20

30 Oct '20

Hi all, For various reasons I'm not interested in maintaining my Haskell packages any more. If anyone has any interest in taking over then I am happy to hand them over: async-io-either classy-influxdb-simple haskell-time-range hoist-error reflex-dom-svg servant-waargonaut tasty-hedgehog-coverage tasty-wai waargonaut Been swell, swellings gone down. Cheers, Sean Chalmers

5 10

[Proposal] Strict `sum` and `product`
by Hécate 26 Oct '20

26 Oct '20

My fellow Haskell developers, contributors and maintainers, I wish to present what is certainly a controversial proposal for the `base` library: Making the `sum` and `product` functions from the `base` library strict. This is not a new question, the debate is old, but I am personally convinced that the existence of those two lazy functions is something that should never have happened. One of the first goals that led to the creation of Haskell was to enable collaboration and research in the domain of lazy (or non-strict) programming languages and techniques. While it led to the discovery of new methods and ways to represent programs, we also realised that this paradigm has proven to produce sub-optimal implementations for these functions. And while maintaining backward compatibility *is* important when designing and maintaining a programming language, we have thankfully developed deprecation mechanisms that can be used to signal that bad, or sub-optimal decisions of the past can be corrected. To refresh our collective memory, here is the current state of things, regarding `sum`: ``` ❯ ghci +RTS -M1024m GHCi, version 8.10.1: https://www.haskell.org/ghc/ :? for help λ❯ sum [1..10^9] *** Exception: heap overflow ``` Whereas, with an alternative implementation, such as `foldl'`: ``` λ❯ foldl' (+) 0 [1..10^9] 500000000500000000 (31.35 secs, 88,000,076,288 bytes) ``` I do not think a heap overflow, and the underlying space leak occasioned by the laziness of `foldl`, are behaviours we should aim to preserve for the sake of backward compatibility. And actually, I think that moving these two functions to a strict, space leak-free implementation would benefit the lazy PL research domain by showing a good counter-example of why it is not necessarily suitable for every kind of computation. I also think, and this is rooted from experience, that we must strive to empower our users with the power of laziness. Not burden them with it. Standing on the shoulders of giants is what made Haskell so great, but this should not prevent us from spreading our wings to go higher. ——— Now, there have been Prelude replacements (such as Relude) and companion libraries (like `strict`) who have been shipping such alternative implementations for quite some time now. A point that can be raised is: Why should we bother? Isn't `strict` already enough? To this I answer: `strict` and Relude, ultimately, patches on an tire's inner tube. We may be able to roll with them for some distance, but their very existence is a response to an abnormal situation that we have grown to accept. However, any bicycle rider who has the means to change their tire should do so. I believe we have the means to do so. Another point that could be raised as well is the fact that this implementation change would deviate from the 2010 Haskell Report[0]. If we want to stay true to the spirit and letter of the Report, this is actually a non-issue. Indeed, it is noted that: > This report defines the syntax for Haskell programs and an informal abstract semantics for the meaning of such programs. We leave as implementation dependent the ways in which Haskell programs are to be manipulated, interpreted, compiled, etc. This includes such issues as the nature of programming environments and the error messages returned for undefined programs (i.e. programs that formally evaluate to⊥).[1] As well as in chapter 9: > In this chapter the entire Haskell Prelude is given. It constitutes a specification for the Prelude. Many of the definitions are written with clarity rather than efficiency in mind, and it is not required that the specification be implemented as shown here.[2] And finally, regarding the non-strict nature of Haskell, the Report references strict evaluation to avoid "unneeded laziness."[3] Thus it was expected that laziness would not be a silver bullet, and it could harm performance. ——— Regarding the implementation detail, `sum` and `product` would piggy-back on the already-present `foldMap'` function. Thank you very much for reading, I believe we can all go together towards improving the experience of Haskell developers, starting with this. [0]: Haskell 2010 Language Report, https://www.haskell.org/definition/haskell2010.pdf [1]: Haskell 2010 Language Report, page 3 [2]: Haskell 2010 Language Report, Chapter 9 Standard Prelude, page 105 [3]: Haskell 2010 Language Report, Section 6.2 Strict Evaluation, page 75 -- Hécate ✨ IRC: Uniaika WWW: https://glitchbra.in RUN: BSD

12 20

Version bump in 'unix' and 'parsec'
by Vladislav Zavialov 12 Oct '20

12 Oct '20

Three weeks ago I sent 10 pull requests to GHC boot libraries, bumping the upper bound on ‘base’ to accept base-4.16, for the next GHC release. Most of these were merged, but two remain: 1. https://github.com/haskell/unix/pull/158 2. https://github.com/haskell/parsec/pull/118 Could somebody with the permissions hit the merge button? It’s just a version bump and I need it to unblock some other work. - Vlad

1 0

Use of evaluate in Control.Concurrent.MVar
by David Feuer 12 Oct '20

12 Oct '20

Control.Concurrent.MVar uses `evaluate` in a couple places, and I don't understand why: modifyMVar :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a >>= evaluate) `onException` putMVar m a putMVar m a' return b modifyMVarMasked :: MVar a -> (a -> IO (a,b)) -> IO b modifyMVarMasked m io = mask_ $ do a <- takeMVar m (a',b) <- (io a >>= evaluate) `onException` putMVar m a putMVar m a' return b The general purpose is to make sure that the result of the IO action is forced to head normal form within the scope of the `catch` block created by `onException`. But in this context, I don't see why we need to use `evaluate` rather than just `seq`, or why that is desirable. Couldn't we just do this? modifyMVar m io = mask $ \restore -> do a <- takeMVar m (a',b) <- restore (io a >>= (pure $!)) `onException` putMVar m a putMVar m a' return b David

2 2

llvm-hs version 10, and library maintainers
by Travis Whitaker 02 Oct '20

02 Oct '20

Hello fellow Haskellers, LLVM version 10 is out, and LLVM 11 is on the way. I'm curious if anyone has begun work on getting llvm-hs working with version 10. This is likely to be a bit more of a chore than usual, because of changes in the JIT API. Furthermore, activity on the llvm-hs GitHub repo seems to have slowed; I'm curious who the current maintainers are and whether or not they could use a hand? I make active use of the package and would be happy to contribute time to help out any way I can. Thanks, Travis Whitaker

2 1

How the heck should we fix Ord for Array?
by David Feuer 01 Oct '20

01 Oct '20

At present, the Eq instance for Data.Array.Array is somewhat broken[1]. In particular, it ignores the array bounds for empty arrays (but not for other arrays), so its meaning is inconsistent, and the bounds function doesn't respect ==. The fix to that is tiny and obvious: pay attention to the bounds regardless. Eq and Ord instances are expected to be compatible: a == b <==> compare a b = EQ So when I started putting together a merge request to fix the Eq instance, I glanced over at the Ord instance to see what that was doing. That instance was 1. Incompatible with the current Eq instance. 2. Incompatible with the proposed Eq instance. Specifically, that instance compares the association lists of the two arrays, ignoring the bounds in all cases. It is not at all obvious to me what the Ord instance should actually be, except that it should be compatible with Eq. [1] https://gitlab.haskell.org/ghc/ghc/-/issues/18700

1 0