- Libraries - Haskell.org

Numeric supports base 8, 10, 16 but not 2 -- why?
by Artem Pelenitsyn 07 Dec '20

07 Dec '20

Dear Libraries, I noticed the Numeric module has special-cased functions to read and show integral types in bases 8, 10, 16 but not for base 2. There are also generic-over-base versions, so an interested client can implement the special case for base 2 themselves with little hassle. Still, I think base 2 is common enough that we could support it along with base 8, 10, 16 out of the box. What do you think? I'm happy to submit a merge request if you concur. Kind regards, Artem Pelenitsyn

8 8

Proposal for containers: Add 'pop' function to Data.Map
by Martijn Bastiaan 07 Dec '20

07 Dec '20

Hi all, Proposal: * Add `pop` and `popWithDefault` to `Data.Map` and `Data.IntMap`. * See https://github.com/haskell/containers/pull/757 for exact definition Why: * They're useful functions I expected to be in `Data.Map` and `Data.IntMap`. (This might be influenced by the fact that they're defined on Python's `dict`.) * Their implementations (~ `updateLookupWithKey (\_ _ -> Nothing)`) are harder to parse than a simple `pop`, which should help Haskell codebases become a bit cleaner :). * Their implementations are a bit non-obvious. My first instinct was to write `(Map.lookup ..., Map.delete ...)`, which would have done two traversals. Having "properly" implemented functions in the lib would prevent people from writing their own suboptimal ones. Details and implementation: * https://github.com/haskell/containers/pull/757 Kind regards, Martijn Bastiaan

11 28

containers: symmetricDifference for Set and HashSet
by Ben Franksen 01 Dec '20

01 Dec '20

Would it make sense to add a function like the following to containers: symmetricDifference :: Set a -> Set a -> (Set a, Set a, Set a) symmetricDifference a b = (a \\ b, a `intersection` b, b \\ a) with the idea that this can be implemented more efficiently as a primitive than the above specification? (And similarly for HashSet.) If this is the case, then perhaps difference and intersection could be defined in terms of this new primitive: difference a b = let (r, _, _) = symmetricDifference in r intersection a b = let (_, r, _) = symmetricDifference in r *if* it turns out that this does not degrade performance. Cheers Ben

4 4

MonadZip laws
by Joseph C. Sible 27 Nov '20

27 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 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