- Libraries - Haskell.org

Arg has unlawful instances
by David Feuer 11 May '19

11 May '19

Foldable, Traversable, Bifoldable, and Bitraversable instances of Data.Semigroup.Arg don't respect ==. For example, Arg () 1 == Arg () 2 = True, but sum (Arg () 1) = 1 and sum (Arg () 2) = 2. I believe the best solution is to remove the Traversable and Bitraversable instances, and define foldMap _ _ = mempty bifoldMap f _ (Arg a _) = a There also needs to be some documentation about the fact that the Arg constructor allows inspection that does not respect Eq.

5 4

Proposal: give a field name to Data.Ord.Down
by Fumiaki Kinoshita 05 May '19

05 May '19

It's awkward to write a lambda to unwrap this kind of wrappers. I propose newtype Down a = Down { getDown :: a } with the Show/Read instances as if they didn't have named fields. The same goes for Control.Arrow.ArrowMonad, although I'm not sure about its usefulness...

10 9

Add NonEmptyMap and NonEmptySet to containers
by John Cotton Ericson 29 Apr '19

29 Apr '19

In https://github.com/haskell/containers/issues/608 I proposed adding non-empty variants of Map and Set, analogous to Data.List.NonEmpty for List, to containers. semigroupoids demonstrates the many uses and structure of non-empty containers in general, and libraries such as https://github.com/mstksg/nonempty-containers and https://github.com/andrewthad/non-empty-containers demonstrate the interest in non-empty maps and sets in particular. My favorite use-case is that they're needed to "curry" containers: for example, |Map (k0, k1) v| is isomorphic not to |Map k0 (Map k1 v)| but to |Map k0 (NonEmptyMap k1 v)|. I like this use-case because it comes from the containers themselves. Importantly, there's no good way to do this outside of containers; doing so leads to imbalancing / extra indirection, or massive code duplication. If one wraps the container was an extra value like Data.List.NonEmpty, one's left with an unavoidable extra indirection/imbalance. One can rectify this by copying and modifying the implementation of containers, but that's hardly maintainable; even as though the algorithms are the same, enough lines are touched that merging upstream containers is nigh impossible. On the other hand, the non-empty containers can be elegantly and sufficiently implemented alongside their originals by taking the Bin constructor and breaking it out into it's own type, mutually recursive with the original. This avoids the indirection/imbalancing and code duplication problems: the algorithms work exactly as before creating the same trees (remember the UNPACK), and no code duplicated since the functions become mutually recursive matching the types. To briefly summarize the thread: 1. I proposed the issue after performing this same refactor on the dependent-map package: https://github.com/obsidiansystems/dependent-map/tree/non-empty, a fork of containers. 2. I made https://github.com/haskell/containers/pull/616 which just changes the types, to make sure UNPACK preserved the importance. 3. https://gist.github.com/Ericson2314/58709d0d99e0c0e83ad266701cd71841 the benchmarks showed rather than degrading performance, PR 616 actually /improved/ it. If there is preliminary consensus, I'll make a second PR on top which generalizes the functions like on my dependent-map branch. Thanks, John

13 31

Proposal: Laws for mtl classes
by Li-yao Xia 24 Apr '19

24 Apr '19

Hello Libraries, I am looking for feedback and discussion about the laws I am proposing in the following pull requests (to save you the click, I will copy the laws at the end of this email): - MonadState and MonadReader: https://github.com/haskell/mtl/pull/61 - MonadError: https://github.com/haskell/mtl/pull/62 Laws for the other classes will be proposed in the future. Indeed, you may be surprised to learn that these classes have never had documented laws, in spite of the often touted importance of laws in the Haskell community: https://github.com/haskell/mtl/issues/5 There is a vague consensus that "classes should have laws", but with very little guidance as to how to design those laws. My approach so far mostly consists of "think very hard about all possible configurations, relying on my experience in equational reasoning". There are papers (some mentioned in the Github issue) discussing such laws, they are useful as a starting point, but most of them focus on MonadState or Alternative, and when MonadReader does appear, local is missing from the picture. More crucially, beyond saying "it's the only thing I can think of", it seems difficult to critically evaluate a given set of laws. Some subtle variations can be quite challenging to compare, see for example this post about two definitions of idempotency: https://duplode.github.io/posts/idempotent-applicatives-parametricity-and-a… Suggestions and additional references in this area are more than welcome. As part of figuring things out, I wrote those mtl laws as QuickCheck tests, in a style inspired by the checkers library: https://github.com/Lysxia/checkers-mtl (still unreleased) Further bikeshedding is likely to take place, and feel free to ask questions to clarify anything. - Could these laws be made simpler? - Are there additional laws that are expected to hold? - Are there reasonable instances that break those laws? For instance, I decided to include laws that turn get and ask into noops if their results are ignored, but could it make sense to allow them to have side effects? I have plans to publish more detailed write-ups about those proposed laws (as blogposts or as part of the documentation), but even having documented laws at all seems better than nothing now, if only to serve as a basis for more concrete discussions. Li-yao --- Class definitions and proposed laws reproduced below. -- MonadReader class Monad m => MonadReader r m | m -> r where {-# MINIMAL (ask | reader), local #-} ask :: m r local :: (r -> r) -> m a -> m a reader :: (r -> a) -> m a {- m <*> ask = ask <**> m ask >> pure x = pure x ask >>= \s1 -> ask >>= \s2 -> k s1 s2 = ask >>= \s -> k s s local f ask = f <$> ask local g . local f = local (g . f) -- local is a monad morphism from m to m local f (pure x) = pure x local f (a >>= k) = local f a >>= \x -> local f (k x) ask = reader id -} -- MonadState class Monad m => MonadState s m | m -> s where {-# MINIMAL state | get, put #-} get :: m s put :: s -> m () state :: (s -> (a, s)) -> m a {- get >>= put = pure () put s >> get = put s >> pure s put s1 >> put s2 = put s2 get >> pure x = pure x get >>= \s1 -> get >>= \s2 -> k s1 s2 = get >>= \s -> k s s get = state (\s -> (s, s)) put s = state (\_ -> ((), s)) -} -- MonadError class (Monad m) => MonadError e m | m -> e where throwError :: e -> m a catchError :: m a -> (e -> m a) -> m a {- catchError (throwError e) h = h e catchError (pure a) h = pure a catchError (catchError m k) h = catchError m (\e -> catchError (k e) h) catchError (m >>= k) h = tryError m >>= either h k -- tryError :: MonadError e m => m a -> m (Either e a) catchError m throwError = m throwError e >>= k = throwError e -}

