- Libraries - Haskell.org

Proposal: give Ptr a nominal role
by David Feuer 04 Nov '18

04 Nov '18

Currently, we have data Ptr a = Ptr Addr# type role Ptr phantom This is weird: accidentally coercing a pointer to a different type is very bad. The only reason Ptr has this role is that without it, castPtr and such may not be free or will involve unsafe coercions. Thankfully, we have enough power to fix this now. data Addr = Ptr_ Addr# newtype Ptr a = Ptr_ Addr type role Ptr nominal pattern Ptr :: Addr# -> Ptr a pattern Ptr a# = Ptr_ (Addr a#) castPtr :: Ptr a -> Ptr b castPtr (Ptr a) = Ptr a ptrCoercible :: ((forall a b. Coercible (Ptr a) (Ptr b)) => r) -> r ptrCoercible r = r ptrCoercion :: Coercion (Ptr a) (Ptr b) ptrCoercion = Coercion I propose that we do this.

7 19

Proposal: Add a splitBy / splitOn in Data.List
by Saurabh Nanda 03 Nov '18

03 Nov '18

This has certainly been discussed before. A quick Google search turned up the following past discussions: - https://mail.haskell.org/pipermail/libraries/2006-July/005494.html - https://mail.haskell.org/pipermail/libraries/2012-July/018228.html Is there anything blocking this discussion & implementation? Anything that can be done to unblock it? -- Saurabh.

8 10

Proposal: Move primitive-Data.Primitive.Addr API into base
by Daniel Cartwright 03 Nov '18

03 Nov '18

Motivation: There are a lot of places in base where 'Ptr a' is used in place of 'Addr', because in base there is no 'Addr', only 'Addr#'. The problem lies in the fact that many of these uses of 'Ptr a' are lying; the 'a' value is meaningless. Authors of functions therein have used things like 'Ptr ()', 'Ptr Word8', 'Ptr a', but these types do not mean what they say they mean - they're just Addr. There are probably other motivations for this that I can't think of off the top of my head right now.

11 86

Specialized exponentiation operators
by David Feuer 01 Nov '18

01 Nov '18

We currently have (^) :: (Num a, Integral b) => a -> b -> a (^^) :: (Fractional a, Integral b) => a -> b -> a stimes :: (Semigroup a, Integral b) => b -> a -> a These are very general, but the ergonomics are terrible. The trouble is that in each case, the `b` type variable is a (constrained) type that appears only in one argument and not in the result. In the extremely common case where the exponent is a literal, we rely on defaulting to fix `b ~ Integer`. When the exponent is very small, it will then be rewritten to a simple multiplication. Otherwise, it will pay the price of bignum arithmetic, whether that's required or not. Is there a canonical package providing versions of these functions with the exponent specialized to `Int` and/or `Word`? If not, where might such fit well?

2 1

Generalize "set" operations from Data.List
by Dannyu NDos 01 Nov '18

01 Nov '18

