November 2016 - Libraries

Proposal: merge either into transformers
by Roman Cheplyaka 03 Jan '17

03 Jan '17

I propose to add the sole module of the 'either' package[1], Control.Monad.Trans.Either, to the transformers package. It provides EitherT, a very basic and fundamental data type. The difference between EitherT and ErrorT is that the latter has an Error constraint, which is used to imlement 'fail'. Note that 'either' depends on the 'semigroupoids' and 'semigroup' packages to provide appropriate instances. The proposal is not to add those instances to 'transformers' to avoid additional dependencies. The instances can then be left in the 'either' package or moved to the 'semigroupoids' and 'semigroup' packages respectively. ('semigroupoids' already depends on 'transformers', while 'semigroups' does not). Compared to the 'either' package, Show, Read, Eq and Ord instances will be dropped to keep the code Haskell2010 (those instances require FlexibleInstances, FlexibleContexts, and UndecidableInstances). The patch is attached. [*] [*] against transformers-0.3.0.0, because the darcs version is not buildable (Control/Monad/Signatures.hs is not in the repository). Roman

22 72

Many functions can be generalised
by Baldur Blöndal 04 Dec '16

04 Dec '16

A year ago Edwardk Kmett pointed out some possible generalizations of functions [1], I made a ticket about them that led me here [2]. In addition to the functions mentioned > maybeToList :: Foldable f => f a -> [a] > maybeToList = toList > catMaybes :: (Foldable f) => f (Maybe a) -> [a] > catMaybes :: (Foldable f, Foldable g) => f (g a) -> [a] > catMaybes = foldMap toList > mapMaybes :: (a -> Maybe b) -> (forall f. Foldable f => f a -> [b]) > mapMaybes :: Foldable m => (a -> m b) -> (forall f. Foldable f => f a -> [b]) > mapMaybes f = foldMap (toList . f) we also have *many* other functions (I do not propose generalising all these function ((especially when the name stops making sense)), but I will include them) that I will define in the vocabulary of ‘lens’. Some generalise to ‘Foldable’ > take :: Int -> (forall f a. Foldable f => f a -> [a]) > take n = toListOf (taking n folded) > drop :: Int -> (forall f a. Foldable f => f a -> [a]) > drop n = toListOf (dropping n folded) > takeWhile :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > takeWhile p = toListOf (takingWhile p folded) > dropWhile :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > dropWhile p = toListOf (droppingWhile p folded) > -- Same as ‘Control.Lens.Indexed.None’ > filter :: (a -> Bool) -> (forall f. Foldable f => f a -> [a]) > filter p = toListOf (folded.filtered p) > cycle :: Foldable f => f a -> [a] > cycle = toListOf (cycled folded) > lookup :: Eq k => k -> (forall f. Foldable f => f (k, v) -> Maybe v) > lookup = lookupOf folded > listToMaybe :: Foldable f => f a -> Maybe a > listToMaybe = firstOf folded while others — to ‘Traversable’ > transpose :: Traversable f => f [b] -> [f b] > transpose = transposeOf traverse > scanl1 :: (a -> a -> a) -> (forall f. Traversable f => f a -> f a) > scanl1 = scanl1Of traverse > scanr1_ :: (a -> a -> a) -> (forall f. Traversable f => f a -> f a) > scanr1_ = scanr1Of traverse More radical suggestions (pay no heed to the hacky ‘partsOf’, assume better implementation [3]) would allow us to sort a ‘data V2 a = V2 a a deriving (…, Traversable)’ if it contains ordered values: > sort :: (Traversable t, Ord a) => t a -> t a > sort = over (partsOf traverse) Data.List.sort > sortBy :: (a -> a -> Ordering) -> ([a] -> [a]) > sortBy = over (partsOf traverse) . Data.List.sortBy > sortOn :: Ord b => (a -> b) -> ([a] -> [a]) > sortOn = over (partsOf traverse) . Data.List.sortOn > reverse :: Traversable t => t a -> t a > reverse = over (partsOf traverse) Data.List.reverse > -- Based on ‘Control.Lens.??’ > flip :: Functor f => f (a -> b) -> a -> f b > flip f x = fmap ($ x) f or > flip :: (Functor f, Distributive g) => f (g a) -> g (f a) > flip = Data.Distributive.distribute AMP happened some years ago, does this go too far or not far enough? ;) share your thoughts P.s. I understand those skeptical of the ‘partsOf’ solutions but they do feel magical and uses crop up in odd places, especially in compound structures (I don't have better examples): > ghci> peopleList = Pair ["Bob", "Eve"] (Just "Alice") > ghci> data Product f g a = Pair (f a) (g a) deriving (Show, Functor, Foldable, Traversable) > ghci> sort peopleList > Pair ["Alice","Bob"] (Just "Eve") > ghci> reverse peopleList > Pair ["Alice","Eve"] (Just "Bob") > ghci> peopleMap = fromList [(1,"Bob"),(2,"Eve"),(3,"Alice")] > ghci> sort peopleMap > fromList [(1,"Alice"),(2,"Bob"),(3,"Eve")] > ghci> reverse peopleMap > fromList [(1,"Alice"),(2,"Eve"),(3,"Bob")] [1] https://www.reddit.com/r/haskell/comments/2y2pe5/shouldnt_ftp_propagate_cha… [2] https://ghc.haskell.org/trac/ghc/ticket/12828 [3] http://stackoverflow.com/a/33320155/165806

8 19

Re: The lazy Show instance for GHC.Generics.U1 is confusing.
by Ryan Scott 28 Nov '16

28 Nov '16

I don't quite understand your objection (what is the value you're showing?). But the Show U1 instance's laziness is deliberate. We designed all of U1's instances to emulate those of Proxy so that in the future, we could unify the datatypes in GHC.Generics with more standard ecosystem definitions (i.e., replace U1 in favor of Proxy, (:*:) with Product, (:+:) with Sum, etc.) See https://ghc.haskell.org/trac/ghc/ticket/11650 for the discussion on this. Ryan S.