2 2

Add a Functor instance to Kleisli
by Dmitriy Kovanikov 18 Apr '19

18 Apr '19

Hello everyone! I would like to propose to add a `Functor` instance to the `Kleisli` data type from the `Control.Arrow` module. The instance can look like this: instance Functor m => Functor (Kleisli m a) where fmap :: (b -> c) -> Kleisli m a b -> Kleisli m a c fmap f (Kleisli h) = Kleisli (fmap f . h) {-# INLINE fmap #-} (<$) :: c -> Kleisli m a b -> Kleisli m a c c <$ Kleisli h = Kleisli (\a -> c <$ h a) {-# INLINE (<$) #-} Having this instance would be really helpful in improving the `profunctors` package by adding QuantifiedConstraints to it. See more details in the discussion below: https://github.com/ekmett/profunctors/pull/70#discussion_r267648958 Thanks, Dmitrii Kovanikov

4 3

Proposal: Add Data.Monoid.mwhen :: Monoid m => Bool -> m -> m
by James Ashwell 11 Apr '19

11 Apr '19

This would mimic the behaviour of Control.Monad.when for monoids rather than applicatives. mwhen :: Monoid m => Bool -> m -> m mwhen b a | b = a | otherwise = mempty -- Examples: when :: Applicative f => Bool -> f () -> f () when b = getAp . mwhen b . Ap -- mwhen b = getConst . when b . Const guard :: Alternative f => Bool -> f () guard b = getAlt (mwhen b (pure ())) applyIf :: Bool -> (a -> a) -> (a -> a) applyIf b = appEndo . mwhen b . Endo -- Using Monoid m => Monoid (a -> m) -- mwhen b f x = if b then f x else mempty = mwhen b (f x) -- mwhen b f x y = if b then f x y else mempty = mwhen b (f x y) -- etc -- mwhen b x <> y = if b then x <> y else y

5 5

Add missing Monad/Traversable instances to tuples
by Fumiaki Kinoshita 09 Apr '19

09 Apr '19

I submitted https://gitlab.haskell.org/ghc/ghc/merge_requests/644 but it might be still controversial. I'd like to get more opinions again. Here's the list of proposed instances: Foldable ((,,) a b) Foldable ((,,,) a b c) Traversable ((,,) a b) Traversable ((,,,) a b c) Functor ((,,) a b) (Monoid a, Monoid b) => Applicative ((,,) a b) (Monoid a, Monoid b) => Monad ((,,) a b) Functor ((,,,) a b c) (Monoid a, Monoid b, Monoid c) => Applicative ((,,,) a b c) (Monoid a, Monoid b, Monoid c) => Monad ((,,,) a b c) The absence of Traversable instances for tuples feels quite inconsistent given that there are Bitraversable instances already.

22 29

Re: Adding more instances to Kleisli: Generic, Monad, etc
by Ryan Scott 08 Apr '19

08 Apr '19

+1 from me, although I find it somewhat curious that this proposes adding a Generic instance, but not a Generic1 instance. Perhaps that should be included in the patch as well? Ryan S.

2 1

Adding more instances to Kleisli: Generic, Monad, etc
by Fumiaki Kinoshita 07 Apr '19

07 Apr '19

This is another part of https://gitlab.haskell.org/ghc/ghc/merge_requests/644, which is presumably much less controversial: Generic (Kleisli m a b) Functor m => Functor (Kleisli m a) Applicative m => Applicative (Kleisli m a) Alternative m => Alternative (Kleisli m a) Monad m => Monad (Kleisli m a) (Alternative m, Monad m) => MonadPlus (Kleisli m a)

5 7

Data.Map.mapKeysMonotonic is a misleading name
by Elliot Cameron 04 Apr '19

04 Apr '19

Hello! In some recent analysis I ran into a subtlety that caught me by surprise: Data.Map.mapKeysMonotonic has a misleading name. A monotonic function is not a strictly *increasing* function, but merely non-decreasing. However, mapKeysMonotonic requires that it's mapping function be injective, which means it really only supports *increasing* functions. valid (mapKeysMonotonic (\x -> if x `elem` [1,2] then 2 else x) (fromList [(1, "a"), (2, "b"), (3, "c")])) == False The docs hint at this with "This means that @f <https://github.com/f>@ maps distinct original keys to distinct resulting keys." However, I'd propose that we deprecate this name and rename to something like mapKeysIncreasingor mapKeysAsc (to follow the pattern of other *Asc functions). We should also clarify the docs. >From https://github.com/haskell/containers/issues/617

4 9