November 2018 - Libraries

Proposal to add mapAccumL function to vector package
by John Ky 09 Nov '18

09 Nov '18

Hello, I'd like to add the mapAccumL function to the vector package. Specifically the Data.Vector.Storable module, but it would also be useful other vector modules. This is my attempt at an implementation: {-# LANGUAGE ScopedTypeVariables #-} mapAccumL :: forall a b c. (Storable b, Storable c) => (a -> b -> (a, c)) -> a -> DVS.Vector b -> (a, DVS.Vector c) mapAccumL f a vb = DVS.createT $ do vc <- DVSM.unsafeNew (DVS.length vb) a' <- go 0 a vc return (a', vc) where go :: Int -> a -> DVS.MVector s c -> ST s a go i a0 vc = if i < DVS.length vb then do let (a1, c1) = f a0 (DVS.unsafeIndex vb i) DVSM.unsafeWrite vc i c1 go (i + 1) a1 vc else return a0 {-# INLINE mapAccumL #-} The implementation should obey the following law: import qualified Data.List as L import qualified Data.Vector.Storable as DVS (DVS.toList <$> DVS.mapAccumL f a (DVS.fromList bs)) === L.mapAccumL f a bs Cheers, -John

2 5

Taking over maintainership of cpphs, HaXml, hscolour, and polyparse
by Peter Simons 05 Nov '18

05 Nov '18

Fellow Haskell Hackers, it appears that Malcolm Wallace has lost interest in maintaining his packages on Hackage. Some of them are rather important dependencies for others, and therefore I'd like to take over maintenance of the following libraries: - cpphs - HaXml - hscolour - polyparse Polyparse, in particular, needs a maintenance update to fix build issues with GHC 8.6.1. The absence of a working release blocks packages like hlint from supporting that compiler [1]. I tried to contact Malcolm on 2018-09-24 via e-mail. Others have also tried to reach him through WhatsApp other channels. Unfortunately, no-one has received a response, which is why we decided to go through with this process. Best regards, Peter [1] https://github.com/haskell-infra/hackage-trustees/issues/186

11 13

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