- Libraries - Haskell.org

Re: Proposal: Add singleton function to Data.List module
by David Duke 19 Aug '19

19 Aug '19

Stepping to one side of the discussion could I just point out that, notation is not just about the form of the final program. One of the claimed strengths and appeals of FP is the opportunity for program transformation via a useful repertoire of algebraic law, cf the work on Squiggol, and the numerous functional pearls by folk including Richard Bird et.al.. This work befits from having concisely-expressed rules that open the road to manipulation - long-winded identifiers suitable for large libraries are not necessarily ideal for algebraic manipulation. Ye you could treat the two as separate entities, But a pleasant feature of Haskell is the ability to work with the notation both for developmemt and final program. Going back to the original proposal, I'm not bothered, I would probably just ignore a singleton library. However I'm -1 on philosophical grounds. I'm used to teaching FP to undergrads and half the battle is encouraging people to think functionally, to make use of the underlying mathematics and computational model rather than transliterate <insert your favourite 'bete noir'> into Haskell. That means thinking of building programs from functional fragments combined by suitable glue, and appreciating that data constructors can be used as functions Yes it takes beginner's time to recognise some of the patterns, and (:[] is just one such example(when the light dawns, the transformation is rewarding. I've lost count of the number of jaws I've had to pick off the floor :) So I don't want to make a mountain out of a molehill. If it will really improve programmers' lives then okay, So far I' not convinced, and but in fretting over final code can we please not lose sight of the 'bigger picture' and challenges.. -- David Duke E:duke.j.david@gmail.com W:https://engineering.leeds.ac.uk/staff/334/Professor_David_Duke

1 0

Proposal: add indexed map and traverse to Data.List
by David Feuer 18 Aug '19

18 Aug '19

mapWithIndex :: (Int -> a -> b) -> [a] -> [b] mapWithIndex f = zipWith f [0..] traverseWithIndex :: Applicative f => (Int -> a -> f b) -> [a] -> f [b] traverseWithIndex f = sequenceA . mapWithIndex The real implementation of mapWithIndex (and therefore of traverseWithIndex) can be a "good consumer" for list fusion. mapWithIndex can be a "good producer" as well (which the naive implementation already accomplishes). Similar functions (with these or similar names) are already common in packages like vector, containers, unordered-containers, and primitive. A more general function would merge zipping with unfolding: zipWithUnfoldr :: (a -> b -> c) -> (s -> Maybe (b, s)) -> [a] -> s -> [c] zipWithUnfoldr f g as s = zipWith f as (unfoldr g s) But this doesn't seem like the friendliest or most obvious user interface, so I am not proposing to add it to base.

4 3

Add instance MonadFail (f :*: g)
by Dannyu NDos 16 Aug '19

16 Aug '19

instance (MonadFail f, MonadFail g) => MonadFail (f :*: g) where fail s = fail s :*: fail s

3 2

Make sameNat proxy-polymorphic
by Andrew Lelechenko 16 Aug '19

16 Aug '19

Hi all, Currently base:GHC.TypeNats.sameNat is implemented as follows: sameNat :: (KnownNat a, KnownNat b) => Proxy a -> Proxy b -> Maybe (a :~: b) sameNat x y | natVal x == natVal y = Just (unsafeCoerce Refl) | otherwise = Nothing There are applications, when more flexibility is desirable. I propose to change sameNat's type to sameNat :: (KnownNat a, KnownNat b) => proxy1 a -> proxy2 b -> Maybe (a :~: b) It does not require any changes in the implementation, because natVal is already "proxy-polymorphic": natVal :: forall n proxy. KnownNat n => proxy n -> Natural Best regards, Andrew

4 3

indexM or (!?)-style accessor for arrays?
by Zemyla 14 Aug '19

14 Aug '19

This is an issue I originally proposed on GHC Trac, but I'm posting it here because (I think) the Data.Array package is under the purview of the Libraries committee. The vector package has indexM and its cousins so that a user can be strict in the array without necessarily being strict in the value retrieved from that array. Arrays don't have that sort of thing, meaning that anything you do that takes an array will necessarily leave references to the array unless you force the whole thing, and that's not only inefficient, it's untenable for general libraries. What I'm thinking is that the IArray class should have a function like unsafeAtM :: (Array a e, Ix i, Applicative m) => a i e -> Int -> m e For compatibility with older code that wouldn't necessarily define this but would define unsafeAt, we'd have the default implementation unsafeAtM a !n = pure (unsafeAt a n) Also, you could have unsafeAt defined in terms of unsafeAtM, so the minimal implementation could require only one of them: unsafeAt = (coerce :: (a i e -> Int -> Identity e) -> a i e -> Int -> e) unsafeAtM Also, (!?) would be a "safe" indexing tool for arrays, which would incidentally also force the array without forcing the value inside. You would have (!?) :: (Array a e, Ix i) => a i e -> i -> Maybe e (!?) a e = case bounds a of p@(l, u) -> case inRange p e of True -> unsafeAtM arr $ unsafeIndex p e False -> Nothing

2 4

Add instance Eq1 Complex, Show1 Complex, and Read1 Complex
by Dannyu NDos 12 Aug '19

12 Aug '19

instance Eq1 Complex where liftEq f (x :+ y) (u :+ v) = f x u && f y v instance Show1 Complex where liftShowsPrec sp _ p (x :+ y) = showParen (p >= 6) (sp p x . showString " :+ " . sp p y) instance Read1 Complex where liftReadPrec rp _ = parens $ prec 6 $ do x <- step rp Symbol ":+" <- lexP y <- step rp return (x :+ y) liftReadList = liftReadListDefault liftReadListPrec = liftReadListPrecDefault

4 3

Request for comment on new package
by David Feuer 10 Aug '19

10 Aug '19

I've put together a small package for lazifying record types. There's a "classy" version in Data.Lazify and a Generic-only version in Data.Lazify.Generic. A few examples are below. I'd love to hear comments on what looks good and what should be changed before I make the first release. As usual, names are the hardest part. Note especially that the operator ($~) is defined in *both* Data.Lazify and Data.Lazify.Generic, and that no operator corresponds to genericLazify. Hrmm mumble. lazify (1, 2) = (1, 2) lazify undefined = (_|_, _|_, _|_) lazify undefined = Sum (_|_, _|_, _|_) genericLazify (1,2) = (1,2) genericLazify undefined = (_|_, _|_, _|_) genericLazify (Sum (MyCon x y)) = ... oops, MyType isn't an instance of Lazifiable lazifyGeneric (1,2) = (1,2) lazifyGeneric undefined = (_|_, _|_, _|_) lazifyGeneric (Sum (MyCon x y)) = Sum (MyCon x y) Thanks in advance, David

4 6

Add instance Alternative (Either e)
by Dannyu NDos 08 Aug '19

08 Aug '19

instance Monoid e => Alternative (Either e) where empty = left mempty Left x <|> Left y = Left (x <> y) Left _ <|> y = y x <|> _ = x Leftmost Right is returned for sake of consistence with Semigroup instance.

2 1

Re: Add instance Monoid ((f :+: g) a)
by Dannyu NDos 07 Aug '19

07 Aug '19

Ah, sorry. (:+:) is not an Applicative. It's still possible to make instance Monoid: instance Semigroup (f a) => Semigroup ((f :+: g) a) where InL x <> InL y = InL (x <> y) InL _ <> y = y x <> _ = x instance Monoid (f a) => Monoid ((f :+: g) a) where mempty = InL mempty

1 1

Add instance Alternative (f :+: g)
by Dannyu NDos 07 Aug '19

07 Aug '19

instance Alternative f => Alternative (f :+: g) where empty = InL empty InL x <|> InL y = InL (x <|> y) InL _ <|> y = y x <|> _ = x This is analogous to the proposed Alternative Either instance.

1 0