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

Re: TDNR without new operators or syntax changes
by Jeremy . 22 May '16

22 May '16

Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.) 1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports); 2. And exactly one of these definitions matches the type of a (or the expected type of f if given); 3. Then this is the definition to use. That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it. This has nothing to do with ORF, which relies on magic type classes (although there is some overlap in what it can achieve). The primary use-case I had in mind is disambiguating name clashes between local and/or unqualified imports. Cross-posting to cafe and libraries as this doesn't seem to have attracted a lot of interest in users. Maybe it's just a boring proposal, maybe I didn't post it to the right list.

1 0

Proposal: add full complement of support for decreasing things in Data.Map
by David Feuer 20 May '16

20 May '16

Data.Map offers functions to convert from ascending lists to maps, and also offers a function to map an increasing function over the keys of a map. Equivalents for descending lists and decreasing functions are missing. I think we should add them. Any objections?

3 4

Argument order for Data.Map.adjustF
by David Feuer 20 May '16

20 May '16

I managed to find an implementation of Control.Lens.At.at for Data.Map that's fast enough to be useful. The function will be named alterF to match the name of Data.Map.alter. The remaining question is what order the arguments should go in. I had thought to follow those of alter for consistency, giving alterF :: (Functor f, Ord k) => (Maybe a -> f (Maybe a)) -> k -> Map k a -> f (Map k a) Edward Kmett thinks the ergonomics of that order are terrible, and prefers to follow lens at, giving alterF :: (Functor f, Ord k) => k -> (Maybe a -> f (Maybe a)) -> Map k a -> f (Map k a) How do other people feel about this? David Feuer

5 6

Proposal: Add a catamorphism on Trees
by David Feuer 18 May '16

18 May '16

Daniel Wagner would like to add the following straightforward function to Data.Tree. I think this is a grand idea. foldTree :: (a -> [b] -> b) -> Tree a -> b foldTree f = go where go (Node x ts) = f x (map go ts)

9 9

Re: deepseq: instance NFData (a -> b)
by Ryan Scott 08 May '16

08 May '16

I'm tentatively +1 on the idea of removing the NFData (a -> b) instance. Henning raises a good point that there are probably folks who rely on that instance to make automatic deriving of NFData. (Disclaimer: the phrase "folks" includes myself.) A similar scenario arises when deriving Show instances, for which a compromise was made by putting the Text.Show.Functions module in base, which does nothing but export an orphan Show (a -> b) instance. Perhaps, if we wanted to retain the ability to use the NFData (a -> b) instance in limited scenarios (e.g., when you're writing an application and there's no risk of leaking orphan instances to other users), then we could also introduce a Control.DeepSeq.Functions module that exports an orphan NFData (a -> b) instance, and put a giant warning at the top stating that such an instance should be used responsibly. What say ye? Ryan S.

4 6

Proposal: add chunksOf to Data.Sequence
by David Feuer 06 May '16

06 May '16

Data.List.Split.chunksOf n xs breaks up a list xs into chunks of n elements each. The internal "splitMap" function Data.Sequence uses to implement zipWith supports a simple and efficient implementation of chunksOf. All in favor, say "aye". Also, I'm still waiting for a response (any response) to my "cycleN" proposal. David

5 6

deepseq: instance NFData (a -> b)
by Henning Thielemann 01 May '16

01 May '16

According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an instance for NFData on functions was introduced without previous discussion. I find this instance pretty problematic since it has no superclasses. The correct instance would be certainly something like instance (Enumerate a, NFData b) => NFData (a -> b) where Enumerate would be a new class that allows to enumerate all values of a type. This would be hardly useful because it is pretty inefficient. I'd prefer that the instance is removed, again, or even better, be replaced by a non-implementable instance. Alternatively we should replace it by a correct implementation with corresponding superclasses. If we do the second, then we could still omit the Enumerate instance for types where enumeration of all values of the type is too expensive. I assume that the instance was added to simplify automatic derivation of NFData instances. However, I think it would be better if people insert custom deepseq implementation for the expected functions then.

7 7