I've suffered from inconvenience due to the restricted type signature. I'll be very glad if such restrictions are lifted: deleteBy :: (a -> b -> Bool <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Bool.html#t:Bool>) -> a -> [b] -> [b] deleteFirstsBy :: (a -> b -> Bool <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Bool.html#t:Bool>) -> [a] -> [b] -> [b] intersectBy :: (a -> b -> Bool <http://hackage.haskell.org/package/base-4.12.0.0/docs/Data-Bool.html#t:Bool>) -> [a] -> [b] -> [a] I approve these versions because: 1. It makes more sense that the "usual" `delete` and `intersect` functions are specialization of the "By" operations, not the vice versa. 2. Data.Map.Lazy module from *containers* package has these kind of "By" operations. The previous discussion about this in Sep 2016 didn't make much conclusion, so let the discussion continue.

3 4

[core libraries] Call for Nominations
by Edward Kmett 31 Oct '18

31 Oct '18

Dear Haskellers, I'm putting out a call for new nominations (typically but not necessarily self-nominations) to the Core Libraries Committee. We've had two open slots for a while, and technically at least a couple of members of the committee are due to rotate off. To nominate yourself, please send an email to core-libraries-committee at haskell.org by December 1, 2018. The retiring members are eligible to re-nominate themselves. Please feel free to include any information about yourself that you think will help us to make a decision. Being a member of the committee does not necessarily require a significant amount of time, but committee members should aim to be responsive during discussions when the committee is called upon to make a decision. Strong leadership, communication, and judgement are very important characteristics for committee members. The core libraries committee acts as the maintainer of the core libraries mentioned on https://wiki.haskell.org/Library_submissions For the most part members maintain individual libraries under the maintainer guidelines for Haskell, but there are occasional "barn-raising" style calls for discussion and decision whenever things need a broad enough mandate. We seek a broad representation from different segments of the Haskell world -- including but not limited to those focused on education, those focused on industrial applications, those with background in organizing users-groups, and those focused directly on our technical infrastructure. More details about the committee's roles and responsibilities are on https://wiki.haskell.org/Core_Libraries_Committee If you have any questions about the process, please feel free to e-mail us at core-libraries-committee at haskell.org, or contact one of us individually. -Edward Kmett

3 2

Fwd: Proposal: Implement minimumOn, maximumOn to mirror sortOn
by Gabriel Garcia 30 Oct '18

30 Oct '18

Hello, I have a small proposal for review here: https://phabricator.haskell.org/D5110 I'd like to start the discussion on whether this is a useful/acceptable addition the core library. Thanks, - Gabriel

4 3

Adding dup to Data.Tuple?
by Ivan Perez 29 Oct '18

29 Oct '18

Dear all, The function \x -> (x,x) is very convenient when working with arrows. Would it be appropriate to add it to Data.Tuple? Cheers, Ivan

9 13

(un-)deprecation of Control.Monad.Error
by Bertram Felgenhauer 29 Oct '18

29 Oct '18

Dear list, I'm unhappy about the current state of Control.Monad.Error; the module is deprecated, stating: Module ‘Control.Monad.Error’ is deprecated: Use "Control.Monad.Except" instead However, Control.Monad.Except implements 'fail' as an error, inheriting the behavior of Identity. To my mind the whole point of Control.Monad.Error is that it replicates the old non-error behavior of `fail` that the Either type and EitherT used to have. To wit: > fail "123" :: ErrorT String Identity () ErrorT (Identity (Left "123")) > fail "123" :: Except String () ExceptT (Identity *** Exception: 123 In this light I find this deprecation message disingenuous. The situation is similar with the MonadFail class; there is are instance (Monad m, Error e) => MonadFail (ErrorT e m) and instance MonadFail m => MonadFail (ExceptT e m) which means that Except doesn't have a MonadFail instance, because Identity has none, whereas ErrorT implements a non-error version of `fail`. Can we undeprecate the Control.Monad.Error module? Cheers, Bertram

2 3

FW: Contributing to gamma Haskell package
by Alexandre Rodrigues 28 Oct '18

28 Oct '18

Greetings list; I am interested the `gamma ` package (http://hackage.haskell.org/package/gamma) having sent an email about a month ago to the current maintainer about contributing to the package. I am following package takeover procedures<https://wiki.haskell.org/Taking_over_a_package> by posting here, and stating my intentions publicly. Email: ________________________________ From: Alexandre Rodrigues <alexandreR_B(a)outlook.com> Sent: Thursday, September 27, 2018 5:01:50 PM To: mokus(a)deepbondi.net Subject: Gamma Haskell package Hello Mr. Cook; My name is Alexandre, and I’m writing this email to you concerning the Haskell `gamma` package<https://hackage.haskell.org/package/gamma> that you wrote and uploaded to Hackage. The last commit in the package’s GitHub repository was over 6 years ago. A few other packages also depend on this one, but they all seem deprecated. My question is if you have any plans for this package, and if you would accept my contributions to it. The reason why I ask this is because I am a contributor to another Haskell number theory package called `arithmoi`<https://github.com/cartazio/arithmoi>, and the gamma function is a useful tool to have at times. To finalize, I apologize for the unexpected email, and appreciate the time you took to read it. Regards, Alexandre

1 0