- Libraries - Haskell.org

Add traverseWithIndex to Data.Sequence
by David Feuer 20 Jan '16

20 Jan '16

Indexed traversals seem to be pretty popular these days, and sequences should be able to support them efficiently. At present, the best options are 1. Thread a counter through. This doesn't work well for weird things like lazy State. 2. Use zipWith first to add indices, then traverse. This adds a smaller, but still asymptotic, penalty to the same sorts of unusual functors, and also adds constant-factor overhead to strict ones that the counter threading wouldn't. I propose the following, modified mechanically from mapWithIndex. It should be about as efficient as possible in all cases. traverseWithIndex :: Applicative f => (Int -> a -> f b) -> Seq a -> f (Seq b) traverseWithIndex f' (Seq xs') = Seq <$> traverseWithIndexTree (\s (Elem a) -> Elem <$> f' s a) 0 xs' where traverseWithIndexTree :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> FingerTree a -> f (FingerTree b) traverseWithIndexTree _ s Empty = s `seq` pure Empty traverseWithIndexTree f s (Single xs) = Single <$> f s xs traverseWithIndexTree f s (Deep n pr m sf) = sPspr `seq` sPsprm `seq` Deep n <$> traverseWithIndexDigit f s pr <*> traverseWithIndexTree (traverseWithIndexNode f) sPspr m <*> traverseWithIndexDigit f sPsprm sf where sPspr = s + size pr sPsprm = s + n - size sf traverseWithIndexDigit :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> Digit a -> f (Digit b) traverseWithIndexDigit f s (One a) = One <$> f s a traverseWithIndexDigit f s (Two a b) = sPsa `seq` Two <$> f s a <*> f sPsa b where sPsa = s + size a traverseWithIndexDigit f s (Three a b c) = sPsa `seq` sPsab `seq` Three <$> f s a <*> f sPsa b <*> f sPsab c where sPsa = s + size a sPsab = sPsa + size b traverseWithIndexDigit f s (Four a b c d) = sPsa `seq` sPsab `seq` sPsabc `seq` Four <$> f s a <*> f sPsa b <*> f sPsab c <*> f sPsabc d where sPsa = s + size a sPsab = sPsa + size b sPsabc = sPsab + size c traverseWithIndexNode :: (Applicative f, Sized a) => (Int -> a -> f b) -> Int -> Node a -> f (Node b) traverseWithIndexNode f s (Node2 ns a b) = sPsa `seq` Node2 ns <$> f s a <*> f sPsa b where sPsa = s + size a traverseWithIndexNode f s (Node3 ns a b c) = sPsa `seq` sPsab `seq` Node3 ns <$> f s a <*> f sPsa b <*> f sPsab c where sPsa = s + size a sPsab = sPsa + size b

5 5

Re: Proposal: Add conspicuously missing Functor instances for tuples
by Ryan Scott 18 Jan '16

18 Jan '16

Edward Kmett outlines his reasons why he finds instances for (,) useful here: https://www.reddit.com/r/haskell/comments/3pfg7x/either_and_in_haskell_are_… Speaking for myself, I find the Traversable instance for (,) incredibly useful. It's quite nice to build up a list of results alongside a state (i.e, (state, [result]) ), and then traverse over each of the results such that the new results each have their own copy of the state (i.e., [(state, result)] ). That kind of patterns arises quite often in lensy code, and the Traversable instance for (,) is perfect for the job. Right now, if you want to have two different states, you have to employ a kludge (something like ((state1, state2), [result]) ) to get around the fact that there's no Traversable instance for (,,), (,,,), etc. Ryan S.

2 4

Re: Proposal: Add Semigroup and Monoid instances for (:~:)
by Ryan Scott 18 Jan '16

18 Jan '16

+1, with a one stipulation: I'd rather the Semigroup instance be: instance Semigroup (a :~: b) where Refl <> Refl = Refl and similarly for Monoid(mappend). It's a minor quibble, but the documentation [1] for (:~:) says that there's only a proof term for a ~ b if it's inhabited by a terminating value, so performing a strict pattern match seems like the best default here. Ryan S. ----- [1] http://hackage.haskell.org/package/base-4.8.1.0/docs/Data-Type-Equality.htm…:

2 2

Proposal: Add Peano numbers to base
by M Farkas-Dyck 15 Jan '16

15 Jan '16

I have seen these redefined many times now. Examples: https://hackage.haskell.org/package/numericpeano-0.2.0.0/docs/Numeric-Peano… https://hackage.haskell.org/package/numeric-prelude-0.4.2/docs/Number-Peano… https://hackage.haskell.org/package/type-fun-0.0.1/docs/TypeFun-Data-Peano.… https://hackage.haskell.org/package/number-0.1.1.0/docs/Data-Number-Peano.h… https://hackage.haskell.org/package/Peano-0.0.4/docs/Data-Peano.html#t:Peano I often see them used as DataKinds. Too, operations on them can be lazy, which is sometimes useful. I filed a ticket: https://ghc.haskell.org/trac/ghc/ticket/11402 Discussion period: 2 weeks

7 7

Proposal: Add Semigroup and Monoid instances for (:~:)
by David Feuer 14 Jan '16

14 Jan '16

These are not likely to be *useful*, but they fall easily into the general bucket of "exactly one sensible instance exists". instance Semigroup (a :~: b) where r <> _ = r instance a ~ b => Monoid (a :~: b) where mempty = Refl mappend r _ = r

3 3

GHC.Generics and instances of Functor, Applicative, etc?
by Conal Elliott 13 Jan '16

13 Jan '16

I'm using GHC.Generics and have noticed that the data types defined there don't have instances of the standard classes (at least not defined in that module), such as Functor, Applicative, Foldable and Traversable. It'd be very useful to be able to rely on such instances, so that one can define instances of custom types via instances of the generic types. (Hopefully, the compiler can remove most or all conversion overhead) Is there any reason not to add these generic instances? -- Conal

2 2

Re: Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec
by Ryan Scott 11 Jan '16

11 Jan '16

> In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. For better or worse, that is indeed the case. Before, Eq1/Ord1/Read1/Show1 relied on the type argument having an implicit dictionary to use, which is why you could get away with piggybacking off of your existing Eq/Ord/Read/Show instances. Now, Eq1, Eq2, and friends rely on explicit dictionary passing, so they're strictly more powerful than Eq et al. > Is there some assistance to define eq1 and compare1 for an ADT? At the moment, no. Sometime in the future, I want to do two things which should make the situation a little better: 1. Write a language extension to derive Eq1/Eq2/etc. It definitely won't be making it into GHC 8.0 due to time constraints, plus I need to propose a design. And... 2. ...I should write a Template Haskell shim which implements the proposed design. I already have a package called deriving-compat [1] which has done this (but only for recent changes to -XDeriveFoldable), so that would probably be a logical place to put it. Until then, if you need to hand-roll Eq1/Eq2/etc. instances that align with your Eq instances, I'd recommend copying the output of ghc -ddump-deriv, copying the generated instances, and replacing the necessary calls with dictionary arguments. For example, given this instance: data Example a = Example Int a deriving Eq Compiling with ghc -ddump-deriv gives you this (after some code cleanup): instance Eq a => Eq (Example a) where Example i1 a1 == Example i2 a2 = i1 == i2 && a1 == a2 e1 /= e2 = not (e1 == e2) Then, you can create an Eq1 instance with some minor adjustments: instance Eq1 Example where liftEq eq (Example i1 a1) (Example i2 a2) = i1 == i2 && eq a1 a2 > What are the use cases where eq1 was not powerful enough and liftEq is needed? The previous type signature of Data.Functor.Classes in transformers-0.4 resulted in some awkward instances, a prime example being found in Data.Functor.Compose: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Functor f, Eq1 f, Eq1 g, Eq a) => Eq (Compose f g a) where Compose x == Compose y = eq1 (fmap Apply x) (fmap Apply y) instance (Functor f, Eq1 f, Eq1 g) => Eq1 (Compose f g) where eq1 = (==) newtype Apply g a = Apply (g a) instance (Eq1 g, Eq a) => Eq (Apply g a) where Apply x == Apply y = eq1 x y This is a super-kludgey instance because it requires f to be a Functor instance. In general, having these Functor constraints pop up everywhere results in less efficient instances, and it won't work at all for many GADT-like constructions that can't have legal Functor instances. With the new API, there is no need for these Functor constraints: import Data.Functor.Classes(Eq1(..)) newtype Compose f g a = Compose (f (g a)) instance (Eq1 f, Eq1 g) => Eq1 (Compose f g) where liftEq eq (Compose x) (Compose y) = liftEq (liftEq eq) x y Ryan S. ----- [1] http://hackage.haskell.org/package/deriving-compat

2 4

Eq1, Ord1, Show1: move from eq1, compare1, showsPrec1 to liftEq, liftCompare, liftShowsPrec
by Henning Thielemann 10 Jan '16

10 Jan '16

In transformers-0.5:Data.Functor.Classes class methods like eq1 are replaced by liftEq. With transformers-0.4 I could define: data T a = complicated definition ... deriving (Eq, Ord, Show) instance Eq1 T where eq1 = (==) instance Ord1 T where compare1 = compare instance Show1 T where showsPrec1 = showsPrec In transformers-0.5 it seems that I have to implement Eq1, Ord1, Show1 instances manually. Is there some assistance to define eq1 and compare1 for an ADT? What are the use cases where eq1 was not powerful enough and liftEq is needed?

1 0

Foldable.Mapped
by Henning Thielemann 04 Jan '16

04 Jan '16

I found the following data type useful when working with the Foldable class: {- | It holds: > foldMap f . Mapped g = foldMap f . fmap g but use of 'Mapped' avoids 'Functor' constraint. -} data Mapped f a b = Mapped (a -> b) (f a) instance (Foldable f) => Foldable (Mapped f a) where foldMap g (Mapped f xs) = Fold.foldMap (g . f) xs foldr g x (Mapped f xs) = Fold.foldr (g . f) x xs foldl g x (Mapped f xs) = Fold.foldl (\acc -> g acc . f) x xs Should it be added to Data.Foldable?

4 4

Haddock with GHC 8
by Dominic Steinitz 14 Dec '15

14 Dec '15

Hello All, I submitted a PR for Haddock to support mathjax on 16 May. As I understand it, the maintainer of Haddock did not wish to apply it immediately as it would change interface files (although I have to admit I don’t know what this entails). Are there any plans to release a new version of Haddock along with GHC 8? Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

3 4