- Libraries - Haskell.org

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 19 Nov '20

19 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

Proposal: Move `mapM` and `sequence` out of Traversable
by Emily Pillmore 07 Nov '20

07 Nov '20

Hi All, I have a proposal for the `base` library: I would like to move `mapM` and `sequence` out of the class definition for `Traversable`, redefining them as toplevel aliases: ```haskell mapM :: Traversable t ⇒ Monad m ⇒ (a -> m b) -> t a -> m (t b) mapM = traverse sequence :: Traversable t ⇒ Monad m=> t (m a) -> m (t a) sequence = sequenceA ``` This slims `Traversable` by 50%. This would be a very small breaking change, which is completely tractable, but a great improvement for the ecosystem imo. Thoughts? What timeline should we shoot for with a change like this? Cheers, Emily

6 8

Wiki page for 3-Release-Policy is not found
by Takenobu Tani 04 Nov '20

04 Nov '20

Dear Libraries, Currently, a wiki page of `3-Release-Policy` is not found: * https://prime.haskell.org/wiki/Libraries/3-Release-Policy Does anyone have a plan to migrate those pages? Regards, Takenobu

6 8

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