December 2014 - 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

Proposal: add liftA4 and liftA5 to match liftM4 and liftM5
by David Feuer 14 Jul '16

14 Jul '16

Since Applicative is supposed to be important now, I figure we should get these in.

12 33

[containers] Proposal: Change to the Data.Map Monoid
by Nick Partridge 10 Oct '15

10 Oct '15

Hi, Currently the Monoid instance for Data.Map is implemented using union/unions, which are left biased. On key collision, it discards values from the right hand side of `mappend` - https://github.com/ghc/packages-containers/blob/bae098fb0a3994bc2b0ec331300… If you compare this with the Monoid for Maybe, it's like we're defaulting to First as the monoid instance for maps. A more useful instance, however very much a breaking change, would be to make the instance depend on a Monoid (or better yet, a Semigroup) for the values in the map: instance Monoid v => Monoid (Map k v) where mappend = unionWith mappend This lets us build up maps with values in a useful Monoid, and mappend them with gusto. Thoughts? - Nick Partridge Discussion period: 2 weeks.

15 22

Generalize filterM to Applicative
by David Feuer 25 Mar '15

25 Mar '15

Currently, filterM :: (Monad m) => (a -> m Bool) -> [a] -> m [a] filterM p = foldr go (return []) where go x r = do flg <- p x ys <- r return (if flg then x:ys else ys) We could change this to filterM :: (Applicative f) => (a -> f Bool) -> [a] -> f [a] filterM p = foldr go (pure []) where go x r = f <$> p x <*> r where f flg ys = if flg then x:ys else ys

7 12

replace definition of error with errorWithStackTrace
by Carter Schonwald 03 Jan '15

03 Jan '15

http://hackage.haskell.org/package/base-4.7.0.1/docs/GHC-Stack.html#v:error… has been in GHC for for >=1 major version, and for normal builds, acts just like error, BUT, when an error is thrown in a profiled build, it appends a stack trace with some basic source location data to the end of the error message! I think this change would benefit many! My current understanding is that the DWARF based approach to stack traces wont make it into GHC 7.10 , and while this variant would only provide extra info in profiling builds (and strictly less than the dwarf work), its something that can definitely be done in a single small patch that could easily be swapped out for that improved approach once it lands. discussion period: 2 weeks unless theres a clear unanimous agreement to make the change ASAP, OR if the stack trace error stuff is landing in 7.10 and I'm misinformed! cheers -Carter

11 19

Proposal: improve the Data.Tree API
by João Cristóvão 01 Jan '15

01 Jan '15

Hello, The Data.Tree API seems rather poor. Some research on hackage shows some additional functions being defined in very unrelated packages: http://hackage.haskell.org/package/debian-3.81/docs/Debian-Apt-Dependencies… http://hackage.haskell.org/package/hledger-lib-0.22.1/docs/Hledger-Utils.ht… I propose the addition of the following functions, that seem rather straigh forward to me: -- | get the sub-tree rooted at the first (left-most, depth-first) occurrence -- of the specified node value lookupTree :: Eq a => a -> Tree a -> Maybe (Tree a) -- | get the sub-tree rooted at the first (left-most, depth-first) value that -- matches the provided condition findTree :: (a -> Bool) -> Tree a -> Maybe (Tree a) -- | keep only the elements that match the provided condition filter :: (a -> Bool) -> Tree a -> Tree a The 'Tree' is appended in the name, to distinguish from the Foldable instances, that return the value, and not a sub-tree. Additionally, the following two functions might also be useful (even if the implementation is very simple in the second case): -- | get the sub-tree for the specified node value in the first tree in -- forest in which it occurs. lookupTreeInForest :: Eq a => a -> [Tree a] -> Maybe (Tree a) -- | Length of the tree length :: Tree a -> Int There are probably more useful functions to add, so suggestions are welcomed. Previous discussion: https://github.com/haskell/containers/issues/39#issuecomment-35799628 Discussion period: 2 weeks Cheers, João

12 35

Proposal: Add filterM or filterA to Data.Sequence
by David Feuer 31 Dec '14

31 Dec '14

This can be given exactly the same implementation as the one for lists: filterM :: (Applicative f) => (a -> f Bool) -> Seq a -> f (Seq a) filterM p = foldr go (pure empty) where go x r = f <$> p x <*> r where f flg ys = if flg then x <| ys else ys Bikeshed all you like over the name.

8 14

Proposal: Move some functions from Control.Monad to Data.List
by David Feuer 30 Dec '14

30 Dec '14

Specifically: filterM, mapAndUnzipM (unless we can sensibly and efficiently generalize it from lists to arbitrary Functors or at least Traversables, which looks like it might be possible), zipWithM, zipWithM_, replicateM, replicateM_ These functions all have to do with monads, yes, but they're about using monads with lists. Some other types are perfectly capable of doing similar things with monads. David the Feuer

2 2

Does anyone want intersperse for Data.Sequence?
by David Feuer 30 Dec '14

30 Dec '14

containers master now uses a new mechanism to implement <*> that can also be used directly to implement an efficient intersperse function corresponding to the one in Data.List. The real question is whether anyone wants one. The potential for clashing names is obviously a point against. The other is that the same asymptotic bounds (but almost certainly worse constant factors) can be obtained using intersperse x xs = drop 1 $ forwards $ Backwards (fromList [const x, id]) <*> Backwards xs

9 13

Strange errors trying to install terminfo
by Sean McAfee 29 Dec '14

29 Dec '14

Hello-- I hope my question is appropriate here; I couldn't find an obviously better forum for what is apparently a cabal issue in a fair amount of searching. I've been trying to install the terminfo package on my Ubuntu system like so: > ~$ cabal install terminfo > Resolving dependencies... > Configuring terminfo-0.4.0.0... At this point, the command hangs, and I notice my mouse cursor has transformed into a crosshair image for some reason. I can't click on anything normally, but after several clicks around the screen, the command resumes: > /home/mcafee/node-v0.10.31/configure: line 10: syntax error near unexpected token `(' > /home/mcafee/node-v0.10.31/configure: line 10: `CC = os.environ.get('CC', 'cc')' > Failed to install terminfo-0.4.0.0 > cabal: Error: some packages failed to install: > terminfo-0.4.0.0 failed during the configure step. The exception was: > ExitFailure 2 I executed this command from within an Emacs shell buffer. I tried again from an xterm window and got the same result. I tried yet again from a textual virtual terminal, and the only difference was that this line was printed several times after the "Configuring" line: > import.im6: unable to open X server `' @ error/import.c/ImportImageCommand/368. Any help resolving this issue would be most welcome.

2 2