- Libraries - Haskell.org

Re: Request: Add sortOn to Data.Sequence
by David Feuer 10 Jun '16

10 Jun '16

I think thIs is an interesting idea, generally. There seem to be two situations that may call for separate functions. If the "key" type can be stored in an unboxed mutable array, then it seems likely desirable to sort using such an array. Otherwise, we can use the existing sortBy as suggested. On Jun 10, 2016 12:30 PM, "Alan Isaac" <alan.isaac(a)gmail.com> wrote: REQUEST ------- The request is to add `sortOn` to Data.Sequence. `sortOn f` would be equivalent to `sortBy . comparing f`, but would offer a performance advantage by using a Schwartzian transform to only evaluate `f` once for each element in the input sequence. BACKGROUND ---------- Adding `sortOn` to `Data.List` was proposed at least as early as 2008: http://www.haskell.org/pipermail/libraries/2008-October/010797.html It was added in 2014, in response to this feature request: https://ghc.haskell.org/trac/ghc/ticket/9004 RATIONALES ---------- - convenience - performance: faster than `sortBy` - safety: encourages (although does not require) reliance on existing instances of Ord - interface consistency (specifically, when comparing to Data.List) Comment: it is certainly possible to pick at each of these rationales. See the discussion here: http://stackoverflow.com/questions/37691898/why-is-sortby-so-oddly-unconstr… SCOPE ----- Introduces no new dependencies except possibly on `Data.Ord.comparing`. SOLUTIONS ----------- The implementation in Data.List is:: sortOn :: Ord b => (a -> b) -> [a] -> [a] sortOn f = map snd . sortBy (comparing fst) . map (\x -> let y = f x in y `seq` (y, x)) An analogous implementation is possible for Data.Sequence. However, this request does not propose a specific implementation. WHAT MIGHT BREAK ---------------- No anticipated breakage. _______________________________________________ Libraries mailing list Libraries(a)haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

2 1

foldl' semantic change
by David Feuer 10 Jun '16

10 Jun '16

The semantics of foldl' for lists were changed between base 4.7 and base 4.8. Specifically, foldl' became strict in the initial value of its accumulator. I opened http://ghc.haskell.org/trac/ghc/ticket/12173 to report this. The change was entirely accidental, according to Joachim Breitner. However, Duncan Coutts indicated he is pleased with the change. I don't personally have a dog in this race, but I feel very strongly about three things: 1. The strictness should be fully documented, both in Haddock and the next Haskell Report (the Haskell 2010 Report does not go into sufficient detail to support either choice). 2. There should be *one* meaning of foldl' in base. Thus the default Foldable instance should match the ones for lists and arrays. 3. The containers package should be consistent with base in this regard.

5 7

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

Proposal: Left-Associative Semigroup Operator Alias in "Data.Semigroup"
by Herbert Valerio Riedel 07 Jun '16

07 Jun '16

Hello! In short, the right-associative fixity of (Data.{Monoid,Semigroup}.<>) subtly conflicts with definitions of (<>) in pretty printing APIs, for which the left-associative variant is sometimes desirable. This subtle overloading of (<>) is error-prone, as one has to remember which version of (<>) is currently in scope in order to be able to reason about non-trivial expressions involving this operator. This proposal is an attempt to resolve this unfortunate and confusing situation by completing the `Semigroup`/`Monoid` vocabulary with a standard left-associative alias. Please see https://ghc.haskell.org/trac/ghc/wiki/Proposal/LeftAssocSemigroupOp for more details. Discussion period: 4 weeks

6 5

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