- Libraries - Haskell.org

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