- Libraries - Haskell.org

Proposal: add isEmpty to Monoid
by Dr.Koster 25 May '19

25 May '19

It's often useful to have a generalized null/unit test, e.g. to check if a monadic stream `m a` reaches EOF. A workaround is to use `Eq a, Monoid a` constraint and use `== mempty` test. But this is no only inefficient for some type, but also impossible for some monoids, such as Builders. I propose add this test `isEmpty :: a -> Bool` to `Monoid`, to provide the ability to check if a value is the unit value. Cheers Han Dong~

3 3

request: a Nat ordering constraint that is not an equality constraint
by Nicolas Frisby 22 May '19

22 May '19

This email proposes an extension and possible change to GHC.TypeLits module in the core `base` library. Is there support for this kind of extension/change to GHC.TypeLits? If so, I'll open a GHC GitLab Issue. (If not, I would be very appreciate if someone were able to suggest a nice workaround.) # The Proposed Extension Please add an alternative to <= that is not defined via ~. For example: ``` module GHC.TypeLits.Passive where class IsTrue (a :: Bool) instance IsTrue 'True instance TypeError ... => IsTrue 'False type (<=) x y = IsTrue (x <=? y) ``` as opposed to the existing definition: ``` module GHC.TypeLits where type (<=) x y = (x <=? y) ~ 'True ``` Its name should be an operator and should be somewhat obvious -- I can't think of one other than <=, so I hedged here by putting in a new module instead. There should be a means of *explicitly* converting back and forth between evidence of the two constraints; they are equi-satisfiable but affect type inference in their scope differently. # The Optional Change I anticipate most users would prefer Passive.<= to today's <=, so the optional library change in this proposal is to redefine <= and relegate its old definition to a new name. Perhaps: ``` module GHC.TypeLits where type (<=) x y = IsTrue (x <=? y) type (<=!) x y = (x <=? y) ~ 'True ``` # The Motivation I'll explain with an example for some concreteness. I wrote an interface for size-indexed vectors for my employer. It involves some code like this: ``` import GHC.TypeLits newtype Fin (n :: Nat) = Unsafe_MkFin{forgetFin :: Integer} mkFin :: (KnownNat i,i <= n) => proxy i -> Fin n mkFin = Unsafe_MkFin . natVal ``` Constraints like `(i <= n)` show up throughout the library's interface. The problem is that <= is an equality constraint. Therefore many uses of `mkFin` et al *require* that I introduce local equality constraints. And those sadly spoil lots of desired type inference by making outer tyvars untouchable. That's the problem: I have to choose between GHC's specialized solving of <= constraints and unspoiled type inference in their scope. # Additional Context It is important that today's <= be an equality constraint, because it participates in some constraint improvements that introduce equality constraints. For example (x <= y,y <= x) implies x ~ y (c.f. the scary https://gitlab.haskell.org/ghc/ghc/issues/16586) Because <= constraints have the potential to "become" an equality constraint, tyvars outside of a <= constraint must be untouchable in its scope from the get go. However, neither my library nor any of its uses relies on such constraint improvements enabled by <= constraints. In this context, I would much rather that <= could never "become" an equality constraint, so that it need not be an equality constraint, so that it would never render a tyvar untouchable. # An Alternative As a partial workaround, I could write ``` data Dict i n = (i <= n) => MkDict mkFinD :: (KnownNat i) => Dict i n -> proxy i -> Fin n mkFinD MkDict = mkFin ``` and then take pains to only introduce the <= constraints in the argument of `mkFinD`. By limiting the scope of the ~ constraints like that, I could prevent them from spoiling the desired type inference. But it's very cumbersome to manage their scopes manually. # Work Estimation I just thought of the `IsTrue`-based approach while writing this email, so that detail is somewhat half-baked. It has the right *indicative* semantics, but I doubt today's GHC solver would know what to do with a Given `IsTrue (3 <=? 5)` constraint -- so I'm guessing that exact approach at least would require some significant changes in TcTypeNats. Thank you for your time. -Nick P.S. - Some of the issue tracker links at https://wiki.haskell.org/Library_submissions#The_Libraries respond with 404. P.P.S. - Is there a standard place to find something like `IsTrue`? More generally: a test for type equality that does not drive unification? Thanks again.

3 7

Proposal: DerivingVia, MTL
by Reed Mullanix 19 May '19

19 May '19

As it stands, working with newtypes around transformers can be kind of a pain. For example, consider newtype FreshT m a = { unFreshT :: StateT Int m a } deriving (Functor, Applicative, Monad, MonadReader r, ...) Right now, we can't just GND the instance: instance (MonadState s m) => MonadState s (FreshT m) However, the instance we end up writing is completely formulaic. Fortunately, we can solve this by using the recently added -XDerivingVia newtype Inner (t :: (* -> *) -> * -> *) m a = Inner { getInner :: t m a } deriving (Functor, Applicative, Monad) instance (MonadState s m) => MonadState s (Inner (StateT s') m) where get = Inner $ lift get put = Inner . lift . put This lets us derive the instance that we were looking for newtype FreshT m a = FreshT { unFreshT :: StateT Int m a } deriving newtype (Functor, Applicative, Monad, MonadReader r) deriving (MonadState s) via Inner (StateT Int) m This can be extended to other transformers/classes very easily. It also works well when dealing with newtyped transformer stacks. newtype FooT s e m a = FooT { unFooT :: StateT s (WriterT String (ExceptT e m)) a } deriving newtype (Functor, Applicative, Monad, MonadError e) deriving (MonadWriter w) via (StateT s (Inner (WriterT String) (ExceptT e m))) deriving (MonadState s') via Inner (StateT s) (WriterT String (ExceptT e m)) Cheers, Reed Mullanix

2 2

Proposal: add foldMapA to Data.Foldable or Control.Applicative
by Vanessa McHale 11 May '19

11 May '19

It's relatively easy to define foldMapA, viz. foldMapA :: (Monoid b, Traversable t, Applicative f) => (a -> f b) -> t a -> f b foldMapA = (fmap fold .) . traverse I've used found it useful once so far: http://hackage.haskell.org/package/dir-traverse-0.2.0.0/docs/src/System.Dir… Cheers, Vanessa McHale

9 19

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