May 2016 - Libraries - Haskell.org

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

Proposal: add fromRight and fromLeft to Data.Either
by Anton Felix Lorenzen 12 Jun '16

12 Jun '16

When working with Either, I am often missing two simple functions: fromRight :: Either a b -> b fromLeft :: Either a b -> a It has been implemented a couple of times: http://hayoo.fh-wedel.de/?query=fromRight But I don't want to depend on yet another library for such a basic function. Could it be added? Anton

13 14

Proposal: Add // for Data.Sequence
by Alan Isaac 10 Jun '16

10 Jun '16

BACKGROUND ---------- Data.Array provides (//) for incremental array updates. Data.Sequence lacks this useful functionality. SCOPE ----- Doing this efficiently may require that Data.Sequence access Data.IntMap. (It currently does not.) David Feuer commented: We may need to add some more splitting functions to Data.IntMap, if it supports them, but we probably want to do so anyway to match up with Data.Map. SOLUTIONS ----------- David Feuer offered the following implementation sketch. (See https://github.com/haskell/containers/issues/262) Collect all requested changes into an IntMap, then use something similar to Data.Sequence.splitMap with Data.IntMap.split to spread them through the tree. David Feuer commented: splitMap itself is overkill, because we'll likely be able to preserve whole subtrees. WHAT MIGHT BREAK ---------------- No anticipated breakage.

1 1

Proposal reminder: Add functions to get consecutive elements to Data.List
by Johan Holmquist 08 Jun '16

08 Jun '16

The discussion period for this proposal is near (31 of May). So far I count 1 for and 2 against the proposal. Joachim Breitner made a good enumeration of some advantages of adding these to base. Here is an enumeration of pros: * Availability in Data.List gives this pattern a common name. * A common name for this makes code easier to read and decreases the risk of getting the definition wrong. * The argument won't have to be repeated, hence making it easier to chain the functions. * List-fusion potential. Tobias Florek pointed out that `zip <*> tail` can be used to define this inline without the need for repeating the argument and made a reference to the Fairbairn threshold. This is elegant, but I am afraid that people might consider this obscure code golfing if used. Cheers Johan Holmquist ---------- Forwarded message ---------- From: Henning Thielemann <lemming(a)henning-thielemann.de> Date: 2016-04-13 13:28 GMT+02:00 Subject: Re: Proposal: Add functions to get consecutive elements to Data.List To: Johan Holmquist <holmisen(a)gmail.com> Cc: Haskell Libraries <libraries(a)haskell.org> On Wed, 13 Apr 2016, Johan Holmquist wrote: It is not strictly more general because it cannot handle empty sequences. > Think of it as if it handles the non-[] case.

7 12

Re: Proposal: add fromRight and fromLeft to Data.Either
by David Feuer 31 May '16

31 May '16

No one wants to remove fromMaybe. In fact, it could serve as a template for total fromLeft and fromRight: fromLeft :: b -> (a -> b) -> Either a x -> b fromRight :: b -> (a -> b) -> Either x a -> b On May 21, 2016 8:55 AM, "Edward Kmett" <ekmett(a)gmail.com> wrote: I'm personally -1 on this. A large portion of the community is vehemently against adding new partial functions, and they have to share base with the rest of us. I'd say more people want to remove fromMaybe, head, tail, etc. than want to double down on the pattern at this time. -Edward On Fri, May 20, 2016 at 4:08 PM, Anton Felix Lorenzen <anfelor(a)posteo.de> wrote: > When working with Either, > I am often missing two simple functions: > fromRight :: Either a b -> b > fromLeft :: Either a b -> a > > It has been implemented a couple of times: > http://hayoo.fh-wedel.de/?query=fromRight > > But I don't want to depend on yet another library > for such a basic function. > > Could it be added? > > Anton > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

10 14

Discussion: Add total indexing function to Data.Sequence
by David Feuer 31 May '16

31 May '16

Data.Sequence offers index :: Seq a -> Int -> a which throws an error if the index is out of range. I'd like to add something like indexMay :: Seq a -> Int -> Maybe a Aside from the safety factor, indexMay would offer a way to ensure the indexing occurs at a particular time. Much like Data.Vector.indexM, this can help prevent memory leaks. In fact, an analogue of indexM can be implemented in terms of indexMay: indexM :: Applicative m => Seq a -> Int -> m a indexM xs i = case xs `indexMay` i of Nothing -> error "indexM: index out of range" Just x -> pure x

8 13

Proposal: Add `maxOn` and `minOn` functions to Data.Ord
by Daniel Díaz Casanueva 30 May '16

30 May '16

I think these are useful in general, and that they would make a good addition to `Data.Ord`. The names are inspired by `sortOn`. Definitions: ``` minOn :: Ord b => (a -> b) -> a -> a -> a minOn f x y = case comparing f x y of LT -> x _ -> y maxOn :: Ord b => (a -> b) -> a -> a -> a maxOn f x y = case comparing f x y of GT -> x _ -> y ``` These don't need to be the exact definitions, but they convey the semantics I'm looking for.

6 8

Proposal: Add insertAt to Data.Sequence
by David Feuer 30 May '16

30 May '16

I've come up with an implementation of insertAt :: Int -> a -> Seq a -> Seq a -- Defined to be equivalent to insertAt i x xs | i < 0 || i > length xs = error "insertAt: index out of range" | otherwise = take i xs <> singleton x <> drop i xs that inserts the given element at the given index with very little tree restructuring. I came up with the vague notion that it might be interesting to try to do something like this early last year, but I wasn't sure how at the time. I largely forgot about it until today, when someone on StackOverflow pointed to the issue I'd opened and asked if it would be implemented, presumably because he wants it. What do y'all think? David Feuer

5 5

Proposal: add foldMapWithIndex to Data.Sequence
by David Feuer 23 May '16

23 May '16

foldMapWithIndex :: Monoid m => (Int -> a -> m) -> Seq a -> m This would match both Data.Map.foldMapWithKey and Control.Lens.Indexed.ifoldMap, filling out the indexed fold menagerie. Annoyingly, the straightforward implementation I've come up with is rather slow when used with Endo to implement either foldlWithIndex or foldrWithIndex. I suspect the polymorphic recursion inherent in these sequences is blinding GHC's optimizer. Oh well.

2 1