1 0

Traversal order newtypes for Data.Tree, and Ord instances
by David Feuer 27 Nov '16

27 Nov '16

Data.Tree.Tree has Foldable and Traversable instances for traversing a tree in preorder. Should we add the derived Ord instance to match? Should we offer newtypes for traversing in post-order and level-order with Eq and Ord instances to match? I've made coercions explicit below, rather than relying on map/coerce rules, to make performance characteristics clearer. deriving instance Ord a => Ord (Tree a) newtype PostOrder a = PostOrder {getPostOrder :: Tree a} deriving (Show, Read, Functor) instance Foldable PostOrder where foldMap f (PostOrder (Node a ts)) = foldMap (foldMap f . PostOrder) ts <> f a instance Traversable PostOrder where traverse f (PostOrder (Node a ts)) = (\ts' a' -> PostOrder (Node a' (coerce ts'))) <$> traverse (traverse f . PostOrder) ts <*> f a instance Eq a => Eq (PostOrder a) where PostOrder a1 ts1 == PostOrder a2 ts2 = (coerce `asTypeOf` map PostOrder) ts1 == coerce ts2 && a1 == a2 instance Ord a => Ord (PostOrder a) where PostOrder a1 ts1 `compare` PostOrder a2 ts2 = ((coerce `asTypeOf` map PostOrder) ts1 `compare` coerce ts2) <> (a1 `compare` a2) newtype LevelOrder a = LevelOrder {getLevelOrder :: Tree a} deriving (Show, Read, Functor) I'm still working out the best ways to perform level-order folds and traversals. One option for Foldable is instance Foldable LevelOrder where foldr c n (LevelOrder (Node a ts)) = a `c` frlof c n ts where frlof :: (a -> b -> b) -> b -> [Tree a] -> b frlof _c n [] = n frlof c n ts = roots where (roots, forest) = uzt c (frlof c n forest) ts uzt :: (a -> b -> b) -> b -> [Tree a] -> (b, [Tree a]) uzt _c n [] = (n, []) uzt c n (Node a fr : ts) = (a `c` n', fr ++ ts') where (n', ts') = uzt c n ts David Feuer

1 0

The lazy Show instance for GHC.Generics.U1 is confusing.
by David Feuer 23 Nov '16

23 Nov '16

I was messing around in GHCi, exploring the generic representation of a particular value. I tried out both case testSequence of IxSequence x -> case from x of M1 (L1 y) -> y and case testSequence of IxSequence x -> case from x of M1 (R1 y) -> y I was initially mystified to see that neither of these produced an error. Surely, I thought, it can't be both L1 and R1! And indeed it can't. But the Show instance for U1 is lazy, so the first test happily printed out M1 {unM1 = U1} even though that is utter nonsense. I propose that U1 simply derive the Show instance to avoid such peculiar behavior. David Feuer

1 0

Remove redundant Functor constraint from StateT Applicative/Alternative instances
by Baldur Blöndal 22 Nov '16

22 Nov '16

Does this belong here? Applicative [1] and Alternative [2] instances of StateT have redundant constraints > instance (Functor m, Monad m) => Applicative (StateT s m) > instance (Functor m, MonadPlus m) => Alternative (StateT s m) The Functor constraint may be removed [1] https://hackage.haskell.org/package/transformers-0.5.2.0/docs/src/Control.M… [2] https://hackage.haskell.org/package/transformers-0.5.2.0/docs/src/Control.M…

4 4

Pattern synonyms and record fields for Cont, Writer, Reader, State, ...
by Baldur Blöndal 22 Nov '16

22 Nov '16

This will look like the original definitions [1] > newtype State s a = State { runState :: s -> (a, s) } before they became type synonyms > type State s = StateT s Identity by defining pattern synonyms > pattern State :: (s -> (a, s)) -> State s a > pattern State {runState} <- S.runState -> runState > where State a = state a Trac ticket #12767 for further information. [2] [1] http://book.realworldhaskell.org/read/monads.html#id643643 [2] https://ghc.haskell.org/trac/ghc/ticket/12767

2 2

Add ifThenElse and (?) to Data.Bool
by winter 21 Nov '16

21 Nov '16

It seems this’s a very old request, see https://wiki.haskell.org/If-then-else <https://wiki.haskell.org/If-then-else>. I’d like to see following: ifThenElse :: Bool -> a -> a -> a ifThenElse True x _ = x ifThenElse False _ y = y infixr 1 ? (?) :: Bool -> a -> a -> a (?) = ifThenElse in Date.Bool module, it will have advantages that: + It’s more composable than syntax. + Write (xxx ? yyy $ zzz) instead of (if xxx then yyy else zzz) is more consistent with (f . g $ x) style, and save key strokes. + In module with RebindableSyntax enabled, you can import ifThenElse to get default behavior. Whether or not to be exported by Prelude is another question, but Data.Bool seems a good place to start with. Cheers~ Winter

9 16

Add default MonadPlus or Alternative method to MonadFail
by Baldur Blöndal 17 Nov '16

17 Nov '16

The documentation for Control.Monad.Fail notes > If your Monad is also MonadPlus, a popular definition is >> fail _ = mzero This could be made a default definition for MonadPlus or Alternative > class Monad m => MonadFail m where > fail :: String -> m a > fail = const empty > default fail :: Alternative m => String -> m a This simplifies instances like [] and Maybe > instance MonadFail [] > instance MonadFail Maybe

1 0

Re: Proposal: Add portable eliminator for Data.Type.Equality
by David Feuer 15 Nov '16

15 Nov '16

On Nov 15, 2016 12:24 AM, "wren romano" <winterkoninkje(a)gmail.com> wrote: > > subst :: a :~: b -> f a -> f b > > subst Refl x = x > > I'm all for adding this function, but do note that the type is > suboptimal since GHC lacks general functions (and higher-order pattern > matching) at the type level. Which means we'll actually end up wanting > a family of different "subst" functions to cover all the (relevant) > cases the definition above would cover in a language like Agda, Coq, > etc. Yes, we will, but those can be written using `subst` and one or more auxiliary types without additional "primitive" eliminators (see below). > E.g., > > Prelude> let x :: Either Bool Int; x = Right 42 > > Prelude> :t (`subst` x) > (`subst` x) :: Int :~: b -> Either Bool b > > When I might've really wanted/meant (Bool :~: b -> Either b Int) We can write newtype Flip f x y = Flip { unFlip :: f y x } subst2 :: a :~: b -> f a x -> f b x subst2 eq = unFlip . subst eq . Flip The subst2 function will work on the left side of Either.

2 2